The possibile uses for these datasets are infinite, but the interface must be purposeful. To clarify what the product needs to accomplish, we organised a two week discovery phase which focused on user research.

We reached out to people in the two target audiences: academics and healthcare industry experts. We set up interviews and focus groups with both experienced data scientists and people who had never worked with big data before, the so called “citizen scientists”.

Ultimately, we used a mix of several user research methods to reveal the nuances of what users expected and needed from the product.

UX research yields multiple unique pieces of information. In order to predict what users need during every step of the process, the findings must be integrated into a coherent whole.

By analysing, comparing, and contrasting all this insight, we discovered general patterns. These patterns allow us to understand outliers such as the miscellaneaous methods people use to reach their goals.

The model also shows differences in what users need. For example, university researchers are required to go through a lengthy approval process before they can even start engaging with the datasets. In contrast, researchers from pharma companies start experimenting with the datesets early on, but will encounter regulatory limitations later.

We tested nine data query tools that are common in the healthcare industry. The purpose of benchmarking is to help us gain an in-depth understanding of the challenges that manifest in big data tools for healthcare.

We identified design patterns that users might expect, as well as unique interactions that are either bright ideas or failed attempts to solve a problem.

Thanks to this effort, we can avoid the dead paths that others have tried and save time during the design process. But there’s also another major benefit: the user experience we create is meant to integrate into the general healthcare application space and push the envelope.

The user experience is designed to cope with a broad range of query complexity: from simple two-factor queries, all the way up to multiple-factor queries on 8 levels of depth.

We wireframed 5 models of query builders based on 3 different assumptions and transformed them into interactive prototypes through iterative UX design. The clickable prototypes enabled us to analyse the pros and cons of each model through user testing.

We used an evolutionary process where the variants evolved in parallel until some of them merged into a winning model. This UX design process, which incorporates exploration and empiric selection, ultimately led to a query tool that outperforms all the original versions.

Tools for data analysis were integrated as modules: descriptive statistics, correlation functions, and others. They fit into the modular architecture of this healthcare softcare as plugins.The same is true for data visualisation modules.

In other big data analysis tools, these features have a needlessly complicated user experience, plus a dry and technical look and feel. The ambition for these data analysis modules was to tailor the UX design to users who are not data scientists.

Healtchare researchers work in teams. One individual can be part of many different teams. In terms of what accounts for a UX challenge, this admin section seems trivial, but it is in fact a critical factor for user success. To make sure the admin modules don’t end up being a source of frustration, we’ve invested just as much meticulous work, care, and testing to shape their user experience.

We used neutral colours for screens where users will mostly focus on raw data, and electric shades of blue, purple, green, and red for data analysis modules. Illustrations have been used sparingly, to add brief moments of delight at key steps of the user flows.

The design system aims to support development efforts both throughout the implementation of our design and in the future. Developers have a library of components they can use to release the features planned for the next two years.

The development team was invited to participate in our workshops from the start. To us, developers are important project stakeholders, whose technical expertise helps guide certain design decisions.

During design workshops, we wanted to make sure the user interactions we were prototyping were achievable from a technical standpoint. For the development team, being involved early on meant a chance to choose optimal backend technologies, as well as a step towards accurate effort estimates.

As design drew to a close, our role in the collaboration with the development team shifted to one of support. We participated in regular meetings to brief them in preparation of their sprints and we provided live support on Slack and Zeplin over the course of the entire implementation.