The value of sharing prototypes
Designing global data sharing to tackle diversity in health sciences
I recently designed a secure data system. It helps people to both share sensitive data sets across organisations and analyse them in a collaborative way. Supporting a partnership of global health funders to make data-driven decisions about diversity.
I used different types of iterative prototyping to reduce complexity. This helped get ideas out of other people’s heads and align the team’s understanding of the new service. A prototype is the simplest model to test a concept. Its value is what you learn as a result of sharing it.
The problem
Wellcome Trust spends around a billion pounds a year on health research. However, the people and projects funded are not as diverse as they should be. This is a problem because health impacts everyone. A diversity of people and ideas across science and research are needed to solve the urgent health challenges facing us all. To understand the extent of the problem, Wellcome has teamed up with other global funders of health research to share and analyse their diversity data together. In total 21 partners across Asia, Africa, Europe, Australia and North America.
Make, share, learn. Mitigate risk.
I was briefed to lead design for Wellcome Data Labs. At the point of me joining:
- There was limited insight about the people who would be involved in the collaborative data projects.
- Complex legal contracts were in progress and responsibilities undefined.
- No one knew how the data sharing/analysis projects were practically going to work.
- A technical proof-of-concept for hosting data existed. But it did not perform well in a heuristic evaluation with data scientists. (It had been engineered without user or design input due to limited resources.)
Over 9 months, I designed with lawyers, project managers, data scientists and an agile engineering team. Together we turned an ambitious strategic vision into a future service blueprint and integrated product for launch.
1. Prototyping to learn
Initially, people said things to me like “of course we’ll do [x]”. So I made simple diagram prototypes, to replay and socialise assumptions based on what I’d heard. Then people said things to me like “oh well, I thought something different actually”. Prototyping (anonymised) conversations into diagrams provoked reactions. Those reactions, from future users and varied stakeholders, helped me to learn more. About the real needs people had, interdependent factors and undocumented business requirements.
For example, I created a simple diagram as a discussion tool to learn more about the key legal checkpoints for a collaborative data analysis project. What must happen by individuals vs by groups/organisations?
The discussion that resulted around this diagram helped me to understand what wouldn’t work as much as what could. I learned that repetitive dataset access requests could be simplified and grouped for a project team and dataset owners, but only if linked to legal documentation in an auditable way.
This knowledge reduced the risk of wasting resources on developing the wrong logic models and service-level maps. In the product, it simplified steps for both users and the product engineering team. My final design iteration reduced the complexity of dataset access for project members down to a single onboarding screen.
2. Prototyping to co-create a future service
No one knew how these global collaborations would practically work. So I began talking to people and mapping end-to-end processes based on the insight I did have. I then started combining these together into a prototype. I used service blueprinting not just to communicate with people, but to also draw out further information. After I demoed an early draft, a key stakeholder reached out to me. He’d been inspired by my presentation to create his own version and was keen to share it. This helpfully made some invisible service components visible. I quickly amalgamated my version into his and found a time to meet up.
From then on we co-created blueprint iterations together. Our aim was to develop a shared understanding of future ways of working and interdependencies. We communicated what we were doing more widely and added in first-hand insights from other people. These prototypes helped us to quickly identify knowledge gaps, questions and pain points in new governance processes. We were also then able to consider the integration of a new digital product into existing omnichannel workflows. The final blueprint provided a single clear dialogue for the stakeholders which hadn’t existed before. Documenting how people will interact with online and offline touchpoints in a robust and detailed way. It also informed a roadmap for building and testing the digital product.
“Data Labs helped us lead that process of visualizing what the steps and requirements were, and especially how the technical build sat alongside the human process. Including new governance designed to ensure funders retained complete control over their data.” Stakeholder
3. Prototyping to facilitate a decision
When I started, a technical proof-of-concept existed. It had lots of backend functionality for data sharing/analysis. But usability testing showed people struggled to find things within it. Key issues included navigating long busy menus and labelling. The product team needed help to decide what to do next.
- I held ad-hoc contextual enquiry sessions.
- I shadowed 2x data scientists at work. To learn about the tools they were already familiar with using.
- I did desk research into the information architecture of similar products.
- I researched alternative labelling to the confusing engineering language.
- I worked with the developers to reverse engineer the functionality that had already been built. Then explored ways we could reconfigure it around the 3x product aims: access, analyse, share.
After documenting my findings, I used them to prototype meta-level information architecture concepts. To explore improved ways of meeting the mental models of our intended users and product objectives.
I communicated my work to the product team and stakeholders. How would we structure the information architecture? What should we do next to test these concepts with users? The research-informed prototypes were a tangible anchor to talk around. These simple prototypes helped to facilitate a complex product decision on what to do next. Making a decision was clearer — as everyone was literally on the same page.
4. Prototyping to test hypothesis
Sharing sensitive data across numerous global organizations is complex. Evolving legal work meant I needed to adjust and change my prototyping approaches over time. One uncertainty I had to design for was the approval and export/sharing of collaborative analysis results. I began by capturing my assumptions. For example:
If analysis has been created using multiple datasets, then multiple people will need to approve the resulting analysis export, because the parent datasets are owned by more than one organisation. So, I’ll need to design complex approval flows that integrate with the digital product.
I asked the product team to prioritize which assumptions were the riskiest. Then I prototyped hypothesis solutions using process mapping and digital wireframing.
These hypothesis prototypes helped me to explore the complexity and unknowns in detail with stakeholders. Having the prototypes aligned conversations and thinking between different disciplines in the product team too.
- The prototypes offered a safe outlet for people to challenge assumptions and expectations. E.g. how much we needed to build into the product.
- They helped confirm what could be simplified. E.g. project owners could coordinate the approvals using email.
- They led to valuable feedback in usability testing.
All this insight helped me to further consider the logic and accessibility and informed the final design.
5. Prototyping to earn trust and confidence
Earning trust and confidence in the security of the data system was a fundamental business requirement. If this didn’t happen, nobody would be sharing any data. I made a lot of different prototypes to answer key security questions and to build confidence ahead of having live users. Here are two examples.
All designs centred around the legal agreement that dataset owners retain 100% control. This led to some difficult product decisions. Including what happens if dataset access is revoked. I made interactive prototypes of confirmation alerts, dataset access controls, notification emails and audit logs (codesigned with colleagues in information governance). Usability testing these with dataset owners from partner organisations built trust in data controls. Which led to validation without using engineering time.
In the later stages, sharing dynamic interactions and complex logic was really important in building both confidence and trust. I worked with the product engineers to design and build code prototypes of the data analysis workspace. Having this prototype built in code, allowed us to understand how the product would actually be experienced in the real world. We natively tested the UI, analysis tools and file sharing flows. Using real devices, datasets and data scientists. It also enabled us to test how robust the workspace security was from people trying to export data through dubious means.
Anyone can prototype
The purpose of most of these prototypes was not to wow people with my visual design skills. But to work through complex problems with other people’s input. I find that people are more likely to be engaged when there is something in front of them. Which in turn helps me to benefit from their knowledge and different perspectives. I encourage you to give it a try.
Further reading
Prototyping
- Interaction Design Foundation, Prototyping: Learn Eight Common Methods and Best Practices
- Nielsen Norman Group, When and Why UX Practitioners Use Service Blueprints
- Ben Holliday, A guide to different types of prototyping
Wellcome
