Dashboards Have Requirements, Too

But I’d rather do just about anything else first.

Stefany Goradia
3 min readJan 18, 2021

My first mini-series of 2021 is “5 Data Viz Resolutions to Make in 2021.”

This is #3: more effort on requirements documents

“I am the worst offender of this one.” — Me, just now. Also last year, and the entire decade before that.

It goes without saying that data visualization is sexy (heh). But its not-so-sexy underpinnings — like research, planning, requirements gathering, documentation, testing, and other important steps — are often overlooked in development.

These underpinnings are standard operating procedure for the age-old software development life cycle (SDLC), but data practitioners in our field don’t always follow this rigor when creating dashboards and analyses, despite having many similar steps and goals as software or product development.

In fact, requirements and documentation is often picked last— if at all.

The data field can be a cruel place.
This image was inspired from a hilarious original cartoon by Paul Noth.

While formal Requirements Documents might not seem relevant if you’re not a software or product developer, I’ve seen the result of overlooking these steps lead to a range of consequences for citizen analysts and dashboard builders:

  • business users not using your dashboard over the long haul (or claiming it doesn’t have the information that they need),
  • an increased number of questions from users when assumptions and definitions aren’t well-documented, let alone recalled by the builder when asked about it 3 months later,
  • and inconsistent definitions of metrics/values lead to incongruence between data sources and more trust fail, which accumulates trust debt over time and becomes harder and harder to recover from (even if I did make up the term “trust debt” just now)

But this is all easier said than done, when exact steps can be hard to list. Overlapping concepts all sound slightly similar (yet all mean something slightly different) and add more complexity to the requirements and design mix. We can start by learning about concepts like:

  • software development life cycle (SDLC),
  • systems engineering or systems development life cycle (also called SDLC),
  • technical requirements document (TRD),
  • business technical requirements document (BTRD),
  • user research and/or discovery,
  • functional requirements, non-functional requirements, system requirements, all the requirements

A starter process could be kluged together from a few of these. I haven’t yet seen an industry-standard methodology specific to building data dashboards that is as widely-cited as disciplines like software development or systems engineering, though a few are attempting to emerge. The so-called data analytics life cycle consists of 6 steps: discovery, data prep, model design, model build, communicating results, and operationalizing (put into production). Others have proposed an 8+ step dashboard development life cycle, which seems too many to list in a simple sentence.

With time, something may crop up as a widely-accepted data/dashboard life cycle methodology, but you’ll be ahead of the curve if you start thinking about this as a formal process, and maybe even start implementing something along these lines now.

Not sure where to start? I started here:

And if there is another methodology out there that we should all spend time to learn about, drop a link in the comments and help to spread the word among your fellow data practitioners!

Stefany Goradia has spent her career on the front lines of healthcare analytics and writes about how to interpret healthcare data, communicate to stakeholders, and to support informed decision making.

Originally published at https://stefanygoradia.bio on January 18, 2021.

--

--

Stefany Goradia
Stefany Goradia

Written by Stefany Goradia

Health Data Guru. 50% Healthcare 50% Data. Healthcare is complex and health data is unique. I write about how they come together—and sometimes other stuff too.

No responses yet