Designing how the product learns after launch

Usage data can show that a clinician clicked a feature.

It cannot, by itself, show whether they understood the result or trusted it.

I worked on a feedback and instrumentation model that separated product behaviour from clinical confidence.

The problem

VoxelBox was introducing unfamiliar workflows and capabilities.

When a feature was not used, several explanations were possible: the user did not discover it, did not understand it, the result was not clinically relevant, the control was too difficult to use, the user did not trust the generated output, the user completed the task elsewhere, or the feature was valuable only for a subset of cases.

A large event-tracking list would not resolve this ambiguity.

The model

I grouped product evidence into a few useful categories.

Activation

Did the user reach and perform the core workflow? For example, opening a processed result and meaningfully interacting with the relevant imaging output.

Friction

Where did the workflow break or require repeated effort? Failed uploads, repeated attempts, abandoned reporting actions and difficulty reaching important controls.

Retention

Did users return to the core clinical workflow across cases? Repeated use of the viewer or reporting flow was more meaningful than isolated interaction with secondary utilities.

Explicit clinical feedback

Did the output help, confuse or change the user’s interpretation? This required targeted feedback rather than assuming intent from clicks.

My approach

I reduced the event list to signals the team could actually use.

For every event, the question was:

What decision would we make differently after seeing this?

If there was no clear answer, the event was not essential.

I also separated on-tool feedback captured in the context of a case, off-tool feedback gathered through interviews and support, release education such as guides and contextual prompts, and usability issues, which should not be confused with disagreement about the science.

Why this work matters

A product does not become evidence-driven by collecting more data.

It becomes evidence-driven when the team can distinguish behaviour, usability and clinical value well enough to make a decision.