Virtual Therapeutics
Building Infrastructure That Scales: Design System for Healthcare Tools
⏵ Consolidated fragmented styles to improve usability and increase user trust
⏵ Made it quicker to iterate on designs by creating reusable components in Sketch
⏵ Implemented code component library with developer to ensure parity between design and code
Role
Design systems, usability
Collaborators
Lead frontend developer, head of engineering
Timeline
2021 – 2022
Virtual Therapeutics
Building Infrastructure That Scales: Design System for Healthcare Tools
⏵ Consolidated fragmented styles to improve usability and increase user trust
⏵ Made it quicker to iterate on designs by creating reusable components in Sketch
⏵ Implemented code component library with developer to ensure parity between design and code
Role
Design systems, usability
Collaborators
Lead frontend developer, head of engineering
Timeline
2021 – 2022
Context
Virtual Therapeutics was preparing to launch patient-facing products but had internal tools with fragmented visuals which would erode trust with users
When I joined Virtual Therapeutics as the first and solo UX designer, they had several internal tools for patient management, headset tracking, program monitoring. These were developed in a piecemeal way with no designer involvement.
Even a small change meant updating the same element multiple times across each page and each tool. This made it difficult to improve existing tools.
In addition to this, the roadmap had new tools that would be patient-facing. Having a consistent design language would build trust with patients and allow fast scaling as more users signed up.
4
internal tools updated
Context
Virtual Therapeutics was preparing to launch patient-facing products but had internal tools with fragmented visuals which would erode trust with users
Some examples of the components I built and documented, following a developer-friendly structure.
The evolution from the screenshot on the left to the screenshot on the right took several incremental changes over years.
UI Audit
Auditing our existing UI elements revealed that engineers were unnecessarily coding the same thing over and over, while users were struggling to understand where to click
I built my case to the head of engineering by first doing a UI audit. I combed through 4 different internal tools and put together a presentation that showed the different versions of each UI element.
This made it clear to leadership that a design system was needed and well worth the initial resource investment. I emphasized that an incremental approach was possible and better than not having a design system at all. Engineers were wasting time writing code for a component that had already been implemented.
256
color styles consolidated
UI Audit
Auditing our existing UI elements revealed that engineers were unnecessarily coding the same thing over and over, while users were struggling to understand where to click
Prioritization
With the constant need for new features, developers didn’t have the bandwidth to optimize old code. The trade-off I presented was to build out one or two of the most impactful components at a time.
Developers were on board with this idea and had wanted one for a long time. However, shipping new features had always been prioritized.
Prioritization
With the constant need for new features, developers didn’t have the bandwidth to optimize old code. The trade-off I presented was to build out one or two of the most impactful components at a time.
The trade-off with this approach was short-term consistency, but it created an opportunity to demonstrate the value of design systems and get buy-in from everyone across the company.
After listing out all components we currently used, I cross-referenced it with our roadmap to capture any brand new components that were incoming.
First I prioritized the low-hanging fruit like UI elements that appeared very frequently, multiple times on a single page, like buttons and form inputs.
Next were the strategic priorities. For example, we were starting to build dashboards. This was a great opportunity to pull chart components up into the MVP, so that those components were standardized from the get-go, and wouldn’t need to be revisited later.
Expandable table row from IBM's Carbon Design System
Expandable table row for VT's Design System
I also looked at other companies’ design systems that had products similar to ours. This provided a lot of insight about best practices and current trends. It also ensured we didn’t miss any important components.
Designing for Engineers
To ensure that engineers would actually use the design system, I worked closely with the lead frontend developer to learn their existing tools and workflows like Bootstrap.js
I learned that the engineering team uses Bootstrap.js, so I studied the documentation, taking note of naming differences (tooltip vs. popover, stroke vs. border, fill vs. bg) and structural conventions (primary vs. secondary button is controlled by the class attribute in CSS, compared to a symbol override in Sketch).
Using terms and attributes that engineers were familiar with would remove friction and make it more likely that they would use the component. They wouldn’t have to go and look it up in the documentation.
Designing for Engineers
To ensure that engineers would actually use the design system, I worked closely with the lead frontend developer to learn their existing tools and workflows like Bootstrap.js
Modular Design
Building components in a modular way allowed one component to be flexible and serve multiple use cases
I defined the architecture of the design system so that just one component was versatile enough to be used in multiple ways.
A straightforward example of this is buttons. Rather than having separate components for a text-only button, an icon-only button and a text-and-icon button, I built these as attributes of a button (icon=true/false, label=true/false).
This allowed us to get much more bang-for-our-buck in terms of code. It’s much easier to get one component approved and built rather than 3 different ones.
This also prevented the previous problem of fragmentation from occurring again by making components easier to maintain.
Modular Design
Building components in a modular way allowed one component to be flexible and serve multiple use cases
Implementation
I built the components in Sketch so that they resembled actual code components as closely as possible, to make translation from design to code easier
Building the components in Sketch and observing the engineering team code them revealed some fundamental differences between design tools and code tools.
It was a rewarding challenge to maintain parity between the two libraries while adapting to each tool’s strengths.
I also maintained an open dialog with the engineering team as they built the components to ensure parity.
Implementation
I built the components in Sketch so that they resembled actual code components as closely as possible, to make translation from design to code easier
Documentation
Robust documentation usage guidelines and context-based examples helped ensure adherence
Even though I wanted to remove friction for engineers by removing the need for documentation, I still documented the design system for company-wide visibility and so we had a single source-of-truth.
I included usage guidelines for each component so that engineers could quickly choose the right component without waiting for me to get back to them.
I also created some wireframes that showed components being used in context, not just in isolation.
Documentation
Robust documentation usage guidelines and context-based examples helped ensure adherence
Outcomes
Engineers are now actually excited to ship new features and work on frontend improvements
While it was hard to measure exact time saved, there were several intangible impacts of implementing a design system.
⏵ Prototyping and iteration was easier and quicker
⏵ 4 internal tools were retrofitted with the new design system within 6 months
⏵ Engineers were more willing to make changes
⏵ New external products appeared more professional and gained user trust due to visual consistency
17
relieved engineers
Outcomes
Engineers are now actually excited to ship new features and work on frontend improvements
While it was hard to measure exact time saved, there were several intangible impacts of implementing a design system.
⏵ Prototyping and iteration was easier and quicker
⏵ 4 internal tools were retrofitted with the new design system within 6 months
⏵ Engineers were more willing to make changes
⏵ New external products appeared more professional and gained user trust due to visual consistency
Challenge
Accepting that perfect is the enemy of good was crucial to start making incremental improvements
At a startup with limited bandwidth, building a design system had always been deprioritized. As a designer, my instinct was to overhaul everything and make everything perfect from scratch.
The resource constraints forced me to reframe my thinking and look for the smallest changes that would make the biggest impact.
This shift also helped me get the head of engineering on board. Turns out, even the engineers had been putting off building a component library because it seemed like an overwhelming and daunting task.
Challenge
Accepting that perfect is the enemy of good was crucial to start making incremental improvements
At a startup with limited bandwidth, building a design system had always been deprioritized. As a designer, my instinct was to overhaul everything and make everything perfect from scratch.
The resource constraints forced me to reframe my thinking and look for the smallest changes that would make the biggest impact.
This shift also helped me get the head of engineering on board. Turns out, even the engineers had been putting off building a component library because it seemed like an overwhelming and daunting task.
Psst…my portfolio is way cooler when viewed on desktop. Case studies on mobile are shortened.
Psst…my portfolio is way cooler when viewed on desktop. Case studies on mobile are shortened.
Seattle
❖
Open to full-time roles
❖
8+ years of experience
❖
VR, Health & Finance
❖
Enterprise & B2B
❖
Let’s connect!
If you’re curious about how we can work together, please reach out and let's set up a chat!
2026 ❖ Built in Framer
Seattle
❖
Open to full-time roles
❖
8+ years of experience
❖
VR, Health & Finance
❖
Enterprise & B2B
❖
Let’s connect!
If you’re curious about how we can work together, please reach out and let's set up a chat!
2026 ❖ Built in Framer