Clinical teams were managing complex patient information across fragmented tools and manual processes. I led UX research and product design for an MVP concept exploring how teams could recognise emerging patient risk earlier, understand what required attention, and move from signal to action.
Patient dropout can disrupt clinical trials, but it is not something a dashboard can simply “solve”. The opportunity for the product was further upstream.
Our early research suggested that clinical teams were working across fragmented information, monitoring large numbers of patients manually, and sometimes recognising concerning patterns only after they had developed.
How might we help clinical teams recognise emerging risk earlier and understand where their attention is needed?
Product question that guided the MVPThat question became the foundation of the product.
As UX Researcher and Product Designer, I led research and synthesis, developed the information architecture, shaped features and interaction patterns, facilitated collaborative workshops, and translated the emerging product direction into wireframes and an interactive Figma prototype.
I worked closely with the Product Owner, engineering, QA, a cognitive researcher, business stakeholders, and clinical experts. The project reached a testable MVP prototype stage, but not production measurement, so this case study focuses on the reasoning and product decisions rather than unmeasured outcomes.
Direct access to patients was heavily restricted, so I began by building an understanding of the problem through secondary research and the people closest to the clinical workflow. I reviewed academic literature around patient dropout and engagement in clinical trials, particularly in oncology, to establish the broader context and identify possible factors contributing to disengagement.
I then facilitated a workshop with the team to map the patient journey as we understood it across onboarding, waiting, treatment, and post-treatment. At this stage, the journey was deliberately treated as a set of assumptions rather than validated patient behaviour.
Clinical expert interview — building an understanding of workflows, information needs and constraints when direct patient access was limited.
Through semi-structured interviews with a trial physician and nurse, I explored their workflows, pain points, compliance challenges, information needs, and the ways they compensated for limitations in existing tools. Later, together with another researcher, we spoke with three additional clinical experts to challenge and refine our understanding.
The research gave us a clearer problem, but it did not immediately tell us what the interface should look like. Rather than starting with “What should go on the dashboard?”, I started with the decisions clinical trial managers needed to make.
Research-informed Trial Manager profile and journey — used to connect workflow context with information and decision needs.
The information requirements suggested that a single dashboard would not be enough. Managers needed to move between different levels of decision-making. That led to a three-level product structure.
The dashboard architecture was therefore not the starting point of the solution. It was a consequence of the information needs identified through research.
Once the information requirements and initial structure were clearer, I brought together engineering, the Product Owner, business stakeholders, a cognitive researcher, and QA. The purpose of the workshop was not to present a finished design for approval. It was to explore how the product requirements could become a feasible product together.
Collaborative workshop — translating information needs into a feasible dashboard structure with product and technical stakeholders.
As the product grew across overview, trial, and task levels, navigation became an important interaction problem. I explored the information architecture and navigation through low-fidelity wireframes before moving into higher-fidelity prototypes.
Low-fidelity wireframe — exploring the relationship between the global overview, individual trials and deeper product areas.
Designing the dashboard was not only about arranging cards or visualising metrics. The more important question was which information belonged there in the first place.
Research and expert input helped establish the information users needed to make decisions. I used those needs to shape the hierarchy and worked with the Product Owner and technical team around what information the system could realistically provide.
The model generated the signal. The interface needed to provide context.
The predictive model itself was not my responsibility. But how its output became meaningful to a human user was a design problem. Rather than treating a risk score as a self-explanatory number, I designed the experience so users could move from a signal toward the information behind it.
As the dashboards developed, another question emerged: should every manager see the same information in the same configuration? In collaboration with the Product Owner, we explored a more flexible dashboard model that allowed information to be organised according to different priorities.
Customisable dashboard direction — allowing users to prioritise information while preserving the product's underlying hierarchy.
In a clinical environment, visual hierarchy has consequences. High-priority information needs to stand out, but if everything looks urgent, nothing is. The interface therefore used multiple signals — hierarchy, labels, icons, status indicators, and restrained use of colour — to distinguish different levels of attention.
Red was reserved for information requiring genuine urgency rather than being used as the default visual language for risk. The intention was to help users recognise priority without turning the entire dashboard into an alarm state.
When I joined the project, an early prototype already existed. It had been created before substantial UX research and did not yet reflect the workflows and information needs we later uncovered.
Over seven months, the work moved from understanding the domain and defining the problem to establishing information requirements, product architecture, dashboard hierarchy, navigation, interaction patterns, and an interactive Figma prototype.
After
Before
Design evolution — original prototype (left) and the later MVP concept (right).
The result was not a finished or validated clinical product. It was a structured MVP concept ready for further validation and iteration.
The project gave us a clearer understanding of the clinical workflow and allowed me to translate that understanding into a coherent product concept. But the project ended before we could establish whether the solution improved real-world clinical or business outcomes, so I cannot claim that the product reduced patient dropout.
The next step would be to validate whether clinical trial managers can identify which trial requires attention, recognise the patient or activity requiring investigation, understand why something has been flagged, locate supporting information, and determine the appropriate next action.
I would use task completion, time on task, navigation errors, comprehension of risk indicators, and qualitative confidence as proposed usability measures. If the product moved into production, the next level would be behavioural measurement: whether relevant risks were identified and acted on earlier.
What I learned: a dashboard is not primarily a collection of components or metrics. It is a prioritisation system. Before deciding how information should look, I need to understand what decisions users are trying to make, what information supports those decisions, and what deserves their attention first.