Vera — Mobile App · Process

The full process

The research, personas and flows behind Vera — Mobile App. The case study covers the decisions; this is the work underneath them.

02 — User Research

Who Actually Opens the App

Vera's members are not a single archetype. The app is opened by a working parent triaging a child at bedtime, by a new member deciding whether the membership was worth it, and by someone waiting on a result they are frightened of. Each state needs a different first screen.

👩
Maya Okonjo
Working Parent, 34 · Primary Member
  • Book a same-day visit for her son without a phone call
  • Manage five family profiles from one account
  • Get a straight answer at 9pm without going to urgent care
  • Separate logins for each family member on her old provider
  • Never sure whether a symptom justifies a visit
🧑
Daniel Ruiz
New Member, 41 · Evaluating Value
  • Understand what the membership actually includes
  • See a real person he'll be seeing, not a call centre
  • Know exactly what is billed and what is covered
  • Sceptical of subscription healthcare after past surprise bills
  • Churns quickly if the app feels like every other portal
👵
Priya Raman
Managing a Chronic Condition, 58
  • Understand results without searching medical terms online
  • Ask a follow-up question without booking a whole visit
  • Track a prevention plan over months, not appointments
  • Raw lab values with no interpretation cause days of anxiety
  • Has to re-explain her history to whoever picks up

03 — Defining the Opportunity

Core Challenges

CHALLENGE 01
🌿
Premium Without Coldness

"Handcrafted and premium" in most product categories means dark, minimal and precise. In healthcare that reads as clinical and expensive. The app needed a luxury register built from warmth — cream, botanical green, editorial serif — rather than from restraint alone.

CHALLENGE 02
🧠
One Screen, Many States

The home screen serves a member with nothing happening, a member with a visit in two hours, and a member with an unread result. A static dashboard serves all three badly. The home screen had to know which of those was true and lead with it.

CHALLENGE 03
🔒
Trust Without Friction

Health data demands biometric locks, secure screens and privacy messaging. Every one of those is friction. Placed badly, security theatre makes an app feel bureaucratic — the exact quality the membership is meant to eliminate.

CHALLENGE 04
⚠️
The Emergency Boundary

A calm, always-available care app risks becoming the first place someone goes during a genuine emergency. The product needed a quiet, permanent boundary that never alarms in normal use but is unmissable in the moment it matters.


04 — Discovery & Research

Market Insights

FINDING 01
4.1x
Continuity Drives Outcomes

Patients who see the same clinician consistently show materially better chronic disease outcomes and fewer emergency department visits. Continuity is not a comfort feature — it is a clinical outcome driver, which makes surfacing the named care team a health decision, not a brand one. (Source: BJGP Continuity of Care Study 2023)

FINDING 02
63%
Process Anxiety, Not Medical Anxiety

A majority of patients report anxiety about the process of getting care — the booking, the waiting, the not-knowing — distinct from anxiety about the medical issue itself. The booking and results flows are therefore anxiety-management surfaces, not just transactional ones. (Source: Nuffield Trust Patient Experience Report 2024)

FINDING 03
78%
Same-Day Access Is the Switch Trigger

In direct primary care models, same-day availability is cited by the large majority of new members as the reason they switched. Anything in the app that hides or delays that promise — extra taps, unclear availability — attacks the core value proposition. (Source: DPC Journal Patient Survey 2024)


05 — User Flow

The Member Journey

STEP 01
Editorial Onboarding
Three beats that establish the brand before asking for anything: what the membership is, the four people who will know you, and the proof that others trust it.
STEP 02
Passwordless Entry
Magic-link sign-in — no password to forget or reset. Biometric app lock is offered immediately after, as an opt-in with a plain explanation of what it protects.
STEP 03
Meet Your Team
Before the app is ever used, the four faces are introduced by name and role. The relationship is established at first run, not discovered later in a menu.
STEP 04
Today, Derived
A single contextual hero card computed from live state — next visit, then unread result, then a warm default. Acting on it changes what the card becomes.
STEP 05
Book, Message, Read
Three-step booking that ends in a morph animation; one team thread for messages; results that open with a plain-language sentence before any number appears.

06 — Toolkits

Tools & Workflow

This project was designed and built end-to-end — from PRD and brand lock through an interactive HTML prototype to a shipping native Android codebase.

📐Claude CodeDesign & Build
🤖Jetpack ComposeNative UI
📰Fraunces & Instrument SansTypography
🗄️Room & DataStoreLocal-First Data
🧪HTML PrototypeFlow Validation
Kotlin Jetpack Compose Material 3 Navigation Compose Room 2.6 + KSP DataStore Preferences androidx.biometric SharedTransitionLayout Coil-SVG

07 — Design Strategy

From brand lock
to running code.

The sequence mattered here more than usual. Because the brief demanded a specific emotional quality, the brand had to be locked — colour, type, motion character — before a single screen was laid out. Every subsequent decision was measured against it, and the ones that failed were the ones that were technically correct but tonally wrong.

01
PRD & Brand Lock
Wrote the product requirements and a separate brand-lock document first: exact palette, type axes, motion spring constants, and a written rule that no default Material component would ship. Fixing this early prevented the slow drift toward generic that most app projects suffer.
02
Interactive HTML Prototype
Built every flow as a tappable HTML prototype at 390×844 before writing Kotlin. This surfaced the booking sequence problem in an afternoon rather than after a week of Compose work — the three-question flow was reordered twice at prototype stage and never touched again.
03
Content Design Before UI
Wrote the plain-language result copy before designing the result screen. "Everything looks healthy, Maya" is the design; the gauges are decoration around it. Leading with content forced the layout to serve the sentence rather than the data table.
04
Custom Component System
Built a floating pill tab bar, a hand-drawn 1.75px-stroke icon set on Canvas, illustrated SVG avatars, and custom cards, chips, gauges and switches. Nothing was inherited from the Material default set — the visual signature lives in these small parts.
05
Local-First Data Layer
Appointments, messages, record items and plan milestones live in Room, seeded on first run; settings and session in DataStore. Book a visit, kill the app, relaunch — it is still there. The repository is a deliberate seam where a real backend plugs in without touching the UI.
06
Accessibility & Motion Discipline
Dynamic type honoured plus an in-app larger-text toggle; touch targets at or above 48dp; status always encoded as colour plus icon plus words. Reduce-motion collapses every spring and reveal to a 150ms fade — the app degrades to calm, never to broken.

Back Return to the case study