Dashboard Canvas

A bad business dashboard is like an awkward car dashboard: it can distort data, mislead users, and seriously slow down decision-making. A good one highlights key data, focuses users on what's important, and helps make decisions quickly and effectively, recognizing risks and opportunities for growth in a timely manner.

In this article I broke down a step-by-step algorithm that helps gather and systematize user requirements, prioritize different parts, and design a solid dashboard.

Why do we need a process governing requirements?

Dashboard design is a discipline at the intersection of analytics and design. I don't believe in a process where the dashboard client drafts a requirements for the developer because it reduces the developer to just 'a pair of hands.' In my approach, the specialist is responsible for preparing the specifications and understanding the task.

As a BI analyst, the developer needs to determine the business user's needs for the dashboard and propose solutions based on those needs. It's impossible to say beforehand that there are ready-made solutions for specific metrics or departments. For example, I was once asked if we could create a style guide that would dictate which metrics are shown by specific charts, with profit always being a waterfall chart and LTV always a line graph. It doesn’t work like that, the user’s needs must be identified each time for each department and company individually.

Over the years, I've developed a convenient framework for dashboard development called the Dashboard Canvas. It helps to systematize the requirements gathering process, ensures that no important details are missed, and facilitates a deliberate choice of visualization type. This framework, reminiscent of the Business Model Canvas, isn't magical; it's simply a common-sense guide. It has been tested in various companies of different sizes and has proven to make dashboards more useful with fewer iterations.

Dashboard Canvas

The Dashboard Canvas consists of 5 parts — you can fill them out using a PowerPoint template or in a regular text document, item by item:

• Users and Context of Use
• Dashboard Goal
• Metrics, Dimensions, and Data Sources
• Business questions and actions versus related chart types
• Dashboard wireframe

Let's go through each step and see what problems they address. We will use an example of a dashboard for the sales department.

Users and Context of Use

Of course, first — we must determine who will be using the dashboard, as we will be addressing the tasks of these users. It's important to briefly describe the roles, their tasks, and what they do on a daily basis. It's also important to understand the context in which the dashboard is used: is it used daily, or monthly? Will it be used by a few people or hundreds? Will it be displayed on a screen during meetings, or is a mobile version needed for salespeople who often work in the field?

Example:

Sales Department Head

Views the dashboard daily, wants to see the overall picture, and have the ability to analyze the success of channels and different types of products. Needs to know which deals and managers to focus on. If the company owner suddenly calls, must be able to provide updates on the sales plan and when new deals are likely to be closed.

Sales Managers

View the dashboard every day, want to know which deals to focus on first and their status. They analyze their portfolio and plan what needs to be corrected to meet their targets.

Context of use

The dashboard is viewed daily in the morning during workday planning or during stand-up meetings on computer monitors (managers work remotely).

Occasionally, the Sales Department Head needs to access the report from a mobile device to understand the overall situation and report it to the company's head.

Dashboard Goal

At this stage, it's necessary to describe how our business and the specific division for which we are creating the dashboard operate. The goal is to synchronize the vision of the situation and the tasks. It is most convenient to describe the task based on interviews: first, the analyst communicates with the users, then forms a dashboard goal. It's a bit humorous how sometimes users simply say we need a dashboard just because we need one.

Example:

The company provides services to B2B clients. The sales process consists of the following stages: Receiving a lead → Meeting (in-person or online) → Proposal submission → Agreement, pushing the client → Contract signing, invoicing → Receiving an advance, starting project work.

In the sales department, there are four managers, each with a quarterly plan.

The main goal of the dashboard is to reduce mistakes due to manual data preparations, streamline sales, and create a common understanding of the current situation. It would also be beneficial to provide analytical capabilities to analyze channels, products, and potential activities to meet the sales plan.

Metrics, Dimensions, and Data Sources

This part is quite straightforward. Here, it is important for us to find out which metrics users employ for decision-making, what kinds of data slices are needed, and from which data sources we can obtain them. This information will assist us in the next step of selecting questions, as well as in the development of the dashboard.

However, it is very important not only to focus on existing metrics but also to consider what else might be useful. Think about the processes that occur during business operations. For example, what affects the number of taxi trips? Weather is one such factor! And such a metric is unlikely to be found in a regular data table in a DWH.

Example:

Managers handle deals in CRM and update data daily. Key metrics for analysis include: Sales, Plans, Average deal closing time, Overdue deals, Sales funnel conversion, Average transaction value, and Number of deals in the funnel.

These metrics are analyzed weekly by funnel stages, sales managers, sales channels, and products.

Main data is sourced from the table schema.table_crm. Plans are approved quarterly and filled out in Excel quarter_plans.xslx.

Business questions and actions versus related chart types

Here, it is necessary to understand which business decisions users will make based on visualized data and which questions need answers. This is arguably the most challenging and crucial task in the Dashboard Canvas, because I would say that at this particular moment, you design your dashboard structure.

At this stage, in response to questions, one often hears, "I need to monitor the metrics." This monitoring must be converted into specific descriptions and not be general. Ask users for specific thresholds and metrics, real-life examples, actions they take after looking at the dashboard, or colleagues they contact.

Example:

• If LTV exceeds ten dollars per month, it means we are profitable, and all is well. If it is less, then we try optimise our marketing costs.
• If our retention dips, we will launch new advertising campaigns or resend emails to specific user segments.
• If a particular cohort significantly declines, it means we need to investigate bugs in the release since the cohort's start.
• If a manager sees that a sales manager is not meeting targets, he reviews all their deals and tries to understand which ones he can help close.

After you have compiled a list of questions, you need to design a chart for each that either answers the question or allows immediate action, such as adjusting a campaign budget in an advertising dashboard. It's also very helpful to group questions into blocks of common themes, which will aid in the layout design later on.

Here, you should use best practices for selecting charts and visualizations that match user questions. However, don't get too carried away; for most business tasks, standard visualizations like bar charts, line charts, tables, and BANs (Big Ass Numbers) are suitable.

Dashboard wireframe

At this stage, you need to draw a dashboard layout. It doesn't have to be very detailed, but it's important to show the structure of the blocks and types of charts. For creating layouts, I use simple tools, which I've discussed in this post.

Unfortunately, many skip the layout step when developing a dashboard, as "it's faster to do directly in the BI system." However, this approach is incorrect. Even if you can quickly assemble a prototype in BI, the purpose of the layout isn't to show how everything will look in reality, but to present the concept to the user so they can focus on the overall picture and structure without getting distracted by technical details and data. By making a prototype directly in BI, you risk lengthy discussions during demonstrations about specific figures or button colors, although these elements may not be ready yet.

Here is the interactive version of the results from this case study.

Key Takeaways and Additional Links

You should understand that gathering requirements is your responsibility, not something the client should deliver to you on a platter. If you are simply converting Excel prototypes brought by others into BI dashboards, you're acting not as a BI analyst but as a BI developer. While this is a possible way to work, it offers less value to the business and to your professional development.

Use the Dashboard Canvas or any other structured framework that allows you to consider all nuances and create a truly important dashboard.

Follow me on Tableau Public and send an invitation to connect on LinkedIn.

Additional Links

— Video of hands-on master class on Dashboard Canvas

— Dashboard Canvas template and more examples in Miro

— Wireframe tools in PowerPoint and Tableau

P.S. If you think this article was useful for you, I would appreciate your reaction and reposts. And as always, I am eager for discussion on any BI topic.