A Design System People Trust
70 components, adopted by design and engineering, delivered end-to-end in under 3 months.

Project Overview
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 Medical Center, 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
Diagnosing the Problem
GoalFind 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.
Why It Mattered
GoalTie the drift to real patient cost
The University of Rochester Medical Center 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.
The Approach
GoalRebuild 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.
Moving the Team Forward
GoalMake 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.
Scaling Across Platforms
GoalExtend the system without fragmenting the brand
Once the core library had earned trust, I extended it to the medical school as a bespoke pattern library, one that sharpened student storytelling to draw applications while holding clinical brand coherence across very different audiences. The same foundation now serves patient-facing care and academic recruitment alike.
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 served annually by the digital experiences the system supported
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.
Next project