For the third Cambridge Visualisation of Biological Information meetup, organiser, Will Spooner, invited Greg McInerny and me to talk about “best practices in bio vis”. While Greg covered wisdom, mistakes, and deception in visualisation (particularly in figures used in academic papers), I wanted talk about how we can apply UX design practices to visualisation challenges. Rather than just give a talk that lists and describes methods and techniques from UX design, I tried to focus on WHY you would use any of those approaches; why would you bother to learn and apply them, on top of everything else you have to do? I framed things in terms of important questions you might want to ask whilst going through the process of designing data visualisations, so that we can try to gain clarity and develop your understanding.Anyone who has spent more than about 5 minutes around a small child knows that they as a LOT of questions about, well, everything. I suppose it’s part of a developmental stage, and as they try and build a schema to make sense of their environment, they ask us adults “why?” and “what’s that for” and “who’s that?”, etc. Questioning and verifying like this, though, can obviously be usefully applied to our work. What is important? What problems are the audience trying to solve?
Are you getting out enough?
It can be easy to work on design projects (of data visualisations or anything else) without leaving our desks but there’s a great deal of value in getting out of the building and actively learning about the audience for our visualisations. From a UX design perspective, this is simply user research – developing an understanding of someone else’s day-to-day reality, and asking more questions: Who are the audience? Why do people need to visualise these data? What are they trying to achieve? How does data visualisation actually fit into their work? What is the context-of-use? Are we talking about exploration, hypothesis, task-focus… ?
Can you tell me more about that?
We typically use interviews and shadowing / observations to allow us to learn more about the users or the audience. A question like “Can you tell me more about that?” might allow you more freedom to have an open mind, and to explore interesting lines of enquiry. Andrew Travers wrote a really nice, accessible book about interviewing for user research – well worth checking out. For more in-depth ideas, look to Steve Portigal. We also run workshop sessions, where we include people from that audience in parts of the design process. This gives us another way to learn about what works and what is important, by observing how participants make choices and interact. We can capture a lot of information in this way, but then we have to make it shareable and useable, so that it has utility within a project. UX designers have a number of techniques for making sense of lots of information, and communicating it with others.
What can the data tell us?
Although my focus, and that of my UX design colleagues at the EBI, is on the audience or the users, in larger, more complex projects, we find it really useful to have a data visualisation expert in the team. This has been the case in recent CTTV work, where Ryo Sakai has helped us explore data and understand what is possible. He is able to visualise data in different ways, quite quickly. Although those visualisations might not be what we use in the final product, they are an excellent way to enrich our understanding. This gives us another lens through which to view what we learn from user research.
Are we building this to meet a need or solve a problem that our research uncovered?
Once we start building things (and “building” typically starts by sketching with pen and paper), it’s useful to check that what we build is meeting needs or solving problems that our earlier research uncovered. A sensible way to keep things on track is to be explicit about what you’re trying to build. Agree and write down project goals, the problems you’re trying to help people solve with data visualisation, or the opportunities you’re trying to meet. James Chudley has written about importance of photos in UX design. How he talks about describing the purpose of a photo is, I think, directly relevant to how we design data visualisations, and consider how they fit into a wider context of use.
Could it be simpler?
Ah, simplicity. Don’t just add add layers of data because you can. What needs to be there? I watched a great talk on sketching from UX designer, Eva Lotta Lamm, where she quoted minimalist painter, Hans Hofmann:
“The ability to simplify means to eliminate the unnecessary so that the necessary may speak“
which I think is eloquent (and makes a change from that Einstein quote!). In visualising very large data, and perhaps making that interactive, there is inevitable, necessary complexity. Minimalism is not a helpful goal, but try to avoid making things complicated. Oh, and whilst talking about building things, I took a little detour… In the last couple of years, I’ve been increasingly interested in Systems Thinking (as described by the likes of Russell Ackoff), and how it can be a useful way to frame UX design. I’ve also taken inspiration from architect and designer, Eero Saarinen. In 1956, speaking about his Tulip chair, he said
“In any design problem, one should seek the solution in terms of the next largest thing.”
Does it make sense?
So here, I talked a tiny bit about evaluating the data visualisation itself. Bearing in mind what I’d just said about systems, however, I was keen to point out that my expertise aren’t in that kind of evaluation; of finding out if a visualisation is comprehensible, and if one version is better than another. Greg touched on this in his talk — he mentioned a paper by Harrison et al, where they had investigated the best graphs for spotting correlations in data. In terms of what I have read, I’d suggest you look to papers on this topic from Heidi Lam, Sheelagh Carpendale, Bill Buxton, Alvitta Ottley, Miriah Meyer… there are bound to be plenty of others.
But I also mentioned the value of critique. This is something my colleagues and I use in workshop settings, and it’s really something we should do more of in general. The important things are that
- it should be a dialogue
- it should be structured
Fernanda Viégas and Martin Wattenberg wrote a great piece on design and redesign of visualisations, and considered criticism and critique in particular. Essential reading. But in terms of structured approaches you can use, I can recommend a couple. First, and very simple, is to ask people (colleagues, domaine experts, etc) to tell you two things that work well, and two things that need to be dropped if improved. If you’re using printouts or sketches, you can indicate good and bad points using coloured sticky dots. This is commonly called the 2+2 format, and it assumes that people understand what you were trying to achieve, and that your dialogues is framed in this way. To build on that, my friend Alişan Atvur suggests a format that he calls the “critique cross“. Essentially, it breaks the critique into four parts (the quadrants around the cross).
- Time – how much time to we have for this critique (e.g. 10 minutes or an hour – makes a difference!)
- Context – what is the audience or user trying to achieve?
- Logic – what design decisions have you made, and why?
- this varies, but it could be Principles – what specific design principles were you trying to stick to? Things that really mean something to the audience, and that you uncovered through research.
I wrote about critique a little while ago, but there’s a lot of good stuff out there, on the web..
Can people use it?
Since we are most often (at the EBI, at least) considering visualisations that are part of a bigger system, we begin to think about usability testing, and this is much more familiar territory. Usability testing is one of the first things we introduced at the EBI, and I used an image of my team-mate, Jenny Cham, testing a prototype search system that involves visualisations.
Do our assumptions hold up?
Once we’ve spent some time testing things that we’ve built, and testing our assumptions, too, it’s useful to share findings with the rest of your team, if you haven’t already directly involved them. Are you on the right track? Do you need to alter what you’re doing? Arguably, it’s better to learn early on, right?! It’s also worth pointing out that consciously reflecting on your work is worthwhile. This is an important step in any design process but perhaps the least often addressed (I could do better!). As well as reflecting on the testing and validation stage, and reporting things to the rest of your team and other stakeholders, reflection should give us an opportunity to get better at what we do. Another of my team-mates, Niki Karamanis, has made reporting back to the team an integral part of the process in one of the big projects we work on together.
What do we focus on next?
A clear understanding of goals, and the feedback you get from testing and validation, can help you prioritise work, too. We find this is especially useful in larger, more complex design projects, where there’s much more scope for “leakage”!
“Waterfall bad, washing machine good”
A long time ago, I saw Leisa Reichelt give a presentation titled “Waterfall Bad, Washing Machine Good“. It was largely a discussion of Agile and lean processes in design and development. It made an impact on me. So, although in this talk, I presented things in a linear way, in practice, the way we work; the way we ask questions and apply UX design to data visualisation, is not linear. It’s a cyclical, iterative process, fed by user research, validation, and innovation… kind of like a washing machine going round and round until you get something clean. I’m not all that keen on best practices: they are a moving target, and what works in one situation isn’t always going to work in another. But in a broad sense, asking questions and having an open-minded approach to design projects (data visualisation or otherwise) might not be such a bad best practice.