Case Studies
Building Healthcare Design Systems
Company
Cleveland Clinic & University Hospitals
Collaborators
Developers, UX Designers, QA Team Members, PMs, Product Owners, Researchers, Writers
About the Project
This case study spans two chapters of my career. I’ve spent the past eight years in the healthcare space at Cleveland’s two biggest healthcare systems. Cleveland Clinic and University Hospitals with Cleveland Clinic being one of the most well-regarded in the nation. The experiences were distinct in scale and complexity but connected by the same foundational philosophy: start with the smallest elements, build with intention, and create systems that empower teams rather than constrain them.
Design Systems
Branding
UI Design
Research
University Hospitals
Collaborators: 1 front-end developer, a team of back-end developers
The Challenge
When I joined University Hospitals as its only UX designer, a new website redesign was already underway and being built. I inherited that project midway through and was responsible for completing it. What I quickly recognized was that without a structured design library, every new feature and page would require starting from scratch, inconsistencies would accumulate, velocity would suffer, and the site would gradually fracture visually as it grew. There was no existing framework for design consistency beyond the brand guidelines themselves.
The Approach
Rather than just finishing the site and moving on, I extracted the design language from the existing work and formalized it into a reusable library — colors, typography, buttons, forms, iconography, building out the foundational layer of what would become UH's first digital design system. With a genuine library in place I could maintain visual consistency as the site grew, move faster on new features, and hand off reliable, predictable work to development. The most important thing I built here wasn't any single component. It was the habit of systems thinking, and the lesson that the hardest part of a design system isn't building the components. It's building the culture around them.
Typography
Color System
Iconography Design & Curation
Find a Doctor
App Icon System
Cleveland Clinic
Collaborators: 8UX Designers, 8 Developers, QA Team, PMs
My role: UX Designer, Co-lead of design system governance team
The Challenge
When I joined Cleveland Clinic the conditions were different from UH in almost every way — larger team, larger scale, more complex products, more stakeholders. But the starting point was surprisingly similar: a single well-designed page template existed, but a true system did not.
Building from One Page to a Full System
We started where the work was — taking the single existing page template and systematically extracting and formalizing its parts. Typography. Color. Buttons. Forms. From that foundation we built outward, adding components as the product required them, always with an eye toward flexibility, reusability, and scalability.
Typography
Color System
List Styles
Today the Cleveland Clinic design system includes over 50 components, at least 18 page templates, a full set of design tokens, and dedicated Figma library files for components, iconography, and wireframing. It is actively used by 10 designers, 8 front-end developers, and 4 or more product teams.
The Card Component: A Study in Flexibility
Of all the components in the library, the card is the one I'm most proud of — not because it's the most technically complex, but because of how far it has traveled from its origins.
What started as a simple content container has evolved through extensive use of Figma variants into one of the most flexible components in the system. Today it accommodates an array of scenarios including horizontal blog and search result listings with date and category markers, location cards with mileage pills for proximity-based browsing, leadership profile cards for the executive directory, rich call-to-action cards with images, titles, blurbs, and buttons, and newsletter subscription panels with checkbox-based interest selectors. The same underlying component powers all of these experiences — a genuine example of systems thinking applied to real product complexity.
Governance and Documentation
One of the most important investments we've made is in the governance infrastructure around the system. Every component created in Figma is accompanied by comprehensive documentation communicating design intentions to developers as they build. Once a component is built it gets a home in Storybook. We are currently building out Zeroheight as the central source of truth where design documentation and engineering implementation meet in the middle.
The Figma Workspace Audit
A design system is only as good as its findability. At a certain point recognized that the Figma workspace itself had become a source of friction for the team. Some designers weren't sure where to look for existing components, naming conventions between design and development didn't match, and the general state of organization was impeding rather than enabling the work.
I facilitated a workshop with all eight members of the UX team to surface these pain points directly. Three themes emerged clearly: navigating the workspace to find components and understand where new work should live, naming misalignment between what the UX team called things in Figma and what the development team called them in their own systems, and the general messiness of an active workspace where in-progress work was mixed with finalized components.
From those findings I developed a remediation plan and delegated specific action items across a group of four of my teammates, including myself. We established a clear information architecture for the Figma workspace with explicit rules for where things live. We conducted a full naming audit, renaming components to align with development conventions and creating a new collaborative governance process for naming decisions going forward. And we implemented a branching strategy that gave designers space to work messily toward finalization while keeping the published library clean and reliable.
File Organization and Branching Standards
Workspace Organization
The Impact of Having a System
The most compelling evidence for the value of the Cleveland Clinic design system isn't a single metric — it's the accumulation of what becomes possible when a team doesn't have to reinvent the wheel.
When the leadership section of the site needed a full relaunch across multiple page templates, the work was turned around in a matter of days rather than the month or more it would have required without the system. Two of the three pages were built by development based on wireframes alone. No high-fidelity were designs required because the components were so well established that the engineering team already knew exactly how to implement them. The full relaunch from concept to completion took just a couple of weeks.
On another initiative the redesign of the London homepage that I was a key contributor to, we also had a lot of great outcomes
Page views increased 15% from 5,239 to 6,025
Time spent per session increased 31.13% from 1.06 to 1.39 minutes
High-intent actions increased — Book an Appointment up 1.9 percentage points, Find a Consultant up 1.6 percentage points
Site search dropped out of the top 10 entirely, indicating users are finding what they need through the designed navigation rather than resorting to search as a fallback
The behavioral shift is as telling as the numbers. The previous top click — a single London Locations button capturing 16% of all clicks — was replaced by a more distributed, intentional information architecture that drove higher overall traffic while directing users toward higher-value actions. That's what good systems-informed design looks like in practice.