Kavya Jyothi

Kavya JyothiKavya JyothiKavya Jyothi
  • Home
  • My works
  • More
    • Home
    • My works

Kavya Jyothi

Kavya JyothiKavya JyothiKavya Jyothi
  • Home
  • My works

Design Guidelines 2.0

A unified design system that brought clarity and consistenc

1. Background

Role: Senior Product Designer
Skills: Design Systems, UI Audit, Component Architecture, Collaboration, Documentation, Accessibility
Timeline: 6–8 months
Outcome: A scalable, developer-friendly design system (“GUI Guidelines 2.0”) that dramatically improved consistency, alignment, and delivery speed across product teams.

Summary:
When I joined the team, every product looked and behaved differently. Developers were designing UI on the fly, components existed in 5+ variations, and teams had no shared visual language.
GUI Guidelines 2.0 was created to solve this — a system that united designers, developers, and PMs around one clear, scalable set of rules.

2. Background & Challenge

Before GUI Guidelines 2.0 existed, our product ecosystem faced several issues:


1. Visual inconsistency

Buttons, tables, forms, and states all looked different across products and features.


2. Developers designing independently

In the absence of guidelines, developers made UI decisions themselves.
This led to:

  • mismatched components 
  • unpredictable interactions 
  • duplicated patterns 
  • design drift over time
     

3. Slow reviews & rework

Design–dev alignment took longer because UI debates happened repeatedly on every feature.


4. No onboarding reference

New designers and developers had no source of truth to understand how the product should look or behave.


5. Low accessibility awareness

Contrast, spacing, and interaction states lacked structure, making the product harder to use.


The root issue:
Everyone had good intentions — but no shared rules.

3. The Goal

Create a practical, scalable, developer-first design system that:

  • unifies UI across all products 
  • reduces ambiguity and rework 
  • speeds up design–dev handoff 
  • creates predictable behavior patterns 
  • improves accessibility 
  • supports long-term scalability
     

Not a “beautiful Figma library,”
but a real system teams actually use.

Approach Step 1: Audit (200+ Screens)

Approach Step 1: Audit (200+ Screens)

Approach Step 1: Audit (200+ Screens)

I reviewed existing screens from multiple modules and identified:


  • different button styles
  • inconsistent table types 
  • different form layouts 
  • inconsistent spacing 
  • inconsistent typography 
  • different alert behaviors 
  • mismatched icons
     

This audit helped us understand the scale of inconsistency and which areas needed the most structure.

Step 2: Pattern Grouping

Approach Step 1: Audit (200+ Screens)

Approach Step 1: Audit (200+ Screens)

I grouped components into logical categories:


  • Core components (buttons, inputs, dropdowns)
  • Data components (tables, cards, lists)
  • Layout patterns (headers, grids, spacing rules) 
  • Interaction states (hover, focus, disabled, errors) 
  • Feedback patterns (alerts, toast messages)
     

This allowed us to see the full “inventory” and understand missing or redundant patterns.

Step 3: Co-Design

Approach Step 1: Audit (200+ Screens)

Step 4: Designing Components (The 2.0 Library)

Instead of designing in isolation, I collaborated closely with the engineering team.


We discussed:

  • what was feasible 
  • what needed to be simplified 
  • how components should behave 
  • naming conventions 
  • rules that make development easier
     

This ensured the system was developer-approved, not designer-imposed.

Step 4: Designing Components (The 2.0 Library)

Step 5: Documentation (The Real Secret)

Step 4: Designing Components (The 2.0 Library)

I redesigned each component with:


  • consistent spacing 
  • clear visual hierarchy 
  • accessible color contrast 
  • predictable behavior states 
  • simplified variations 
  • responsive rules 

Each component came with:

  • usage guidelines
  • do/don’t examples 
  • behavior rules 
  • anatomy diagrams 
  • code-friendly naming

Step 5: Documentation (The Real Secret)

Step 5: Documentation (The Real Secret)

Step 5: Documentation (The Real Secret)

GUI Guidelines 2.0 wasn’t only visuals — it was documentation clarity.


I created:

  • a component catalog
  • style foundations 
  • behaviour rules 
  • accessibility guidelines
  • contribution model
  • versioning standards
     

This helped everyone understand how decisions are made, not just what the component looks like.

Step 6: Rollout + Team Training

Step 5: Documentation (The Real Secret)

Step 5: Documentation (The Real Secret)

I held short onboarding sessions with:

  • developers 
  • QAs 
  • PMs 
  • designers
     

We walked through:

  • usage 
  • common mistakes 
  • component examples 
  • how to request new patterns
     

This made adoption quick and smooth.

5. What Guidelines 2.0 Includes

5. What Guidelines 2.0 Includes

5. What Guidelines 2.0 Includes

The GUI Guidelines 2.0 system established a unified visual and interaction standard across all product teams. It includes core design principles, scalable components, interaction patterns, accessibility rules, and developer-ready specifications to ensure consistency and speed across the entire ecosystem. 


Foundations

5. What Guidelines 2.0 Includes

5. What Guidelines 2.0 Includes

  • Color system 
  • Typography 
  • Spacing scale
  • Grid layouts
  • Iconography

Components

5. What Guidelines 2.0 Includes

Components

  • Buttons 
  • Forms & inputs 
  • Dropdowns 
  • Cards 
  • Tables 
  • Tabs 
  • Modals 
  • Pagination 
  • Tooltips 
  • Tags & badges

Patterns

Accessibility

Components

  • Error & validation rules
  • Loading states
  • Empty states
  • Feedback messages
  • Navigation templates

Accessibility

Accessibility

Accessibility

  • Contrast rules
  • Focus indicators
  • Touch targets 
  • Keyboard navigation principles

Documentation

Accessibility

Accessibility

  • Usage guidelines
  • Best practices 
  • Do/Don’t 
  • When to use / When not to use

6. Impact

1. Consistency Across the Product

The UI finally looked unified, regardless of which team worked on the feature.


2. Faster Design–Dev Handoff

Developers knew exactly which component to use.
Designers stopped redrawing the same elements.


3. Fewer UI Bugs

QA reported fewer inconsistencies and visual defects.


4. Less Rework & Fewer Debates

Teams aligned faster because decisions were documented.


5. Predictable Behavior = Predictable Experience

Users experienced fewer surprises and more familiarity across features.


6. Faster Onboarding

New designers and developers understood the product within days, not months.

7. What I Learned

  • A design system succeeds only when developers are co-owners. 
  • Consistency is not about visuals — it’s about trust. 
  • Documentation matters as much as the components themselves. 
  • You don’t need fancy design to make a system useful — clarity wins. 
  • The best design systems grow with the team, not ahead of them.
  • GUI Guidelines 2.0 transformed our product into a unified, scalable, developer-friendly system. 

Validation of Impact

Feedback note from the Principal Architect acknowledging the impact of my Design Guidelines 2.0 work.

To respect confidentiality, I cannot share the actual design system artifacts, components, or internal patterns used in the semiconductor tools. However, here is a verified testimonial from the Principal Architect who led the engineering direction on this product. His feedback highlights the clarity, usability, and impact of my design work without exposing sensitive system details.

← View Other Projects

This website uses cookies.

We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.

Accept