From Spreadsheet to System
Livongo offered 5 health programs — Diabetes, Hypertension, Weight Management, Diabetes Prevention, and Behavioral Health — sold standalone or bundled into "Whole Person" solutions. Each client purchased a different combination. Each combination changed which registration fields were shown, required, or hidden.
The configuration lived in a spreadsheet: 50 client configurations × 74 registration fields = 3,700 decision points. Operations managed this manually. New client onboarding required cross-referencing dozens of field visibility rules, qualification criteria, eligibility checks, and billing types.
SF
Salesforce Config
- Program bundle selection
- Pricing tier & enrollment caps
- Eligibility rules & billing type
- Field visibility (Show/Require/Skip)
50 configs × 74 fields
→
API
Data Resolution
- Employer HR → name, DOB, address
- Health Records → diagnosis, A1C
- Carrier Data → insurance, coverage
57% of fields sourced before first screen
→
UX
Registration Flow
- 6 steps (down from 9)
- Confirm, don't enter
- Adapts per client config
- ~5 min saved per registration
Recognition over recall
💡
The core design principle
Shift the member experience from data entry to data confirmation. Three upstream services resolve member data before the first screen loads. The member validates what the system already knows rather than starting from blank forms.
Impact at a Glance
57%
Fields Sourced
20 of 35 fields ready to confirm — not type from scratch
33%
Fewer Steps
6 steps vs. 9 — coverage + coaching handled elsewhere
~5 min
Time Saved
~3 minutes vs. ~8 minutes average
Side-by-Side Comparison
Two Paths, One Goal
The optimized flow sources data upstream so the user arrives already known to the system.
Original Flow
9 Steps
User enters all information manually from scratch. Every field requires input.
View Original Flow →
-
1
Name, email, password, DOB, phone — all blank
-
2
Manual address entry
-
3
Search for employer or enter coverage code
-
4
Loading state while eligibility is checked
-
5
Enter insurance provider, member ID, group ID
-
6
Health questions — diabetes type, diagnosis, meds
-
7
Notification setup and coaching thresholds
-
8
Full health survey — height, weight, conditions, habits
-
9
Completion screen
Optimized Flow
6 Steps
−3 Steps
20 of 35 fields pre-populated from employer, health plan, and carrier data. Coverage verified server-side; coaching moved to on-device setup.
View Optimized Flow →
-
1
Confirm Identity ConfirmEnter name & DOB to verify enrollment
-
2
Create Account User entersEmail, password, and phone to set up access
-
3
Diabetes Program Setup ConfirmMonitoring routine — CGM, blood glucose, meds from records
-
4
Health History ConfirmHeight, weight, conditions, lifestyle — some from records, some user-entered
-
5
Receiving Your Device ConfirmShipping address from employer records — confirm or edit
-
6
Next steps: app, coach, and kit setup
-
–
Coverage Search / Verification / Insurance SkippedEmployer sponsorship verified server-side
-
–
Coaching & Alerts SkippedDeferred to on-device setup after first use
💡
Tip: Click any step name to jump to that screen in the prototype. Use arrow keys or step buttons to navigate within each flow.
Design Rationale
What Changed
Four shifts in the experience when upstream data is available.
From Data Entry to Data Confirmation
20 of 35 fields arrive pre-populated from employer HR, health plan records, and carrier APIs. Each field is labeled with its source. The user reviews, edits if needed, and moves on — recognition instead of recall.
Coverage Steps Skipped
Employer sponsorship and insurance eligibility are verified server-side before the user sees their first screen. No searching for employers, no member IDs, no group codes — three steps removed entirely.
Multi-Source Data Integration
Three data sources feed the flow: employer HR (identity, address), health plan claims (clinical history, conditions), and carrier APIs (device detection). Each source is color-coded — blue for employer, teal for health records, purple for carrier — so users see exactly where each data point came from.
Partnership, Not Paperwork
Each step explains why it matters and where the data came from. The system shows what it knows, the user fills in what only they can share, and together they build a complete health picture.
System Architecture
How the Optimized Flow Works
Three services resolve member data before the first screen loads.
User Lookup
Resolves a UUID or basic identifiers (name, DOB, zip) to a unique member record. Entry point for all downstream data sourcing.
Inputs: UUID or First + Last + DOB + Zip
Output: Canonical member ID
Output: Canonical member ID
Profiler
Aggregates data from employer HR, health plan claims, pharmacy records, and carrier APIs into a single member profile.
Sources: Employer HR, Health Plan, Pharmacy, Carrier
Output: Unified member profile (24 fields)
Output: Unified member profile (24 fields)
Question Engine
Scores each field against available data. High-confidence fields are pre-filled for confirmation; low-confidence fields are left for the user.
Input: Question ID + Member Profile
Output: Answer + Confidence Score
Output: Answer + Confidence Score
UUID / Name+DOB+Zip
→
🔍 User Lookup
→
📋 Profiler
→
🧠 Question Engine
→
✅ Sourced Form
Detailed Field Analysis
Breakdown by Field
Every field in the flow — how it's handled in each version and where the data comes from.
35 Fields — 14 Confirm, 7 User-Entered, 12 Skipped, 2 Partial
Scroll horizontally on small screens to see all columns.
| Field Name | Original Flow | Optimized Flow | Data Source | Notes |
|---|---|---|---|---|
| Steps 1–2 — Confirm Identity & Create Account | ||||
| Legal First Name | Manual entry | 🔴 User enters | ✏️ User Enters | Identity confirmation |
| Legal Last Name | Manual entry | 🔴 User enters | ✏️ User Enters | Identity confirmation |
| Email Address | Manual entry | 🔴 User enters | ✏️ User Enters | Member enters on account creation step |
| Password | Manual entry | 🔴 User enters | ✏️ User Enters | Security requirement |
| Mobile Phone | Manual entry | 🔴 User enters | ✏️ User Enters | Personal device |
| Date of Birth | Manual entry | 🔴 User enters | ✏️ User Enters | Identity confirmation |
| Language | Manual entry | 🟢 Confirm | ✏️ User Enters | Footer selection — defaults English |
| Steps 3–5 — Coverage Search, Verification & Insurance | ||||
| Coverage Search | Manual search | ⚠ Skipped | 🏢 Employer HR | Employer sponsorship — verified server-side |
| Insurance Provider | Manual entry | ⚠ Skipped | 🏢 Employer HR | Employer benefits — verified server-side |
| Member ID | Manual entry | ⚠ Skipped | 🏢 Employer HR | Employer benefits — verified server-side |
| Group ID | Manual entry | ⚠ Skipped | 🏢 Employer HR | Employer benefits — verified server-side |
| Step 3 — Supporting Your Diabetes | ||||
| Gender | Manual entry | ⚠ Skipped | 🏢 Employer HR | Auto-confirmed from employer records |
| Diabetes Type | Manual entry | ⚠ Skipped | 🏥 Health Records | Auto-confirmed from health records |
| Diagnosis Date | Manual entry | ⚠ Skipped | 🏥 Health Records | Auto-confirmed from health records |
| A1C Check | Manual entry | ⚠ Skipped | 🏥 Health Records | Auto-confirmed from health records |
| Medications | Manual entry | ⚠ Skipped | 🏥 Health Records | Auto-confirmed from pharmacy claims data |
| BG Check Frequency | Manual entry | 🟢 Confirm | 🏥 Health Records | Inferred from supply orders |
| Doctor BG Recommendation | Manual entry | 🟢 Confirm | 🏥 Health Records | From diabetes care plan notes |
| Exams History | Manual entry | ⚠ Skipped | 🏥 Health Records | Auto-confirmed — exams within last year from claims data |
| CGM Usage | Manual entry | 🟢 Confirm | 🏥 Health Records | Moved to diabetes step for continuity |
| Coaching & Alerts — Moved to On-Device Setup | ||||
| Coaching Thresholds | Manual entry | ↗ Moved | ⏳ Deferred | Moved to on-device onboarding |
| Contact Method | Manual entry | ↗ Moved | ⏳ Deferred | Moved to on-device onboarding |
| Step 4 — Health History | ||||
| Height | Manual entry | 🟢 Confirm | 🏥 Health Records | From most recent clinical record |
| Weight | Manual entry | 🟢 Confirm | 🏥 Health Records | From most recent clinical record |
| Conditions | Manual entry | 🟡 Partial | 🏥 Health Records | HBP from records; user adds others |
| Smoking Status | Manual entry | 🟢 Confirm | 🏥 Health Records | From clinical notes / ICD codes |
| Vaccines | Manual entry | 🟡 Partial | 🏥 Health Records | Flu from records; pneumonia user-entered |
| Activity Level | Manual entry | 🔴 User enters | ✏️ User Enters | Lifestyle — not in records |
| Eating Habits | Manual entry | 🔴 User enters | ✏️ User Enters | Lifestyle — not in records |
| Demographics | Manual entry | 🔴 User enters | ✏️ User Enters | Optional self-reported |
| Step 5 — Your Welcome Kit | ||||
| Street Address | Manual entry | 🟢 Confirm | 🏢 Employer HR | User confirms |
| Apt / Suite | Manual entry | 🔴 User enters | ✏️ User Enters | Often not in records |
| City | Manual entry | 🟢 Confirm | 🏢 Employer HR | |
| State | Manual entry | 🟢 Confirm | 🏢 Employer HR | |
| Zip Code | Manual entry | 🟢 Confirm | 🏢 Employer HR | |
The Structural Parallel
This is a CPQ problem
Configure
Client purchases a program bundle. Programs = SKUs. Each bundle defines which fields, qualifications, and billing rules apply.
Price
Qualification criteria determine eligibility. Pricing rules = field visibility rules. The "price" is which experience the member gets.
Quote
The registration flow is the "quote" — a personalized experience generated from configuration data. One of thousands of possible combinations.
The spreadsheet that governed Livongo's registration is the same kind of artifact that Salesforce CPQ generates today — and the same kind of artifact that modern CPQ platforms are replacing with guided, automated configuration.