UX design, bioinformatics and cars

Guillaume Filion is team leader at a genomics lab in Barcelona. On his personal blog, in January 2015, he published the article “If Cars Were Made By Bioinformaticians” which one of my colleagues pointed out to me. Regardless of the self-explanatory title, it is actually a wry, satirical view of how bioinformatics tools and software are developed.  It made me laugh (particularly the bit about “having many options”) but it also got me thinking.

As a user experience designer at one of the world’s leading bioinformatics institutes (and proud of it) I thought I’d offer my perspective. Here’s the summary version:

  • Don’t worry about a clever name; spend the time to understand what people need to do, to test your assumptions (don’t make bioinformatics Ford Edsels), and to figure out where your software or tool is going to fit in
  • Speed and accuracy are important factors, but these should fit with the needs and perceptions of the users. What is “good” for them?
  • Focus on outcomes and value, not on huge lists of features
  • Constraints make good design decisions possible
  • Consciously design bioinformatics tools with the appropriate degree of complexity and for the love of BLAST, please handle errors elegantly

The reason that Guillaume’s original article works, and that people I know around the bioinformatics community find it funny, is that the analogy of a car reflects a truth that many have experienced. There are lots of tools and software out there that people use to support biological research, but maintenance, support, usability, documentation, etc. can vary wildly. If we dig into what Guillaume has written, we can begin to learn things; even pick out some heuristics for how we can design better bioinformatics software. Or cars, for that matter.

1. Cars would have nice names

“Here we present CaЯ (vehiCle for chAnging geo-cooЯdinates), a fast and accurate tool as an alternative to existing vehicles.”

Guillaume’s article gets off to a good start – the car gets an obscure acronym as its name – a common issue for bioinformatics software and tools. There are lots of tools because lots of people often want (or need?) to make their own tool for their own dataset, and then publish it. The name might mean something to its creator but it can be opaque and hard to remember for anyone else.

From a UX design point-of-view, though, there’s more to it.

Familiarity breeds confidence

First-of-all, use language and terminology that is unambiguous and that makes sense to the audience. Actually, the name might not matter that much, but it should be clear what the software does, what distinguishes it from similar things, and what value it provides.

Innovate to solve problems

Then there’s the issue of innovation. On more than one occasion, I’ve heard Eric Reiss – a well-respected information architect and user experience designer – say that “innovation should occur only to solve a problem, otherwise you’ll surely create new problems”. It’s something that has stuck with me, an often helps me think critically about decisions I make in my work. Indeed, early on in projects, my colleagues and I, along with project stakeholders, often put a lot of effort into defining the problems we’re trying to solve. That gives us a solid foundation for the rest of the design process.

Get out of the building

It’s encouraging that in lots of the projects my colleagues and I work on, there is an increasing appreciation of the value of taking time to carry out user research early on. We do this so that we can better understand what people are trying to do and where our products fit in, and that helps us (as a development team) make better-informed design decisions as the project continues.

I’ve had some interesting discussions recently about doing this before projects start, for example as a precursor to writing grant proposals but that’s another story.

2. Cars would be fast and accurate

“Bioinformaticians develop fast and accurate software. Their cars would be just the same.”

For sure, bioinformatics software benefits from being fast (speed of response; how quickly your job results are returned) and accurate (what algorithm is that, exactly? Can you trust it?).

Actually, in terms of interaction design, the speed of something like a web-based application; the responsiveness of a system, is an important factor in overall user experience (UX). Just think about how you feel when you have to wait for something, and the difference that some sense of progress (system feedback) makes to that feeling. This is one of those areas where the choices made by my developer colleagues can have a direct impact on the UX, whether we are talking about graphical or command line interfaces.

What attributes do your users value?

Speed and accuracy are important factors, but these should fit with the needs and perceptions of the users. What do the users perceive as valuable or high quality. What makes it “good” for them? Let’s not forget, usability is one of the pillars of good UX design, but so are credibility and findability, amongst others.

What does success look like?

Finally, when we talk about measurable things like speed and accuracy, we can start to think about indicators of success. Making this part of the discussion in the projects my colleagues and I work on is increasingly important. In recent work, my team-mate Niki and I have working with something called the HEART framework, originally developed by Google product development teams, to help us have a structured way to talk about what success means for our product.

3. Cars would have many options

“Bioinformatics is all about freedom. And as far as software goes, more freedom equals more options.”

Here’s one you can really get your teeth into. And it’s the one that had my team-mates and I crying with laughter.

Let’s consider web-based bioinformatics tools and software – the main thing I work on at the European Bioinformatics Institute – and leave pipelines and APIs aside for now.

This for me is perhaps the most important point that Guillaume mentions. Having too many features and functions (and displaying lots/all of them at once!) is a quick way get a bioinformatics tool or piece of software into trouble.

In the last few years, my colleagues and I have had numerous anecdotal discussions, run surveys, carried out usability tests, and conducted structured interviews with lots and lots of people within the bioinformatics and biomedical sciences community. I can tell you that all but the most experienced power users are freaked out by complicated, feature-rich, choice paralysis-inducing interfaces.

Here’s the thing, though – powerful bioinformatics tools are not everyday products that should necessarily be easy-to-use, the first time round. They often do require training and familiarisation… just like learning to drive a car. But they also need to be well-designed, so that their power can be expressed through an appropriate level of complexity. Complex is OK but complicated is not.

So how do you avoid having too many features (“featuritis”), but still offer the power that is necessary? How do you manage complexity? How do you know what to give prominence to?

I’d suggest that there are a few approaches you can take.

Define the problem you’re solving (or the opportunity you aim to meet)

Those early discussions that my UX colleagues and I have with project initiators and other stakeholders really help us to set the vision for a project, and this is especially when the product will be software that people are going to use. And as we test assumptions, we might adapt that vision as we go along, helping to refine it.

Talking about “vision” might sound like a lot of marketing waffle. It ain’t.

It is simply about having a shared understanding of what we’re trying to make, and what it will enable users to do. My team-mate Niki has been using the following image in recent project work, to get that point across. This is why we bring people together, ask them to write and sketch, and then stick it all on a wall.

shared vision

Jeff Patton and Luke Barrett’s cartoon – agreeing on a shared vision for a product


Carry out user research

I’m going to bang this drum a lot. It pays dividends to understand your users; to learn about their “pain points” and the things that help them; to learn about context-of-use; and so on. Coupled with a clear understanding of what a project is trying to achieve, you have a solid foundation for making decisions later on. To do that, you need to get out of the building.

A couple of times now, I’ve had the opportunity to talk a bit about the “gentle art of not asking users what they want”, and instead recommend that project teams use focused research to discover opportunities and latent needs. A while ago, my friend Per Axbom wrote about the same thing.

User research isn’t about getting people to design your software and its interface for you, it’s more about getting to the root of problems – you still have work to do, to design solutions.

Embrace constraints

Ideas are great but if they can’t be translated into value, then they’re not worth all that much. Constraints give us a frame in which to picture our solutions, and they help us make choices.

Understand what you can do. What limitations do you face in terms of time, resources, money, technology…? From our point of view, we try to understand those constraints by continually communicating with stakeholders, scientists and developers. What is possible? What is convention? What is expected? This is the day-to-day reality of UX design.


Based on all this knowledge you have, you can start prioritising work and features. There a couple of good frameworks to help you think about prioritisation and that I use in projects at the EBI.

The first, and simplest, is the impact/effort matrix. The second, more powerful option, is to investigate the Kano model.

This graphic was used in the excellent UX Mag article about using the Kano model to leverage UX design

This graphic was used in the excellent UX Mag article about using the Kano model to leverage optimal results

In terms of prioritising things on a webpage, for example, this is often an exercise in simplification. One of the most useful, readable books you can find on that topic is Giles Colborne’s “Simple and Usable”, in which the author discusses four major approaches to simplification: Remove, Hide, Group and Displace.

One of the approaches we frequently use is that of grouping, where we arrange features in such a way to put similar things together. In that this can help our users develop familiarity with an interface, it can be thought of as a kind of chunking. This term simply means arranging information in a way that makes it more comprehensible and memorable. One of the first things I read on this was Ryan Singer’s 2004 article, “An introduction to using patterns in web design”, which I found influential.

Even better, there’s a bioinformatics-specific example of this. If you look at the the Enzyme Portal paper that was published in 2013, you can read about the “canvas sort” method that my colleagues Paula de Matos and Jenny Cham developed, specifically to address the issue of grouping or chunking important information and features in an interface, and used successfully in that project.

Build. Test. Learn.

Also consider that the first thing you release and start gathering feedback on (e.g. from usability testing… ) doesn’t have to be the finished article. Based on the vision, your user research, the constraints and the priorities, build something sensible. Test it. Learn from that. Iterate and make it better.

This is accepted wisdom in the domains of lean startup and lean product development, and the mindset has had an increasing impact on the UX design community in recent years. It’s about iterative, rather than incremental, design. There’s even a neat little graphic to illustrate it…

Iterate, improve, and provide value

Your user or customer needs to get from A to B. Iterate, improve, and provide value

4. Cars would support many standards

“Why have only one standard when you can have many?”

I’m going to steer well clear of any arguments about trying to agree standards within the bioinformatics community. Here be dragons, I expect.

Speaking as a UX designer, however, this part of Guillaume’s article got me thinking about conventions, design patterns and component libraries.

Conventions are good, except when they’re not

Earlier in this article (I know, it’s long) I mentioned the benefit of constraints in guiding design decisions and keeping things realistic. Arguably, understanding conventions in bioinformatics, for example in the visualisation of particular data, is one such constraint. But conventions can sometimes be tricky: think red/green colour blindness versus heatmaps in microarray data, something that the Nature Publishing Group are certainly taking seriously.

It’s also possible to challenge conventions. Ryo Sakai and his PhD supervisor, Jan Aerts, explored this as part of the BioVis 2013 data redesign contest, as did Nick Goldman (of the EBI), Marek Kultys and others.

Design patterns

By this, I mean interaction design patterns – descriptions, use cases and examples of the interactive elements one sees in software and webpages. There are numerous design pattern libraries out there – such as the one from Welie.com – but nothing specifically for for common bioinformatics interfaces; things like sequence alignment tools, for example.

It turns out that developing a library of design patterns for the interfaces and interactions of bioinformatics tools isn’t an easy thing to do – I haven’t quite got it to happen yet at the EBI – but it’s not an idea I have given up on yet. There are initiatives at the EBI that may just drive the development of such a thing.

Component libraries

There’s perhaps more success in the area of developing a component library in the shape of BioJS, a project I’ve been involved in for a couple of years. The vision there is to develop a registry of reusable JavaScript components for presenting information and visualising biological data. It’s growing.

5. Cars would be all about user experience

“Bioinformaticians are very accessible, you just have to drop them an email and they almost always respond…”

Guillaume finishes up talking about user experience, which may be what made me think of writing a response, and he focuses on how a user might seek support.

The provision for and quality of support is definitely important to someone’s experience of a product or service, and that’s where things get interesting. In past projects – the early redesign of the EGA (European Genome-Phenome Archive), for example – I’ve experimented with introducing concepts from the domain of service design, without muddying the waters by mentioning it by name. By working with colleagues to consider the holistic design of a service and all its various “touchpoints” – the website, the helpdesk, documentation, data submission tools, conference posters – we’ve been able to produce something demonstrably better.

An on the topic of support, it’s worth noting, too, that a well-tended support / help desk queue can act as a treasure trove of user information for research and trouble-shooting.

But in Guillaume’s CaЯ scenario, the user (Alice) contacts the support because of an error, and doesn’t get a particularly helpful reply. Therein is the lesson – error prevention and graceful recovery from unavoidable errors are a key aspect of UX design that is all-too-easy to overlook. Years ago, Jakob Nielsen and Rolf Molich developed their 10 Heuristics for User Interface Design. On errors, they had this to say, “Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Test your system or software for how it behaves when something goes wrong or it is used “incorrectly”. Designing only around the best case scenario is probably unrealistic.

Simple things like form validation (client and server-side) can help massively in avoiding errors, but errors can still occur. In that case, consider what your error pages say – the tone of voice, the information, the options… help your user out.

Making this work

When my colleagues and I design things, we don’t do it in a bubble. We don’t think we have all the answers; we don’t do our thing and pass it to developers; we don’t sprinkle magic UX dust on a project near the end.

At the EBI, we can see a growing culture of trust and familiarity that enables us to work with domain experts, developers and other partners to design bioinformatics tools and software that provide real value to the wider community.

Maybe if we designed a car together, it wouldn’t be too bad, either.


2 thoughts on “UX design, bioinformatics and cars

  1. I can barely express how much I am grateful for this post! It is as “good” as mine is “bad”, I mean as constructive as mine is destructive.

    I agree with everything you wrote. I will add two points, that are more practical tips, but I believe that they can make a difference.

    My personal favourite is the featuritis, which usually takes the form of unlimited options that implicitly assume that the user understands the back end perfectly. I like the way BLAST deals with this issue. Many options are available, but if you ignore them all, BLAST will still look for your query sequence in the database you say. I will do something, and I won’t do anything really stupid. Meaningful default parameters is an easy way to be beginner-friendly while not penalizing power users.

    I like the car building sketch above because it conveys a very important message: people will use your software if they can quickly get some success with it (more generally, people will do something if they get the impression that they are good at it). Why not helping users make their own success? And an easy way to do this is to give an example. It can be an input file, a simple command line etc. Anything that the user can reproduce and then later modify for their own needs. Allow your users to also build, test and learn.

    • Thanks for taking the time to reply, Guillaume.

      Regarding your points…
      1) that’s a good one – setting those meaningful defaults necessarily requires domain expertise, but it also directly influences the user experience. It’s an easy win, potentially. I suppose it is also a way to prevent errors, too, which is always a good idea
      2) too true. A few years back, when I was still organising design-related talks on campus, we had Des Traynor talk about The Language of Software, and he mentioned the importance of setting up the “blank slate” – show the user what they can do here. Don’t just leave a big space, and expect them to figure it out. We do this, for some of our tools and services, but perhaps it could be more elegant. Good point.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s