Mirror, Mirror on the wall, whose dashboard is best of them all?

Hope you all are doing good in this difficult time. Keep calm, this too shall pass!

In Program Management world, Reporting Dashboards play a critical role. Trust me, getting a dashboard right is a gut-wrenching process. There are so many moving parts in an Org and it is complex & critical to collect data from multiple sources. Dashboards are nothing but a representation of extracted & aggregated meaningful actionable information from the data collected from multiple sources.

The end goal being, it must assist user to make informed decision based on actionable data

While dashboards could be Operational or Strategic in nature, let's discus a typical software Release dashboard which every Program Manager starts his day with. Sharing few principles that I follow or look for in a Dashboard

What is a Reporting Dashboard?

Take a look at the dashboard in your car. That’s exactly what a dashboard is supposed to tell a user. It brings out the vitals, right in the face. What’s your speed? What’s the RPM? Are all vitals green? What’s the fuel level, how much more I can run?

Can you imagine a car running without a dashboard? You won’t know anything about what’s going on with the car. That’s exactly what a reporting dashboard is designed to tell us.

Now, not all dashboards are designed at best to solve the purpose, so let’s take a look at some critical elements which should not be skipped while designing a Reporting Dashboard.

Keep it simple!

Yes, again using the same phrase, thus emphasizing the fact that this is not a rocket science project. Simple implementations go a long way and often tough to implement as well, its easier said then done.

Simplicity is the core element of a Dashboard. Figure out what are the 3-4 most important metrics to present the status. Think hard about what's the most important data that you want the user of the Dashboard to focus on. You will always be tempted to put out all the data that you prepared with blood and sweat, but let go!!

For example - I prefer to summarize the status on top, two line summary of what's in the store for a visitor.

When anyone looks at it, he clearly see a “yellow” status. It gives an idea of how we are converging based on burn rate and what’s the runway. Shows critical problem areas - open payload. Short and sweet, right?.

Leave room for double click

Take a deep breath before putting any data on the dashboard. Allow the user to get to the next level of details, if he wants to. A classic example is how “Status” and “Status Category” fields are mapped in JIRA. The later abstracts the details and the user can choose to get to the details if he wants to.

Categorizing the status at a high level really helps in cutting the chase and keeps the details abstracted. Until the issue is Resolved/Done, it is still an Open item. Now, whether the issue is in “Pending Review” or very close to getting resolved, it’s still Open and actual status is a second level of detail.

Tell a story

This is a very critical aspect of a reporting dashboard. Throw too much information on the screen and people will completely lose the focus on the problem. Define a flow on how a user navigates from one widget to another. If you disclose everything upfront, it will mostly dilute the entire conversation and the focus. 

Start with a short summary, and dive into each summarized item in the next set of widgets. This keeps the user engaged and the narrative is very clear. A simple methodology I prefer is below. 

User Color coding, consistently!

First, you must have color codes. Human brain connects with colors much faster than words. The moment you see Red, Yellow or Green, you get very specific signals in your brain.

A picture says a thousand words, a colored one shows thousand emotions

Second, be consistent about it throughout the dashboard. This is a common mistake people make while designing the Dashboard. Your definition of Red must be consistent throughout the application.

For example - If less then 40% progress is "Red" for an Epic, it need to mean the same for an Initiative or for Overall Release. This way, user doesn't have apply any special check for any special category or topic.

Assist in the context switch

This is the result of storytelling in the dashboard. If it's done well, it will help the user in switching the context between bugs, stories, features and overall release readiness. When you are talking about open bugs, don’t bring the feature bugs which are still work in progress and vice versa. 

Here we can clearly see a crisp summary in Section 1 where all details are abstracted and only the progress at an Initiative level is revealed. Once the user reviewed the Initiative summary section, he clearly knows which Initiative he needs to further dig in. That’s when you show him details and take him to the next level in the tree, which is Epic level details. The dashboard assisted him in a context switch from Initiative summary to the next level of details for a specific Initiative.

Similarly, do that for second order, which is our case is Epics. Show the user list of all the epics along with a progress summary and the user can further choose which Epics he wants to get into more details. He can simply expand the Epic and clearly see what’s happening.

You see what’s happening here? You are guiding the user to reach the problem area, a lot faster without even him realizing that. Interesting, isn't it?

These were few aspects that I look for in a Dashboard. Honestly, it better be good if thats what I am looking at with my morning tea (not a coffee person :)). I am sure there are lot more aspects to be mindful off, while creating a dashboard. Do tell me about your thoughts and considerations for a Dashboard.