Principles of UX / UI (Product Design): Design Systems (Component Libraries, Tokens, Style Guides)

Design Systems (Component Libraries, Tokens, Style Guides)

Design Systems Study Guide

For aspiring product designers, graphic designers transitioning to UX, and bootcamp students

What This Is

A design system is a single source of truth for all UI elements (buttons, typography, colors, spacing) and rules (interaction patterns, accessibility standards) that keep a product consistent, scalable, and efficient. Think of it like LEGO: instead of carving each brick from scratch, you reuse pre-made pieces to build faster and avoid mismatched designs.

Why it matters:
- Saves time: No more redesigning the same button for every screen.
- Improves usability: Consistent patterns reduce cognitive load (e.g., all "Submit" buttons look and behave the same).
- Enables collaboration: Developers, designers, and PMs speak the same language.

Real-world example:
A hospital’s patient portal uses a design system to ensure the "Book Appointment" button is the same color, size, and hover state across desktop, mobile, and kiosks. This reduces errors (e.g., patients accidentally clicking "Cancel" instead of "Confirm") and speeds up development when adding new features like telehealth scheduling.

Key Terms & Principles

• Design Tokens
  Definition: Variables that store design decisions (e.g., colors, spacing, typography) in code-friendly formats (JSON, CSS). Tokens make global updates easy—change a token once, and it updates everywhere.
  Example: A token named --primary-blue: #2A5BD7 is used for all buttons, links, and icons. When rebranding, you only update the token, not every instance.

• Component Library
  Definition: A collection of reusable UI elements (buttons, modals, cards) built in tools like Figma or Storybook. Components include variants (e.g., primary/secondary buttons) and states (hover, disabled).
  Example: A "Card" component in Figma has slots for an image, title, and CTA button. Designers drag it into mockups instead of redrawing it each time.

• Atomic Design (Brad Frost)
  Definition: A methodology for building design systems in layers:

• Atoms (basic elements like buttons, icons)
• Molecules (groups of atoms, like a search bar + button)
• Organisms (complex sections, like a header with navigation)
• Templates (page layouts)

• Pages (final screens with real content).
  Example: A "Product Card" (molecule) combines an image (atom), title (atom), and "Add to Cart" button (atom).

• Style Guide
  Definition: A document (often a PDF or web page) that defines visual rules: typography, color palettes, logos, and usage guidelines. Less interactive than a design system but useful for branding.
  Example: A style guide for a bank might specify that body text uses Inter 16px, with a line height of 1.5x, and that the logo must never be stretched.

• Design System vs. Style Guide
  Key difference: A style guide is static (colors, fonts, logos). A design system is dynamic (components, tokens, code snippets, interaction rules).
  Example: A style guide says "Use #FF5733 for CTAs." A design system provides the actual CTA button component in Figma and React, with hover/focus states.

• Heuristic: Consistency & Standards (Nielsen’s #4)
  Definition: Users should feel familiar with your product’s patterns. Follow platform conventions (e.g., iOS vs. Android) and internal consistency (e.g., all error messages use the same red).
  Example: If your app uses a hamburger menu on mobile, don’t switch to a bottom tab bar on one screen—it confuses users.

• Heuristic: Recognition Over Recall (Nielsen’s #6)
  Definition: Minimize memory load by making actions visible (e.g., showing a dropdown menu instead of requiring users to remember commands).
  Example: A design system includes a "Date Picker" component so users don’t have to type dates manually (reducing errors).

• WCAG Contrast Ratio
  Definition: Text and interactive elements must have sufficient contrast against their background for readability. WCAG AA requires:

• Normal text: 4.5:1 (e.g., black text on white).

• Large text (18.66px+ bold or 24px+ regular): 3:1.
  Example: A light gray button (#CCCCCC) on a white background fails contrast. Use a darker gray (#757575) or add a border.

• 8-Point Grid System (Spacing)
  Definition: A spacing scale based on multiples of 8px (e.g., 8px, 16px, 24px) to create consistent layouts. Works well with most screen densities.
  Example: Padding inside a card is 16px (2x8), and the gap between cards is 24px (3x8).

• Design System Governance
  Definition: Rules for maintaining and updating the system. Includes versioning, contribution guidelines, and a process for adding new components.
  Example: A team uses a RFC (Request for Comments) process: Designers propose a new "Notification Banner" component, gather feedback, then add it to the library.

• Design System Documentation
  Definition: Instructions for using the system, often in tools like Storybook, Zeroheight, or Notion. Includes do’s/don’ts, code snippets, and usage examples.
  Example: A "Tooltip" component’s docs show how to trigger it (hover/click), max width, and when not to use it (e.g., for critical alerts).

Step-by-Step Process Flow

1. Audit the Existing Product

Goal: Identify inconsistencies and gaps.
Actions: - Inventory UI elements: List all buttons, inputs, cards, etc. in a spreadsheet or Figma board. Use plugins like Auditor to auto-generate a list.
- Spot inconsistencies: Highlight mismatched colors, fonts, or spacing (e.g., three different "Primary Blue" shades).
- Map to user flows: Note where inconsistencies cause friction (e.g., a "Save" button looks different on mobile vs. desktop).

Figma Tip: Use Auto Layout to test if components scale predictably. If a button’s text wraps awkwardly, adjust padding or min-width.

2. Define Foundations (Tokens & Styles)

Goal: Create a scalable base layer.
Actions: - Colors: Pick a palette (5–10 colors max) and assign roles (e.g., --primary: #2A5BD7 for CTAs, --error: #D32F2F for alerts). Use tools like Coolors or Adobe Color.
- Typography: Define a type scale (e.g., h1: 32px/1.2, body: 16px/1.5). Limit to 2–3 fonts (e.g., Inter for UI, Playfair Display for headings).
- Spacing: Adopt the 8-point grid (e.g., 8px, 16px, 24px). Use Figma’s spacing tokens to enforce consistency.
- Elevation: Define shadow styles for depth (e.g., shadow-sm for cards, shadow-lg for modals).

Example:

Color Tokens:
--primary: #2A5BD7
--primary-hover: #1E40AF
--text-primary: #1F2937
--text-secondary: #6B7280

3. Build Components (Atomic Design)

Goal: Create reusable, flexible UI elements.
Actions: - Start with atoms: Build buttons, inputs, icons, and typography styles. Use Figma’s Variants to group states (e.g., Primary Button / Hover / Disabled).
- Combine into molecules: Create search bars, dropdowns, and cards. Use Auto Layout for responsive behavior.
- Document rules: Add notes in Figma (e.g., "Use Primary Button for main CTAs only").

Figma Tip: Use Component Properties to let designers toggle states (e.g., Icon Left/Right for buttons) without detaching instances.

4. Test & Validate

Goal: Ensure components work in real contexts.
Actions: - Usability test components: Ask users to complete tasks (e.g., "Find and click the ‘Submit’ button"). Watch for confusion (e.g., users ignoring a disabled button).
- Accessibility audit: Use Stark or Axe to check contrast, keyboard navigation, and screen reader compatibility.
- Developer handoff: Export tokens to JSON/CSS and test components in Storybook. Verify that hover/focus states work.

Example Test Scenario:

"You’re booking a doctor’s appointment. How would you confirm your time slot?" - Success: User clicks the "Confirm" button (primary CTA).
- Failure: User hesitates or clicks "Cancel" (button may look too similar).

5. Document & Govern

Goal: Make the system usable for the whole team.
Actions: - Write guidelines: Use Zeroheight or Notion to document: - When to use each component (e.g., "Use Alert for errors, Toast for success messages").
- Do’s/don’ts (e.g., "Don’t use Primary Button for destructive actions").
- Code snippets (e.g., React/HTML examples).
- Set up a contribution process: Define how new components are proposed (e.g., via GitHub issues or Figma comments).
- Version control: Use semantic versioning (e.g., v1.2.0) and changelogs to track updates.

Example Documentation:

Button Component
- Primary Button: Use for main CTAs (e.g., "Submit").
- Secondary Button: Use for less critical actions (e.g., "Cancel").
- Disabled State: Opacity 50%, cursor: not-allowed.
- Do: Keep text concise (1–3 words).
- Don’t: Use for navigation (use `Link` instead).

6. Maintain & Evolve

Goal: Keep the system alive and relevant.
Actions: - Regular audits: Every 3–6 months, review components for inconsistencies or unused elements.
- Gather feedback: Survey designers/developers on pain points (e.g., "The dropdown component is hard to customize").
- Deprecate old components: Archive unused components with a clear migration path (e.g., "Use NewCard instead of LegacyCard").

Figma Tip: Use Figma’s Library Analytics to track component usage and identify unused elements.

Common Mistakes

Mistake 1: Building Components in Isolation

What happens: Designers create components without testing them in real layouts, leading to awkward spacing or misaligned elements.
Correction: - Design in context: Build components inside a template (e.g., a dashboard or form) to spot issues early.
- Use real content: Avoid "Lorem ipsum"—test with actual text lengths (e.g., a long German word breaking a button).

Example: A "Card" component looks great alone but overlaps with other cards when placed in a grid. Fix by adding Auto Layout and testing in a real layout.

Mistake 2: Over-Engineering the System

What happens: Creating too many variants (e.g., 10 button styles) or overly complex components that no one uses.
Correction: - Start small: Begin with 3–5 core components (button, input, card) and expand as needed.
- Follow the 80/20 rule: 80% of use cases should be covered by 20% of components. Add complexity only when necessary.

Example: Instead of a "Button with Icon Left/Right/Top/Bottom," start with "Button with Icon Left" (most common use case).

Mistake 3: Ignoring Accessibility

What happens: Components fail contrast checks, lack keyboard navigation, or don’t work with screen readers.
Correction: - Bake in accessibility: Test components with: - Keyboard-only navigation (can you tab through all interactive elements?).
- Screen readers (e.g., VoiceOver or NVDA—does the button announce its state?).
- Color blindness simulators (e.g., Stark or Color Oracle).
- Document requirements: Add accessibility notes to component docs (e.g., "This modal must trap focus").

Example: A "Toggle Switch" component fails because it’s not keyboard-operable. Fix by adding role="switch" and aria-checked attributes.

Mistake 4: Not Involving Developers Early

What happens: Designers build components that are impossible to implement (e.g., animations that don’t exist in the codebase).
Correction: - Pair with devs: Hold a design-dev sync to align on: - Naming conventions (e.g., ButtonPrimary vs. BtnPrimary).
- Technical constraints (e.g., "We can’t support gradient borders in CSS").
- Handoff tools (e.g., Storybook for React components).
- Use design tokens: Export tokens to code (e.g., via Style Dictionary) to ensure consistency.

Example: A designer creates a "Floating Action Button" with a complex shadow effect, but the dev team can’t replicate it in CSS. Solution: Simplify the shadow or use a pre-built component from the code library.

Mistake 5: Treating the Design System as "Done"

What happens: The system becomes outdated as the product evolves, leading to "shadow design" (designers creating one-off components).
Correction: - Assign an owner: Designate a Design System Lead (even part-time) to maintain the system.
- Schedule regular updates: Plan quarterly audits to: - Remove unused components.
- Add new components based on product needs.
- Update tokens for rebranding or new features.
- Encourage contributions: Let designers/developers propose changes via a RFC process (e.g., GitHub issues or Figma comments).

Example: A team adds a "Dark Mode" feature but forgets to update the design system. Result: Inconsistent dark mode styles across the app. Fix: Add dark mode tokens and update all components.

Design Interview / Portfolio Tips

1. Show Your Process, Not Just the Output

What interviewers want: Evidence that you can build and maintain a design system, not just use one.
How to showcase it: - Portfolio case study: Include: - Audit phase: Screenshots of the "before" (inconsistent UI) and "after" (unified system).
- Token/component creation: Show your Figma file with tokens, variants, and Auto Layout.
- Testing: Describe how you validated components (e.g., "Usability tested the dropdown with 5 users; 4/5 completed the task without errors").
- Documentation: Link to a Notion/Zeroheight doc or include a screenshot of your component guidelines.
- Interview storytelling: Use the STAR method (Situation, Task, Action, Result) to describe a design system challenge.
Example:

"At [Company], our checkout flow had 3 different ‘Continue’ buttons. I audited the UI, created a unified button component with variants, and documented usage rules. This reduced dev time by 30% and improved conversion by 12%."

2. Explain the "Why" Behind Your Decisions

What interviewers want: Proof that you understand design principles and business impact.
How to showcase it: - Link to heuristics: Explain how your system addresses Nielsen’s heuristics (e.g., "Consistent buttons reduce cognitive load—Nielsen’s #4").
- Quantify impact: Use metrics like: - "Reduced dev time by X% by reusing components." - "Improved accessibility compliance from WCAG AA to AAA." - "Decreased design debt by eliminating 20+ one-off components." - Show trade-offs: Discuss compromises (e.g., "We limited the color palette to 8 colors to balance brand flexibility and consistency").

Example Portfolio Snippet:

"I chose an 8-point grid for spacing because it aligns with most screen densities and reduces decision fatigue for designers. This improved layout consistency by 40% (measured via design QA audits)."

3. Differentiate Between Similar Terms

Tricky distinctions interviewers test: | Term 1 | Term 2 | Key Difference | |--------|--------|----------------| | Design System | Style Guide | A design system is interactive (components, tokens, code); a style guide is static (colors, fonts, logos). | | Component Library | Pattern Library | A component library has reusable UI elements (buttons, cards); a pattern library has reusable solutions (e.g., "How to design a checkout flow"). | | Design Tokens | CSS Variables | Tokens are design decisions (e.g., --spacing-md: 16px); CSS variables are the code implementation. Tokens can be used in Figma and code. | | Atomic Design | Modular Design | Atomic Design is a specific methodology (atoms → molecules → organisms); modular design is a broader approach to reusable parts. |

How to answer in interviews:

"A style guide is like a brand’s rulebook—it defines colors and fonts. A design system is like a LEGO set—it includes the rules and the reusable pieces (components, tokens) to build products faster."

4. Prepare for Whiteboard Challenges

Common design system interview tasks: 1. "Design a button component with variants."
- What to do: Sketch a button with states (default, hover, active, disabled, loading) and explain your decisions (e.g., "Disabled buttons have 50% opacity to indicate non-interactivity").
- Key principles: Fitts’s Law (size), contrast (WCAG), consistency (Nielsen’s #4).

1. "How would you audit an existing product’s UI?"
2. What to do: Outline steps:
   1. Inventory all UI elements (buttons, inputs, etc.).
   2. Group by type (e.g., all "Primary Buttons").
   3. Identify inconsistencies (e.g., 5 different blues).
   4. Prioritize fixes (e.g., "Unify buttons first—they’re used everywhere").

3. Key principles: Heuristic evaluation, atomic design.

4. "A developer says your dropdown component is too complex to build. How do you respond?"

5. What to do: Propose a compromise:
   • Simplify the design (e.g., remove animations).
   • Break it into phases (e.g., "Let’s build the basic dropdown first, then add search later").
   • Show data (e.g., "This dropdown is used in 10+ flows—it’s worth investing in").
6. Key principles: Collaboration, feasibility.

Quick Check Questions

1. A stakeholder wants to add a new "Premium" button style to the design system for a high-priority feature. The system already has 5 button variants. How do you decide whether to add it?

Answer: - Check usage data: Is the "Premium" button needed in multiple places, or is it a one-off? - Apply the 80/20 rule: If 80% of use cases are covered by existing buttons, avoid adding a new variant.
- Propose alternatives: Can you use an existing button with a badge (e.g., "Premium" label) instead? - Key principle: Consistency (Nielsen’s #4)—too many variants increase cognitive load.

2. During a design QA, you notice a developer used a one-off button style instead of the design system’s primary button. How do you handle this?

Answer: - Ask why: Did they miss the component? Was the system’s button not flexible enough? - Document the fix: Add the one-off style to the system (if justified) or update the component to cover the use case.
- Educate the team: Hold a quick sync to explain the system’s value (e.g., "Using the system button saves dev time and ensures consistency").
- Key principle: Design System Governance—prevent "shadow design" by making the system easy to use.

3. A designer on your team wants to add a new "Dark Mode" to the design system. What steps do you take to implement this?

Answer: 1. Audit existing components: Identify which elements need dark mode variants (e.g., buttons, cards, text).
2. Create dark mode tokens: Define new colors (e.g., --bg-dark: #121212, --text-dark: #E0E0E0).
3. Update components: Add dark mode variants to buttons, inputs, etc. (use Figma’s Mode Switcher).
4. Test contrast: Ensure text meets WCAG AA (4.5:1 for normal text).
5. Document: Add dark mode guidelines (e.g., "Use --bg-dark for surfaces, --surface-dark for cards").
6. Handoff to devs: Export tokens to CSS/JSON and update Storybook.
- Key principle: Scalability—design systems should evolve with product needs.

Last-Minute Cram Sheet

1. Design System = LEGO set (reusable components + rules).
2. Tokens store design decisions (colors, spacing) in code-friendly formats.
3. Atomic Design: Atoms → Molecules → Organisms → Templates → Pages.
4. 8-point grid for consistent spacing (8px, 16px, 24px, etc.).
5. WCAG AA contrast ratio: 4.5:1 for normal text, 3:1 for large text.
6. Fitts’s Law: Make important buttons large and easy to click.
7. Nielsen’s #4: Consistency reduces cognitive load.
8. Figma tips: Use Variants for component states, Auto Layout for responsiveness.
9. ⚠️ Style Guide ≠ Design System (static vs. interactive).
10. ⚠️ Don’t over-engineer—start small and expand as needed.