Using a design process for data visualisation projects

Tiny Viz Talks—11 May 2021

Transcript

00:08—Thank you very much for having me everyone I'm, as Sophie said, an information designer from Mudano, which is now part of Accenture, so I work in a huge consultancy on quite a range of projects, and I'm going to talk to you today about using a design process for data visualisation projects.

00:27—So in any data visualisation project you'll have some data, and you'll have some people who need information from that data, and data visualisation kind of sits in the middle, to be the kind of conversation between those two things.

00:39—But sometimes when we're really focused on what we're trying to produce in terms of visualisation, or maybe someone's given us a really direct instructions to what they want to see, we can get a little bit focused on the data visualisation – maybe we're trying out something really technically difficult or we get bogged down in that so we sometimes forget about the end user.

01:00—And in this case a design process can be really helpful as a framework to cement our thinking and make sure that we're doing the right kinds of things.

01:11—There are quite a lot of different diagrams that people use for design processes, but fundamentally they all kind of talk about: understanding the situation that you're working in, coming up with some ideas to solve the problem that is arising from those, and trying things out and testing them on people, and then eventually getting people to use it.

01:30—The Design Council has one that focuses on divergent and convergent thinking: divergent when you're trying to open up to new ideas and explore different options, and convergent when you're trying to narrow down your focus and get really specific about what you're trying to do. And so they have a double diamond shape thing.

01:49—The Interaction Design Foundation has interpreted it slightly differently and they go through the stages of empathising with your users, trying to understand what it's like to be them, defining your problem, coming up with some ideas, prototyping those ideas, and testing your ideas. The Interaction Design Foundation brings in the important aspect that this isn't a linear process, it doesn't go from A to B. You loop back and everything that you learn along the process can inform previous decisions. And it's absolutely right to iterate on those, as Ana said.

02:23—At Mudano we've created a very complicated one, that I quite like because it's squiggly and it shows that it's not quite an easy thing to do and sometimes you have to go right back to the start um but it still has those four stages: understanding what's going on, identifying the challenges, creating concepts and ideas, experimenting with them, and then embedding it in your organisation. The precise details of this will vary from project to project, and you just need to pick what's right for your current situation.

02:54—The reality does not necessarily allow us to do the process from start to finish. Often other people get in the way.

03:03—So let's say you had the global superstore data set, or something similar to that, and someone told you "I want to see sales over time".

03:12—This slightly limits your ability to be creative with this and to really think about what you're trying to visualise, because they've told you, so you start right in the middle of the design process: you're probably at the prototyping stage at this point and you probably don't need that many iterations because they've said what they want to see – it's quite easy for you to find that maybe – and you can present it to them so it's quite limiting as an information designer or a visualisation expert to do that.

03:42—If you ask them why, you might come up with a little bit more information.

03:45—There could be a number of reasons that they want to see sales over time information: perhaps they're working on a marketing campaign and they want to know what products they should focus on, maybe they're in charge of warehouse space and they want to make sure that they're making most efficient use of it, perhaps they're checking the contracts with the delivery company and they want to focus on the right areas geographically, or maybe they're thinking about how they might reward their loyal customers.

04:09—All of these will probably have some variation of sales over time that is useful for understanding these problems, but the types of graphs that you'll come up with each of these different problems are probably quite different and you'll focus on different areas. You might use filters in a different way, you might combine it with different types of data and you might realise that actually you don't have all the data that you need to answer the questions.

04:33—For example, I haven't studied the global superstore dataset recently, but I don't think it has the size of the product on there so if you're trying to fit it in a warehouse you may not know how big it is.

04:43—And at this point you open yourself up to a bit more of the design process. Now you can come up with a more specific definition of what you're trying to do and you can open up to other problems that you might need to address in order to really give the user the most useful information. You've got a lot more opportunity to come up with ideas and you've actually got things to try out here and it's not just one chart that someone's told you they want to see, you've got a lot of different options that you can try.

05:12—And, ultimately, it's probably going to be a more fulfilling experience and more useful for people.

05:17—And then at this point you can always work backwards to understand a bit more about the users themselves and to conduct research with them: ask them questions about what they do all day and really try and fit your visualisation into their day-to-day work, so it's not just another thing that they have to deal with, it's something that can fit quite seamlessly into their their work every day. And you can do this by observing their behaviours, and what they do. Ask them questions about what they like or don't like, and come up with insight about the people who are using the data visualisation that you're creating.

05:53—And then you can really transform this process to make sure that the users, the people who need the information from the data, are the ones that you're really focusing on throughout the whole process.

Q&A

06:09—Brilliant thank you so much Emily. Everyone please pop your questions in the chat. But while we're waiting for those to come in, I have a couple:So first of all, I loved your talk through of the development of your specific Mudano design process, just wondering for someone picking that process up and who's about to embark on a project, how would you recommend that they allocate time to each phase of that? Would you say that there's a proportion of time that you expect to spend on each phase or is it sort of too agile to even say?

06:44—Well there's the ideal, and then there's what you're actually going to get on a project, which are very different things. I think ideally you'd spend a lot of time in the research area understanding your users and defining the problem, and then from that hopefully the visualisation side of things is relatively quick. So I'm kind of lumping in technical requirements in that as well and understanding how the data works... I don't know that stuff very well. So that would all be in the first part of it and hopefully the majority of your work would be in that area. In reality it doesn't work like that. People don't like to pay for research time, they just want to see stuff, so usually you need to come in in the middle point, show them some stuff and then say "I can make this better if you let me ask you some questions" and so then that kind of working back tends to be more how people do it. But once you're used to working with a particular client usually they're more receptive to doing that first because it is actually faster in the long run, but it just kind of takes that conversation and bringing them on the journey of using a design process for data viz as well, because it's probably not something they're familiar with.

07:55—Definitely, thank you. We've got a couple of questions coming in, I'm just doing to read them out now. So Michelle's just asked how do you balance deadlines for the process, and she's also said great talk I love how fun it is thank you.

08:13—Balancing deadlines with the process I think it's just about communicating with people and kind of letting them know what your limitations are and how much you can achieve with the information that you currently have available. You'll always be able to do something, uh unless you actually can't in which case, you know, just tell them that! But I think it's kind of letting them know what's going on and you know where they can help you by getting more information. I work with a range of... I usually work with Tableau developers and business analysts and then we have some project managers around doing something important as well and I think kind of helping them to get you access to the users is probably one of the most beneficial things that they can do, and just kind of saying "all right, well if I can't actually speak to the users then we might come into this problem, this problem, this problem later on". So it's probably advisable for them to try and front load that, or at least to get it in the diaries because if you're working with senior people they're impossible to pin down, and actually get them to commit the time to you so even just having a conversation about what do you do all day is quite useful. I hope I answered that question, thanks Michelle.

09:33—Maybe we have time for maybe just one more. I think someone was curious about the comment you made about colour theory in your introduction perhaps, so they're curious about how do you balance including the brand colours and style of the clients with visual best practice taking into account colour theory?

09:50—Grey. Lots of grey. Yeah brand colours are horrendous for data viz in nearly all situations, but I think generally trying to minimise the amount of colour that you use on screen, as Ana said, I think kind of using fewer rather than more colours is good for this, and yeah just grey it up. Everything grey and then you add colour, rather than the other way around I think. Use colour to draw focus. But yeah colour theory is mind-blowing... I don't know how people manage that.

The curse of "neutrality"

Here's a situation: we're at work, we've spotted something that seems off, for example a group of people are frequently disadvantaged by a process, and we want to do something about it, to fix it. We need to collect evidence so we run a survey, across a much wider group than we can easily observe. We suspect this process isn't the only area of work that this group of people may be disadvantaged so our survey is quite broad in the questions it poses too.

Some time passes...

That was quite an undertaking! We've put in a lot of effort to get permission to run the survey, write it, circulate it, collect and collate responses, compile the data, cross-check it and analyse it. We want to tell people about this—they need to know about our work, and we should be thorough. We get everything together: tables, charts, some information about what we did and how we did it. Some supporting notes from senior people. We don't want to offend anyone so we stick to the point—we explain what we've done, using technical language so no one can poke holes in it.

We've got a fine-looking report on our hands! But, was that what we wanted?

Let's rewind a little. We wanted to change a process that was disadvantaging a group of people. We saw a human experience that wasn't the best, and we wanted to rectify it. The data was to validate whether our observations were also true for a larger group. But now, somehow, it's the main event, and the people we wanted to help haven't seen anything change.

It's easily done once the cogs are in motion. Numbers lend a sense of legitimacy that text alone may not, and with that comes responsibility. We, quite rightly, want to do the right thing. We're aware of the power of numbers and want to display them in the correct way. Which, often, involves barely touching them and letting others work out whether or not they're important. We describe them in language that is comparable to that in a legal document, so as not to misrepresent them. It's admirable, but adds a lot to the plate of any reader and it really hides our message. So how might we approach this differently?

Most importantly, we need to accept that these numbers aren't neutral. We had an agenda going into this—we wanted to change something for a specific group of people. This informed the way that we pitched the idea in the first place, the way we wrote the survey, the way we circulated it, the groups of people we cared most about responding to it and so on.

But we weren't the only ones.

The people who agreed to let us run a survey will have had an agenda, and may have pushed this on us to a degree throughout the process as well. The people who completed the survey will also have had their own agendas and they will have been led by the experiences they had that day rather than on average. In short, the survey data is as good an indication as we're likely to be able to get, but it isn't perfect.

It's also good to remember that just because we have data on a topic, it doesn't mean we need to use it. We chose to ask the questions we asked, we can equally easily choose not to highlight the responses to those questions if they're not useful to us, or others. Clearly there's an ethical line here, if the data directly contradicts our assertion then we probably should include it—I'm not suggesting ignoring data we don't like. But sometimes there simply isn't much to say about the data we collect, and that's OK—we don't need to find a story where there isn't one, or shoehorn in something that's unrelated to our message purely because we have data available.

So let's allow our data to tell the story. Come down on a side. Draw focus to one element over another. We're not out to misrepresent the situation, but let's not force people to work out for themselves what we're trying to tell them either. State our case, in words and with data. We wanted to change a situation for people—let's not leave it up to chance for the sake of appearing neutral.

Why dashboard designs sometimes fail

We consume a large amount of data in our working lives and, largely, the way we do that has improved over time. We used to share data in Excel files and regularly spend weeks creating static reports to present to people, which were likely out of date by the time they came to be used. Now, it’s just as likely that we have access to data in dashboards instead of being limited to a static spreadsheet. These dashboards update automatically, are available to everyone who needs them, and there have even been training sessions to show people what’s in them.

This is a significant improvement, without doubt, so why can’t people find the information they need?

Often it will come down to a straightforward, yet not effortless, reason: the information has not been presented with the users’ intentions in mind.

This article explains the process that you should go through to visualise the kind of business intelligence your company needs. For now, we’ll assume you’ve already sorted out data quality and the systematic complexities required to make it available in a dashboard, and you’ve selected a dashboarding tool that will do it justice. What now should you do with those tables of clean data?

For most people, it won’t be enough to simply see that data presented in a more visual way if it doesn’t easily enable them to answer their questions and make sensible business decisions using it. Often, dashboards are created to provide a window into a dataset and have quick access to up-to-date charts and tables—someone working with the data wants to show something. These dashboards may not have gone through much testing before being shared widely, and may focus too much on data and not enough on insight. This type of visualisation is great for exploring data, and gaining an understanding of how it works, but not everyone is interested in that kind of view. For many people, it takes time and patience to interact with data in this way, and can be frustrating if they need to hunt around for an answer to a specific question.

Dashboards are at their most valuable when they are designed for a specific purpose, and have taken the needs and constraints of the people using them into consideration. Just as we would present textual information in different ways depending on who it’s for and how it would be read, we should consider these variants when presenting data too. Consider, for example, the language and typography used for a news headline, an email, a report, a presentation—it is quite natural to vary our words and draw attention to different aspects of the information for these purposes, because the needs of the audience are different. The amount of time they have to spend engaging with the information, the intention behind seeking out the information, the action they’ll take after they’ve absorbed it, and so on. The same is true for data. Instead of creating a dashboard to show something, create one to help someone else understand what they need to from the data.

We can approach this using a design process.

First, begin by empathising with the people who would need to use the dashboard (the users) and defining the problems they may be having with the existing dashboards. For example, who are they? What are they trying to do? What decisions do they need to make, or actions might they take upon looking at the data? How much time do they have? What situations will they use the dashboard in? How are they used to making decisions with data otherwise? And so on. Ideally, we’d talk directly to the users, through workshops and interviews, to get their views. You might find that you don’t have easy access to users—in that case an educated guess could help you get to a reasonable starting point to later test with users. It’s often helpful to write down the assumptions that you’re making during this process, so that you can refer back to them and understand how they may have affected your thinking. The information you acquire during this stage will form the basis of your user requirements, so this is an important step in the design process.

These requirements are a valuable tool for you to use to start coming up with ideas for features, functionality, filters and focus areas. Some requirements may not be immediately feasible because of data availability, cost, or some other factor, but you can make the decision to come back to those at a later date. Try to avoid jumping straight to your dashboarding tool at this point, and think about how you can answer the users’ questions with the data you have available. Jot them down, and arrange the ideas into a sensible structure according to who would use a dashboard, how they would use a dashboard, the amount of detail they’d need in a specific scenario, and logical routes from high-level to detailed information. Think about the kinds of filters and navigation the users would need to find their way around and easily access the information they need. While you’re jotting down ideas, it can be helpful to use something that’s easy to adapt as you consider potential scenarios—(virtual) post-its on a whiteboard can be helpful here. Draw links between your screens to show navigation between them and consider what someone might expect to see if they clicked on a specific element of your dashboard. Consider how you can use tooltips and other interactivity to help users easily understand the charts you’ve selected.

Planning your dashboard like this, holding back on immediate delivery to try things out in a quick and easy-to-amend manner, enables you to save time and prevent waste further down the line by designing for your audience right from the beginning.

By this point you’ll have a good idea of how your dashboard could work—you’ve got a record of where your users could find specific types of information and how they’d interact with the dashboard to reach the level of detail they need. Now you can build your prototype in your dashboarding tool. While you’re doing this, bear in mind the impact that visual design will have on how users interact with the dashboard. Position, size, contrast and grouping of elements on a screen all affect how a user sees the information. You’ll want to create a clear hierarchy to direct attention to a logical starting point to guide a user through the information. Remove anything that doesn’t have to be on screen—chart junk can easily add up to create a seemingly impenetrable view, and an overcrowded screen can be overwhelming on first view. Aesthetics aren’t just the icing on the cake, either—people are much more likely to want to use something they find appealing to look at, and they will be more willing to explore it in the first place.

Your dashboard should be shaping up nicely now.

Before you get too attached to it, test it out with a representative sample of users to see whether they understand things in the way that you intended. You won’t be able to see this for yourself by this point, so if you can’t get access to real users, find someone else to test it for you. Fresh eyes are vital to spot inconsistencies, make sure your choices align with what the users need, and understand what they expect from interactivity within a dashboard.

Do this by setting users tasks that align with the original requirements, and watch how they attempt to complete them. Ask them to think aloud while they’re doing these tests. They might naturally search for the answer in a place you didn’t expect, which could be a change you make to improve the speed at which users can learn how to use the dashboard when you roll it out more widely.

It’s unlikely you’ll get the dashboard exactly right first time, and that’s to be expected. By observing users through tests initially, and later being receptive to feedback, you can revise your dashboard to be an irreplaceable tool for the people who need it. It bears repeating, but time spent in these design development stages will ultimately reap value further down the line.

The world is full of poor design examples. Don’t let your dashboards be among them.