X-Lab Systems had an ambitious product idea which would revolutionise how healthcare workers request lab tests and receive test results. I was tasked with taking their 'Order Comms' product from idea to MVP.
Result
From the ground up, I was in charge of designing an innovative health-tech platform that caught the attention of multiple labs and general practices throughout the UK. This led to a fully-funded pilot phase. Furthermore, I meticulously crafted a comprehensive set of brand guidelines and a UI library, ensuring that no detail was overlooked.
The lay of the land
Existing Order Comms solutions (OCS) are mostly so specific that they only work for one GP or hospital. One solution that is used in the UK is ICE (Integrated Clinical Environment), which is available for select GPs and hospitals. ICE is a powerful too, but has a few critical problems that prohibit widespread adoption and use outside of specific hospitals and GPs:
It is not always accessible outside a hospital’s network, which limits requesting for on-site visits etc
ICE doesn’t work in some cases if the patient isn’t registered with the hospital and/or within its catchment area
Licence fees can be a huge expense for low-volume users
ICE in all it's 80's glory
Principles
As with any startup, there are lot's of moving parts which change and shift very quickly. In this rapidly evolving environment, I created a set of design principles to help keep important values front and centre in the design process.
How to get results
One of my key focus areas was on results, specifically how they are received, displayed and subsequently acknowledged. I started out by setting out the flow of how this would work functionally. I purposely included aspects that were out of scope, to ensure that the designs would be flexible to accommodate any changes as X-Lab scaled.
Exploring results
The design explorations for results underwent a number of different iterations following feedback from stakeholders and prospective customers. One key insight was that requesters would methodically read test information in the following order; patient information, order details and results. Of all participants, not one deviated from this on-page flow.
Initial experimentation with page layout. Exploring modules to house different patient and test related data.
Introduced patient information in an expand/collapse container to help surface relevant information
at a scannable level and reduce the page noise. Also introduced test requester acknowledgement.
Results
Through a few quick rounds of feedback both internally and externally, I landed on a clean and effective UI. This was deliberately simple, to allow for flexibility when presenting different types of results back e.g. multiple similar tests, multiple different tests, numerous single tests etc.
Ordering a test
Another key aspect of this project was the process of ordering a test. This experienced needed to be significantly different from manually filling out a paper form. Which can be partially achieved through design, however it also relied on things like automation and pre-population to expedite the order.
It's worth noting that there are strict information handling requirements for patient information - this was a continuous thread which had an impact on the UX at large - in short, what's legal ain't always pretty...
Step 1 in the ordering a test process.
Step 4 in the ordering a test process.
Plays well with others
Everything I designed for the OCS needed to work in unison with another product (Labgnostic) from an implementation perspective. The quickest and most effective way I achieved this was by presenting most information in modules, which were clean and clear but also malleable and to a large extent, future-proof.
Searching for an order module
Orders workflow module
Test results report module
Searching for a patient module
