Role
Sole Product Designer
Team
1 PM, 2 Engineers
Timeline
Jan - Apr 2026 (4 mo.)
01 — BACKGROUND
A workflow based on manual entry using spreadsheets and hand-offs
Pager Health lets healthcare companies build employee wellness programs with incentives for health-related activities. Setting one up required a Pager CSM and a client CSM to fill out a spreadsheet together, then Pager's CSM would manually re-enter everything into the Admin Tool. One process, two data entries, neither sufficient.
External problem: Customers couldn't modify their own programs. Any change required a support ticket.
Internal problem: CSMs couldn't resolve issues themselves. Tasks escalated to the data architect.
Result: A pipeline clogged with spreadsheets, tickets, and engineering work.
02 — CONSTRAINTS
We couldn’t modify the database
No new API endpoints. No schema changes. The design challenge was to create a self-serve experience using only frontend changes on a backend that was never built for it.
I positioned to the product manager and engineers that the initial design cleanup is to remove dead fields and translate database language. For each field, I asked “Is it actually used?” and “Does it provide value to our customers?” If the team couldn’t answer yes to both, it was removed.
The PM debated clients had the professional experience to learn the system. But our internal CSMs, people who had worked there for years, were still uncertain about how to use it. A client with no institutional context would have no chance.
03 — DISCOVERY
Two sessions, two perspectives
I held separate discovery sessions with the backend architect and the CSM team so each felt comfortable being candid.
Architect: Data types, validation rules, database logic
Client success manager: What each setting was for and whether it actually served users
Before proposing anything, I asked the architect to query production data for every field and return what clients were actually using. The results made the problem obvious.
Simplifying incentive limits without losing control
Incentive plans allowed four cap combinations: award count, award sum, redeem count, and redeem sum. Each was available at the plan and activity levels. Admins had to decide which made sense for each situation.
Interviews and usage data showed that users constantly misinterpreted the features. More importantly, the problem was that these two levels asked different questions.
Insight: At the plan level, customers cared only about total dollars paid out. At the activity level, they cared only about how often members earned rewards. Showing all four options at both levels made most choices irrelevant in each context.
Recommendation: Limit plan level to total payout caps and limit activity level to earn count caps. Remove the unused options from each level for clarity and focused control.
Before: Four limit types × two levels = eight combinations, most of them meaningless in context.
Limit type | Transaction type | Meaning |
Award | Count | Number of times awarded |
Award | Sum | Total amount awarded |
Redeem | Count | Number of times redeemed |
Redeem | Sum | Total amount redeemed |
After: One limit per level, chosen to match its logical role.
Level | Limit rule | Why |
Plan | Redeem + Sum | Plans set spending limits |
Activity | Award + Count | Activities track earning frequency |
Before: Four limit types × two levels = eight combinations, most of them meaningless in context.
Limit type | Transaction type | Meaning |
Award | Count | Number of times awarded |
Award | Sum | Total amount awarded |
Redeem | Count | Number of times redeemed |
Redeem | Sum | Total amount redeemed |
After: One limit per level, chosen to match its logical role.
Level | Limit rule | Why |
Plan | Redeem + Sum | Plans set spending limits |
Activity | Award + Count | Activities track earning frequency |
Solution: Dropdowns were replaced with sentence-style controls. At the plan level: “$400 redeemed per member per year.” At the activity level: “Members can earn rewards up to 5 times per week.” A cross-functional review with the data architect and CSMs confirmed that the interface was correct by default without instruction.
Limits plan level before: caprule
Limits plan level after: redemption rules
Limits activity level before: caprule
Limits activity level after: earning rules
04 — KEY DECISIONS
Four decisions that shaped the arc
01 — Structural simplification
The prerequisite toggle problem: two booleans with four states, two of them broken
Context: Activities could be gated behind requirements members had to meet first. Admins configured this through two independent boolean toggles: "Is Award" and "Is Visibility."
Problem: Two independent booleans produce four states. No one had asked which states the product actually intended to support. Two were coherent and one was silently blocked server-side. The fourth, a silent auto-grant through an external channel, was a real workflow admins could trigger accidentally but never configure intentionally. The UI exposed a data model that had never been constrained to the states the product needed.
Solution: I reframed the question to, “what should happen to an activity when a member hasn't met its requirements?” A single dropdown with three distinct behaviors (visible but blocked, hidden until ready, auto-granted silently) that replaced two toggles. The unidentified workflow was surfaced, and the invalid combinations could no longer be expressed.
Insight: Interface complexity is often a symptom of a data model that was never asked the right question. The designer's leverage is finding and diagnosing the unconstrained state space and forcing the product decision everyone has been routing around.
02 — PM pushback
Linear wizard vs. grouped wizard: one field per screen wasn’t one decision at a time
Context: The PM proposed a one-field-per-screen wizard that sounded clean in theory, but the configuration was not a sequence of independent decisions. Settings were deeply interdependent. For example, plan-level redemption limits directly affected activity reward limits. A fully linear format would have required users to hold relationships across a dozen screens, or backtrack repeatedly to reconcile decisions they'd already made.
Solution: Rather than argue in the abstract, I built a low-fidelity prototype demonstrating that reconciling two related settings required four navigations. I kept the PM's intent, plain-language questions, but reorganized the flow into four logical sections: Plan Basics, Redemption Rules, Activities & Rewards, and Review & Submit. Summary panels let users see what was configured without losing their current context.
Result: The PM agreed after using the prototype. Design advocacy is most effective when it's tangible. A prototype that demonstrated a problem was more persuasive than a critique that described one.
03 — Engineering constraint
No draft mode: a design which conveyed a sense of control but had no mechanism to control
Context: The backend created database objects at each step of the wizard. There was no draft state. The API was fixed for MVP.
CSM interviews revealed users expected a draft mental model with the ability to save progress, submit when ready, and cancel without consequence. Because the system couldn't support those expectations, the design had to acknowledge the gap honestly.
Design decision | Problem it addressed |
Status messages at every step | Made saved objects visible; confirmed what could be undone |
Delete buttons at each step + review screen | Made every created object visible and removable |
"Cancel" renamed "Save & Exit” | Matched the label to actual system behavior |
Known gap: Orphaned objects remained if users don't clean up (documented for V2). Shipping an honest frontend solution on time was the right decision over a complete solution that would have missed the compliance deadline.
04 — Design limit
Relative dates: hitting the ceiling of what frontend design could solve
Context: Participation windows were stored as date offsets relative to each client's plan year start. "Months 1–3" meant January–March for a January plan and July–September for a July plan. The template was shared across clients with different fiscal years. No frontend change could fix this.
Result: Naming the constraint precisely helped produced the V2 spec: expose plan start date per client so offset translation can happen server-side, making a real date picker viable. A design workaround, written honestly, gives the next designer a clear picture of what exists and what needs to change before it can be removed.
Solution: A collapsible preview tool below the offset inputs. Admins entered their plan start date and saw a live translation. For example, months 1–6 with a January start means members can participate from January through June, and a July start means members can participate from July through December.
05 — VALIDATION
Four studies, progressively higher stakes
The 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 01: 10 internal CSMs, existing interface (baseline)
60% task success / 22 min avg / 65% error rate
Only 4 in 10 understood how changes affected members without the configuration guide. The interface was operable but not self-contained.
Study 02: 10 internal CSMs, configuration as data entry
45% task success / 25 min avg / 75% error rate
A functional minimum: 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. The interface was operable but not legible.
"This is harder than the old way."
Study 03: 10 internal CSMs, configuration as record management
80% task success / 14 min avg / 40% error rate
7 of 10 understood member impact. 10 of 10 preferred the guided flow.
Visual distinction between settled decisions and active edits. Completion improved, accidental edits dropped. But users still lacked confidence and the interface didn't communicate whether their work was finalized or still in progress.
Study 04: 6 external clients, zero training, configuration as authorship
~95% task success / 10–13 min avg / 10–15% error rate
The complete mental model. Save state told users where things stood. Progressive disclosure separated immediate decisions from deferred ones. Structured summaries reflected choices back in plain language. None of these were aesthetic, but 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, and with dramatically higher success than the baseline.
Production risks
Controlled studies showed strong results in an ideal environment. Three risks prevented production deployment following the product pivot, with 20% of implementation incomplete:
01. No production-environment validation: Untested under real data loads, network latency, and integration conditions
02. No draft mode: Objects saved immediately to the backend; orphaned data possible if users abandon mid-flow
03. No automatic date translation: Relative offsets required conceptual understanding; scheduling errors remained possible under stress
06 — SOLUTION
Multi-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.
07 — LEARNINGS
Five things I'd carry into any legacy product project
01 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.
02 "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.
03 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.
04 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.
05 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