Patients
An effortless, non-judgmental way to capture pain in the moment — and later see patterns in their own life, in plain language.
Product design case study · Manage My Pain by ManagingLife, Inc.
Making chronic pain legible — for patients, clinicians, and the systems that treat them.
Manage My Pain is a clinically validated digital-health platform that helps people with chronic pain measure, monitor, and communicate what they live with every day. As the product designer and UX engineer on the product since 2021, my job was to turn a medically dense, emotionally heavy problem into an experience that feels calm, trustworthy, and usable — across phone, tablet, and web.
- Role
- Senior UX Engineer
- Problem
- Pain is subjective, invisible, and hard to recall — yet clinical and financial decisions depend on it being captured accurately
- Scale
- Clinically validated product · hundreds of thousands of users across 100+ countries · 4 platforms
- Outcome
- A design system that cut repeated design work and lifted key conversion by double-digit margins
ManagingLife Android · iOS · iPad · Web Since June 2021 · ongoing, fully remote
Why this work mattered
The hardest design problem wasn't the UI — it was the subjectivity.
Chronic pain is long-standing pain that persists beyond normal healing. It affects roughly one in ten people and carries enormous human and economic cost. But the central design challenge is not data entry — it is that pain is invisible, subjective, and emotionally loaded. A patient's memory of a flare-up fades; a clinician needs a structured, comparable picture; a payer needs evidence a treatment is working. One experience has to serve all three without betraying any of them.
Clinicians
A clinically relevant, time-bounded report that turns scattered entries into a decision-grade picture of what changed and why.
Payers & employers
Evidence that a treatment or program is reducing the human and financial cost of chronic pain at a population level.
My role, scope & what I owned
What I actually owned — strategy, roadmap, compliance, and 0→1 discovery.
Product strategy & ownership
On the surface area I led, I owned the design end-to-end and shaped a meaningful share of the product direction — not just the UX layer on top of someone else's roadmap. On adjacent areas outside my surface, I partnered with product and engineering rather than deciding alone.
Compliance as a design constraint
I worked directly with ManagingLife's compliance and engineering teams on the regulated parts. Because the company is Toronto-based (PHIPA/PIPEDA) and serves US and EU users (HIPAA/GDPR), privacy was a constraint I designed against in the room — not a legal review handed off at the end.
Regulated surfaces I designed
- Consent & data-sharing flows — capturing and managing how PHI is shared.
- Role-based access & clinician permissions — who can see and act on what.
- PHI handling — across capture, display, and export, not just storage.
- Data export & deletion workflows — giving people control over their own record.
- Audit-readability of the clinical report — a clinician-facing report has to be defensible, not just readable. Co-designed with engineering and compliance.
Leading ambiguous 0→1 discovery
Several decisions on this product started as undefined problems — separating capture from review, and one data model with two reading modes — that I led from ambiguity to shipped surface: framing the problem, building conviction through research, and defending the tradeoff to people who had a stake in the answer. That is the part of the work I'm hired for.
The constraints I designed within
Healthcare constraints aren't obstacles — they are the design brief.
Constraints shaped every decision here. I list them up front because they explain why a "better-looking" version of any screen was often the wrong answer.
-
Engagement over conversion
This is long-term condition management. Success is sustained, honest use over months and years — not a one-time signup. Every prompt had to respect someone who is tired and in pain.
-
Health literacy & vulnerability
Users span many ages, languages, and literacy levels, often in sensitive physical and emotional states. Clarity and dignity beat polish.
-
Sensitive health data
Pain entries are personal health information. Design had to make capture feel safe and make sharing deliberate, never accidental.
-
Clinical & scientific validity
Reports carry real medical weight. I could not optimize for ease at the cost of the validated measures clinicians rely on.
-
Legacy & platform reality
The product lives on Android, iOS, iPad, and web with existing architecture and constraints. Solutions had to be buildable across all of them.
-
Patient vs. clinician tension
The same data must read as gentle and personal for a patient and as precise and comparable for a clinician. That tension drove most of the information architecture.
Where my judgment showed up
The decisions that required judgment, not just screens.
Drawing the screens is the easy part. The work below is the part that can't be templated: deciding what to build, what to leave out, and how to resolve competing needs under constraints.
Decision 01
Capture pain in the moment — then make meaning later.
The tension: a fast, low-effort entry helps a tired patient record accurately, but a clinician needs depth and structure. I split the experience in two — a friction-light capture flow optimized for someone in pain, and a separate, reflective review surface where patterns become visible. This respected both the human reality (entry must be effortless) and the clinical reality (the report must be rich).
Tradeoff accepted: less data captured per tap at entry, in exchange for more entries captured at all.
Decision 02
Build one design system, not four parallel UIs.
With surfaces on Android, iOS, iPad, and web, the easy path was to design each platform separately. I instead invested in a unified design system so the product felt like one coherent thing and so design work compounded instead of repeating. As a UX engineer, I built components that mapped to implementation, which meant engineers spent less time translating and more time shipping.
More upfront systems work for consistency and speed that paid out over years.
Decision 03
One dataset, two reading modes.
The same longitudinal pain data had to read as gentle and personal for a patient and as precise and comparable for a clinician. Rather than build two products, I built one data model with two presentations: a warm, pattern-led view for the person living with pain, and a dense, time-bounded, clinically structured report for the care team. The patient never has to learn clinical language; the clinician never has to interpret raw logs.
How I built conviction
Research existed to inform a decision — never as a section to fill.
I ran interviews and field observation with patients and clinicians, and shaped provisional personas from what I saw. But I deliberately resisted the "research gallery." Every artifact below earned its place because it changed a decision above — most often by revealing that what a patient could articulate and what a clinician needed were not the same thing.
I observed how patients actually recorded pain between visits and how they tried to describe it to doctors in the room. That gap — between a lived, fading experience and the clinical question "how has it been?" — is the entire reason this product exists, and it set the bar for every capture and reporting decision.
AI in the process
Where AI accelerated the work.
As AI tools matured during this engagement, I folded them into my process rather than treating them as a threat. They made me faster on the parts that should be fast, which left more time for the parts that shouldn't.
Research synthesis
Grouping and theming raw interview and observation notes into patterns far faster than manual tagging, so insight reached the team sooner.
Content & documentation
Drafting component documentation, spec copy, and handoff notes — giving engineers clearer references and freeing me for harder design problems.
Rapid exploration
Generating layout and interaction variations to pressure-test an idea before committing to a build, especially for cross-platform parity.
Repetitive production
Mechanical resizing, token cleanup, and versioning work that once consumed evenings — compressed without lowering the quality bar.
AI in the process
Where AI stopped — and judgment became essential.
The honest half of this story: AI generated possibilities, but it could not own the outcome.
- Identifying the right problem to solve — deciding that capture and review should be separate, for example, came from understanding the lived experience, not from a prompt.
- Domain and clinical judgment — knowing which pain measures carry medical weight and must not be optimized away for ease.
- Resolving competing stakeholder needs — balancing a patient's need for low effort against a clinician's need for structure, where no option is universally correct.
- Interpreting ambiguous research — deciding which observation was signal and which was noise, especially when users couldn't clearly articulate their own needs.
- Taking ownership of tradeoffs — AI can list options; a designer chooses one, defends it, and lives with the result.
Design that knew the code
Being a UX engineer changed the design itself.
Because I work close to implementation, my designs were shaped by what is buildable across four platforms — not just what looks right in a mockup. I built components to map to implementation, wrote user stories and requirements for the front end, and kept clickable prototypes as the shared source of truth so interaction questions were resolved before a ticket was opened.
What changed
Outcomes
Product-level
- Hundreds of thousands of users across more than 100 countries.
- More than a thousand five-star reviews.
- Millions of pain episodes recorded.
- Clinically validated status, supported by the company's evidence work.
Contributory
- The cross-platform design system improved design consistency and delivery efficiency, and cut repeated design work.
- Improvements I led lifted key conversion metrics by meaningful double-digit margins (exact figures are confidential).
- That work contributed to sustained active-user growth within a six-month window.
What I'd carry forward
Reflection — what I learned, and what I'd do differently.
Optimize for the tired user, always.
Designing for someone in pain rewired my defaults. I now assume the user is low on patience and energy, and I treat low effort as a feature, not a compromise.
Separate capture from meaning.
The biggest insight was structural: people can capture fast or reflect deeply, rarely both at once. Splitting the two surfaces changed how I approach any longitudinal-data product.
Systems compound; one-offs decay.
Investing in the design system early was the highest-leverage decision. The cost felt heavy then; the compounding return is what made everything else possible.
I under-indexed on measuring my own impact.
If I restarted, I'd instrument the design's effect more deliberately from day one — not to claim credit, but to learn faster what actually moved engagement.
AI is a teammate, not a verdict.
Folding AI in sped up the mechanical work and exposed, by contrast, where human judgment is irreplaceable. That clarity now shapes how I scope any project.
What surprised me.
How often the 'better' design was the less polished one. In healthcare, restraint and clarity consistently outperformed novelty.
Questions hiring managers ask.
01 How much of the product strategy did you own versus executing within an existing team?
On the surface area I led, I owned the design end-to-end and shaped a meaningful share of the product direction — not just the UX layer on top of someone else's roadmap. On adjacent areas outside my surface, I partnered with product and engineering rather than deciding alone.
See this in the case study ↑ 02 Did you work directly with compliance teams (HIPAA/GDPR), or were engineers/legal responsible?
I worked directly with ManagingLife's compliance and engineering teams on the regulated parts. Because the company is Toronto-based (PHIPA/PIPEDA) and serves US and EU users (HIPAA/GDPR), privacy was a constraint I designed against in the room — not a legal review handed off at the end.
See this in the case study ↑ 03 Did you design consent flows, audit logs, RBAC, clinician permissions, PHI handling, or data deletion workflows?
Yes. I designed and owned consent and data-sharing flows, role-based access and clinician permissions, PHI handling across capture, display, and export, data export and deletion workflows, and the audit-readability of the clinical report. I co-designed the implementation details with engineering and compliance.
See this in the case study ↑ 04 Did you make roadmap decisions or only UX decisions?
Both. On the surface I led, I proposed what to build and influenced the roadmap, not only how it should look. I won't claim I set the roadmap in isolation — that was a shared product call — but I was a voice in it, not just an executor of it.
See this in the case study ↑ 05 Can you lead ambiguous 0→1 product discovery?
Yes. Several decisions on this product started as undefined problems — separating capture from review, and one data model with two reading modes — that I led from ambiguity to shipped surface: framing the problem, building conviction through research, and defending the tradeoff. That is the work I'm hired for.
See this in the case study ↑Next
Want to talk about product design for regulated, high-stakes work?
I'm open to product design and UX engineering roles, and selected long-term consulting — especially in digital health and complex SaaS.