Dashboard Roasting: A Collaboration Between Data and Design

by Hayden McLeod, Data Analyst II @ Resilia — Read how Resilia takes a design-first approach to dashboarding and why you should too.

dash●board roast

/ˈdaSHbôrd rōst/

noun

1. A critical review of a dashboard, typically by a design-centric team or team member, to ensure that a dashboard is implementing and following design best practices

Intro

As a data analyst, my job is to enable stakeholders to make data-informed decisions. To do that, there are three main objectives I must achieve: gain insights from the data we collect on our platform, visualize those insights to make them easily digestible, and package those visualizations in such a way that stakeholders can take action.

As an industry, there is a lot of focus on the first two objectives, largely driven by the ease of using enterprise BI tools. However, there seems to be much less attention on the packaging of the visualizations — of the insights — and how we can turn them into actions, which is arguably the most important aspect of our jobs as data analysts.

At Resilia, we combat this industry shortcoming by taking a design-first approach to our dashboarding and reporting. We achieve this through guidelines modeled after design best practices but also through continuous review and collaboration between our data and design teams, which we internally refer to as our “dashboard roasts.”

Why Dashboard Design Matters

The two most important reasons we take a design-first approach relate to our stakeholders.

Firstly, if a dashboard is not designed in a user-friendly manner, a stakeholder is less likely to gain the full insights contained within the dashboard and would be less likely to return to it for continuous insights. A poorly structured data filter could limit the depth of insight the stakeholder obtains from the dashboard, i.e. they may not be able to slice the data as intended. The information and interactions must be presented clearly and intuitively to ensure that a stakeholder is ingesting the story that the data team is trying to tell.

Secondly, if a stakeholder has a bad user experience interacting with one of our dashboards, they’re less likely to trust the information contained within the dashboard. This could mean that something as simple as a poorly placed chart, an unclear label, or even a weird color choice could invalidate otherwise accurate data and insights in the minds of the stakeholder. In extreme cases, this could even lead to eroded trust in the data team as a whole.

Dashboarding Best Practices at Resilia

Currently, our internal dashboarding guidelines at Resilia center around three main categories. First, they must tell an original story. Second, we embrace a “less is more” philosophy and keep dashboards simple. Third, we make sure the dashboards are clear and consistent.

Tells an Original Story

We have three guiding principles that we follow to ensure our dashboards tell an original story:

1. Story is complete and clear
2. Does not repeat information or story told in another dashboard
3. Use an inverted pyramid approach to storytelling

Telling a clear and complete story ensures that each dashboard remains focused on answering the question being asked within it and nothing more. Doing so helps us make decisions on what should or shouldn’t be included in the dashboard by asking ourselves how a potential new chart fits into the overall story we’re trying to tell.

Ensuring dashboards contain unique insights helps us to organize our information in such a way that our stakeholders can more easily find what they’re looking for. As a counter-example, if we had numerous dashboards that had similar insights into user activity, stakeholders may often find themselves forgetting which dashboard to look at. However, by having information or stories only contained in one place, they are easier for stakeholders to find.

Image by Brent Dykes via Forbes

Using an inverted pyramid approach to storytelling allows stakeholders to get a range of insights from the dashboards depending on the depth of insight they’re looking for. The inverted pyramid places the most important information at the top, often KPI-type metrics. This allows a stakeholder to open a dashboard and get the highest level takeaway in a matter of seconds. The next layer of the pyramid is where we often include trends or some kind of insight over time. With a few more minutes in the dashboard, a stakeholder can get a better insight into how we’re doing over time, how things are evolving, etc. The last layer of the pyramid focuses on specifics. This is where we include the deepest level of insights contained in the dashboard: data logs, specific breakdowns, lists of events. This is where a stakeholder can go to research specific events.

Less is More–Keep it Simple

We have two guiding principles to ensure that we keep our dashboards simple and neat:

1. Include no more than 10 charts on a dashboard
2. Limit graphics to 6 or fewer dimensions

Including no more than 10 charts on a dashboard prevents stakeholders from being overwhelmed. We often find there is little need to display the information in that many different ways, especially if filters are being used effectively to slice the data from different angles. Additionally, using 10 or fewer charts prevents dashboards from drifting away from their intended story–tying this closely to the guiding principle of telling a clear and complete story.

Similarly, limiting graphics to 6 or fewer dimensions reduces the ‘messiness’ of charts and improves readability, ultimately improving stakeholder usability. In cases of a dimension being greater than 6, we often try to find ways that we can group them to reduce the number to something more easily digestible once visualized.

Make it Clear and Consistent

Instead of relying on a guiding principle, we have a checklist to ensure dashboards are clear and consistent. While some parts of our checklist are specific to our BI tool and company, some of the general guidelines include the following:

• Include a 1–2 sentence objective at the top of the dashboard as well as any notes or caveats pertaining to the information within the dashboard
• All titles, axes, labels, and keys are clear and concise
• Include a time-based filter for all dashboards, along with any other common dimensions (such as line of business or plan)
• Filters are not applied by default

Including the objective and notes at the top of each dashboard immediately provides necessary context to stakeholders. The objective helps them understand what question or story the dashboard is answering or telling, and the notes provide any nuances to the data or story being told.

Having clear titles, axes, labels, and keys is a largely recognized standard in the data community. There should be no room for ambiguity when a stakeholder is looking for clarity on what a chart is telling them.

Including consistent dimensions as filters allow stakeholders to routinely slice data in similar ways. For us, this means always including filters for our various lines of business, platform plans, as well as time-based filters.

Filters not being applied by default helps reduce any confusion or misinterpretation of the data. This means that by referencing some of the common filters above, our dashboards generally aren’t filtered to a specific line of business by default. Instead, we let the dashboard exist in its most general state and allow stakeholders to filter down to the specific questions they want answered.

Dashboard Roasting

What It Is

Defined at the top of this blog post, dashboard roasting is a critical review of a dashboard, typically by a design-centric team or team member, to ensure that a dashboard is implementing and following design best practices.

In practice, this has taken place here at Resilia in the following way:

1. I gather a list of 2–3 dashboards that I want the design team’s input on. Generally speaking, I want their input for at least one of three reasons–to either help me improve an existing dashboard, hold me accountable on design best practices we’ve established already, and/or assess new design ideas as our analytics and insights continue to evolve.
2. Once I’ve gathered my list, I schedule time with the design team and send them the dashboards, along with any context, at least a few days in advance. The context I provide is usually a high-level summary of the dashboard, any caveats that are relevant to the design, and then any design features or questions specifically that I want their input or advice on.
3. We meet, usually for 45 to 75 minutes depending on how long they’ll let me keep their attention. In our meeting, I start by diving into whichever dashboard is of highest interest to me or the design team. Within that dashboard, I do a high-level walkthrough of what the dashboard is trying to accomplish, the design choices intentionally made, and any design issues I ran into either due to the data or BI tool. Then I open the floor to questions and comments. At this point, the key is to sit back, listen, and take note of any and all feedback. Once they’ve provided me all of their thoughts and our discussions have subsided, we move on to the next dashboard and repeat.
4. Immediately after each dashboard roasting session, I take specific notes of all of the feedback, which fall into one of two categories: general data visualization feedback and dashboard-specific feedback. From there, actions are taken depending on the type of feedback. For general feedback, I start by implementing new best practices into all of our reporting or dashboarding moving forward. For dashboard-specific feedback, I either save the notes for future reworking or, in cases of really bad designs, I add those changes to our backlog to get addressed immediately.

It’s worth mentioning that while this is how our dashboard roasting sessions have taken place historically, there’s no one way to do this process. Ultimately, the key objective is to get the dashboards in front of the design team, get their feedback, have these conversations, and to learn from them.

Why You Should Do It (Too)

To capture the value of dashboard roasting, we must consider what the main outcome from this process is; better-designed dashboards that help stakeholders make data-informed decisions.

By having these dashboard roasts regularly, we’re able to ensure the best possible dashboards for our stakeholders. The ongoing nature of these meetings allows our design best practices to grow and evolve as our company does. Additionally, they help to hold our data team accountable and foster a culture of improvement and collaboration.

Finally, tying this back to the importance of dashboard design, these are the two main value propositions that I believe dashboard roasting offers:

• Improved stakeholder trust in the dashboard and analytics team as a whole
• Improved stakeholder insight obtained from the dashboard

Conclusion

As data analysts, we need to spend more of our time focusing on the design of our reports and dashboards, not just the numbers behind them.

There are some great best practices that ensure a consistent design-first approach, such as the ones outlined above. Though these should always be tailored to your organization and stakeholders.

Partnering with design-focused teams to roast your dashboards can help iterate on internal best practices, improve the overall effectiveness of your reports and dashboards, and help hold your data team accountable when it comes to implementing design best practices.

—

Interested in how Resilia’s platform has data visualization best practices baked in so our users can spend less time worrying about data and more time making an impact? Then check out this blog post here by Rebecca Larson, Senior Product Designer @ Resilia.

Is evaluating which BI tool makes the most sense for your company more your interest? Read about how Resilia navigated this process in this blog post by Will DeCesare, Data and Analytics Manager @ Resilia.