Case studyDesign systemHealthcare
Building an enterprise design system from legacy chaos.
How Viveka Health moved from fragmented UI patterns to a unified design system powering multiple healthcare products — built with accessibility and developer handoff in the core from day one.
Challenge
Multiple healthcare products shipping inconsistent UI, duplicated components, and uneven accessibility — slowing every release.
My role
Primary designer on the system. Led tokens, components, documentation, and adoption — with 1–2 designers collaborating on patterns.
Outcome
A shared component library, accessibility built in by default, and a measurable drop in how long it takes to ship a new feature.
Context
What Viveka looked like before the system.
Viveka Health builds enterprise healthcare platforms — eligibility verification, claims workflows, provider search, care coordination — used by US healthcare organizations to manage benefits and member services.
When I joined, the products had grown fast. Multiple teams shipping features in parallel had produced real business value and real design debt: five variations of the same button, three different date pickers, inconsistent form patterns, and accessibility gaps that surfaced during audits. Every new feature was an argument about which version to use.
Design wasn't the bottleneck. Re-deciding was the bottleneck.
The problem
Four compounding issues, not one.
Calling it “no design system” would've been wrong. Components existed. They just existed everywhere, in slightly different shapes. The real problems were deeper:
- Fragmentation. Similar patterns solved differently across products, making cross-product work painful for both designers and engineers.
- Accessibility debt. Components hadn't been built with WCAG 2.1 AA in mind. Screen reader support, focus management, and color contrast were inconsistent.
- Velocity tax. Every new feature meant re-deciding basics — which button, which input, which modal pattern. Design reviews turned into consistency debates.
- Handoff friction. With no shared language between design and engineering, the same component got implemented two or three different ways in code.
Approach
Four decisions that shaped the system.
Start with tokens, not components.
The fastest way to fake a design system is to build a dozen components and call it done. The system looks finished; nothing underneath actually changed.
I argued for starting with the layer underneath: tokens for color, typography, spacing, radii, and elevation. Tokens are unglamorous — you ship them and no screen changes. But once they're in place, every component you build after is consistent by construction, and you can theme the whole system by editing a single file.
The bet paid off later, when dark mode and accessibility contrast adjustments became single-file changes instead of audits across hundreds of screens.
Accessibility as a default, not a pass.
The easy path is to ship components first and audit them for accessibility later. That path produces patches. The hard path is to make accessibility a condition of shipping.
Every component in the system has keyboard support, focus management, ARIA labels, and contrast-checked tokens baked in at the component level. Engineers can't accidentally ship an inaccessible button because the inaccessible button doesn't exist.
Healthcare users include people on screen readers, people with motor disabilities, and people reading on their phone in bad lighting. The system respects all of them by default.
Documentation that answers “why,” not just “what.”
Most design system docs tell you what a component looks like and what props it takes. Useful, but incomplete. The documentation I pushed for answers a different question: when should you use this component, and when should you not?
Every component page includes usage rules, anti-patterns, and the reasoning behind the decisions. A new designer or engineer doesn't just learn what's in the system — they learn how to think about it. This is how a system outlives the person who built it.
Adoption over completeness.
A design system that isn't used isn't a design system — it's a Figma file. Completeness is less important than adoption. I'd rather have 15 well-adopted components than 50 that nobody uses.
I prioritized what teams actually reached for every day: buttons, inputs, modals, tables, form patterns. I deferred exotic components until someone asked for them. And I stayed close to the teams adopting the system — pairing during implementation, answering questions, fixing friction fast.
Adoption isn't a launch event. It's a practice.
Outcome
What changed, qualitatively.
Shorter path from spec to ship.
With shared components and patterns, features that used to require a full design pass can now be composed from existing pieces — and engineering handoff is noticeably faster.
Accessibility by default.
Components ship with WCAG 2.1 AA compliance built in. Teams don't need to become accessibility experts — they just need to use the system correctly.
A shared vocabulary.
Design, engineering, and product now use the same names for the same things. Reviews stopped being consistency debates and started being design debates.
A system that can outlive me.
With tokens, documentation, and adoption practices in place, the system keeps working whether I'm in the room or not. That's the real deliverable.
Reflection
What I'd do differently.
If I started again, I'd invest more in adoption infrastructure earlier — office hours, a Slack channel for system questions, regular component critiques. The system gains trust by being a good teammate, not just a good library.
I'd also push harder on engineering partnership from week one. The best parts of the system came from tight collaboration with engineers — and the slowest parts came from moments when design ran ahead and engineering had to catch up.
Design systems aren't a design project. They're a team practice. The sooner you treat them that way, the better they get.