Good overview on what it takes to build a dashboard/report.

A dashboard doesn’t try to solve a problem per se, but tries to provide one or more perspectives into the data, perspectives that can help solve one or more problems, respectively that make sure that no problems occurred. I find it better to think in this way, because is the question how much the metrics and visuals help to reflect the respective perspectives, respectively what overlapping exists between the perspectives. Consequently, it’s important to determine whether the perspective is complete, what kind of stories can be built upon data, and how much the visuals can support the narrative.

Conversely, it’s important to understand the set of requirements that led to the dashboard, quite often these being a problem statement or consequence of it.

It's important to ask who the data owners are and which their perspectives on the data are. Same for stakeholders/audience. Sometimes is important to understand which are the processes behind the data. Without the proper understanding of the processes, you risk creating more issues on the way.

The success of a report should be considered during its whole life cycle and be defined in more usable terms.

First make sure that the basis data is correct, respectively that the processes behind are understood to the degree that the choice of the perspective is correct. It’s helpful to provide an extract with a set of data to have it reviewed as surprises may appear. It’s an opportunity to get feedback from the users, respectively to identify issues with the data and/or logic.

Document the essential! One should establish good practices beforehand.