A new UX method for building better data visualization products
You’ve heard of user personas, and maybe even Jobs to Be Done. But what about QTBA? No? Good. I made it up.
When building data visualization products, we need a better way of understanding the people using it. While previous standard web UX methods can help in this process, I think that building a data visualization product with the purpose of delivering insight is fundamentally different than most web builds.
Let’s dive right in with an example from a previous design workshop. My team and I were starting to sketch out possible user flows for a client’s data-driven microsite (not to be confused with user journeys — a user flow is basically how a person gets from point A, to B, to C as they travel through your site). While this project was not a dashboard product per se, the website had lots of data visualizations, filters and searchable fields. So in many ways, it possessed many dashboard-like qualities.
After deciding what the secondary pages needed to be for the sitemap, we reached an impasse. One of the UX guys in the room drew a box for the home screen (a page with lots of data viz) and asked: “So where does the user go next? And how many possible flows could you make through the site from here?”
This question left me puzzled. Not because I didn’t understand the idea behind the exercise, but because it seemed that the question had a circular answer.
The problem with traditional user flows in data viz
Here’s the first problem: most websites try to funnel users toward a single action or set of actions. Whether it’s buying a product, sharing a link, signing up to a newsletter, or whatever else you want people to do. In a now very popular UX Medium post, Alexander Hadley summarized a user flow this way:
A user flow is a series of steps a user takes to achieve a meaningful goal.
User flows should also follow three fundamental laws:
- User flows should have a clear purpose,
- Should go in one direction,
- And represent a complete task.
Sounds great! These principles should, when done correctly, lead to a user flow that looks something like this:
Great! Very clean. But when the goal of a website is to deliver insight through data, this linear model starts to fall apart. Once the user reaches the main sections of data visualization and discovery, the goal is no longer funnelling them to another page. The goal is exploration. So while the user can go to different pages, we want the user to stay right here: learning more, interacting more, exploring more. And there’s often no defined task to complete.
“But where does the user go on the page?” You can see how this becomes a difficult question to answer. Most user flows can be visualized using a linear diagram, with nodes being the pages and each line being a different path users can take through the site. This works well when users can choose between a handful of new pages to visit, buttons to click or actions to take.
But with a dashboard-like site, the options for actions to take start to multiply exponentially. Want to know how many possible actions a user can take on this page? Take the number of charts and then multiply it by the number of filters. Take this number, and then multiply it again by the number of sortable fields and/or toggles. It quickly becomes a maze of tangled journeys. A choose-your-own-adventure free-for-all.
Let’s look at the three fundamentals of user flows again, but applied to this new data visualization/dashboard scenario:
Has a clear goal? ❌
“Find new insight” is too vague. What kind of insight? Why? Who’s it for?
Goes in one direction? ❌
At first, yes. But then where does it go from there? How many directions? Can the user go back? (often, yes)
Represents a complete task? ❌
Hardly. Rarely do people get a complex question answered by looking at a single chart or graph. Often, it requires exploring one chart, then filtering to a specific time range, then re-filtering to compare a different time range, and so on. Sometimes it can take time and targeted exploration to find the insight you’re looking for.
Susie Lu illustrates this concept perfectly in her fun and quirky blog post / comic series on designing dashboards. When designing the UX of a product, most designers assume a linear journey. But with most data-driven products, we need to account for a branching journey instead.
Branching user flows are complicated and unpredictable. But it also provides a much-needed role-reversal: instead of designers deciding where users should go, the power of discovery is given back to the user to choose from dozens, even hundreds, of different paths.
Inspired by Susie’s post, Elijah Meeks expanded on this concept with this article exploring the similarities in video game design and building dashboard products. In complicated strategy and role-playing games, the player has ultimate control to customize weapons, choose an outfit, travel to different territories, and find new items of interest. They have a task to complete, but it’s up to them how they do it. Data viz dashboards act in a similar way.
A Job To Be Done?
Remember fundamental law number three of good user flows? The one about representing a complete task? UX designers have started thinking more about user behaviour this way, as task-motivated rather than personality driven. Instead of basing designs on stereotypical user personas, some UX professionals advocate for a Jobs to Be Done (JTBD) mindset.
The JTBD method is based on the idea that humans have limits. And because of these limits, we need to borrow/hire some products in order to accomplish complex tasks. Once accomplished, the job is done: there is a clear start, middle and end to the story.
With JTBD, we have a better starting point for thinking about how to design data visualization products. I personally like the simplicity of this approach. People use data as a way to accomplish tasks and jobs that they could otherwise never dream of doing. But with data, it’s slightly different. We often don’t have jobs to be done: we have questions to be answered.
The Questions to Be Answered (QTBA) approach
We could all use fewer acronyms in our life to remember, so take this QTBA thing or leave it. Call it what you will. It’s more about the principle than the name anyways. I’ve heard other people talk about similar ideas using the term “insight stories”. Whatever floats your boat. But here’s the gist:
Building a data visualization product always starts with a list of questions from the people that will be using it. If someone is actively exploring and analyzing data, they will have a question in mind that they want to answer. Our job as data designers is to anticipate these questions and provide intuitive, user-friendly ways to find the answers in a dataset.
Here’s what the QTBA approach looks like when applied to a question. The goal is defined, but options on how to achieve the goal aren’t locked in. And once a user finds an insight to answer the question, it doesn’t necessarily represent the end of the journey. It may even raise a new Question to Be Answered.
Sometimes these questions may not be apparent at first. That’s why it’s helpful to have some tried-and-tested UX methods ready for workshops, like a user story exercise. User stories allow people to use natural language to define the role, desire and motivation for each user. For example:
As a [UX Designer] I want to [embrace Agile] so that [I can make my projects user-centered].
Starting with user stories can help start discussions around what people want to do with the data. It also reveals the motivations behind wanting to find certain insights. From these, we can translate each user story into a question (or multiple questions). These questions then create our feature list, since the features of our data-driven site will serve to aid the user in finding answers to the questions.
Once we’ve got a feature list, we can start designing! But nothing too crazy yet. Start with sketches, wireframes and rough mockups. Then test, iterate, rinse, repeat.
This initial “discovery” phase is crucial to ensure the best data visualization product possible. We first need to discover what it is we’re building—and what questions need to be answered—before we can start designing and prototyping a solution. That’s where the QTBA approach comes in.
Thoughts? Feelings? Let me know! I’m curious to hear how other people plan for creating data products as well. Leave a comment below or find me on Twitter.
