Role
Sole Product Designer
Team
1 PM, 2 Engineers
Timeline
Jan - Apr 2026 (4 mo.)
TL;DRSetting up an incentive program at Pager Health used to take two people and a spreadsheet: a CSM filled it out with the client, then keyed the same data into an internal admin tool by hand. Clients had no way to change anything themselves, so even small edits turned into support tickets, and 80% of users still needed a guide just to get through setup.
The backend was too fragile to touch on this timeline, so I redesigned the whole configuration experience using only frontend and plain language. I cut 8 configuration paths down to 2, replaced a broken boolean toggle with a single outcome-based dropdown, and reworked a proposed one-field-per-screen wizard into four grouped sections that kept prior decisions visible as users moved through it.
Results: task completion got 40% faster, 20 redundant fields came out entirely, and all six external clients tested completed setup with zero training. That's a real jump from the baseline, where only 64% of users who technically "completed" the task had actually configured it correctly.
SOLUTIONMulti-step wizard with preserved context
Grouped wizard format: Four sections, each with a summary panel showing prior decisions, so users could see how choices connected without backtracking.
Plain language throughout: Every decision got reflected back in plain terms, with the database schema kept out of view entirely.
Progressive disclosure: Advanced options stayed hidden until they were relevant. Twenty unnecessary fields came out.
Delete controls at every step: Every object a user created stayed visible and deletable, closing the gap where drafts used to go missing.
Explicit, outcome-based labels: Navigation described what an action actually did, not the internal name the system used for it.
Contextual explanations: Explained the architectural constraints directly and pointed users toward what actually worked within them.
Data-driven defaults: I removed fields with no real production usage, so the wizard only asked for what completing the task required.
BACKGROUNDPager Health partners with 10 healthcare companies to deliver rewards-based wellness programs, offered as an employee benefit through the employers those 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, 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 because the configuration was too difficult to complete directly or because 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 I could pull.
DESIGN CHALLENGEBuild a genuinely 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 counted from each client's plan year start. That meant "months 1 to 3" was January through March for one client and July through September for another, and no frontend change could fix that, since the logic lived in the backend. What I could do was add a live preview: admins enter their plan start date and see the actual date range their settings produce, so they can check it visually instead of doing the math in their head. Writing the constraint down clearly also gave us a real spec for the eventual fix, exposing plan start dates so a true date picker becomes possible.
Task completion: 12% drop-off, 40% of total failure, 100% (n=30)
Simplifying Configuration: From Caprules to Plain-Language Rules
Admins really only cared about two things: total dollars at the plan level, and reward frequency at the activity level. But the form spread eight configuration paths across both of those. I moved each setting to where admins expected to find it and swapped raw fields for plain-language sentences. Task completion had already been sitting at 100%, but silent misconfiguration was happening underneath that number, so closing that gap mattered as much as cutting 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 produced four possible combinations, and only two of them actually worked. One combination looked valid but silently failed. Another worked, but only by accident, there was no way for an admin to choose it on purpose. I replaced both toggles with a single plain-language dropdown, which made the broken combination impossible to select in the first place.
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 sounded simple, until I actually mapped the workflow and found the decisions were tangled together, plan-level redemption limits affected activity reward limits, so a linear format would make admins recall or re-navigate every time they needed to reconcile two settings. Instead of arguing that in the abstract, I built a low-fidelity prototype and showed that reconciling two related settings took four separate navigations in the linear version. The PM tried it and agreed on the spot. A working prototype that showed the problem beat a critique that just 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 rounds exposed: things like status indicators and contextual prompts aren't complexity, they're part of how a user builds a mental model of what's happening. Stripping them out didn't simplify the experience. It just made it harder to read.
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. Without the guide, only 4 of 10 understood how their changes affected members. It worked, but only with help.
Study 02, functional minimum. A table with inline inputs, no status feedback, no visual hierarchy. The theory was that less interface meant less cognitive load. What it actually removed was the user's ability to make sense of the task. Half the participants found this harder than the old way.
Study 03, record management. 7 of 10 understood the impact on members, and all 10 preferred the guided flow over the old one. Distinguishing settled decisions from active edits visually improved completion and cut down on accidental edits, but people still weren't confident their work was actually finalized.
Study 04, authorship. This is where the full mental model came together: save state told users where things stood, progressive disclosure kept immediate decisions separate from deferred ones, and structured summaries reflected choices back in plain language. None of that was decoration, it was signal the first version had stripped out, and it turned out to be load-bearing. External clients with no product background finished setup only a little slower than trained internal staff, and did dramatically better than the baseline.
Production risks. Controlled studies showed strong results in an ideal environment, but three risks kept this out of production after the product pivot, with 20% of implementation left 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 work as a design research tool. When I asked the architect to pull usage data on every field, it gave us objective grounds to cut features, without turning it into a stakeholder debate.
- Treating "no prior training needed" as a hard requirement forced good decisions. If cross-functional review couldn't explain what a setting was actually for, that setting usually didn't need to exist. That one framing is what eliminated the 20 fields.
- Weekly whiteboarding with engineers heads off handoff surprises. The architect caught 6 major issues in those sessions, issues that would otherwise have turned into 2 to 3 week rework cycles if we'd found them after handoff.
- Button labels carry as much weight as layout does. "Cancel" versus "Save & Exit" looks trivial until an engineer asks what cancel actually cancels, and you realize the label was doing work it couldn't actually do.
- Writing down a constraint you can't solve is still design work. The date offset problem had no frontend fix, full stop. But documenting what it was, why it existed, and what would need to change made V2 actionable instead of speculative. Being honest about a limit is more useful than pretending there's a design solution for everything.
Made with Bullet