CASE STUDY 07 · MedPlus Health Check App

MedPlus Health Check App

Real-Time Inventory & Batch Tracking: Syncs fitness wearables to track steps, heart rate, and sleep.

Centralised Dashboard: Manages multiple devices and daily health progress in one place.

Personalised Experience: Customises user profiles and device settings to individual wellness needs.

01 / 04 · Open editorial spread with hairline grid lines and a deep green swatch, representing the Atlas design system

The Challenge

Nine squads maintained eleven versions of the same button, four date pickers and three different definitions of an error state.

Every new feature restarted the same debates, and accessibility defects reappeared in each rebuild.

Previous system attempts failed because they were published as libraries, never funded as products.

User Research

Designer interviews19 designers across squads said their biggest blocker was not knowing whether an existing pattern was current, deprecated or safe to use.
Engineering shadowingEngineers rebuilt the same components because the design file and the code library had drifted apart.
System auditA full inventory across nine products quantified the duplication cost in engineering hours and QA time.
Accessibility reviewA WCAG audit gave the system a non-negotiable baseline to inherit, which became a rallying point for squads.

Research was conducted before any design work; findings shaped the problem definition and strategy.

Discovery

A full component inventory across nine products quantified the duplication cost in engineering hours, while conversations with squad leads exposed why the previous system was ignored. We realized adoption was an incentive problem, not a documentation problem — and that a WCAG accessibility audit would give the new system a non-negotiable baseline every squad could rally behind.

Contextual interviews

Interviewed designers, engineers, and squad leads across all nine products to understand why the previous system was bypassed and where drift began.

Journey mapping

Mapped the design-to-code handoff journey for a typical component, pinpointing where tokens, specs, and documentation broke down between teams.

Analytics review

Audited component duplication across codebases and ran a WCAG accessibility review to set a measurable baseline for consolidation.

Strategy

Problem
Consistency was more expensive than inconsistency.
Insight
Adoption is an incentive problem, not a documentation problem.
Opportunity
Make the system the fastest path to shipping.
Strategy
Fund it as a product, with users, a roadmap and support.
Solution
Tokens, a governed component set and a visible contribution path.

Design Process

Wireframes

Token architecture and component hierarchy sketches were drafted before any UI component was designed.

Exploration

Governance models, contribution paths, and adoption strategies were trialled with volunteer product squads.

Prototypes

Paired design-engineering prototypes were built for the ten highest-traffic components to validate tokens and patterns in production context.

Testing

Accessibility and dark-surface testing were built into component acceptance criteria before any pattern was released.

Final Design

A tokenized foundation with 48 governed components, a public contribution pipeline, and an adoption dashboard visible to leadership.

Only the iterations that changed the direction of the work are shown — not every exploration.

Final Experience

A tokenised foundation shared by design tooling and production code.
48 governed components with usage guidance, accessibility notes and do/don't examples.
A contribution pipeline that accepted patterns from squads instead of blocking them.
An adoption dashboard that made progress and gaps visible to leadership.

Personas

Persona 01

Devika

Product designer, 28

“I spend half my time rebuilding the same button.”

Devika designs in a five-person product squad. She spends more time hunting for the current component than solving the actual problem.

Goals

Find the approved pattern in seconds
Know which variant is production-ready
Contribute back without a heavy process

Frustrations

Three versions of the same button
Undocumented usage rules
Libraries that change without notice

Needs ready-made patterns
Unsure which version is current
Wants clear usage guidance

Persona 02

Arjun

Frontend engineer, 32

“The design says one thing, the code says another. Which one is right?”

Arjun builds the front end for two squads and is the person who discovers when design and code disagree.

Goals

Ship UI without pixel-guessing
Rely on a stable, typed component API
Match design tokens exactly

Frustrations

Designs using detached overrides
Breaking changes with no migration notes
Duplicated components across repos

Values stable API
Hates undocumented overrides
Needs design-token parity

Persona 03

Priyanka

Design manager, 38

“I need to know if my team is using the latest version.”

Priyanka manages three design squads and reports consistency and delivery health to leadership every quarter.

Goals

See adoption per squad at a glance
Reduce duplicated design effort
Prove the system's value with data

Frustrations

No visibility into who uses what
Teams quietly forking components
Anecdotes instead of adoption metrics

Tracks squad adoption
Reports consistency to leadership
Needs dashboard visibility

Impact

+38%

Faster feature delivery

94%

Component adoption across squads

-62%

Accessibility defects at QA

-45%

UI rework per release

Design reviews shifted from pixel debates to product and flow decisions.
New designers and engineers reached productive output in days rather than weeks.