As part of the third Cambridge Visualisation of Biological Information meetup (May 5, 2015), I talked a bit about how UX designers work on data visualisation at the European Bioinformatics Institute. Rather than churn through a range of UX processes and techniques, I framed everything in terms of the questions we find it useful to ask, and to keep asking.
12. “The ability to simplify means
to eliminate the unnecessary
so that the necessary may
speak” – Hans Hofmann
Could it be simpler?
12
13. Sketching
Assuming you take an experimental, iterative
approach, sketching allows you lots of
degrees of freedom.
Importantly, it allows you to learn fast and
often, and to fail cheaply.
13@francisrowland
19. Get some critique
Getting critique from colleagues and domain
experts can be really useful, but it needs to be
managed.
Good critique is a dialogue.
19@francisrowland
21. Usability testing
Let’s try to avoid this...
“Man became
so frustrated
with computer
he shot it eight
times”
http://metro.co.uk/2015/04/22/man-became-so-frustrated-with-computer-he-shot-it-eight-times-5161310/
21
27. Round-up of questions
● Are you getting out enough?
● Can you tell me more about that?
● What can the data tell us?
● Are we building this to meet a need or solve a problem that
our research uncovered?
● Could it be simpler?
● Does it make sense?
● Can people use it?
● Do our assumptions hold up?
● What do we focus on next?
27
28. Is there time for another pint?
Probably, yes.
Contact:
@francisrowland or frowland@ebi.ac.uk
Sporadic blogging:
http://ebiinterfaces.wordpress.com
Data Visualization for Biology workshop (Nov 2015)
http://bit.ly/1xrbIXk
28
Notes de l'éditeur
Rather than give a talk that lists and describes methods and techniques from UX design that I think can be applied to data visualisation, I wanted 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?
Try to gain clarity and develop your understanding.
What is important? What problems are the audience trying to solve?
The Toddler Test
I’m a UX designer at the European Bioinformatics Institute.
When my work focuses on data visualisations, it tends to be in the setting of an online application or service used by the wider bioscience community, rather than standalone visualisations (e.g. as figures for a paper) or visualisations used “internally” by research teams. So that’s the kind of thing my talk focuses on - for other things, look to the literature (for example, articles by Bang Wong and Martin Kryzwinski in Nature Methods)
Get out of the building.
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… ?
User research, by any other name.
What is THEIR reality?
Interviews and observation are some of our favourites.
Participatory design sessions can also provide a lot of insights.
“Can you tell me more about that?” might just be your killer question (hat-tip to Andrew Travers)
Allow yourself to follow lines of enquiry.
In 2014, we started to map interview findings directly onto things called “empathy maps”. This really helped us manage what we learned and synthesise something useful from it. This is only one way to process the information you collect, of course.
You can start to turn all this information into simple, shareable reference documents like personas and activity descriptions.
As a designer, I try to layer my understanding of a problem space, and working with people with other expertise provides this richness.
So, either working alongside a data (visualisation) expert, or consciously switching between that role, and the role of audience-focused designer, and inform your work.
Having a data visualisation expert explore and visualise data in different ways can open up new possibilities, and it can introduce essential constraints.
In recent work, we’ve been collaborating with Ryo Sakai, and his work has fed directly into the visualisation design process.
Be explicit about 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 (see http://www.slideshare.net/cxpartners/photo-content-strategy-james-chudley-cxpartners). 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.
Don’t just add add layers of data because you can.
What needs to be there?
See more about Herr Hofmann http://www.wikiart.org/en/hans-hofmann
(thanks to Eva Lotta Lamm for educating me about this quote!)
I could give a whole talk on the whys and wherefores of sketching, not least because this is something that scientists and developers already do! I’ve seen them.
In a quick, light-weight way, sketching can help you with generation - variation - iteration of ideas.
Pairing and Design Studio format are both very productive structures for generating and developing sketches.
As for why…
Communication
Collaboration
Visualisation
(as well as helping you think about and understand a problem space)
Yes, you can sketch in code, but perhaps that’s best for data exploration.
Try leaving your computer alone, and picking up a pen and paper.
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.”
In particular, the idea of something (the thing we might be designing… like a data visualisation) and how it fits into a wider ecosystem.
So in the case of a project where I am working on a data visualisation with colleagues, that visualisation fits into an interface, the interface into an application, the application into a workflow, the workflow into an area of research… and so on.
Trying to have a view of this ecosystem, and not just one part of it, seems like a sensible way to approach design in a complex setting like science.
I am by no means experienced in evaluating the comprehensibility and usefulness of a standalone data visualisation.
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.
I often use the 2+2 format (2 things to keep, to things to ditch or improve) as a simple approach.
Also very useful is Alisan Atvur’s “critique cross” (see https://www.flickr.com/photos/francisrowland/15569157226/ )
Frame any discussion with 1) how long have we got to talk? 2) what is the user/audience trying to do/see here? 3) what logic have you applied to your design choices? 4) this could be the key design principles guiding your choices
Are you on the right track? Do you need to alter what you’re doing?
Better to learn early on.
This is an important step in any design process but perhaps the least often addressed (I could do better!).
As well as reflecting our our validation stage, and reporting things to the rest of your team and other stakeholders, reflection gives us an opportunity to get better at what we do.
A clear understanding of goals, and the feedback you get from testing and validation, can help you prioritise work.
This is especially useful in larger, more complex design projects.
As you consider these questions, and the ways in which you might answer them, also consider that this is a cyclical, usually iterative process, rather than a linear, incremental one.
- Learn - Build - Test - Reflect -
This was one of two talks given at an event focused on “best practices” in design and data visualisation.
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.