STIX

Medical AI · 0→1 product design · MVP definition
Turning a working medical AI model into a testable product

Role: Product Designer
Team: Data scientists, medical researchers and developers
Output: Clickable prototype for clinical validation and development

Context

STIX began as a working AI model that could analyse urine test strips, but there was no product around it.
The proposed application recorded a short video of the strip rather than relying on a single photograph. This gave the model several frames to analyse and increased the accuracy of the reading.
The technology worked, but the team still needed to decide who the product was for, how each user would interact with it, and which part of the larger vision should become the first MVP.

Starting with alignment, not screens

Before designing the interface, I ran a six-hour workshop with the client's data scientists and medical researchers, together with the development team.
We organised the product around three main user perspectives:
  • Clinicians in GP practices, who needed to review a patient's previous tests and see how their results had changed over time.
  • Patients, including pregnant women, who needed to record and submit a test accurately and select the relevant hospital or institution.
  • Researchers, who needed access to anonymised test data and a simple dashboard for reviewing it.
We also identified an administrative role responsible for creating accounts and assigning users to institutions.
During the workshop, we mapped the main scenarios and future journeys, then prioritised features by user value and technical feasibility. This gave the team a shared product definition before development began.

Choosing the first use case

The wider concept could support patients, clinicians and researchers, but trying to deliver every workflow at once would have made the first version too broad.
We decided to focus the initial MVP on research. The first product needed to support the collection of anonymised test results and give researchers a practical way to review the data.
This choice shaped the permissions and information architecture. Research data needed to remain useful without exposing the identity of individual patients, while accounts and institutions still had to be managed correctly.
The clinician view and patient experience remained part of the wider product direction, but we left direct patient-to-doctor test sharing outside the first MVP.

Designing around the model

The capture flow was an important part of the product, not simply a camera interaction. If the test strip was recorded incorrectly, the quality of the input available to the model could be affected.
The patient journey therefore needed to make the submission process clear, help the user send the correct test, and connect it to the appropriate institution.
For clinicians, I explored how individual test results could form a history rather than remain isolated readings. This would allow a clinician to review previous results and understand what had changed over time.
For researchers, I designed a small dashboard for reviewing anonymised tests.

From workshop to prototype

After the workshop, I developed user flows and translated the agreed priorities into a clickable prototype.
The prototype became a shared reference point for medical, research and engineering discussions. Instead of each group imagining a different product, the team could review the same journeys, permissions and system behaviour.

Outcome

The project turned a working medical AI model into a defined product with clear users, workflows and MVP boundaries.
The resulting clickable prototype was handed over for clinical validation and development. It gave the team a practical basis for testing the research workflow before expanding into direct patient and clinician use.