Turning the design system from ignored to fully adopted
Researched our workflow like users, then rebuilt the documentation around it.
7 min read
Outcomes
- 70 components shipped, now all in production across the site
- Cut design-doc review comments 40-50% (measured in Figma), retiring a recurring 2-hour sync
- An estimated one-third faster design-to-build handoff
- Documentation adopted by developers and content editors
- End-to-end rollout in under 3 months
Timeline
Under 3 months, end-to-end
The Problem
At the University of Rochester Medicine, the design system had fallen out of use, leaving design and engineering to speak different languages.
The Solution
I rebuilt the system from the foundation up. That meant auditing what existed, defining a token architecture beneath it, and building the components shoulder to shoulder with engineering. Then I documented the whole thing so developers and content editors could trust it enough to use.
My Role
UX Designer
Team
- 1 UX Lead
- 2 Developers
- 1 Product Manager
I Personally Owned
- Component auditing
- Documentation structure
- Responsive behavior specs
- Content editor guidance
- Developer collaboration workflows
- Implementation clarification
My Process
The system had quietly drifted out of trust
Goal: Find why the system stopped being the source of truth
We had a design system. It had just stopped being the source of truth. Developers shipped small, ad-hoc fixes, each one simple and harmless on its own, and over time those little decisions drifted out of sync until nobody trusted the library anymore. The big-ticket widgets held up fine. The small stuff fell apart, the bits and pieces the original system had never really accounted for. I found the shape of it by auditing what we already had. Our entire library lived on one sprawling board, hard to parse, disorganized, missing the very components the site ran on every day. Everything we needed sat crammed into a single screenshot. The evidence pointed past another patch, toward a new foundation.
- What drifted: the disclosure control, every label (filter pills, search-result labels, campus and location labels, the accepting-patients label, the distance indicator), the single card block, the condition-search result card, plus drop shadows, strokes and borders, accents, and text highlighting.
- What held: the large widgets stayed consistent, provider cards, location cards, CTA blocks, and stories.
- The gap: we needed a system comprehensive enough to govern the small pieces of the site, not just the big-ticket widgets.
When design and engineering drift, patients pay
Goal: Tie the drift to real patient cost
The University of Rochester Medicine runs as a 30,000-person academic health system, serving 1.2 million patients across the region. When the system drifts and the two teams stop speaking the same language, the cost lands on patients.
High-stakes search friction
Broken patterns force patients to spend more time finding care than receiving it.
Slow feature release
Work piles up, and users wait longer for pressing bug fixes or feature updates.
Loss of trust
A medical portal that looks fragmented quietly tells patients the institution behind it is, too.
A new foundation, built with engineering in the room
Goal: Rebuild the design system on a foundation people could trust
Three steps, two of them mine and one I drove with engineering. The first was executive buy-in, and I made that case in the terms leadership weighs: money and time. Every week, teams burned hours reconciling work built from different sources of truth, with a standing two-hour sync running every other week just to catch the drift. Framed as efficiency and cost, the rebuild got its green light.
- 01
Problem Framing
I ownedI started with the developers rather than the components. They showed me why the old library had failed: it covered the big widgets but never the small pieces teams reached for, so trust in it eroded. One comprehensive source of truth would fix that; a longer component list wouldn't.
- 02
Token Architecture
I ownedI rebuilt the foundation and defined the full token set, from type and color through grid, spacing, iconography, animation, borders, and shadows. Drift stops at the root now: the small pieces inherit from one source instead of getting hand-styled on every page.
- 03
Engineering Partnership
CollaborationI built every component alongside the developers, never across a handoff wall. When something couldn't be built cleanly, the design gave way. That habit earned the system enough trust to be adopted, and it cut review time once work reached handoff.
The foundation the rest of the system is built on: color, type, and icons
Goal: Defined once, referenced across the library
The system starts with three documented foundations: color, type, and icons. Every component is built from these, so the same values show up across the site instead of getting re-decided page by page. The palette carries its own accessibility floor. Each pairing is scored for WCAG AA or AAA and tuned for older patients reading under stress, and color is never left to signal a state on its own.
Seventy components, drawn for every state and screen
Goal: The library that replaced the sprawling old board
This is the after the old board never became. Every component got documented the same way, from the buttons up, across four breakpoints and every interaction state. The provider search card leads because the research work redesigned that exact surface, so the system and the studies kept sharpening each other. The rest cover what the site runs on: result cards, stats, feature blocks, patient stories, video, and calls to action.
Documentation made the team trust it again
Goal: Make the documentation do the convincing
Most design systems document the big components and stop there. This one documents every widget the same way, down to the small pieces that used to drift, so developers and content editors can move without pulling each other off real work. Each widget answers the same six questions. That consistency turned the library from a liability into a tool the team reached for on its own, and it shifted reviews from "I don't like the blue" to "does this serve what the patient needs?" The payoff showed up in the review queue. Once developers and content editors had what they needed up front, their comments on the design docs dropped 40 to 50 percent, a number I got by counting the threads on the Figma files before and after, alongside the meeting hours we won back. The questions that remained were sharper, builds moved faster, and my best estimate is that a typical component went from spec to merged in about a third less calendar time.
The same system, extended to the medical school
Goal: Extend the system without fragmenting the brand
Once the clinical library had earned its trust, that same foundation became a bespoke pattern library for the School of Medicine. Its visual language carried straight over: Rochester blue, the yellow accent, Proxima Nova, and the stat box with its blue rule. Each widget gets documented the same disciplined way, so the two libraries feel like one system. Where they part is the audience. Clinical components help patients find care; these help a prospective student picture the program. Numbers become class sizes and rankings, and the quote widget carries a medical student's story, the same pattern behind the Student Voice work. A few patterns are new to this context, like the accordion, rich text, and button group that longer program pages lean on.
My Impact
A design system earns its keep only when people trust it enough to reach for it every day. I built for that trust first, and it carried the library into daily use across design, engineering, and content. All 70 components run in production today.
<3 mo
end-to-end delivery, from audit to adoption
1.2M
patients reached by the experiences this design system powers
70
components shipped, all now in production across the site
40-50%
fewer review comments on design docs once teams had what they needed up front
What I'd do differently
The part that took convincing
Every earlier attempt at a system had failed here, so the real work was convincing stakeholders this one would hold. That proved harder than designing the components. A good system stays easy to trust and maintain once people buy in, and only then does it scale.
Three ugly truths
- 01
The 40 to 50% drop in review comments comes from me counting Figma threads before and after. Directional evidence, no control group.
- 02
The one-third faster handoff is my estimate from calendar time, and it stays labeled that way.
- 03
This organization had watched design systems fail before. The hardest resistance I faced was rational, built from promises earlier libraries had broken.
Liked this project?
I'm happy to walk through the decisions behind it, or talk about what I could bring to your team. Email is the fastest way to reach me.