Design Thinking: Building a Design System for an Existing Product

Building a design system from scratch is one thing. Building one for a product that already exists — with established patterns, legacy decisions, and a live user base — is an entirely different challenge. You're not starting with a blank canvas; you're reverse-engineering consistency from years of accumulated design decisions, then charting a path forward that improves the product without breaking what already works.

Design thinking provides the ideal framework for this challenge. Its human-centered, iterative approach helps teams navigate the complexity of existing products while ensuring the resulting design system serves real needs — not just theoretical ideals. This guide walks through how to apply each phase of design thinking to build a practical, adoptable design system.

Why Existing Products Need Design Systems

Most products that have been in market for more than a year suffer from what we call design drift — the gradual accumulation of inconsistencies that occurs when multiple designers and developers build features over time without a shared source of truth.

Common symptoms of design drift include:

• Multiple button styles: Different pages use different button sizes, colors, and border radii for the same type of action
• Inconsistent spacing: Padding and margins vary between similar components across the product
• Color proliferation: What started as a 6-color palette has grown to 30+ distinct values
• Typography chaos: Font sizes, weights, and line heights vary without a clear hierarchy
• Duplicated components: Multiple implementations of the same pattern (modals, dropdowns, form fields) with subtle differences

A design system addresses these issues by establishing a single source of truth for design decisions. But building one for an existing product requires understanding what exists today before defining what should exist tomorrow.

Phase 1: Empathize — Understanding Your Users

In design thinking, empathy means understanding the people you're designing for. For a design system, your primary users are designers and developers — the people who will use the system daily to build and maintain the product.

Interviewing Your Team

Start by talking to the people who will use the design system. Key questions include:

• For designers: What's your current workflow? Where do you spend the most time? What components do you recreate most often? Where do you struggle with consistency?
• For developers: What's hardest to implement from designs? Where do you find yourself writing custom CSS for things that should be standardized? How do you handle responsive behavior?
• For product managers: Where do users report confusion or inconsistency? Which features take longer to ship than expected? Where does the product feel "off" compared to competitors?

Conducting a Visual Audit

A visual audit is the most critical discovery activity. Systematically screenshot every screen in your product and catalog the visual patterns you find. Tools like Figma make this process manageable:

Document everything without judgment. The goal is to understand the current state completely before making decisions about the future state.

Phase 2: Define — Setting Clear Goals

With a thorough understanding of the current state and team pain points, you can now define what your design system needs to accomplish. This is where you transform observations into actionable goals.

Establishing Design Principles

Design principles guide every decision in your design system. They should be specific enough to resolve disagreements and broad enough to apply across the entire product. Examples:

• Clarity over cleverness: When in doubt, choose the more obvious solution. Our users are completing tasks, not admiring our interface.
• Consistent, not uniform: The same component should look and behave the same everywhere, but different contexts may require different components.
• Progressive complexity: Simple tasks should have simple interfaces. Complexity should only appear when the user needs it.
• Accessible by default: Every component must meet WCAG 2.1 AA standards. Accessibility is not an afterthought.

Defining Your Token System

Design tokens are the foundational building blocks of your design system — the smallest, most atomic decisions that everything else is built upon:

• Color tokens: Consolidate your audited colors into a rationalized palette. Map semantic meanings (primary, secondary, success, warning, error) to specific color values.
• Typography tokens: Define a type scale with clear hierarchy. Most products need 6-8 distinct type styles, not 30.
• Spacing tokens: Establish a spacing scale (typically based on 4px or 8px increments) that creates consistent rhythm throughout the interface.
• Border radius tokens: Standardize corner rounding to 2-3 values (small, medium, large).
• Shadow tokens: Define elevation levels for layered interfaces.

Prioritizing Components

You can't build everything at once. Prioritize components based on:

• Frequency of use: Buttons, inputs, and typography are used on virtually every screen
• Inconsistency severity: Components with the most variation across the product benefit most from standardization
• Development effort: Start with components that are relatively simple to implement
• Impact on user experience: Standardizing navigation and form elements has an outsized impact on perceived quality

Phase 3: Ideate — Exploring Solutions

With clear goals and priorities, the ideation phase is about exploring how your components should look and behave. This is where you make design decisions that will define the product's visual language going forward.

Component Anatomy

For each component, define its anatomy — the parts that make it up and how they relate to each other:

• Structure: What elements does the component contain? (icon, label, description, etc.)
• Variants: What variations exist? (primary, secondary, ghost, destructive buttons)
• States: How does the component respond to interaction? (default, hover, active, focused, disabled, loading)
• Sizes: What size options are needed? (small, medium, large)
• Responsive behavior: How does the component adapt to different screen sizes?

Naming Conventions

A consistent naming system is essential for adoption. The structure should flow from broad to specific:

component / variant / state / size
button / primary / hover / medium
input / text / focused / large
card / elevated / default / responsive

This hierarchical naming makes components easy to find and understand, even for team members encountering the system for the first time.

Phase 4: Prototype — Building the System

Prototyping a design system means building the actual components in your design tool and beginning to document usage guidelines. This is where theory becomes practice.

Building in Figma

Modern design tools like Figma make design system creation significantly more manageable with features like:

• Components and variants: Create a single component with multiple variants (size, state, theme) that designers can swap between
• Auto layout: Define spacing and alignment rules that components maintain as content changes
• Constraints: Control how elements resize and reposition within components
• Styles: Define reusable color, typography, and effect styles that can be updated globally
• Component properties: Expose boolean, text, and instance swap options that make components flexible without being fragile

Documentation

Every component needs documentation that covers:

• When to use: The appropriate context for this component
• When NOT to use: Common misuses and better alternatives
• Anatomy: Visual breakdown of the component's parts
• Variants: Available options and when to use each
• Accessibility: Keyboard behavior, ARIA attributes, screen reader considerations
• Code reference: How the component maps to the development implementation

Phase 5: Test — Validating and Iterating

A design system is only as good as its adoption. Testing means putting the system in front of real users (designers and developers) and measuring whether it solves the problems you identified in the empathy phase.

Adoption Metrics

Track these metrics to understand how well your design system is being adopted:

• Component coverage: What percentage of the UI is built with design system components?
• Design-to-code consistency: How closely do implemented features match the design system specifications?
• Time to design: Are designers creating screens faster with the system?
• Custom overrides: How often are developers overriding design system styles? (Lower is better)
• New component requests: Are gaps being identified and filled through a governed process?

Iteration Cadence

A design system is never "done." Establish a regular iteration cadence:

• Weekly: Review component requests and bug reports
• Monthly: Ship minor updates (new variants, documentation improvements)
• Quarterly: Major releases (new components, breaking changes, visual refreshes)

Common Pitfalls to Avoid

1. Trying to Do Everything at Once

The biggest mistake teams make is trying to systematize the entire product in one pass. Start with the most impactful components (buttons, typography, colors, form elements) and expand from there. A small, well-adopted system is infinitely more valuable than a comprehensive system nobody uses.

2. Designing in Isolation

A design system built by designers alone will frustrate developers. A system built by developers alone will lack design rigor. Cross-functional collaboration from day one ensures the system works for everyone.

3. Ignoring the Existing Codebase

Your design system must account for the reality of the existing codebase. If the product uses specific CSS frameworks, component libraries, or architectural patterns, the design system should work with them, not against them.

4. Over-Engineering Components

Resist the urge to make every component infinitely configurable. Components should be flexible enough to cover real use cases but opinionated enough to enforce consistency. When in doubt, fewer options are better.

Getting Started: A Practical Roadmap

If you're ready to build a design system for your existing product, here's a practical 12-week roadmap:

The key insight of design thinking applied to design systems is this: you're not just organizing pixels — you're solving human problems. The designers who struggle with inconsistency. The developers who waste time guessing at specifications. The users who experience a disjointed product. A great design system serves all of them.

Need help building a design system for your product? Our UX services team has deep experience creating scalable, adoptable design systems for existing products. Get in touch to discuss your project.