X-Lab Systems are a health-tech company that specialise in connecting diagnostic systems across the globe.
UX/UI Design
WEB APP DESIGN
Role
Freelance Senior Product Designer.
Electronic lab testing requests in the UK were limited to hospitals and general practices only, which meant that everyone else in occupation health was limited to paper-based requests, resulting in inefficient and unsafe processes.
Errors in diagnosis
4.4%
Diagnostic errors were occurring in approx. 4.4% of all consultations,
Time-consuming processes
~52m
On average, 52 minutes was spent filling out manual forms, significantly impacting clinical decision-making.
Impact on patient safety
37%
37% of all test requests in the UK contained some aspect of patient misidentification.
Source: Consensus - Cheraghi-Sohi et al., 2018, 2021, Litchfield et al., 2015
To start, I mapped out the test ordering flow with technical considerations, in collaboration with the Product Manager and Engineering Lead. This ensured my designs would be robust enough to accommodate future changes and additions.
Originally, the flow for ordering a lab test was made up of the following steps.
I aimed to balance user input and automation to prevent errors while ensuring enough ‘friction’ to prompt the requester to consider their actions and feel confident in their input.
Fine tuning the flow
After testing various prototypes both internally and externally, it became evident that the flow was incomplete. Two key steps were missing:
1. Order date – allowing tests to be requested immediately or scheduled for a later date.
2. Clinical details – adding an extra layer of information to the request, to help prevent errors between the requester and the testing lab.
Order date
The requester could now specify whether their order was immediate or scheduled for a future date right from the start of the test ordering process.
Search for a patient & Patient details
Originally, numerous patient details were required to progress, with minimal automation. Which was easier to implement but placed the responsibility on the requester to get things correct.
Including a ‘search for a patient’ feature streamlined the process for the requester by autofilling the patient’s details where relevant.
Selecting tests
Selecting tests underwent several iterations to balance function and form. Initially, it involved simply searching for a test. Later, I tested the idea of grouping tests, such as a full blood test, which includes specimen details.
The final test selection method subtly yet effectively combined both approaches, allowing users to select a test and specify specimen types if needed.
Clinical details
By incorporating a clinical details step, the requester gained the ability to input, add and remove clinical details through a free text field.
Specimen details
This step was vital for preserving the accuracy of information transfer between the requester and the testing lab. The specimen type and associated tests were seamlessly carried over from the test selection step, and the requester had the option to generate a barcode if needed. Furthermore, they could view the required container type (colour-coded) and specify the collection time.
Order summary
The summary step prior to submitting the order was designed to verify the accuracy of all details and ensure that no information was overlooked.
The requester had several different ‘points of entry’ for receiving test results. In the initial stages, all options were open, so I mapped out the journey to address various considerations, providing technical perspective and aligning with the requester’s experience. Additionally, legal compliance was a crucial factor to consider.
Viewing orders & searching for a patient
In the early stages of testing with users, I had designed the platform to have separate sections for home, ordering a test and orders.
After testing a few variations, it became obvious that there wasn't a need for separate 'home' and 'order' sections. Instead I created a view that incorporated the two sections through a broader and more powerful search. Additionally I included functionality to allow orders to be filtered.
Mobile experience
SMS notifications were included for requesters who might not always have access to a computer, such as sports team physicians.
However, since a mobile experience was not part of the pilot phase, I designed a screen that gave the requester the top line results, but prompted them to use a computer to view the full report.
Notifications of results
The primary way for requesters to review test results was through email, however, I wanted to include a way they could be notified through the platform itself, so I created a notification feature which lived in the header and linked through to the specified test result.
There were (or are) a lot of different types and I wanted to create something plain, simple and modular that could give the requester the information they needed as quickly and effectively as possible.
Following usability testing, I found that the use of colour in the original design conveyed the wrong message, by showing that something was good or bad.
This was a reminder that the results needed to appear neutral for analytical purposes and not be guided by aesthetics, for example, a normality 'above range', wasn't always a bad thing.
Before
After
Before
After
There was also a legal requirement where the requester had to acknowledge the test, which triggered an internal record, which both the requester and testing lab could review if anything had gone wrong.
