Role
Sole Product Designer
Team
1 PM, 2 Engineers
Timeline
Jan - Apr 2026 (4 mo.)
TL;DRPager Health's incentive program setup was a manual, two-person relay: a spreadsheet handoff followed by manual data entry into an internal admin tool, with no self-serve option. Every change meant a support ticket, and 80% of users still needed a guide to get through it. With the backend too brittle to touch, I redesigned the entire configuration experience using only frontend and plain language: consolidating 8 configuration paths into 2, replacing a broken boolean toggle with a single outcome-based dropdown, and reorganizing a proposed one-field-per-screen wizard into four grouped sections with persistent context.
Results: 40% faster task completion, 20 redundant fields eliminated, and 6/6 external clients completed setup with zero training, up from a baseline where only 64% of users who "completed" the task had actually configured it correctly.
SOLUTIONMulti-step wizard with preserved context
Grouped wizard format: Four logical sections with summary panels that kept prior decisions visible, letting users understand how choices related without backtracking.
Plain language throughout: Decisions reflected back in plain terms. No database schema visible to users.
Progressive disclosure: Advanced options hidden until relevant. Twenty unnecessary fields removed.
Delete controls at every step: Every created object was visible and deletable, resolving the draft-mode gap.
Explicit, outcome-based labels: Navigation reflected what actions did, not what the system called them internally.
Contextual explanations: Clarified architectural constraints and guided users toward correct use within system limits.
Data-driven defaults: Fields without production usage were removed. The wizard emphasized what completing the task actually required.
BACKGROUNDPager Health partners with 10 healthcare companies to deliver rewards-based wellness programs. These programs are offered as an employee benefit through the employers these companies serve. Workers earn rewards for healthy habits, and incentive plans define the reward structure and how employees redeem them.
PROBLEMA manual, two-step configuration process. Setting up an incentive program meant a clunky relay between people: a Pager CSM and a client CSM filled out a shared spreadsheet together, and then the Pager CSM manually keyed that data into an internal admin tool.
No self-serve option, so every change meant a ticket. Once a program was live, clients had no way to modify it themselves. Any change, no matter how small, required filing a support ticket. This left Pager CSMs frequently blocked and pushed client requests up the chain to the data architect.
80% of users (12 of 15) referred to the configuration guide, because the UI didn't clearly distinguish system inputs from user intent.
33% of users (5 of 15) escalated to the data architect, either the configuration was too difficult to complete directly, or the guide itself fell short.
CONSTRAINTThe backend was too brittle to restructure within the MVP timeline, which ruled out new APIs or database changes and left frontend as the only lever we could pull.
DESIGN CHALLENGEBuild a truly self-service experience using nothing but frontend design and plain language, on top of a backend that was never built for it.
DECISIONS & OUTCOMESRelative Dates: Hitting the Ceiling of What Frontend Design Could Solve
Participation windows were stored as date offsets relative to each client's plan year start, so "months 1 to 3" meant January to March for one client and July to September for another, a problem no frontend change alone could fix since the logic lived in the backend. I added a live preview instead: admins enter their plan start date and instantly see the real date range their settings produce, turning an abstract offset into something they can visually confirm. Naming the constraint precisely also produced a clear spec for the actual fix, exposing plan start dates so a true date picker becomes viable.
Task completion: 12% drop-off, 40% of total failure, 100% (n=30)
Simplifying Configuration: From Caprules to Plain-Language Rules
Admins only cared about two things, total dollars at the plan level and reward frequency at the activity level, but the form exposed eight configuration paths across both. I moved each setting to where admins actually expected it, and replaced raw fields with plain-language sentences. Silent misconfiguration had been invisible even at 100% task completion, so closing it mattered as much as the path count.
Configuration paths: 8 to 2. Silent misconfiguration: 36% to 0%
The Prerequisite Toggle Problem: Two Booleans, Four States, Two Broken
Two independent toggles created four possible combinations, only two of which worked. One looked valid and silently failed. One worked by accident, with no way for admins to choose it on purpose. I replaced both with a single plain-language dropdown, making the broken state impossible to select.
Task completion: 63% to 87%. First-try accuracy nearly doubled. Misreading errors down about 80%
Linear Wizard vs. Grouped Wizard: One Field Per Screen Wasn't One Decision at a Time
A one-field-per-screen wizard seemed simple until mapping the workflow showed the decisions were deeply interdependent, plan-level redemption limits affected activity reward limits, so a linear format would force admins to recall or re-navigate to reconcile settings. Rather than argue this in the abstract, I built a low-fidelity prototype showing that reconciling two related settings required four navigations. The PM agreed after using it firsthand: a working prototype that demonstrated the problem was more persuasive than a critique that only described it.
Navigations to reconcile two related settings in the linear format: 4
VALIDATIONThe hypothesis: a stripped-back interface would be easier to use than a complex one. Build the functional minimum, validate it, add complexity only when the cost of leaving it out is proven.
What the early iterations exposed: signals, status indicators, visual cues, and contextual prompts aren't complexity, they're the mechanism behind a user's mental model. Removing them doesn't simplify the experience. It makes it illegible.
Study | Participants | Format tested | Task success | Avg. time | Error rate |
1 (baseline) | 10 internal CSMs | Existing interface | 60% | 22 min | 65% |
2 | 10 internal CSMs | Configuration as data entry | 45% | 25 min | 75% |
3 | 10 internal CSMs | Configuration as record management | 80% | 14 min | 40% |
4 | 6 external clients, zero training | Configuration as authorship | 95% | 13 min | 12% |
Study 01, baseline. Only 4 of 10 understood how changes affected members without the configuration guide. Operable, but not self-contained.
Study 02, functional minimum. A table with inline inputs, no status feedback, no visual hierarchy. The hypothesis was that less interface meant less cognitive load. What it actually removed was the user's ability to make sense of the task. Operable, but not legible. Half the participants found this harder than the old way.
Study 03, record management. 7 of 10 understood member impact, 10 of 10 preferred the guided flow. Visual distinction between settled decisions and active edits improved completion and reduced accidental edits, but users still lacked confidence that their work was finalized.
Study 04, authorship. The complete mental model: save state told users where things stood, progressive disclosure separated immediate decisions from deferred ones, and structured summaries reflected choices back in plain language. None of these were aesthetic choices, they were signals the first iteration deliberately removed, now proven load-bearing. External clients with no product knowledge completed setup only slightly slower than trained internal staff, with dramatically higher success than baseline.
Production risks. Controlled studies showed strong results in an ideal environment, but three risks prevented production deployment following the product pivot, with 20% of implementation incomplete:
- No production-environment validation. Untested under real data loads, network latency, and integration conditions.
- No draft mode. Objects saved immediately to the backend, so orphaned data was possible if users abandoned mid-flow.
- No automatic date translation. Relative offsets still required conceptual understanding, so scheduling errors remained possible under stress.
LEARNINGSFive things I'd carry into any legacy product project
- Database queries are a design research tool. Asking the architect to pull usage data on every field gave objective grounds to remove features, no stakeholder debate required.
- "No prior training needed" is a forcing function. When cross-functional review couldn't explain what a setting was for, it usually meant the setting shouldn't exist. That framing eliminated 20 fields.
- Weekly whiteboarding with engineers prevents handoff surprises. The architect caught 6 major issues in working sessions that would have been 2–3 week rework cycles discovered after handoff.
- Button labels carry as much weight as layout. "Cancel" vs. "Save & Exit" seems trivial until an engineer asks "what does cancel actually cancel?" and exposes a label doing work it can't do.
- Naming unsolvable constraints is design work. The date offset problem had no frontend fix. Documenting what it was, why it existed, and what would need to change made V2 actionable instead of speculative. Honest documentation of limits is more credible and more useful than pretending every problem has a design solution.
Made with Bullet