Articles
Design Systems
The AI-native software program I'd build if I started over
If you took away the incumbent team, the half-built tooling, and the political memory of an earlier attempt, what shape would the program actually want to be?
The design system I'd build if I started over
If you took away the incumbent team, the half-built library, and the political memory of an earlier attempt, what shape would the program actually want to be?
Design systems are 25% pixels, 75% people
The tokens, components, and code are the part you can point at. Whether any of it gets used comes down to work that isn't design or engineering at all.
How I use Claude to ship design system work faster
Not component generation. The value is in compressing the tedious, repeatable work so judgment can go where it actually matters.
Writing component specifications that engineers trust
Engineers don't ignore specs out of disrespect for design. They ignore them because the specs are wrong in specific, predictable ways.
Multi-platform design systems: what's different about native
Tokens don't solve the platform problem. When you take a web design system to iOS and Android, the hard parts have nothing to do with color values.
The design system office hours model that actually works
Office hours that wait for people to show up usually don't. Here's a different approach to design system support that generates real usage.
How to handle design system requests you can't prioritize
Silence on a deprioritized request costs more than a clear answer. Here's how to handle the queue without destroying trust.
When a component is ready to be in the system
The bar for 'done' in a design system is different from the bar for done in a product. Most teams discover this at the worst possible time.
Design system adoption metrics worth tracking
Component count and install numbers are the metrics design system teams report most and learn from least. Here's what actually tells you something.
How to get engineering to actually use the design system
Engineers who skip the design system almost always have a reason they can articulate. Listening to it is faster than any adoption campaign.
What the Figma component library and the code component library should share
Figma and code diverge constantly, and some of that divergence is fine. The problem is not knowing which divergence to fix and which to leave alone.
Theming vs. variants: when to use each
Teams reach for theming when they need variants, and variants when they need theming. The confusion is expensive and usually shows up in production.
How to evaluate a third-party component library
Most teams make the buy-vs-build call too early, with the wrong criteria, and find out it was wrong two years later when the cost of switching is enormous.
The design system documentation nobody reads (and how to fix it)
Most doc sites get traffic on component pages and almost nothing else. The problem isn't the writing. It's what the other pages are trying to do.
Building for multi-brand: what changes and what doesn't
Multi-brand design systems sound like a tokens problem. They're actually a question about how much of your design is brand and how much is something else.
How to version a design system without breaking things
Semantic versioning is the easy part. The hard part is what to do when your tokens change and a thousand consumers don't notice.
What happens when your design system has too many components
Component proliferation is a governance failure, not a success. Here's how to recognize it, what it costs, and what to do about it.
Token architecture: the decisions that matter before you write a line of code
The naming and structure of your token system determines whether it survives past the first redesign. Here's what actually matters.
How to kill a component (the right way)
Building a component is celebrated. Deprecating one is avoided. That asymmetry is how design systems bloat.
Why your design system's naming convention will make or break adoption
Naming is how the system communicates intent. Bad names mean engineers have to remember what something is rather than understand it.
How to run a design system contribution model that doesn't collapse
Open contribution sounds democratic and scales poorly. Here's what actually works.
How to write component documentation that people actually read
Most documentation is written to be comprehensive. Good documentation is written to be used at the moment of need. The difference is everything.