Case Study · IMeasureU / Vicon · 2022–2024

Ensuring data accuracy: a re-alignment challenge for Knee Monitor.

A post-surgery rehab wearable started getting flagged for unreliable data. The hardware was fine. The UI was burying the one action that kept the data trustworthy — so users skipped it. This is how that got fixed.

Role · Senior Product Designer Team · 7 across product, engineering, clinical Tools · Figma, FigJam, Miro

In a nutshell

The product.

Knee Monitor is a system of wearable sensors and a companion app that helps physiotherapists accurately assess, monitor, and improve knee rehabilitation for patients recovering from surgery.

The accuracy of every measurement depends on one thing: the sensors staying in the right position on the patient's leg.

Knee Monitor app screen showing a patient assessment in progress

The situation

A splash of negative feedback, when the lab said the product was solid.

31%

of users were complaining that the product wasn't telling the truth.

Our lab tests demonstrated very stable, reliable results. Out in the world, customers were saying something different.

Being an advocate for the best user experience, I stepped up to investigate the gap between what the device measured in a controlled environment and what physiotherapists were seeing in clinic.

Challenge overview

The accuracy gap was a UI problem, not a hardware one.

Sensor accuracy depends on proper alignment, and the sensors are prone to slipping or shifting during patient movement. Hardware improvements to the attachment method were slow. Algorithmic improvements were even slower. So the fastest path to better data ran through the interface.

The job was to make the need for re-alignment unmissable, and the re-alignment itself smooth enough that physiotherapists would actually do it mid-assessment.

31% of users complained the product was untruthful
68% corrected sensor placement mid-assessment without re-aligning
1% noticed the sensor had moved at all
0% ran the in-app re-alignment flow

Zero. Not "low adoption" — zero. The feature existed in the app and no one used it. That's the number that defined the brief.

Diagnosis

This is how the app looked at that point.

Original Knee Monitor app interface with the re-alignment warning at the top and the button out of view when scrolled

The re-alignment control sat at the top of the screen. Once the physiotherapist scrolled down to actually run an assessment, the button was out of view. The warning above it was easy to miss — and even when it wasn't, the path to act on it was painful:

  • Hold the warning in mind while running the rest of the assessment.
  • Scroll to the top to reach the re-align button — losing the assessment's place.
  • Complete the re-alignment, scroll back down, and hunt for where the assessment was interrupted.

Stack those three frictions on top of a clinician already managing a patient and a stopwatch, and the rational move is: skip it.

The team

Seven people, one shared brief.

A small cross-functional group with the Product Specialist embedded as a live bridge to the user community — he's a practising physiotherapist himself.

Mari
Mari
Senior Product Designer
Sybille
Sybille
Lead Algorithm Engineer
Kate
Kate
Software Developer
Andy
Andy
Product Manager
John
Melody
Dr. Physical Therapist · Persona
Melody
Brian
Patient · Total Knee Replacement · Persona
Brian
John
Dr. Physical Therapist · Product Specialist

Approach

An outcome-first, user-centred approach.

My priority as design lead was to make sure the team was building toward an outcome — better data — rather than shipping a feature. That meant getting close to the users, keeping engineering in the conversation early, and iterating in the open.

Direct user engagement

The PM and I embedded with physiotherapists — in-person interviews and observational sessions in real clinic settings. Workflows, frustrations, aspirations. Every design decision had a thread back to one of those rooms.

Cross-functional from day one

Our Product Specialist — a practising physiotherapist — was the live bridge to the user community. The Software Developer and Lead Algorithm Engineer were in early and often, so the constraint-feasibility conversation happened alongside the design exploration, not after it.

Iterate and validate

Figma for rapid prototyping. Usability sessions with physiotherapists for each pass. The feedback loop was tight enough that decisions had evidence behind them by the time they reached engineering.

Open communication

Slack, Google Meet, and Zoom for the day-to-day. Miro and FigJam as the shared canvases for synthesis. Google Forms for short user pulses when we needed signal fast.

Process at a high level

Five stages, one loop.

Identify the problem

Frame the re-alignment gap and its impact on data accuracy and trust.

Conduct user research

Observe physiotherapists in real sessions. Interviews and surveys to surface pain points around sensor alignment.

Ideate solutions

Brainstorm approaches against research findings. Weigh feasibility and UX impact.

Prototype and test

Translate the strongest options into interactive prototypes. Validate with physiotherapists.

Refine, ship, reflect

Detail the final design, hand off to engineering, document outcomes and lessons.

The solution

A re-alignment reminder that follows the user.

The re-alignment tab attached to the test tile, visible throughout the assessment

A persistent tab attached to every test tile that requires sensors. It travels with the assessment, asks a single clear question, and demands no action unless the sensors actually moved.

  • Sticks to every test tile that depends on sensors — always within reach, never blocking the assessment.
  • Active at any stage of the test, not just at the start.
  • Clear language so the user immediately understands when a re-alignment is needed.
  • No action required if the sensors haven't moved — the tab stays quiet by default.

Tab over button. A/B testing showed clinicians preferred the tab pattern over a button. Tabs suggest persistence and exploration — they let users investigate information without losing the context of the assessment they're running. The decision came from users, not from us.

User flow

Re-alignment, in four moments.

Active patient assessment with the re-alignment tab visible
01 · Active assessment

The sensor slips.

During an assessment, the physiotherapist notices a sensor has shifted from its place.

The re-alignment tab catches the user's attention with a clear prompt
02 · Reminder in action

The tab asks the question.

"Has the sensor moved 1 inch or more?" — short, specific, impossible to misread. The physiotherapist taps the tab.

The re-alignment journey running inline within the test tile
03 · Re-alignment flow

It runs inline.

The re-alignment journey is incorporated into the test tile itself — no jumping to a separate screen and no lost context.

The user returned automatically to the original test tab after re-alignment
04 · Back to assessment

The user is returned automatically.

Once the re-alignment is done, the app auto-returns to the test tab the clinician was working in.

Supporting detail

The "why" and "when" sit one tap away.

Information about why alignment matters and when it's required is parked on an additional info tab — available when the user wants it, never blocking the assessment.

The additional info tab explaining why and when re-alignment is required

The results

The numbers moved, and the complaints stopped.

The persistent, integrated re-alignment reminder addressed the issue on three fronts: it prompted users clearly without interrupting them, it dropped the cost of acting on the prompt to almost nothing, and it made data accuracy a natural side-effect of the workflow rather than a discipline the user had to enforce.

93% drop in users complaining the product was untruthful
100% of users now do the re-alignment when prompted
100% of users now notice when the sensor has moved

From 0% running the flow to 100% running it — and the trust signal in customer feedback moved with it. The hardware hadn't changed; the workflow had.

Lessons

What this taught us about designing for clinical tools.