Preventx Clinicial Portal

I worked as design lead and product manager on a complete redesign of a sexual health testing and patient management system.

I was responsible for untangling a web of requirements and technical constraints from legacy systems, designing a complete platform architecture, building a white-label-ready design system, documenting and handing off to developers, whilst validating with NHS clinical workers throughout.

This was one of the most rewarding projects I’ve worked on, as I was lucky enough to see first-hand the improvement this new system was going to make to the day-to-day jobs of NHS healthcare workers.

Preventx facilitate at home STI testing services for NHS trusts.

Their online platform provides two experiences, for:

‘Service users’ (patients), who order and receive their test results.
‘Clinical users’, NHS staff who manage test results and patient outcomes.

The current platform was no longer fit for purpose; pulled together piece-by-piece over the course of 15 years, leading to a fragmented experience for the clinical users, and leaving little room for scaling.

Our brief was to redesign and re-platform the system to create a best-in class experience for patients and clinical users alike, enabling Preventx to onboard more NHS trusts and expand their test offering within the UK and into new markets.

The goal

I began with a discovery phase which involved:

Stakeholder interviews and workshops to understand current platform, requirements, and tech limitations
Service user and clinical user interviews to uncover user needs and pain points
Initial architecture of the portal (a lot of what I’ll show you here)

Followed by an iterative agile design sprint program where I would:

Break down epics and write user stories, prioritising with the client
Design features or journeys, intially wireframing, but eventually building pages from our increasingly comprehensive design system
Test with NHS clinical users each sprint and iterate accordingly
Support my UI designers in getting designs prepped for dev hand-off

The approach

1 Designing a new clinician-centric architecture

From speaking to clinical users, we discovered that information about the service user was spread across the platform. With no single case view, we found that some clinical users resorted to printing out all the relevant pages to see the information in one place. This increased the amount of time the users were spending on each case and created room for dangerous human error.

Exploring methods of providing clincians a single case view, on both web and mobile
Considering the architecture of the full journey, from lists of multiples, to detail views of single patients or cases
Increasing the fidelity, with the constant struggle of keeping the UI clean, but surfacing large volumes of data

A consistent architecture across all key journeys

By simplifying the experience to 2 key page frameworks, I was able to ensure consistency and ease of use for clinical users.

A detail framework would be used for cases, conversations and the service user's profile page.
A list framework would cover the case list, conversations list, user list and work list - with filters to the left and results on the right.

The challenge would then be in choosing the best way to display information within each page, and managing workflows across these pages.

2 Scalable, task-based workflows

The existing platform created a new 'case' for any safeguarding concerns, for each test kit, and for each instance of partner tracing. Because of this, clinical users couldn’t see the whole picture, missing key information that could be relevant to their task.

To provide the clinical users with a holistic view, I re-defined cases to represent an entire episode of care, with the associated actions becoming 'processes' and visible within the case page.

This was a real head-scratcher (bear with me)

To provide a more consistent and automated experience I designed a task-based system for tracking the progress of a case.

In my new system, each case has 4 processes within it (safeguarding, testing, partner tracing, care). Each process has a number of tasks that are either automatically added following a system event (eg: a test kit being received) or manually by a clinical user (eg: a reminder to follow up with the patient).

These tasks each have a due date, and a status based upon this due date (closed, upcoming, due, overdue). The status of the tasks within a process dictates the status of the process.

This new system tested very positively with the clinical users who believed it would prevent cases ‘falling through the cracks’.

As a result of this new system, a clinical user can see a prioritised list of due and overdue cases which they need to action, and exactly what action needs to be taken. No cases get missed.
Now, instead of prescribing a workflow to the clinical user we’re facilitating a clinical user's own workflow.
The case page consists of a section for each process, keeping the key information and the open tasks grouped together.
Building the platform around tasks and processes in a modular fashion makes it much easier to support new features and services in the future.