Footage from our research trip to Mumbai – I am pictured pre-pandemic wearing a mandatory N95 mask while observing users in a mobile TB lab
I was Lead Product Designer in a cross-disciplinary team of 16 on a project spanning 7 years, helping to drive and influence product decisions and strategy.
I was initially approached by a Computational Biologist at Oxford University to create an identity and user interface for a family of digital diagnostic tools which are able to identify Tuberculosis (TB) species and antibiotic resistance.
The goal was to take the existing command-line products…
$ mykrobe_atlas predict\
--sample MDR_1\
--species tb\
--seq /MDR_1.fastq.gz
…and make them appealing and usable to non-specialist users. I was asked to create a product with charm.
The target users are non-specialist and non-technical nurses who may sometimes be working in remote areas, often using laptops and with unreliable internet connectivity. This meant the solution had to be something that could be downloaded and then subsequently used offline.
All users would have access to digital DNA sequence files generated by lab-based sequencing machines, with some having early access to pioneering USB-stick sized sequencer from Oxford Nanopore.
Given their sequence file, these users want to quickly know if and what strain of TB their sample contains, and if so what antibiotics it is likely susceptible to. This informs a potential course of treatment and gives an indication if there is a possible outbreak.
Therefore the solution would hide away all technical complexity behind the scenes, presenting clear and actionable information to the user to inform further action.
I and other members of the team undertook user interviews and research initially in the UK, speaking to experts at Oxford University, Genomics England and The European Bioinformatics Institute. This was useful in informing what types of diagnostic information would be most suitable.
However it became clear that these UK-based users were only representative of a particularly expert subset of the target user base. The project started to generate interest in India and I was part of a sub-team that undertook a field trip to TB-prevalent areas of Mumbai.
We were able to visit a range of sites and talk to a range of potential users working in every situation, from dedicated hospitals to temporary mobile labs.
We were able to observe and capture existing workflows to help understand where we could adapt our product to fit seamlessly into day-to-day operations.
I started with a lightweight identity design exercise where we arrived at a solution that satisfied the requirements for charm and animation by using simple forms in a bold and colourful way. The visual language was derived from images of lab samples.
The next logical step was to agree on the content and screens for an initial solution. This was achieved using a mixture of screen mapping coupled with low-fidelity wireframes which contained the information derived from the command-line tool which dictated the feature-set.
The identity and visual language could then be applied to the wireframes. The team reached agreement on a solution which was visually clean and easy to read, while incorporating charm via touches of animation and iconography.
The requirement to work offline and be cross-platform led to a discussion of possible technical solutions such as building multiple clients or using QT, both of which would carry a large initial cost plus ongoing maintenance burden.
Since the interface was predominantly text-based I suggested it might be a good candidate for a relatively new technology called Electron, which provides a way to develop a cross-platform application with web technologies (HTML/CSS/JS) which also works offline.
I created an initial prototype with the goal of having the minimum set of features required to prove Electron as a solution. The developer of the tool worked with me to adjust the input and output of the tool. Passing --format json causes standard output to be in JSON which is more easily consumed by software.
$ mykrobe_atlas predict\
--sample MDR_1\
--species tb\
--seq /MDR_1.fastq.gz\
--format json
The final prototype took the form of a fully signed app containing the command-line tool, proving that the front-end was able to communicate with the tool to analyse a sequence and then display the results to the end user. We were also able to build and run the same app on Linux and Windows, making it more attractive in terms of effort to build and maintain over the long term.
The visual designs were next implemented in the prototype, with added animations added to the splash screen and simple transitions between screens adding to the charm. We added drag-and-drop support which means that with the final production app users can simply drag a DNA sequence file into the app and then view the results within a couple of minutes.
The product owner gave a memorable real-time demo of this in Mumbai which received many gasps with the audience wondering how this was possible.
The initial app was well received by end users and this played a small part in the overall project securing further funding. The vision was extended to create not just a standalone app, but a whole online platform that would allow users to create their own secure online library of sequence data, with potential to collaborate anonymously with others to identify similar samples and potential outbreaks.
We used what we had learned from users in Mumbai to map out the first iteration of the platform. Wireframes were not easily relatable to our end users, so we took the extra step to create fully realised screens before conducting user testing. This gave us much higher engagement and better feedback from our target users, allowing us to iterate and refine the target product state.
One of the most challenging parts of the platform from a product design perspective is visualising the relatedness of different samples. This was initially achieved using a phylogenetic tree.
One of the scientific team members invented a better solution using a hand-drawn node graph which has a significantly lower density of data making it easier to read. To realise this idea, I created a series of prototypes using static data in various types of force-directed graph visualisations and with different layout strategies. Following a cycle of team reviews and prototype refinements we eventually landed on a satisfying visualisation generated in the browser.
I was then able to work with one of the back-end developers to arrive on a JSON data structure which could be generated dynamically via Neo4J. The resulting visualisation replaced the phylogenetic tree.
The final design works across both the offline desktop app and the web-based platform.
I worked with other front-end engineers to build the user interface using React, Redux and Redux Saga with the component library documented live in Storybook. This is fully tokenised and will form a solid starting point for a full design system when the appropriate time arises in future.
I refactored the Electron app to use the component library, giving a consistent appearance and reducing the effort required for ongoing maintenance.
I wrote a simple Babel plugin which automatically modifies import and require to resolve sources with a with an .electron suffix when bundling for Electron, e.g. index.electron.js or styles.electron.scss. This allows the Electron and web-based apps to share the same code base, diverging when needed for specific functionality.
I worked closely with the back-end developers against an OpenAPI spec, with some realtime events using Server-sent events (SSE).
While we were focused on preparing the platform for its first real-world pilot in Argentina, something called COVID-19 stole the news agenda. Many TB labs were forced to change their focus to analysing COVID-19 during the pandemic. This made it impossible to undertake the final pilot and user testing that we had planned.
One other problem was unique to this particular project - the technology is so advanced that none of our users were able to easily grasp what it could do or specifically what they might use it for. This meant we had to push the fidelity of our testable prototypes further than expected so that users would be able to engage with them in a useful way unlocking the necessary insight.
What started out as a small identity and UI project eventually scaled into a multi-year multi-platform product. The other team members were humble, bright and inspiring and I learned so much about pathogens and diagnostics, as well as having my eyes opened to the realities of every day existence in other parts of the world. I am a named author on the research paper published in Nature Communications as an acknowledgment of my overall contribution.
It is still hard to believe that you can put a swab sample in a fancy USB stick then see a complete DNA analysis on your laptop screen within a couple of minutes. It was an honour and privilege to work with people who make such breakthroughs possible.
Post-pandemic, the platform has seen renewed interest and investment from a large global technology firm. It will be migrated onto their platform where it can be scaled to be used for COVID-19 surveillance alongside TB.
