The Why, the What, and the How in Dataviz

This is part nine in a series of articles that illustrate how basic design principles can improve information display. The previous article took a deep dive on the balance between function and visual appeal in a business dashboard. Here, we’ll look at how you can use an in-depth conversation with your client to get really clear on the context and goals for your solution. This will help you to frame a project, and to evaluate the solutions you produce.

Anytime you are working with someone else to create a dataviz, you are going to get a variety of information coming in all at once. It’s your job as a data visualization designer to untangle that information and use it in ways that make sense and support your aims. Unfortunately, the input is often messy, usually contradictory, and can sometimes be quite prescriptive as well. You’ll need to navigate that process thoughtfully if you want to get to a good result. It’s also worth recognizing up front that you may not be able to create an ideal solution with the conditions you’re given, depending on your position in the relationship and the flexibility and requirements of your partner. No matter where you start out, you’ll need to create a space for honest criticism, constructive feedback, and thoughtful evaluation of multiple options in order to support the best possible result for a given set of circumstances.

The hardest question to answer is often the one that we put first: “what do you need?” A client or person coming to you for advice often doesn’t know what they need. Even if they’re certain that they do know, there may be other things that they have not considered (otherwise, there’s probably not much point in asking an expert!). It’s your job to synthesize the information that they give you, and to respond to it by creating a solution that best addresses that need, even if it is not the same as the thing that they originally asked you to do. Theodore Leavitt from Harvard Business School is often quoted for the following illustrative example: “Most people don’t need a quarter inch drill. They need a quarter inch hole.” Once you stop focusing on the specific request (“I need a drill”), you can broaden your thinking and realize that there are probably many ways to achieve a hole, opening up space for more creative solutions that meet the actual need. Nancy Organ has written in Nightingale about some of the specific questions that she asks during this part of the process, which she calls “data visualization therapy.”

Synthesizing different inputs is an important step in getting to the right data vis. Image source.

I often find it helpful to break a request down into the “why”, the “what”, and the “how.” The “how”/”what” distinction is fairly common in companies with agile teams, so it’s likely that people are at least familiar with the idea, and it can be a good way to frame conversations that can sometimes be difficult. It can also be a gentle way to remind people not to be overly prescriptive. A familiar framework can also help to defuse the defensiveness that some people may feel when you start asking probing questions. In any good design conversation, the “why” and the “what” inform and determine the “how”, so you’ll want to get very, very clear on those before you start diving into solutions.

Why is this chart important?
What information does a user need from the chart?
How do you want to see the data displayed?

The “why”/ “what”/ “how” conversation can be particularly tricky to navigate, because one kind of question can often masquerade as another. “What are you trying to achieve?” is actually a “why” question, even though it uses the word “what.” The point here is not to force a particular grammatical structure or word choice — it is to scrutinize the intent and the motivations for different requests. Sometimes, this can be helpful: if you run into someone who is particularly resistant to a “why” conversation, they may be perfectly willing to answer questions phrased using a “what” instead.

“Why” questions — Purpose

“Why” questions try to tease out the core purpose of the chart, to understand its real value, and to identify a user’s motivations in seeking the information it contains. (You probably started this when determining the purpose and audience for your chart.)

Why is the user interested in this chart?
What’s the big-picture task that users are trying to do?
What will a user learn or gain by using this chart?
Why do you want to add this chart (to your report, dashboard, etc.)?
What are you hoping to achieve with this visualization?

“What” questions — Definitions and constraints

“What” questions focus on defining the challenge, and establishing the parameters and constraints that will guide your design. These questions should suss out the details, identify additional use cases, and create a broader context for the visualization. All of these will help you to get clear on the task, and will guide you in designing. I think of “what” questions as the ones that will help me to distinguish between different options, and identify the best solution.

What are the characteristics of the data?
What medium/technology will you be working in?
What are the current standards for showing this data?
How is the user used to seeing this information?
How much is the client open/willing to change?
What is the budget for this work?
What specific task(s) is the user trying to accomplish with the chart?
What information does the user need to complete their task?
What is most important to emphasize?

“How” questions — Implementation specifics

“How” questions should usually be answered as part of the design phase and not up front, but you might want to get a sense of general preferences and expectations to help frame your design choices. These questions focus on the specific details of the implementation, and help you to think through how a particular solution supports the needs identified by the “why” and the “what.”

How do users want to see the data?
Which chart type should you use?
How will you show labels and data values?
How do users access the chart, and how can they interact with it?

The “why”/ “what”/ “how” conversation is an information-gathering session, and ultimately, a negotiation about the parameters that you can and cannot control. If your chart needs to show 5,000 data points, that is going to seriously limit your options. If you can include filters, bucket categories supported by drill down, or simplify to a “top-ten” approach, that may completely change the options for your design.

It can sometimes be difficult to get your partner to engage in a “why”/ “what” conversation, and some may even perceive it as a waste of time. Recognizing that this is a conversation about control can sometimes help you to find places to shift the discussion in productive ways. Most people will tend to get off track and revert back into the “how” as a proxy for the “what” when they’re not clear. That’s ok — just like following your breath in meditation, resist the urge to get frustrated, and instead gently refocus the conversation and bring them back to the task at hand.

A particularly prescriptive “how” request ultimately becomes a constraint for the designer, and should probably move into the “what” category instead. People and organizations who are not used to working with design or who think of design as a last step to “make things pretty” sometimes try to turn all of the “hows” into “whats,” and end up over-constraining the problem. If the client insists that they absolutely must have a line chart, in many ways they’ve pre-determined the outcome, whether or not they realize it. Not leaving enough “how” to work with limits the options you can create and where you can apply your expertise. As a designer, you sometimes need to take a few of these “whats” back in order to be able to do your job well. Most constraints are just a well-intentioned attempt to be clear, and the criteria may actually be much more flexible than they appear in the initial statement.

This conversation is also a delicate dance around authority, your power in the relationship, and how much leverage you have to inform the final solution. Depending on your client, they may be reluctant to get into why they are asking for this particular thing, because that creates an opportunity for you to judge their conclusion, and opens them up to receiving contradictory opinions or advice. If they perceive your role as one that should simply take instruction, they may receive questions about motivation and purpose as an affront. This is especially true if they are used to being the boss or the expert, or if they do not trust you to be able to understand the full problem. It is your job to establish yourself as a partner in the process by demonstrating your own expertise and gaining their trust. A well-placed question, alternative options or illustrative examples can go a long way toward helping your client to embrace the relationship.

You probably see a much wider range of possibilities than your client. Image source.

Most people who start out being prescriptive simply do not see the variety of alternatives and the complicated decision tree that you do. They cling to the path that they know, rather than looking at the universe of options that you can see. If someone is anxious about their timeline or suffering from decision fatigue (most people are, most of the time), then opening up more possibilities can feel overwhelming or be perceived as a threat. The harder it was to get to consensus with their team before coming to you (and the further along they are in developing the proposed solution), the more stress you’ll cause by asking them to entertain different options. It’s your job to help them see those other options, and to act as a guide so that that they can tolerate the uncertainty you’re introducing without being overwhelmed.

Many clients have never thought about why they need a particular thing, and they may be afraid to expose their lack of knowledge. Some people may mistake your “why” questions for resistance to their preferred solution. Reassuring statements like “I’m just trying to understand the context” can help to defuse defensiveness and move the conversation forward. If you can expose alternative options that they find attractive in the “what” part of the conversation, you’ll find that people are often willing to discard some of those early absolutes.

Navigating the conversation

The “why”/ “what”/ “how” conversation can be a delicate one, but it is also important. It establishes you as a partner and an expert, as well as giving you the information that you need to do your work well. Here are some things to keep in mind, to help you navigate these dynamics.

Keep a lid on your own defensiveness, especially if you feel that your expertise is being overruled. Patience and persistence are a lot better at building trust than anger. You are the expert here, but they also have information that you need. Working with someone will almost always go better than trying to overrule or out-argue them. Most resistance comes from discomfort and unfamiliarity rather than ignorance, incompetence, or ill will.

Assume good intent, until you cannot do otherwise. Most people do not understand how to specify design, and particularly not data vis. They will be awkward and clumsy at it. They may bruise your feelings, insult your intelligence, or make unwise choices from time to time. This is almost always unintentional. Help them to see a better way.

Signal cooperation and helpfulness. You are trying to understand, not correct. They have important information that you need to hear — you can decide later what to do with it, but these conversations are critical for helping you to understand the job. Offer options and suggestions rather than arguments for why your way is best. Explain how your solutions help to meet their goals.

Pay attention to your tone and body language. Keep an open, curious orientation, and make sure that you are responding thoughtfully to their requests. Smile a lot. Nod. Thank them for helpful information. Explicitly point out how their feedback affects your decision-making process and recommendations, and how you will use it to inform your design. Explain the connections that they cannot see. Correct gently, and offer alternative perspectives when possible.

Listen to the client’s signals. This kind of conversation is often uncomfortable for people. Pay attention to your partner’s cues and openness to discussion. If they’re shutting down, back off for a while and give them a break. Focus on something else for a while, and then come back. The last thing you want is for them to feel hounded and back into a corner, because you’ll spend all of your time trying to get them to come back out again. Pay attention to what they’re saying with their tone, their answers, and their body language. Respect their boundaries, even while you push them to consider other things.

Commit to delivering the best possible solution, given the constraints. Don’t be afraid to expose risks and don’t pretend that you can “fix” a bad solution, but also make sure that you are not threatening the client with abandonment or failure if they don’t like your advice. If you want them to be open to considering your informed opinion, you need to show that you are also considering theirs. “I foresee these problems if we go with that solution. I can counteract a few of them with x, y, z, but these issues will remain weaknesses that are likely to cause you trouble down the line. This other alternative might work better here.” It is your job to do the absolute best work that you can, even if the circumstances are less than ideal.

Frame your objections as questions, and be sure that they are not leading or dismissive. If there is something that doesn’t fit, ask about it, but don’t assume that their solution is wrong. There is usually a lot of information hidden in prescriptive requests for a particular solution — figure out what the person is defending, and why it’s important to them. If there’s something that you absolutely would never do, be clear about it without shutting down the conversation. “I wouldn’t usually recommend that, but can you tell me more about why you were leaning that way?”

Help your client to reframe when necessary. “I need to see this data in a line chart” often means “I want to focus on changes over time.” Help them to understand what is important, and where it is ok to let go. Framing charts as a mechanism for completing a particular task often helps people to consider alternatives that they might otherwise dismiss, and it gives you a context for suggesting other options — not as competition, but as possible alternatives.

Keep digging until you get what you need. A client or user will almost never be able to answer your questions directly, because they simply do not know how to think about the problem in this way. That’s okay. Just keep asking, and approach the question from multiple angles, to get the clearest picture that you can. Just be sure to communicate what you are doing along the way!

Come back to the conversation. Each design review should revisit this initial conversation. Tie your decisions back to the original “what” list, and explain where you were going, and why. Evaluate the different solutions in terms of their effectiveness, and talk through their strengths and weaknesses. Then pause, and ask whether there are additional “whats” that didn’t come up in the first round. Usually, people will think of a whole new level of “whats” once they are focused on a particular solution rather than an abstract first conversation. That’s a natural part of the process; go along with it, and use it to refine.

Reassure them that this phase is temporary. If you have someone who is particularly resistant to open-ended thinking, it can help to identify it as a stage in a process. “First, we need to think really big and get clear on the task, and then we’ll get practical and ground it back in reality.” Narrate the journey and help them to see how the open-ended conversation informs the solution phase.

Reward people for embracing discomfort. Remember that your client is probably uncomfortable, and signal to them when they are doing well. Point out how their comments help you, acknowledge that this can feel a bit awkward, and translate for them how this is important to framing how you think. “I know I’m pushing the edges here, but what do you think of this?” is sometimes enough to get people to look at a solution they might otherwise ignore, especially if you point out that you’re trying to get clear on why one solution is better or worse than another to them.

Troubleshooting

Despite your best attempts, there are bound to be situations where someone is not willing to play along. Here are some common trouble spots, and ways to address them:

People may interpret your questions as resistance, or as challenges to their expertise and authority. If you find yourself getting caught in endless arguments or justifications about why this one chart is so important and they really, really need it, this is probably because your partner is hearing your questions as a threat to their preferred solution. Reassuring them that you want to make sure you understand or explaining why you are asking can disarm some of those concerns.

People almost always conflate “what” and “how.” In most cases, a requester comes to me with some mix of “what” and “how” parameters. Try to articulate the distinction, and get them to engage in the conversation as much as you can. Sometimes it helps to make a list of the “whats” and the “hows” as you go through the requirements, and to decide together where to put each one.

People may not be familiar with the job tasks. Quite often, the person requesting the chart is not the person who will use it, and they likely don’t have a good idea of what the real subtasks actually are. Often, people will try to be helpful and give you answers anyway. In many cases, these may be nothing more than blind guesses. This is why it is critical to talk to users who actually perform the job, and to balance what you are told against your own experience and expertise.

There may be multiple motivations at play. This happens a lot in top-down organizations focused on compliance: you’ll be commissioned by management, and their primary focus is on compelling their users to engage with the chart. Recognize that the client may not be willing to engage in deeper conversation if they’re already dug in elsewhere. Do your best to bring the conversation back to common goals: getting the chart right will help to encourage compliance by making it even more useful to the end user.

People usually don’t know what they need. Even if you talk to an expert user who performs these tasks every day, they may not actually know how they do it, what steps they take, or what information they really need. Expertise is built by establishing shorthand and conceptual groupings that make it easier to do complex tasks. The more expertise your partner has, the harder it will be for them to break things down, and this can cause you to miss things. Interviewing a range of users with different levels of experience can help to counteract this. For a new system, your partner may simply not have thought deeply enough to be able to answer questions in advance. This is where a lot of “what” questions come in handy, and interacting with early mockups can also help them think through the real need.

People might forget to mention something important. Even if someone does know precisely what they need, they may think it’s obvious or not worth mentioning. This is especially true if they are using an existing system that has defaults that they assume to be universal. Watch out for hidden “of course” statements: “of course you’ll need to export the data — the system would be useless without it.” Time constraints, impatience with the process, and fear of talking down to the designer can all contribute to people not saying what they actually need. Having a standard checklist of items can help to make sure that you cover all of your bases, but there is no substitute for checking in frequently as the design progresses (and factoring in time to re-think when people realize that they “forgot to mention” something critical in the final review). A thorough, step-by-step review of the workflow also helps to uncover hidden needs.

“Whys” tend to stack. You may get an answer at one level, but really need information at a different one. Improving engagement and compliance might be the “why” at the top of a manager’s mind, but they probably also need to communicate with their team, and increase the perceived relevance or clarity of the information as well. Understanding the full “why” stack helps to clarify what kind of problems you can (and can’t) expect to solve with the design.

You may simply disagree. At some point, you may realize that your professional opinion is simply at odds with what the client wants. Do your best to help them understand your reasoning, expose the risks as you see them, and then decide whether you can live with the “whats” that you’ve been given. There is almost always something you can do to make a solution better, even if you don’t think it’s ultimately the right one. If you feel that the solution is harmful or unethical, you may need to leave the project, but if you are managing the conversation well, it seldom comes to that. Hopefully, you’ve been able to establish a solid relationship and a set of shared goals in the previous stages to help you avoid that outcome, and you’ll come to a mutually agreeable solution instead. If not, it’s good to know up front that things aren’t likely to work out, and to reduce losses on both sides if the differences are irreconcilable.

Ultimately, the “why”/ “what”/ “how” conversation is just the first step in establishing the context and a basic understanding of your design task. Coming out of this conversation, you should have a clear idea of your purpose, your constraints, the information that you have to work with, and some possible options on the table. The next step is to get practical and start applying this information to shape your design. I encourage you to take the initial “what” as a starting point rather than an ultimatum, and to push the edges of your original framing of the problem when and where it makes sense do so. This conversation should be a starting place, not the final word on your design. Once you’ve clearly defined the request, you can apply your creativity to suggest good solutions and ways to create even better options.

Thanks to Mary Aviles for editing.

Erica Gunn

Website

Erica Gunn is a data visualization designer at one of the largest clinical trial data companies in the world. She creates information ecosystems that help clients to understand their data better and to access it in more intuitive and useful ways. She received her MFA in information design from Northeastern University in 2017. In a previous life, Erica was a research scientist and college chemistry professor. You can connect with her on Twitter @EricaGunn.