DEV Community: Eli Holder

Timely Advice: How long does dataviz take?

Eli Holder — Thu, 26 May 2022 18:48:12 +0000

This article is featured by Data Visualization Society (DVS). You can go here to read it on Nightingale.

Every client asks, “How long do you think that will take?” I’ve built software for a long time. I used to resist even answering the question. I’m a Fred Brooks acolyte and appreciate all the unforeseen ways that a complex project can go sideways.

I don’t mind it anymore though. It’s an important part of setting expectations (which make for happy projects and happy clients). And, for anyone who's worked for a fixed fee, it’s important for understanding if a given project will be profitable. So, not only do I attempt to estimate timing for every project, I also track the actual time to see if I’m right.

One of the challenges for estimating -- and expectation setting -- is having a track record of similar projects to reference. If you’re a larger shop, with a long history and full portfolio, you have an information advantage.
Smaller, independent shops, or freelancers, earlier in their careers, don’t have this advantage so it can be difficult to estimate.

Or, even worse, it can be easy to give into the pressure from occasionally overzealous clients fixated on budget line-items (“You’ll spend how long on research?!”).

The goal with sharing this data is to even out that informational asymmetry, and give a detailed reference of time and effort involved in producing (fairly complex) data visualizations.

3iap’s time-tracking dataset

From the start of 3iap in 2020, the focus was data visualization services for clients. Since then, 3iap has done a variety of projects, covering the full spectrum of work you might encounter as a dataviz consultant (e.g., research, analysis, data-wrangling, metrics, design, and various types of engineering). I’ve kept a close record of the time spent on each project.

As of early 2022, 3iap has logged ~1,550 hours of client dataviz work (in addition to sales / marketing / paperwork / etc., +300 hours of general product consulting to pay the bills, and an obscene number of untracked hours on silly side projects).

Below are findings about how that time was spent, in addition to highlighting 10 specific projects that represent a range of different dataviz work.

How much “dataviz” work goes into dataviz?

Distribution of 1,550 hours spent on 3iap client projects, split by activity type.

Roughly 60 percent of the total time was spent directly designing or engineering visualizations.

Design + Engineering

Distribution of dataviz design and engineering time spent on 3iap client projects, split by activity sub-type. Design and engineering activities together made up 60% of total hours.

31 percent of the time was spent on design, which can include everything from story discovery, typically bouncing between exploratory analysis and sketching story concepts with a pen and markers (4 percent), mocking up specific charts in Figma or Google Sheets (6 percent), prototyping different design approaches in Observable (3 percent design, 3 percent engineering), and even the occasional copywriting (2 percent).

On seeing this, I was surprised that slides were the second highest design activity (6 percent) -- I suspect this is due to inefficiency of the tool itself, whereas Figma can be componentized and coded dataviz can be automated, Keynote involves a lot of manual pixel pushing.

29 percent of the time was spent developing visualizations, typically in javascript (13 percent React, 6 percent Angular), but also occasionally in Data Studio (4 percent). This time also coincides with data-wrangling activities, building pipelines to prepare datasets for visualization.

Note, the design-to-engineering ratio might not be representative for others in the field or of a specific project. My background is computer science, so there’s a selection bias toward more technical work. Prototyping designs in code is also part of my design process, which blurs the lines further. Also, most 3iap projects are either engineering OR design, not both. For a more representative ratio, Interactive Scientific Storytelling and Complex Report: Analysis & Presentation Design were projects that involved both design and development.

How much “non-dataviz” work goes into dataviz?

Distribution of data, communication and research time spent on 3iap client projects, split by activity sub-type. Combined these activities made up 39% of total hours.”

This leaves 40 percent of total time on other activities. This remaining time is split between research, client communication, and data wrangling. (All of which are insanely important, but this might be unintuitive from clients’ perspectives.)

18 percent of the total time was spent communicating with clients, users and stakeholders, digging for stories and trying to make sure everyone is on the same page. This includes meetings (8 percent), and documenting designs, plans and code (3 percent), and the rest is email and Slack. While this might seem excessive, communication is a crucial part of the process; a few hours of up-front meetings, mind-reading and documentation can save days of rework. For that reason, a significant portion of communication time coincides with other activities. For example: 7 percent of total hours were tagged with both communication and design, which might include co-design exercises with clients or design reviews.

As expected, at 16 percent, data wrangling and analysis takes a significant chunk of total time. This includes data prep, which I’ve categorized as fairly mindless data engineering or spreadsheet maneuvering (9 percent) or data pulls (3 percent). More interesting data work was more fragmented: ~2 percent of the time was exploratory analysis (e.g., for storytelling), ~1 percent of the time was spent designing metrics (e.g., exploring different calculations that might best tell a given story) and another 1 percent was creating mock datasets (e.g., to compensate for data security constraints or clients who are slow to provide real data).

Research / discovery was 6 percent of the total time. The bulk of this was spent talking with clients, and coincides with meetings, email, and Slack. It also includes things like industry research, reviewing related academic literature, and whatever materials the client has available.

4 percent of total hours were tagged with both communication and research, which might include client mind-reading exercises, user interviews or other types of qualitative user research. This is probably the highest-impact time spent in any project: It might seem unintuitive, but at least in my experience the fastest path to a compelling data story isn’t necessarily in the data itself, it’s talking with the people behind the data.

Chaos / Overkill

Distribution of total time spent on 3iap client projects, split by cause of unproductivity. Clients cause “chaos,” whereas “overkill” time is self-inflicted.

For certain projects, I also track a category that I call chaos, which is time lost due to client shenanigans. This includes things like adding new scope on a fixed-fee project or revisiting early decisions that lead to rework. This was 8 percent of total hours.

The inverse of this category is overkill, where I become overly excited about an idea, fall down a rabbit hole, and devote way more time to it than is reasonable or sane. This was 4 percent of total hours.

10x 3iap dataviz projects - timing and details

The previous findings covered overall statistics for all 3iap projects. However, it can be helpful to see how time is used on individual projects. For each of the projects below I’ve tried to share enough about the scope of the project to understand the requirements, as well as overall statistics on how the time was spent. There’s also a timeline showing how the types of work evolve throughout the course of a project.

1. Analytics Product Design System (14 Days)

A long-term client asked 3iap to redesign their SaaS analytics app.

Left: Distribution of time spent on a single project, split by activity type. Right: Timeline of activity throughout the course of the project. Each ‘row’ corresponds to eight-ish hours (a “work day”). Each segment represents a single activity. Tile color corresponds to the activity type. Segments with multiple colors had overlapping colors (e.g. user interviews are both ‘research’ and ‘meetings’). Black lines between segments represent the boundaries of a calendar day.

A long-term client asked 3iap to redesign their large, complex SaaS analytics product (covering 200+ distinct metrics). There were three parts of the project: 1) a design system of chart components and supporting elements that can be mixed and matched to answer a wide range of analytics questions, 2) detailed designs of four different narrative reports, showing how the design system can address deep dives into various analysis topics, and 3) API designs and technical specifications for similar flexibility / composability when accessing the data from the backend. Because this was a familiar client and topic, there was little research or data wrangling required.

2. In-Product Chart Component (11 Days)

3iap developed an interactive chart component and automated testing framework within the client's existing codebase.

The goal was to not only deliver the component, but also develop a template for how other charts could be reliably developed and tested within their environment. The component itself was fairly simple, the challenge was making it work (reliably) within their system. This project was fairly chaotic. In addition to last-minute scope creep, startup codebases aren’t known for their quality or engineering practices. No judgment here, but this added significant drag!

3. Complex Report: Analysis & Presentation Design (24 days)

Analyzing a complex and novel topic, new to 3iap and the client, designing appropriate visualizations, then telling a cohesive story within a 51-slide deck.

This involved researching a new topic for the client, designing and developing novel visualizations, working closely with their data engineers to develop a novel set of metrics, several iterations of analysis, developing a framework to generate charts demonstrating the analysis, then designing a deck to tell the whole story. While this is the most research / analysis heavy project in the batch, these activities still only made up 38% of the total time (26% data + 12% research).

4. Embedded Reporting Tool Design (12 Days)

SaaS startup client with a unique dataset asked 3iap to design, prototype and user-test their in-product analytics UX.

The project involved researching their industry, offering and dataset, designing metrics to reflect the activities they wanted to track, designing and prototyping 4 “live reports” across Figma and Data Studio, facilitating user tests, and adapting accordingly. The client was the ideal balance of engaged, open-minded, and data savvy. They also had data available on day one. The project went smoothly and finished ahead of schedule.

Please check out the rest of the article at 3iap or on Data Visualization Society's Nightingale.

Visualizing "Small Multiples" Charts with Observable Plot

Eli Holder — Wed, 19 May 2021 21:42:49 +0000

Let's explore 2 things today in parallel:

Observable's new Plot library for quick data visualizations and exploratory data analysis.
The minor plague that is parking sprawl.

A few reasons why Observable Plot is great:

It’s super quick and relatively mindless to crank out “good enough” charts and graphs. If you need something fancy, d3 is still a reasonable bet, but for basic bar graphs, line charts, distributions, etc., it’s does the trick with minimal fuss.
The API is intuitive, minimal and uses the conventions that most d3 data visualization developers have come to rely on for custom dataviz.
The faceting concept, which we’ll explore here, makes it easy to visualize many different dimensions of the same dataset in parallel, as small multiple charts.

A few reasons why parking lots are the worst:

Car accidents. 20% of car accidents happen in parking lots (leading to 60k injuries each year, src).
Housing prices. More parking → less housing. In NYC, a 10% increase in minimum parking requirements leads to a 6% reduction in housing density (src).
Pollution. More parking → more auto emissions (src).
They’re so, so ugly.

Land Use for Parking Dataset

Let’s start with a dataset. Note that Plot is built with “Tidy Data” in mind, which is another way of saying it’s clean and tabular. Observable’s definition:

Each variable must have its own column.
Each observation must have its own row.
Each value must have its own cell.

So I’ve put together a County Parking Area Dataset here. It’s a combination of the results of this study, which models parking lot land use for the United States and the US Census National Counties Gazetteer File, which has basic facts about counties like population size and land area. It’s ~16k rows, each with 6 fields:

geoid: The FIPS state + county code for the county
countyName: A human readable name for a county
landAreaMSq: Land area in meters squared
parkingLandAreaMSq: Parking lot land area in meters squared
year: The year associated with the parking lot measurement estimation.

We can pull down the data with:

countyDataTidy = d3.json("https://gist.githubusercontent.com/elibryan/0bc177106babf67c1bf446d81fc6e5c9/raw/fea5ebd25f4d0f37f8a70a597540c5c97d030f4f/parking-area-dataset.json")

Then let’s make some charts!

How much have parking lots spread in single city?

A simple area chart in Observable Plot

Let’s start simple and just look at growth for one city. Let’s say Raleigh NC.

First let’s pull out just the Raleigh related rows:

  // The Geoid for Wake County, NC
  const raleighGeoid = "37183";
  // Filter the dataset for just Raleigh data
  const raleighTidyData = countyDataTidy.filter(
    record => record.geoid === raleighGeoid
  );

Then we'll create a simple area chart showing just the Raleigh time series.

We get the plot above from the following snippet:

Plot.plot({
  marks: [
    Plot.areaY(raleighTidyData, {
      x: "year",
      y: "parkingLandAreaMSq"
    })
  ]
})

This loosely translates to “given this tidy data, show me a sane area chart where X is the “year” field and Y is the “parkingLandAreaMSq.” Granted, the result is ugly, but this is a single, straightforward function call.

This introduces Plot’s concept of “marks.” In this context, a “mark” is an abstract term describing any visual encoding of data. Plot offers built in marks for all your favorite data visualizations (e.g. bars, lines, dots, areas, etc).

Let’s clean it up a bit:

We get the chart above from the following snippet:

Plot.plot({
    // Set formatting for the y axis
    y: {
      label: "Parking Lot Area (km^2)",
      tickFormat: (d) => d3.format(",.2r")(d / 1000000)
    },
    // Set the overall chart height
    height: 200,
    // Add "marks" to the plot
    marks: [
      // Define an area...
      Plot.areaY(raleighTidyData, {
        // Where X is year
        x: "year",
        // Y is parking lot area
        y: "parkingLandAreaMSq",
        // Color it a gross orange, to remind us that parking lots are gross
        fill: "#D46C25"
      })
    ]
  });

Conclusions:

Plot gives (nearly) 1-liner graphs for visualizing (silly) data in Javascript
Since 1974, Raleigh’s has more than doubled its surface area devoted to ugly parking lots

How much have parking lots spread across multiple cities?

Small multiples charts in Observable Plot

Let’s plot the 20 counties with the largest land-use area devoted to parking lots.

We get the graphs above from the following code snippet:

// The dataset includes observations for 5 different years
  const pointsPerCounty = 5;

  // Let's get the 20 counties with the largest (ever) parking lot areas
  let largestCountyIds = d3
    .groupSort(
      countyDataTidy,
      (records) => -d3.max(records, (record) => record.parkingLandAreaMSq),
      (record) => record.geoid
    )
    .slice(0, 20);

  // Filter a subset of the data for the selected counties
  const countyIdsToPlotSet = new Set(largestCountyIds);
  let countyDataTidySubset = countyDataTidy.filter((record) =>
    countyIdsToPlotSet.has(record.geoid)
  );

  // Let's add indicies to each row based on the county (a hack for later)
  // It doesn't matter what the indices are, so long as they're sequential
  countyDataTidySubset = countyDataTidySubset.map((record) => ({
    ...record,
    index: largestCountyIds.indexOf(record.geoid)
  }));
  // return countyDataTidySubset;

  // Extract the largest Y value (another hack for later)
  const yMax = _.max(
    countyDataTidySubset.map((record) => record.parkingLandAreaMSq)
  );

  return Plot.plot({
    // Draw a grid on the plot
    grid: true,
    // Set width to 800
    width: 800,
    // Slightly abusing facets to just show a grid of arbitrary charts
    y: {
      label: "Parking Lot Area (km^2)",
      tickFormat: (d) => d3.format(",.2r")(d / 1000000)
    },
    facet: {
      data: countyDataTidySubset,
      x: (record) => Math.round(record.index % 5),
      y: (record) => Math.floor(record.index / 5)
    },

    marks: [
      // Show borders around each chart
      Plot.frame(),
      // Show the area chart for the county with the matching index
      Plot.areaY(countyDataTidySubset, {
        x: "year",
        y: "parkingLandAreaMSq",
        fill: "#D46C25"
      }),
      // Show a label with the name of each county
      Plot.text(countyDataTidySubset, {
        filter: (d, i) => i % pointsPerCounty === 0,
        x: () => "1992",
        // Add the title to the top of the chart
        y: yMax,
        text: "countyName",
        dy: "1em"
      })
    ]
  });

We’re doing a couple things here:

First we’re extracting the 20 counties with the largest parking lot areas
Then we’re plotting them by slightly hacking Plot’s faceting system

Conclusions:

LA County has a crazy amount of parking lot. As of 2012 it’s 290km² (111 sq mi). That is, LA county has about 5x more area for parking than Manhattan has for everything.
Plot’s Facets are great for showing small multiples charts of datasets split by dimension.
Parking lots are the worst.

Like this post?
You can find more by:

Following me on twitter: @elibryan
Joining the newsletter: 3iap.com
Thanks for reading!