DESIGN SYSTEMS
The Figma guts,
not just the screens.
Inside my Figma files.
Polished screens are the easy part to show. This page is about the layer underneath: how components are architected, how properties are named, how a library is organized, and how legacy work gets retired without breaking the teams depending on it.
How I build in Figma
Component architecture + variants
One component family with intentional variants, sized to real product needs, not to every request that arrives.
Properties & naming conventions
Boolean, instance swap, and text properties named so another designer can guess them correctly on the first try.
Auto Layout
Layouts that stretch, wrap, and hug the way the built product does, so handoff matches behavior, not a static frame.
Variables & tokens
Color, spacing, and type values pulled out of components and into shared variables, so a change happens in one place.
Responsive behavior
Breakpoint behavior tested in the file, including content density differences between desktop and small screens.
Mobile ↔ desktop relationships
Deciding when platforms share one component and when a genuine platform difference deserves its own.
Library organization
Pages, sections, and covers structured so people find what they need without asking a designer.
Component documentation
Usage, do/don't, and specs written next to the component, where designers and developers actually look.
Before / After
Not a hypothetical exercise. This is the shape of a real consolidation, hundreds of flows brought together into something a team can actually navigate.
From fragmentation
- 47 slightly different versions
- Detached components
- Duplicated patterns
- Miro + Figma
- No clear source of truth
To a system
- One scalable component family
- Clear properties + naming
- Reusable responsive assets
- Shared variables + documentation
- One organized source of truth
- Faster prototyping + onboarding
How I think about components
01
Do we actually need another variant?
A regulatory disclosure requirement would have added a whole new variant. Instead I raised it with Product and Legal to find out what was truly required, and we removed content instead of adding structure.
Read the full story →02
Should mobile and desktop share a component?
I start with responsive behavior and content density. If the same content can breathe at both widths, it stays one component. If the platform genuinely behaves differently, that's a real split, not a convenience one.
03
When should something become a component?
A recurring pattern earns a component. A one-off solution stays a one-off until it proves it isn't. Premature componentization creates maintenance work for something nobody reuses.
04
What happens to legacy components?
Audit → map → consolidate → migrate → deprecate. Nothing gets deleted out from under a team; it gets replaced, labeled, and retired on a path people can follow.
My design-system process
- Audit→
- Identify patterns→
- Consolidate→
- Componentize→
- Document→
- Test→
- Publish→
- Maintain
A design system isn't a one-time library-building exercise. It needs governance and maintenance as the product keeps evolving, otherwise it drifts right back into the "before" column.
I like a clean
Figma file.Probably more than is reasonable. Clear naming. Logical hierarchy. Reusable components. Predictable properties. No mystery frames called Frame 3847. Easy to navigate, easy to build from, and easy to hand off.