✅ Shipped · Design Systems
Designing scalable, accessible components for a system supporting six product teams - with decisions documented thoroughly enough that any team could implement without ambiguity.
Org
Dev Launchers
Timeline
3 months
Tools
Figma, Storybook
IMPACT
CONTEXT
When I joined the Universal Design System team, the foundation was still being established. Six product teams were making independent visual decisions — different buttons, different spacing, different component logic. The team had identified the recurring challenges; my work focused on solving them at the component level.
01 Designers were rebuilding components locally because they weren't sure if existing ones would scale
02 Documentation was sparse — developers had to guess implementation details that weren't specified
03 Accessibility wasn't documented at the component level, leaving each team to figure it out individually
A design system is only as good as the decisions behind it. Components are the visible output. The thinking - why this variant, why this default, why this constraint - is what makes a system trustworthy enough for teams to actually use.
My work touched four aspects of the system — the same areas that determine whether a design system actually scales.
Components
Tokens
Accessibility
Documentation
MARKET AUDIT
Before designing, I audited how five industry-leading systems handled equivalent patterns. The goal: understand the full range of decisions already made — then choose what fit our context.
Carbon
Material UI
shadcn
PrimeUI
CoreUI
The key insight: Every system handles variants, states, and interaction patterns differently. There's no universal right answer — only what's right for your users, your tokens, and your product context.
DESIGN
Every component went through the same rigor: understand the use case, audit how others handle it, make and document key decisions, design all states, annotate for accessibility, and prepare for handoff.
Used primarily for FAQs and content disclosure. The challenge: balance flexibility with sensible defaults that work for the most common use case without overwhelming designers with options.
Optional Rich Content
Image blocks and action buttons within expanded panels are off by default — exposed as Figma properties so teams can enable without detaching.
Single Select Default
Defaulted to single-select (one panel open at a time) because FAQs reduce cognitive load when only one answer is visible. Multi-select stayed as a variant for comparison contexts.
Touch target: 44×44px minimum on trigger (WCAG 2.5.5)
Focus state: 2px ring using focus color token
Keyboard: Enter/Space toggles, Tab navigates between triggers
ARIA: aria-expanded, aria-controls, role="region"
More complex than most components because it combines row-level and cell-level interaction with system-level states. The challenge: design for the average data case AND the edge cases most teams forget about.
Atomic Composition
Broke table into atoms - header cells, body cells, header rows, footers, pagination buttons, checkboxes - so teams could compose row-based or column-based tables without rebuilding from scratch.
Checkboxes for Selection & Export
Selection checkboxes appear in their own column. When rows are selected, an export action surfaces in the header - so users can act on their selection without leaving the table.
Container: role="grid" on the table
Rows: aria-selected when selection is active
Headers: aria-sort on sortable columns
Keyboard: Arrow keys navigate cells, Space selects, Shift+click for range
DOCUMENTATION
Every component I contributed ships with documentation structured to serve two audiences: designers who need to know when and how to use it, and developers who need to know how to implement it without ambiguity. The structure is consistent across components so the system feels like one authored thing.
01 · Overview
What the component is and what problem it solves. One paragraph, no jargon. A designer should immediately know if this is the component they need.
02 · Usage
When to use - specific contexts where this component is the right choice. When NOT to use - equally important. Named alternatives where relevant. This is the section most designers skip; it's the one I refused to.
03 · Variants + Properties
Every exposed Figma property documented with its purpose and constraints. Default values stated explicitly. Properties that interact with each other called out.
04 · States
Every state shown visually and described in text. Interaction triggers documented (what causes the state change, what it transitions to). Edge cases named.
05 · Accessibility
ARIA roles, attributes, and values. Keyboard interaction patterns. Touch target requirements. Color contrast notes referencing specific token pairs. Written so developers can implement without looking anything up separately.
06 · Best Practices
Do / don't pairs with visual examples. Copy guidelines where relevant. Common mistakes and how to avoid them.
I structure Figma annotations the way Storybook stories need them — so the translation from design to code is one-to-one. Component anatomy, property defaults, state transitions, ARIA attributes, and keyboard patterns are all documented at the point a developer needs them.
MY LEARNINGS
Those users are other designers and developers. Their needs are as worth researching as any end user's. I came in thinking design systems were about components. I left understanding they're about the people who use the components.
Every default I set was a decision other teams would inherit. Single-select for accordion. Image blocks off. Empty state required. These weren't aesthetic choices - they were product decisions that scaled across six teams.
Looking at five systems wasn't about finding the "best" pattern. It was about understanding the full range of decisions already made — so I could make ours intentionally, not by default.
Variables and tokens help, but the real bridge is a designer who understands implementation enough to write specs that developers don't have to interpret. That's where my frontend background has been most useful.