Merida is a special projects team within Apple Health, building a blood sugar monitoring app that helps people understand how their bodies respond day to day. Because this work is confidential, this case study focuses on process and systems thinking rather than product specifics. Happy to go deeper in person!
COMPANY
Apple · Health Special Projects
ROLE
UI Design Systems Designer
TEAM
TOOLS
Illustrator, Sketch, Jira, Miro, Jitter
YEAR
2023 - 2024
CHART COMPONENT
01 · CONTEXT
A system built by everyone
and no one
When I joined, the design system was being built the same way as the app itself: from scratch, by everyone, independently. Designers pulled from different files and versions, 60 of 75 components had no tokens, and engineers had little to implement from. Screens were inconsistent, builds were slow, and every new surface meant starting over.
I audited the system, standardized variables across every component, and wrote the documentation engineers needed to build correctly. There was no Getting Started guide when I arrived. There was one when I left. By then, the system had grown well beyond 75 components.
GETTING STARTED
02 · CHALLENGE
Consistency for a product
that can't afford confusion
Merida is a health product, so ambiguity in the interface isn't just a UX problem. It's a trust problem. Someone watching their blood sugar spike needs to understand immediately what they're looking at. The system had to be precise, accessible, and consistent across every screen.
The hardest part wasn't building it. It was knowing what to build first. I met with every designer on the team and asked what they needed most. Their answers set the order. I built the system around the people using it.
HOME TAB NAV COMPONENTS
COLOR
03 · THE SYSTEM
Assembled, not rebuilt
Building the system meant establishing tokens, creating components with full state coverage, and writing documentation engineers would actually use. Once the foundation was in place, screens could be assembled from pre-built components instead of built from scratch every time. Our PM estimated design and development cycles got 15 to 20 percent faster.
We built governance together. When a designer needed a new component, we evaluated it as a team: How often does this pattern appear? Does it warrant a permanent place in the system? Not everything made the cut. Components were tested against real screens and deprecated when something better emerged. The changelog reflects that honestly.
WAYFINDING / STRATEGY COMPONENTS
CHART COMPONENTS
04 · PROCESS
Audit, build, document, ship
Every new component started with the same question: how are designers already solving this? I audited existing files first, built from what the team had already figured out, then documented each component with a consistent template and annotated Sketch pages for engineering. Every two weeks, we reviewed 10 to 20 components. We repeated that loop until the system was stable.
One decision pushed that system further. Engineering wanted to defer dark mode because the app hadn't launched yet. I disagreed. People may check their blood sugar in the middle of the night, often in a dark room. Dark mode isn't just a preference. It's a clinical consideration. Because the system used semantic tokens from the beginning, supporting dark mode became a theme change, not a redesign.
LIGHT MODE
DARK MODE
05 · THE ARTIFACTS
Spacing Guide. The spacing system adopted by engineering for consistent implementation across every screen.
Tile Components. The most used pattern across the product. Every state, every variant, documented and ready.
Strategy Platter Components. Built from existing designer solutions, codified into a reusable pattern for the entire team.