Building a Unified Design System
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.
The Challenge
Before GUI Guidelines 2.0 existed, our product ecosystem faced several issues:
Visual inconsistency
Buttons, tables, forms, and states all looked different across products and features.
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
Slow reviews & rework
Design–dev alignment took longer because UI debates happened repeatedly on every feature.
No onboarding reference
New designers and developers had no source of truth to understand how the product should look or behave.
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.
Goal & Approach
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.
Step 1: Audit (200+ Screens)
Step 1: Audit (200+ Screens)
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
Step 1: Audit (200+ Screens)
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
Step 1: Audit (200+ Screens)
Step 4: Designing Components
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
Step 6: Rollout + Team Training
Step 4: Designing Components
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
Step 6: Rollout + Team Training
Step 6: Rollout + Team Training
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 6: Rollout + Team Training
Step 6: Rollout + Team Training
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.
Core ComponenT
Key Elements Included in Guidelines 2.0
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
Foundations
Foundations
- Color system
- Typography
- Spacing scale
- Grid layouts
- Iconography
Components
Foundations
Foundations
- Buttons
- Forms & inputs
- Dropdowns
- Cards
- Tables
- Tabs
- Modals
- Pagination
- Tooltips
- Tags & badges
Patterns
Foundations
Accessibility
- 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
Documentation
- Usage guidelines
- Best practices
- Do/Don’t
- When to use / When not to use
Impact
Consistency Across the ProductThe UI finally looked unified, regardless of which team worked on the feature.
Faster Design–Dev Handoff
Developers knew exactly which component to use.
Designers stopped redrawing the same elements.
Fewer UI Bugs
QA reported fewer inconsistencies and visual defects.
Less Rework & Fewer Debates
Teams aligned faster because decisions were documented.
Predictable Behavior = Predictable Experience
Users experienced fewer surprises and more familiarity across features.
Faster Onboarding
New designers and developers understood the product within days, not months.
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.
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.