Vision UI. The Design System That Made Dark Mode, White-labeling, and Consistent Shipping Possible at MontyCloud.

Vision UI: MontyCloud Design System Tokens

Vision UI: Token architecture in the MontyCloud design system

MontyCloud had no design system. Engineers built UI from scratch for every feature, different buttons, different tables, different spacing. I built Vision UI over 3 months. It became the foundation for every feature that shipped after, made dark mode possible, and unblocked white-labeling on the roadmap.

Impact

· 3 months post-rollout

Before · 3–4 rounds

1–2rounds

Design QA cycles per feature

Before · Not possible

✓

Dark mode: now supported via token swapping

Before · Not feasible

✓

White-labeling: architecturally unblocked

Before · Ad-hoc

100+

Annotated handoff mockups produced

Tokens, spacing, component states documented

The problem

I joined MontyCloud as one of the first two designers. No design system, no shared patterns, no component library, no tokens. Every feature had its own visual language.

What the product looked like:

Buttons looked different across pages. Tables, the most-used pattern for MSPs analyzing AWS data, were inconsistent in layout, filtering, and interaction. Colors were hardcoded. Spacing was ad-hoc. Dark mode didn't exist and couldn't exist without a token system.

Why this became urgent:

Engineers were rebuilding UI components for every feature because nothing was reusable
Design QA took 3–4 review cycles per feature, no shared reference for "correct"
White-labeling was on the roadmap but architecturally impossible without tokens
MSPs spent most of their platform time in data tables, and every table worked differently

PM and Founder agreed: we needed a shared design language before we could ship reliably.

Research

I started by auditing what existed and studying what worked elsewhere.

I reviewed the full MontyCloud product (every page, every component pattern), 4 established design systems (Atlassian, IBM Carbon, Shadcn/ui, Preline), AG Grid documentation (already in engineering's stack), Radix UI (headless, accessible primitives), and customer feedback mentioning UI confusion from support tickets.

What the audit revealed: The inconsistency wasn't random, it was the natural result of different engineers building different features at different times with no shared reference. Each engineer made reasonable decisions in isolation. The problem was systemic, not individual.

The design question

How might we establish a shared visual foundation fast enough to ship alongside features: while building something durable enough to support theming, dark mode, and white-labeling the roadmap demanded?

The solution. What shipped, and four decisions inside it

Vision UI: Component library overview in Figma

Three phases over 3 months: core token system + foundational components (Month 1), table pattern + data-heavy components (Month 2), remaining components + legacy migration + composite pattern documentation (Month 3).

Decision 1 · Token architecture before component library

I chose

Token architecture first: colors, spacing, typography, border-radius, shadows all established as variables before building a single component.

I rejected

Component library first, faster to ship visible, usable buttons and inputs in week one, with tokens retrofitted later.

Why

White-labeling was on the roadmap for enterprise MSP clients. Without tokens, theming would mean rewriting styles across every component, a full codebase audit, not a variable swap. I made the case to PM: the slower start would enable every future capability we couldn't build otherwise. Orange had been used as a secondary color throughout the product; I moved it strictly to critical/destructive actions because it was creating false urgency. That kind of systemic correction is only possible at the token layer.

Outcome

Token architecture added real complexity upfront, the first two weeks had more engineer questions than I anticipated. But dark mode shipped in Month 2 as a straightforward token-swap, and white-labeling moved from "architecturally blocked" to "feasible" on the roadmap.

Decision 2 · Table UX: persistent left-panel filter

I chose

A persistent left-panel filter (260px) that stays visible alongside the data table. Users manipulate filters and see results update simultaneously, no toggling, no hidden state.

I rejected

Dropdown filters on the right side that close when activated, the existing pattern, and the one I initially assumed I'd refine rather than replace.

Why

The existing dropdown pattern forced a loop: filter, close, check table, re-open dropdown to see what's active, adjust, close again. Support tickets described this as "losing context." The persistent panel eliminated the loop. Two decisions from testing: I widened from 200px to 260px when testing with PM showed filter labels truncating, accepting less table width on smaller screens. I added collapse-to-icon on screens below 1024px when always-visible on tablet left too little room for data.

Outcome

Design QA for table-related features dropped from 3–4 rounds to 1–2 rounds, there was now one documented, correct table pattern to reference instead of judgment calls. This filter interaction became the MontyCloud standard adopted in the next 3 features without modification.

Vision UI, redesigned table with persistent left-panel filter

MontyCloud product before Vision UI, inconsistent UI and ad-hoc table patterns

Decision 3 · 2px border radius: enterprise aesthetic

I chose

Sharp 2px border radius across the system, buttons, cards, modals, inputs, as a deliberate aesthetic choice.

I rejected

Rounded corners following the industry trend toward softer, consumer-facing UI aesthetics.

Why

MontyCloud's users are cloud engineers and solutions architects, not consumers. Sharp edges read as precise and technical in that context. Rounded corners would have made the product feel more like a consumer SaaS and less like the enterprise infrastructure tool it was. This was the aesthetic I saw in Atlassian Carbon and other enterprise-oriented systems I studied. The 2px choice was intentional, not a default, I documented it explicitly so future designers would understand it was a decision, not an accident.

Outcome

Shipped as the system standard. In retrospect, 2px is probably too sharp for some softer contexts (empty states, onboarding). It became permanent because changing foundational tokens after adoption is expensive, a lesson in how much early decisions persist.

Decision 4 · Adoption strategy: annotated mockups + office hours

I chose

Annotated mockups + weekly office hours + visual QA reviews alongside Storybook documentation. I treated adoption as my primary deliverable, not an afterthought.

I rejected

Documentation-only handoff, ship Storybook, let engineers self-serve, trust that good documentation would be enough.

Why

Documentation tells engineers what components look like. It doesn't tell them which token to reach for when spacing feels wrong, or why two visually-similar components serve different purposes. Engineers weren't accustomed to pixel-level attention to spacing, not because they didn't care, but because there had never been a shared reference for "exact" before. "Close enough" was acceptable when there was no standard. Vision UI created the standard and changed what "correct" meant. That culture shift needed active support, not documentation.

Outcome

After 3–4 escalations through PM establishing that QA standards had changed, the team calibrated. I spent more time on adoption than on actual design work. That was the right allocation, a system nobody uses is worth nothing.

What I can say about outcomes

What I can say confidently:

Design QA cycles dropped from 3–4 rounds to 1–2 rounds per feature
New feature UI development became noticeably faster, engineers stopped rebuilding from scratch
Dark mode shipped as a token swap, not a codebase rewrite
White-labeling moved from "architecturally blocked" to "feasible"
The other senior designer and I could move faster because we shared a component library in Figma

What I can't quantify precisely:

I don't have exact time-savings numbers. We didn't instrument "hours spent on UI implementation" before vs. after. The qualitative signal was strong, engineers and PM consistently said development was faster, and the QA reduction was visible in sprint velocity. But I won't attach specific figures to something I didn't measure.

"I can finally see my data and adjust filters without losing context.", MSP Customer

What didn't ship

Component playground: an interactive tool where engineers could configure components visually and copy the code. Scoped out because Storybook covered most of the need, and a custom playground wasn't justified for a team of ~8 engineers.

Motion/animation tokens: I established static visual tokens but not a motion system. Animations were handled ad-hoc per feature. This was fine for the MVP, consistent motion is a polish concern, not a foundation concern, but it meant animation quality varied.

Composite pattern documentation from day one: I documented individual components but not composite patterns: how they should work together in common layouts (form + table, sidebar + content). I added this in Month 3, but it should have been there from Month 1. Engineers could build correct buttons and still assemble them incorrectly.

What I'd do differently

Document composite patterns from day one. The gap between "correct button" and "correct page layout" was wider than I expected.

Push for analytics instrumentation. Without usage data, I had to rely on PM feedback and visual QA to know which components were misused. Real instrumentation would have told us which patterns needed more support earlier.

What I learned

A design system is an adoption problem, not a design problem. Building the system was the easier half. Getting engineers to use it consistently, that took annotated mockups, office hours, QA escalations, and sustained culture change. The system's value is zero if it sits in Storybook unused.

Tokens are boring and essential. Nobody gets excited about a spacing scale. But tokens made dark mode, theming, and white-labeling possible without rewriting CSS across the product. The boring infrastructure work enabled every interesting capability that came after.

Every decision at a 0-to-1 company persists longer than you expect. The 2px border radius, the 8px spacing grid, the left-panel filter, these became the MontyCloud standard for years because changing foundational tokens after adoption is expensive. Design carefully at the foundation; refactoring it later costs more than the original decision.

MontyCloud Goa Meetup: the people the design system was built for and with

Impact

The problem

Research

The solution. What shipped, and four decisions inside it

What I can say about outcomes

What didn't ship

What I'd do differently

What I learned

More Case Studies