Merida is a special projects team within Apple Health, building a blood sugar monitoring app designed to help people understand how their body responds to the world. This work is confidential, so 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
One designer, not enough hours
Merida is a special projects team within Apple Health, building a blood sugar monitoring app from scratch. When I joined, the design system was being built the same way: from scratch, by everyone, independently. Designers were pulling from different files and different versions. 60 of 75 components had no tokens. Engineers had nothing to implement from.
Screens were inconsistent. Builds were slow. Every new surface meant starting over.
I audited the system, standardized variables across all 75 components, and wrote the documentation engineers needed to build correctly. There was no Getting Started guide before I got there. There was one after. By the time I left, 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. Ambiguity in the interface isn't just a UX problem, it's a trust problem. A user seeing 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 directly what they needed. Their answers determined the order. The system got built around the people using it.
HOME TAB NAV COMPONENTS
COLOR
03 · THE SYSTEM
The team stopped reinventing the wheel
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, the team stopped reinventing the wheel. Screens got assembled from pre-built components instead of built from scratch every time. Our PM estimated design and development cycles got 30 to 50 percent faster.
Governance was something we built together once I joined. When a designer needed a new component, we evaluated it as a team: how frequently does this pattern appear, and does it warrant a permanent place in the system. Not everything made the cut. Components were tried, 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 and built from what the team had already figured out rather than starting from scratch. From there: document with a consistent template, create annotated Sketch pages for engineering handoff, present and demonstrate before review. Every two weeks, 10 to 20 components at a time. That loop repeated until the system was stable.
Engineering didn't want dark mode
Engineering didn't want to design for dark mode. The app hadn't launched yet, and it was framed as a problem for future us. I disagreed. Merida is a health app. People check their blood sugar at night, in dark rooms at 2am. Dark mode isn't a preference feature, it's a clinical consideration. Because I structured the system around semantic tokens from the beginning, switching between light and dark 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. 9 versions, 18 months of documented iteration.