Presenting Vision UI to the team · Token architecture, components & adoption
→ Token architecture & component library
→ Table & data-heavy patterns
→ Storybook documentation & engineering adoption
I joined MontyCloud as one of the first two designers. No design system, no shared patterns, no component library, no tokens. Engineers rebuilt UI for every feature, creating inconsistent patterns and repeated QA work.
I started by auditing what existed and studying what worked elsewhere.
Engineers made reasonable UI decisions independently. The most-used pattern had inconsistent filtering, layout, and interaction.
Build the foundation before scaling the components.
Tables were the biggest pain point.
Without tokens, dark mode and white-labeling couldn't scale.
The inconsistency wasn't a people problem. It was a system problem.
The design question
How might we establish a shared visual foundation fast enough to ship alongside features, while making future theming and white-labeling possible?
Three phases over 3 months:
- Established color, spacing, typography, radius and shadow tokens first.
- Used tokens to make theming and dark mode possible without rewriting components.
- Created the foundation for future white-labeling.
- Replaced dropdown filters with a collapsable left side filter panel.
- Kept filters and results visible at the same time.
- Added responsive collapse below 1024px.
- Storybook documented the components.
- Kept filters and results visible at the same time.
- Weekly office hours and visual QA helped establish the new standard.
A design system is an adoption problem, not just a design problem.
Building Vision UI was the easier half. Getting engineers to consistently use it required documentation, office hours, annotated mockups, and QA calibration.
Tokens are boring and essential.
They made dark mode, theming, and future white-labeling possible without rewriting the product.
MontyCloud Goa Meetup · 2024
