Sayantani Mukherjee

Case study 03Amura HealthUX research

A visual could not fix a summary panel that was never designed for the people using it.

Care teams kept missing client details. The fix on the table was a visual on top of the summary panel. Field research showed the care team had stopped opening that panel. The real job was rebuilding it around what health coaches and doctors need during a live client interaction.

Role
UX Researcher. I led the research end to end and specified the information hierarchy.
Duration
32 days of research and design. Rollout and measurement from March to May 2026.
Participants
6 of 42 care teams: 12 health coaches and 6 doctors.
Impact
Across the same 282 clients, flagged friction from missing client data fell 49.7% between March and May 2026.
Methods
Situational client cases, five second testing, field observation, critical incident technique, affinity mapping, stakeholder validation, open and closed card sorting, MoSCoW prioritisation, information architecture, first click testing, scenario testing
00The problem

What I was asked for and what I actually solved

The request

“Add a visualisation of client’s data on top of the summary panel so health coaches and doctors can read a client at a glance.”

What the team believed

Care teams were missing client details because the summary panel had no at a glance view. A visual layer would close the gap.

What the research showed

The care team had stopped opening the summary panel. They were running client interactions from handwritten diaries. The same client details went missing again and again.

The problem I solved

The summary panel did not surface what health coaches and doctors need during a live client interaction. It had to be rebuilt around both roles.

Why it mattered to the business: missing client context at the point of care created friction in conversations. When the same gap came up again with the same client, it turned into an escalation, which pulls in managers and wears down the care team.

What I led and conducted

  • Team selection and the first study
  • Field observation that surfaced the diaries
  • Critical incident sessions and affinity mapping
  • The interim tracking sheet
  • Card sorting and MoSCoW prioritisation
  • The information hierarchy
  • First click and scenario testing

Who I worked with

  • The Head of Health Coaches and the Head of Doctors, who curated the client situations and signed off the priorities
  • Team leads, who checked nothing was missing and later flagged friction for the impact measure
  • 12 health coaches and 6 doctors across 6 teams

What others built

  • The UX team built the low fidelity panel from my hierarchy
  • In that handoff we renamed it from summary panel to Client case panel
01My process

Reframe, stop the harm, then rebuild

The work ran in three movements: a prioritisation round that turned into a reframe, a fast intervention to stop client data going missing while the redesign ran, then the structural work that produced the new panel.

Reframe · 11 days
  1. First study: situational cases and five second tests1.5 weeks
  2. Discovery through field observation3 days
Stop the harm · 10 days
  1. Critical incident sessions, affinity mapping, sign off and the tracking sheet10 days
Rebuild · 11 days
  1. Open card sorting2 days
  2. Closed card sorting3 days
  3. MoSCoW prioritisation1 day
  4. Information hierarchy2 days
  5. Validation3 days
Figure 01The 32 days as one continuous timeline. Close to a third of it went into stopping the harm before any screen was designed, because missing client data was causing friction with clients while the redesign was still underway.
02The research context

Where the summary panel sits

The core health software is a five panel workspace that care teams use to supervise asynchronous clinical protocols. Panel 02, the summary panel, was built to give the clinical overview of a client. It was live across every team, yet field observation showed it did not support real time triage.

Figure 02The workspace a health coach or doctor has open during a client interaction. The summary panel is meant to be the first thing they read. Whether they actually read it is what this project tested.
03The brief and the first study1.5 weeks

Deciding what the visual should show

The ask was a visual summary layered on the existing panel. To decide what it should surface, I narrowed the 42 care teams to the 6 where client details were going missing most often, then ran two methods side by side with them. The output was meant to be a priority list for the visual.

42care teams across the organisation

Ranked on how often client details were going missing at the point of care

6teams studied · 12 health coaches and 6 doctors

Situational client cases

Realistic client scenarios showed what a coach and a doctor each reach for first when the clock is running.

Five second testing

The current summary panel was shown briefly, then recalled. This measured what the existing layout actually surfaced first for each role.

Figure 03Starting where the problem was worst. Choosing the six teams with the most missing client details meant any pattern would show up quickly. It did.
What came back

The two roles read a client through different data. More importantly, both were working around the summary panel rather than from it.

04The discovery3 days

They had left the panel behind

While running those sessions I noticed something the brief had not accounted for. Each clinician kept a physical diary covering all of their clients, filled in by hand. The entries were inconsistent and often incomplete. The same client details went missing again and again.

Insight

The care team was not supplementing the summary panel. They had stopped opening it.

A visualisation of the client data on top of a summary panel nobody opened would change nothing. The summary panel had never matched the way clinicians work, so it needed rebuilding from the data up.

The brief that was given

A visualisation of client data on top of the summary panel

The brief that was discovered

A summary panel that was never designed for either role

Figure 04The reframe. The brief that was given solved for a surface. The brief that was discovered solved for the structure underneath it. Everything after this point answers the second one.
05Stopping the harm10 days

Making capture reliable before redesigning anything

The redesign would take weeks, but the gaps were causing harm now. So the first job was to get the right client data captured consistently, with the people who would use it.

  1. Step 01

    Scenario sessions, using the critical incident technique

    Six sessions, one per team, each working through five very different client situations. The Head of Health Coaches and the Head of Doctors curated them as situations that happen often and need careful handling.

    • One session per team, so team habits stay visible
    • Situations curated by the two heads, not by me
    • Watch what they reach for, avoid asking what they want
  2. Step 02

    Affinity mapping

    I clustered the session notes until the data a coach must have separated cleanly from the data a doctor must have.

    • Cluster by the moment of need, not by data type
    • Keep the two roles separable through every pass
    • A field earns a place only if it changed a decision in session
  3. Step 03

    Stakeholder validation

    I reviewed the priorities with the Head of Health Coaches, the Head of Doctors and the team leads, so nothing critical was missing before anything went live.

    • Sign off from both role heads and the team leads
    • Disagreements resolved in the room, not by averaging
  4. Step 04

    The interim tracking sheet

    I built a tracking sheet from the agreed priorities, so the care team could start capturing the right data on day one while the redesign ran.

    • Ship the fix before the redesign, because the friction was live
    • Every field maps back to a session observation
Figure 05The ten day sequence from first session to a live tracking sheet. The rules under each step are the constraints I held myself to, so the priorities came from observed behaviour rather than opinion.

“I completely understand that doctors need to view the medical data first, but they do not interact with each client at least 3 times a day. We do that and for that we need to remember the last 2 to 3 requests or doubts and also how their behaviour is in general.”

Health coach, scenario session

“Maybe we should have separate dashboards.”

Doctor, scenario session
Decision

One panel that opens on what both roles share, then lets each role go deeper into what only they need. Separate dashboards would have split one client into two partial views.

New_Template.xlsx shared drive · maintained by hand · one row per client
Identity and case · 7
Food data · 5
Progress · 10
Initial data · 9
Risk and attention · 6
Medical workflow · 8
Medical data · 5
Client Name
Client Number
Treating Doctor
Coaching Team
Implementation Status
Status
Phase
Dietary Preference
Pr g/d (g)
Protein Choice
Fiber Choice
Identified Allergies / Intolerance
21 Days earlier Weight (kg)
14 Days earlier Weight (kg)
7 Days earlier Weight (kg)
Current Weight (kg)
Start Weight (kg)
Target Weight (kg)
Weight loss remaining (kg)
Start BMI
Current BMI
Progression score
Types of Client
Health Goal
Lifestyle / Occupation
Why / Value
Country
City
Gender (M/F/O)
Age
Height (cm)
Next action required
Attention needed
HEC
Prone to Engagement
Medically sensitive
Active Medical Concern
SAQ Filled
Reports Submitted
Validation Call Asked
Validation Call Booked
Validation Call Done
Diagnosis Sent
Prescription Sent
Revised Prescription Sent
Diagnosed Medical Condition
Medication & Titration History
Add on Prescriptions
Hypertension
Diabetes
OG Live groupsLive groupsDataClosed groups

Scroll sideways, the way the care team had to.

Figure 06The tracking sheet as it went live: 50 columns in seven groups, one row per client, with client rows anonymised. It fixed capture. It was also far too wide to be the answer on a screen.
A trade off I accepted

Before release, the Head of Health Coaches and the Head of Doctors added many more fields, because to them everything felt essential. I let the sheet grow. My real output was the information hierarchy of the panel. A wide, well maintained dataset would give me evidence to narrow with later.

06From the tracker to the hierarchy8 days

Deciding what a clinician sees first

With capture stable, I designed the hierarchy for the new panel. The tracker could hold every field the heads wanted. A panel read in the middle of a client conversation could not. The question was never what data existed. It was what each role needs in that moment and what can wait.

Five figures carry the decision, in this order:

  1. Figure 07What the tracker held
  2. Figure 08How the teams sorted it
  3. Figure 09Who needed what and where it landed
  4. Figure 10The new hierarchy
  5. Figure 11The panel it produced

Identity and case7

Client Name, Client Number, Treating Doctor, Coaching Team, Implementation Status, Status, Phase

Food data5

Dietary Preference, Pr g/d (g), Protein Choice, Fiber Choice, Identified Allergies / Intolerance

Progress10

21 Days earlier Weight (kg), 14 Days earlier Weight (kg), 7 Days earlier Weight (kg), Current Weight (kg), Start Weight (kg), Target Weight (kg), Weight loss remaining (kg), Start BMI, Current BMI, Progression score

Initial data9

Types of Client, Health Goal, Lifestyle / Occupation, Why / Value, Country, City, Gender (M/F/O), Age, Height (cm)

Risk and attention6

Next action required, Attention needed, HEC, Prone to Engagement, Medically sensitive, Active Medical Concern

Medical workflow8

SAQ Filled, Reports Submitted, Validation Call Asked, Validation Call Booked, Validation Call Done, Diagnosis Sent, Prescription Sent, Revised Prescription Sent

Medical data5

Diagnosed Medical Condition, Medication & Titration History, Add on Prescriptions, Hypertension, Diabetes

Working artefact: the data guidance counsellors, health coaches and doctors were each collecting per client before the redesign
Working artefactWhat each role was already collecting per client: guidance counsellors at sales and onboarding, health coaches day to day, doctors for medical oversight. Select to enlarge.
Figure 07What the tracker held, grouped exactly as the sheet was structured. Comprehensive for a clinician scrolling at a desk. Far more than anyone can read mid conversation, which is the constraint the rest of this section works against.

How I narrowed it

I wanted the cut made on evidence rather than taste, so three methods ran in sequence, each deciding something the next one depended on.

  1. Stage 012 days

    Open card sorting

    Clinicians grouped the fields freely against a real scenario, starring the ones that are critical before responding to a client. This showed the categories they already think in, not the ones the sheet imposed.

    • Their labels, never mine
    • Roles sorted separately, so divergence stayed visible
  2. Stage 023 days

    Closed card sorting

    The candidate groupings were then tested as fixed categories, to confirm the structure held when fields had to be placed inside it.

    • A category survives only if roles place fields consistently
    • Anything repeatedly misplaced gets renamed or removed
  3. Stage 031 day

    MoSCoW with a top task lens

    Fields were sorted into must, should, could and will not for the screen, weighted by the tasks clinicians perform most often.

    • Only a must have for both roles can reach tier one
    • Will not on screen still lives in the product, so nothing is lost
Card sorting board: data point cards, a star step for the ten most critical before responding to a client, a why and how step, then a layout step
a. The sorting boardParticipants starred the ten data points they must see before responding to the client in the scenario, then explained why and sketched how they would arrange them.
Venn map of data points marked critical by doctors, guidance counsellors and health coaches, with a shared core in the centre
b. Where the roles overlappedWhat doctors, guidance counsellors and health coaches each marked as critical. The centre is the shared core. The edges are needs only one role has.
Prioritisation map linking goals and medical profile fields to doctors, guidance counsellors and health coaches, headed by the rule that a field needs at least two must haves
c. The prioritisation mapEach role’s must haves traced field by field. The rule written at the top is the one that decided the summary.
Figure 08The sorting and prioritisation evidence, shown as the working artefacts rather than redrawn. Select any artefact to enlarge it.
The selection rule

A field could only enter the summary with at least two roles marking it a must have. The health coach plus doctor pair carried the deciding weight. Qualifying was necessary, not sufficient: the MoSCoW cut kept tier one to what a clinician needs in the first five seconds.

Filled circle: the role marked the field critical on the sorting board. Placement: where the field sits in the final panel specification.
FieldDoctorHealth coachGuidance counsellorLanded inWhere exactly
On the case summary, always visible
Phase and phase dayTier 1Case summary: medical status, phase and day
Progression scoreTier 1Case summary
New diagnosisTier 1Case summary: diagnosed conditions
Conditions and symptoms reported during the programTier 1Case summary: active medical concern
MedicationsTier 1Case summary: current medications and dosage
Dietary preferenceTier 1Case summary
Qualified, placed one search away
Height and start weightTier 2Client’s initial data
Health objective and client’s whyTier 2Client’s initial data
Medical and surgical historyTier 2Client’s initial data
Known allergiesTier 2Food and diet
Target weightTier 2Surveillance data
EngagementTier 2Surveillance data
Client motivationTier 2Client’s initial data
Needed by one role only
7 and 14 day earlier weightTier 2Surveillance data
Fibre choice, eating out, food behaviour patternTier 2Food and diet
Purpose triggerTier 2Client’s initial data
Weight loss remainingTier 2Surveillance data
Not on the sorting board, kept in the profile
Phone number, emergency contact, birthdayNot sortedProfileClient profile, not the summary
Language, occupation, guidance counsellor nameNot sortedProfileClient profile, not the summary
Figure 09Field by field: which roles marked it critical and where it landed. Every sorted field that reached the case summary was marked by both the doctor and the health coach. Fields one role needed moved to tier two rather than off the product. Contact and admin details were never on the sorting board and stay in the client profile.
Tier 1

Case summary

Always visible. Read in the first five seconds. Shared by both roles.

Who and whereName, age, gender · Country and timezone
Clinical stateMedical status, phase and day · Diagnosed conditions · Active medical concerns · Current medications and dosage
TrajectoryProgression score · Dietary preference
What happens nextNext action
Tier 2

Further details

Searchable, grouped in sections. Reached for during a conversation.

Client’s initial dataHeight · Start and target weight · Health objective · Client’s why · Medical and surgical history · Work schedule · Routine stability · Family context · Archetype
Food and dietProtein and fibre · Meal preparation · Eating out · Food behaviour pattern · Allergies and intolerances
Active patient managementSymptom tracker · Prescriptions · HIC and HEC flags · Engagement
Surveillance data7 and 14 day weight · Weight loss remaining · Compliance · Responsiveness
Status and workflowReports and validation calls · Follow up date · Prescription status
Tier 3

Deep archives

Secondary tabs. Opened only in a full clinical review.

Historic recordLab report timelines · Revision history · Past prescriptions
Figure 10The information hierarchy I specified for the Client case panel. Tier one is read in the first five seconds, tier two is searched mid conversation, tier three opens only in a full clinical review. This was my deliverable to the UX team.
Handoff

In the handoff to the UX team the panel was renamed from summary panel to Client case panel, to signal a rebuild rather than a reskin.

07The panel it produced

Where the research became a design decision

The UX team built the low fidelity panel from the hierarchy. It opens on the case summary, then puts everything else behind search and grouped sections. Annotations from the build ask for a full view on hover for long medical fields and a sticky section header while scrolling.

Before: the live summary panel
Before: the original summary panel profile view, with client details redacted Before: the original summary panel topic list, with diagnostic and protocol content withheld under NDA

Identity fields up top, then an undifferentiated scroll of topics. Every retrieval was a hunt. Client details are redacted and clinical content is withheld under NDA.

After: the low fidelity Client case panel Two low fidelity frames of the Client case panel: case summary fields on top, further details below with search and a sticky section header, with annotations asking for a full view on hover

Built by the UX team from the hierarchy in Figure 10. The second frame keeps a slot for a case summary visualisation, the original request, sitting above a structure that now works without it. Sample data only.

Figure 11Before and after. The old panel made a clinician hunt. The new one answers the first questions of a live interaction without scrolling. It keeps the rest one search away.
08Validating the model3 days

Two questions decided whether the structure worked

The low fidelity panel carried every field from the tracker, so before it went further I tested the two things that mattered most in a live interaction.

Can a clinician find a specific parameter fast?

First click testing in the UAT lab · 12 health coaches and 6 doctors from the 6 teams

  • Where would you click to find whether this client is prone to escalation?Expected path: tier 2, active patient management
  • Where would you check what the client weighed two weeks ago?Expected path: tier 2, surveillance data
  • Where would you look for the client’s last lab report?Expected path: tier 3, deep archives
82%first click success across 12 health coaches
94%first click success across 6 doctors

Doctors found what they needed almost every time. Coaches sat lower, which tracks with the sorting: their data spreads across more of tier two, so more of their retrieval depends on the section labels rather than on tier one.

Does the case summary alone give enough to act on?

Scenario testing with real cases from past clients · reading tier one only · same participants

  • A client messages that they have been skipping the fibre drink and feel low on energy. Read the case summary only, then say what you would do next.Does tier one alone support the right next action
  • A doctor picks up a client mid phase with a new symptom reported. Read the case summary only, then say whether this needs escalation.Does tier one alone support a safe clinical judgement

For both roles the case summary covered what was needed in most cases. The exceptions were consistent:

Where coaches needed more than tier one

  • High engagement clients
  • Clients who are extremely friendly and share a lot of context
  • Clients asking for clarification on medical data
  • Clients who have altered the protocol repeatedly

Where doctors needed more than tier one

  • Medically complicated clients
  • Clients with many medical documents uploaded
  • Clients who share a great deal of day to day life context
What the tests showed

Tier one holds for the standard case. The exceptions are clients carrying more history or context than a summary can compress, which argues for how tier two is reached, not for putting more on the surface.

09Impact

Friction from missing client data, before and after

  1. Business problemMissing client context at the point of care caused friction. Repeat gaps with the same client became escalations.
  2. Research findingThe care team had left the summary panel for handwritten diaries, so capture was inconsistent.
  3. InterventionThe tracking sheet made the required fields explicit for every client, while the new panel was designed.
  4. Observed outcomeAcross the same clients, flagged friction fell by about half.
608→306friction points flagged across the same 282 clients, March to May 2026
2.16→1.09friction points per client, so roughly two became one
49.7%fewer flags overall, with every one of the six teams improving
How this was measured

Each team lead flagged, per client, where missing data or context created friction at the point of care. The same 6 teams and the same 282 clients were measured twice: first in March 2026, when those clients sat in phases V1 to V3, then in May 2026, when they had moved to V3 to V6. This measures the capture change. The new panel was not yet live in this window.

March 2026, phases V1 to V3May 2026, same clients, V3 to V6

Friction points per client, teams ordered by their March load

The numbers behind the chart
Friction points flagged by team leads where missing client data or context caused friction
TeamClientsMarch 2026, phases V1 to V3May 2026, same clients, V3 to V6Change
FlagsPer clientFlagsPer client
Team 41461162.52541.1753.4%
Team 439982.51471.2152.0%
Team 27571021.79560.9845.1%
Team 20521132.17591.1347.8%
Team 1139872.23421.0851.7%
Team 3549921.88480.9847.8%
All six teams2826082.163061.0949.7%
Figure 12Every team improved, by between 45.1% and 53.4%. The teams starting from the heaviest load moved furthest: Team 41 and Team 4 began above 2.5 friction points per client and cut more than half, while Team 27, already the lightest at 1.79, had the least room and moved least.

An effect that shows up across six teams working independently is hard to attribute to any single team’s habits. Part of the fall still reflects clients maturing into later phases with fuller records, so I read it as the capture change plus natural maturation, with capture as the lever the team could actually pull.

10Limitations

What this study can and cannot claim

  • One organisation, 6 of 42 teams. The findings describe how Amura’s care teams work, not clinical tooling in general.
  • Small validation samples. 12 coaches and 6 doctors make the first click and scenario results directional rather than precise.
  • A judgement based measure. Friction was flagged by team leads, applied consistently within the study but not an external standard.
  • No control cohort. The before and after follows the same clients across program phases, so maturation shares credit with the capture change.
  • The panel itself is not yet measured in use. The impact reflects capture through the tracking sheet. Validation of the panel happened in the lab.
11Next steps

If I were taking this forward

These are open questions the study leaves, not work that has happened.

  1. Separate capture from maturation.Compare a cohort moving from V1 to V3 into V3 to V6 without the tracking sheet, which would isolate how much of the drop the capture change caused.

  2. Test the panel in live workflows.Lab first clicks show where people look. Live use shows whether the hierarchy holds once the panel is no longer new.

  3. Measure time to retrieve.First click success says whether people start in the right place, not how long a live answer takes. Timing it would show the real cost of a tier two lookup.

  4. Stress tier one as complexity grows.Scenario tests already named where the summary runs out: high engagement, medically complicated and heavily documented clients. Those cases are where the next iteration should be tested.

  5. Check the coach gap.Coaches trailed doctors on first click. A tree test on the tier two section labels would show whether the naming is the cause.

  6. Include guidance counsellors.They were on the sorting board but not in validation. They also collect the first client data the panel depends on.