How To Advocate for Data Throughout the Project Process

If you’re building interactive data visualization projects as an individual creator or in a small team (2 to 4 people), you may be able to conceive, design, and build projects without too much explicit process or documentation. But if you’re building visualization projects with a larger team, and especially if you’re doing it for external clients, how can you make sure that all data-related concerns are successfully carried through the project?

First, let’s look at the process for creating web products where data is not a special consideration:

The first three steps capture client objectives and context, requirements and limitations, and user needs. The next three steps consist of the creative exploration, reviews, and iteration. The last two steps involved creating the polished, pixel-perfect design and the complete development of all application views and features on the front-end and back-end.

How do we incorporate data into each stage of this process?

Here are some considerations for incorporating data into these existing steps.

Creative Brief: Is the data best suited by an exploratory tool or a predefined narrative? What insights must be drawn out of the data? What actions or decisions will be made based on this data?

Technical Requirements: How is data integrated into the project? (via API, scraping, database queries, etc.) How often will data be refreshed?

User Research: What insights are hidden in the data that could be valuable to users? What questions and problems are users facing, and how can the data address those?

Creative Development: Explore a wide array of ideas with quick sketching, brainstorming sessions, and back-of-the-napkin analysis. Come up with strategies for conveying the intended meaning and creating the desired look and feel.

UX / Wireframes: Lay the foundational structure that defines how the user will experience the application.

Copywriting: Translate labels, chart titles, legend and annotations into clear, accessible language that considers the audience. Humanize obscure jargon and wrap the data experience with clear, helpful explanations.

“Can you make this explanation less clear?” — Said no one ever

Visual Design (Mockups): There are a great many visual attributes of visualizations. One key principle is that, unlike some types of content where attributes like color, weight, position, line thickness can be selected purely for aesthetic or brand reasons, with data, there is potentially specific meanings attached to these attributes.

Unlike many other types of content, with data, there are many aesthetic choices that influence meaning.

Technical Development: Build it with some combination of scripts, code, and the cloud. This may include an ad hoc solution for efficiently pulling the data into your visualization. I’m not an engineer, so I can’t speak intelligently to this sort of thing.

But wait, there’s more

Beyond adding special considerations for data into each step, there are also some additional steps that arise due the nature of working with data.

Gather & Analyze Data: Perhaps the most critical piece of a data visualization project is making an assessment of the data you have access to for the project, and performing preliminary analysis. This is both the data due diligence needed to properly set up a project, and also the ongoing analysis that occurs as you explore design concepts.

Information Architecture: Understand the underlying structure of information and define what information (both data-related and non) will be presented to the user at each step. Information Architecture is a part of every project, though it may be performed implicitly in straightforward or standardized projects. In the case of data visualization, the IA phase is more critical for making sure that the structure of the data is correctly represented to the user.

Rapid Prototyping: This involves building quick and dirty versions of charts based on samples of the real data to be used in the project. Because you often don’t know what patterns you will find in the data, this allows you to test assumptions and judge if the design concepts that you are considering are actually going to create a compelling experience.

How to communicate visualization design when someone else takes over the project

When the entire project process is performed by one team which has visualization expertise, there may be many design decisions that are informed by best practices of visualization which don’t need to be documented. This is because the team shares domain knowledge; it’s assumed knowledge that may be invisible to an outsider, but it guides the project nonetheless.

But what if, for example, the creative development, architecture, and UX are performed by a team of designers who have data visualization expertise, and then the project is handed off to another team for visual design and technical development?

Here’s a classic example regarding the method of rendering bubble charts. The bubble chart consists of circles whose sizes are scaled to represent numeric values. For designers familiar with data visualization, there’s a well known rule that the area ( pi * r^2 ) of the circle is the dimension that should be scaled to the the numerical value, as opposed to scaling the radius of the circle.

This rule may be obvious to visualization designers, but how should we capture these principles and convey them to another team so that the final output is not “broken” from a data perspective?

How to put this into practice

I am proposing a Chart Specification document as a tool for carrying critical data-informed decisions from one team to the next. This is a new problem, so the terminology is up for debate. It might also be called Data UX, because this chart specification is a layer built upon the information architecture that makes the data clear, digestible, and valuable for the user.

Here are some components of the Chart Specification document. For each chart, or instance of visualization, we need to specify the following:

  1. Subsets of the data to be displayed
  2. Selection of chart type
  3. Chart components to be included (grids, lines, areas, labels, legends)
  4. Max number of data elements chart can support
  5. Guidelines for rendering this chart type
  6. Grouping, sorting, and layering (e.g. z-index)
  7. Labels, including specifying units of measurement
  8. Usage of color (this is very important)
  9. Minimum and maximum values of axes and other scaled elements
  10. Layout of legends
  11. Specific considerations where the design of the chart may integrate or conflict with visual queues in from the surround UI elements (e.g. a button in the UI of a particular color may be mistakenly associated with an element in the visualization that uses the same color)
  12. Animations and transitions used when the chart enters, updates, or exits the display
  13. Bonus: A brief explanation of why this chart selection is appropriate and what insights it provides to users

Please share your comments — what has worked for you? Leave your thoughts below and follow me at @ptvan on Twitter.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.