Designing for the Data Visualization Lifecycle
By: Elijah Meeks
Tags: Dashboard, Design, Exploratory Data Analysis, Data, Data Visualization

Designing for the Data Visualization Lifecycle

Illustrations by Hajra Meeks.

Everywhere you look today, and especially in a data-driven organization, you’ll find data visualization. Data visualization is key to how modern companies create impact. It’s built into every tool and workflow. It’s an important part of the job not just for data engineers, data scientists and data analysts, but also the people without “data” in their title. It’s in product presentations, ad hoc communication on Slack, leadership reports to the shareholders and even in marketing materials.

We want to challenge the tool-centric and role-centric approaches we often see in data visualization which force a person to jump between tools or the artificially created walls of different roles.

At Noteable, we’re explicitly designing our data visualization functionality to reflect how people use data in their work today, not how they did it 15 years ago. We’re looking at how the expectations of data workers and data consumers have grown and converged regardless of their job title or the problem they’re addressing. We want to challenge the tool-centric and role-centric approaches we often see in data visualization which force a person to jump between tools or the artificially created walls of different roles. We feel this will encourage diversity of data visualization expression by bringing in strengths from other approaches. That means, even though we’re developing a computational notebook product, that we need to look at data visualization outside of the confines of a traditional notebook and place it within the broader context of how everyone is using data visualization.

Existing tools tend to be specific to the job/function

The design of tools used to create data visualization has not changed to reflect its ubiquity. Currently available tools are usually tied to and optimized for a specific use case. If you’re a data scientist, you’re focused on validating an approach and typically you’re using Jupyter notebooks or RStudio. If you’re an analyst, you might be using Tableau or Looker. If you’re creating explanatory graphics, it might be D3 if you’re a software developer or it might be Powerpoint if you’re not. If you’re working in finance or human resources, it might be Excel.

Many tools were designed before the data science boom

These tools were designed when data literacy was lower, organizations were less data-driven, and technical limitations meant that tools could only do so much. While the industry has continued to develop, many tools have progressed too tightly coupled with particular kinds of data, approaches to data and professional roles. This can lead to tools which feel highly specialized, such as the BI tools that are primarily used by data analysts.

Tight coupling between approach and tool is also the result of the evolution of data roles, which as they’ve matured have reinforced that the tool defines the job: Graduate courses advertise how to become a data scientist by learning python notebooks, bootcamps tell you to learn D3 so you can be a data viz developer, and countless workshops help you become an analyst by learning Tableau.

But the kinds of work being done by an analyst or data scientist or PM are not discrete, isolated moments of data visualization. The approaches used in one of these areas is not fundamentally different from the work being done in another area. Quite the opposite: the skills and approaches used in one approach could be very useful if incorporated into another.

We see these steps in isolation not because that’s the best way to use them but because they currently take place in isolation.

That’s why it makes more sense to move away from the idea that the data visualization an analyst does is different than that of a data scientist. We see these steps in isolation not because that’s the best way to use them but because they currently take place in isolation. It’s how our convenient rules like “Don’t use pie charts” or “Never use a rainbow color scheme” or “Maximize your data to ink ratio” were created even though they continue to be challenged when analyzed for tasks outside of the isolation in which they were created. But these steps are part of a process that transforms data from raw material into insights and actions. That process spans from the earliest exploration of the data all the way through to the presentation of that data to stakeholders and leadership.

The Data Visualization Lifecycle

It’s best to look at data visualization uncoupled from role or tool, and instead to focus on where it’s used in the process of working with data. Each of these discrete steps requires specific features of data visualization, from the exploratory data analysis of raw data, through validation of hypotheses and explaining patterns in the data, into productizing the charts produced into regular reports and other data resources.

Long gone are the days when organizations were trying to find data; now they all have too much data and the challenge is finding the right data and getting the right summary of it to the right people.

Let’s take a look at each step to see how data visualization is used and how it’s supported today.