In Conversation: How to Approach, Design, and Tell a Story with Data Visualization

Humans like patterns.

Humans especially like patterns when something is complex or is difficult to understand. When you want to tell a complex story with data, data visualization is one of the best ways to do it.  

Data visualization can transform huge amounts of data into interesting, easy-to-digest graphs and charts that beautifully help tell a story. 

While that sounds good, you might not know where to start when designing with data visualization. And that’s fair— it’s not easy to do. 

So how do you make your data visualization a positive experience for your website users, stakeholders, and/or customers? How do you create something, with data, that another human will understand and find impactful? 

To get some answers for these questions, I sat down with Stan Choi, one of our designers at Clique Studios who is well-versed in data visualization. I asked him about his recent work with data visualization and the most important strategies to consider when approaching a project. 

Before we get into the interview, some background: Stan recently worked on a project with the team at The State Higher Education Executive Officers Association (SHEEO). SHEEO compiles an annual report every year called State Higher Education Finance (SHEF). This report is significant. It’s used by policy makers, researchers, academics, politicians, and reporters. The report examines the trends, context, and consequences of state higher education funding decisions. Choi references this report throughout the interview. 

With that, let’s get to it. Choi and I started talking about approach and strategy… 

The Strategy Behind Designing with Data Visualization 

Megan: How do you decide how to best represent the data?  

Stan: First, you should think about whether or not it is better to use charts and graphs, or to list out numbers or text on a data table.

Data visualization is an opportunity to make a page more exciting and to tell a story. Before you jump into the project and start making design choices, think about the best way to tell your story. 

Megan: How do you as a designer decide on the right chart/and or graph to use? 

Stan: Think about how you can improve current visualizations. Choose the chart that is best for the audience. You can have a lot of impact by adjusting a few things. 

Another way is to put yourself in your users’ or customers’ shoes. Think about how they will read the data. 

For example, for our client, SHEEO, the best type of chart to use for Net Tuition as a Percent of Total Education Revenue is a line chart. The data labels are at the bottom so the user can see a timeline. The line chart is simple and tells the story they want to tell —that the student share of total education revenue in each U.S. region has increased over time.

Megan: What other design principles do you keep top-of-mind for data visualization? 

Stan: Data visualization design has to be kept simple. You should declutter your visualizations as much as you can to focus your message. There can be a lot of unnecessary data points or visual elements that distract more than they help tell your story.

Megan: Do you have any tips to keep the design simple? 

Stan: Color is a simple way to draw the user’s attention to what really matters. When emphasizing one piece of data, highlight that data point in a color that’s different from the rest of your chart. Use a color that creates a clear visual separation between the highlighted data and the data it’s being compared to. 

Design Execution 

Megan: How do you decide on colors? 

Stan: Choosing colors is a huge part of data visualization. First, you have to make sure that there is enough contrast. If colors are too similar, it can get confusing. Select colors that the user can quickly recognize as different. Ultimately, it will help them see what the real message is. 

Of course, if you have a lot of  different data points, it will take users longer to understand the meaning of the colors. They’ll have to pause to match up the legend and the colors and to know what they correspond to. You have to consider that too when you’re making color choices. 

(Here’s an example of easily matching a legend with the data each color represents).

In the case of SHEF, I didn’t really want to rely solely on their brand colors because it just didn’t work visually. Instead, I created a color palette based on their brand, and expanded it to be more versatile for what the data visualizations needed. I wanted to make sure to create a simple experience for the user, and the custom color palette helped do that. 

Megan: How many colors should be used in a chart? 

Stan: I think two is ideal. Use one color to highlight your data and then one color for contextual/comparison data. If more colors are required, keep it to six colors or less. Again, you don’t want to overcomplicate a user’s ability to understand the core message. 

Megan: What are the similarities between design with data visualization and a “normal” design? 

Stan: I would say almost everything about data visualization design shares the same principles of designing anything really.

The design should be simple and have a focused intention and strategy behind every decision.  It all  really comes down to understanding the user and how they will receive it. In that regard, it’s the same things we have to consider.

Storytelling with Data 

Megan: How do you determine the order of the data? 

Stan: This is an important factor for sure. To make that decision, it’s important to consider the story that you’re telling. How will people be interacting with the data? What is the data trying to communicate? Balancing these two things helps you determine the best way to present it. 

For the SHEF chart about state funding (see the chart above), it makes sense to order the data from the lowest to the highest appropriations by state. 

Originally, I thought it would make sense in alphabetical order because whoever is looking at this might want to find a specific state. Alphabetical order would make it easiest to skim with that intent. But the client wanted the story to be about who has the least and who has the most, so that’s why ordering it from lowest to highest makes sense: it highlights that story in a glance.

Megan: How do you decide what data to use? 

Stan: You should use data that supports the point you are trying to make. Consider the intended audience’ expectations and what data they may find useful. 

For this project, I used the graphs that SHEF already had—graphs that were very well done. I took the data from those graphs and made some changes to help them be a bit easier to understand, using the colors that worked best for a user. And I also thought about what gridlines worked best. 

We spaced out the data points on the Y and X axis with less numbers because all you really need to know is that it starts at 50% and ends at 100%. The goal for me is to reduce visual noise. If there’s something in a graph that did not need to be there, we took it out. 

Megan: When you are designing, what else do you need to consider? 

Stan: We have to consider flexibility for when things are going to be different in the future. 

For long-term projects, the data can change. It’s important to think through different scenarios of what data could be displayed in the future with the design you’re working on today. 

If the client can provide examples of something that may happen in the future (based on the past), then we should consider that and add it to the style guide—accounting for the data so if something similar happens in the future, it’s easy to incorporate it into the design. 

If you read one section from this article… 

When designing with data visualization, start with the story, not the data or the design. Good stories involve more than numbers – it connects with audiences on an emotional level. The story that is meant to be told is how you decide how to order the data, what colors to use, and what graphs and charts to use and not use.

While the data is important, it’s only as important as the story itself.