Document as I build.
I wrote documentation afterward. Next time, usage guidance belongs beside the component from the start.
Back to workOnahn Michelle / Design system
One system,
every screen.
The foundation behind Michelle: shared tokens, reusable components, and two themes. Built by one designer, for a team building a product.
See the product story
- My role
- Sole product designer
- Foundation
- Primitives and semantic tokens
- Scope
- Components, states, handoff
- In the product
- Light and dark themes
Make the decision once.
Use it where it belongs.
With one designer and a growing product, every screen couldn’t start from scratch.
The challenge
Keep screens and themes consistent while giving engineering clear, reusable decisions.
My approach
Separate raw values from their purpose. Build components on that contract before composing the screens.
Values → meaning → components
Three layers.
One shared language.
Explore the actual library, from the color ramps to the components.
Open image to inspect full size 
Primitives
Start with the raw material.
Color ramps and an alpha scale define the available values. They don’t decide how a button or message should look.
- The interface choice
- Keep raw values in one layer. Components use semantic tokens rather than choosing colors directly.
- The balance to get right
- A palette needs enough range for real states without collecting values nobody uses.
Beyond the default
A field has
more than one job.
Default, hover, focus, filled, disabled, error, success, and read-only. The input component accounts for each state through the token layer.
A beautiful default is a start. The error state still has to do its job.
Same structure.
Two themes.
Semantic names stay the same while their values change by theme. Components inherit the right value for their context.
The dashboard shows that contract in use, across surfaces, text, and cards.
What I learned
A library isn’t done
when it looks tidy.
The system gave Michelle a common foundation. The next improvement is making that foundation easier for someone else to understand and maintain.
See it in the productWhat I’d carry into the next system
Review the names with engineering.
A shared vocabulary deserves a second set of eyes before handoff.
Keep the library lean
Turn one-off patterns into compositions where possible. Add components when the product needs them, and prune those that no longer earn their place.
Good systems make room
for the interesting work.
Let’s talk about yours