Introduction

The following article discusses a dashboard's (high-level) development cycle. It breaks the process into easy measurable steps that start from the initial KPI planning all the way to maintaining and adjusting your end product.

Introduction to Dashboards

A Business Intelligence (BI) Dashboard is a graphical visualization of analytical information to an end-user. The analytical information displayed represents the status of key performance indicators (KPIs) and other critical business metrics.

Different dashboards are be exposed to different personas in the organization. Each dashboard should be designed according to its target audience and the decision(s) they can make based on it.

Dashboard Types

The industry divides "BI Dashboard" into four categories:

Operational Dashboards focus on operational processes within an organization (e.g., a production process). The goal of such a dashboard would be to monitor and overlook a process. These reports are usually used by junior-level employees who make operational decisions.
Analytical Dashboards contain a large amount of data and indicators that help analysts understand data - This includes identifying trends, comparing them with multiple variables, and creating predictions and target figures. These dashboards help analysts define the strategy of a company.
Strategic Dashboards focus on long-term KPIs and high-level metrics. The upper management uses these dashboards to monitor the company's strategy. These dashboards have a high value, but in most cases, as standalone reports - Cannot help decision-making.
Tactical Dashboards display the business/department KPIs and provide all data required to accelerate decision-making. These dashboards are used by mid-management and are the most common dashboards in the market.

The Dashboard Design Process

The high-level process of designing a dashboard contains four main phases:

Planning the BI solution
Executing the dashboard design
Delivering the solution
Monitoring & adjusting the dashboard

Planning the Dashboard

Planning the dashboard includes two main steps:

Requirements Gathering
Solution High-Level Design

Requirements Gathering

A practical and valuable dashboard requires planning.

The information you should gather before designing a dashboard includes:

Functional Requirements - Discussing the user case, business requirements, and involved users
Technical Requirements - Discussing the data sources, structure, and security requirements
A dashboard mockup - Showing the proposed endgame

Functional Requirements

The functional requirements include:

The Dashboard's Objective - Describes a clear goal this dashboard addresses
This may consist of a business question you wish to answer or a decision one should make based on its contents
The Target Audience - The type of users who'll participate in the lifecycle of this dashboard:
- Decision Makers - Who defines the business requirements and questions?
- End Users - Who uses this dashboard?
- Beta Users - Who performs the User Acceptance Test (UAT)?
Call to Action - The user activity that should take place based on this dashboard.
Timelines - The time of when the dashboard has to be ready for UAT and a go-live date.

Technical Requirements

The technical requirements you should gather include:

The KPI Architecture - A list of KPIs included in this dashboard
A KPI Breakdown - How is each KPI calculated (specific data sources and formulas)
Data Update Frequency - The frequency of which the data in this dashboard should update
History Depth - The length of data history this dashboard should present
Data Source Information - The list of data source(s) mentioned in the "KPI Breakdown" and how to connect to each of them
Data Security Requirements - The data restrictions users/groups of users should have

A Dashboard Mockup

The mockup refers to the way the dashboard's viewer anticipates this dashboard should look like - Usually in the form of a graphical illustration.

BI Solution High-Level Design

A dashboard's "High-Level" design requires:

Building a KPI logic
Structuring the dashboard widgets
Planning the data model structure

Building a KPI Logic

The starting point to planning a dashboard is gathering all required KPIs from the decision-makers.
The KPI list may be lengthy, but don’t worry about it:

Phase #1 - Build a Story
Build a story based on the list of KPIs - To do that, ask the decision-makers what the process of making a decision - What factors are considered is? Where is the data located? Make them build a "flow-chart" for the decision-making process.
Phase #2 - Define the First KPI
Find out what is the most significant figure in this dashboard. This will usually be the "First KPI" (usually a business-critical value – Such as the “Total Revenue” or the “Outstanding Sales Amount”).

Now, try to assess what value range is considered “Good” or “Bad” – You’ll later use this information to visualize the data (avoiding just showing a number and leaving an end-user clueless of its meaning)
Phase #3 - The Next KPIs
The next goal is to determine what the end-user would look at next based on either a “Good” or a “Bad” value of the first KPI. Repeat asking this same question as necessary until all scenarios are covered.

Note that the KPI list may change during this process as the customer might have missed a KPI or had one that wasn’t necessary for the decision-making process.
Phase #4 - Verify your Work
Present the decision-maker with the flow-chart you've created - Make sure they could make the “Call for Action” decision off of it.

Structuring the Dashboard Widgets

Structuring the widgets refers to translating the "flow chart" into an intuitively usable dashboard mockup.

A dashboard is constructed out of widgets (each covering one or more KPIs).
As the customer wasn't limited on the number of KPIs covered in the dashboard, we'll have to:

Translate the KPIs into widgets
Categorize the widgets by their type
Choose what widgets fit into the dashboard and which don't

While translating KPIs into widgets, you may realize that the number of widgets exceeds Sisenes's best practices. In this case, assess each KPI's type - The three types of KPIs are:

High-level figures such as a “Total Revenue” or a "Change Rate."
Mid-level figures such as a “Revenue Breakdown" or a "Product Category Breakdown."
Low-level figures such as an "Employee Expense Breakdown" or "Per-product Sales Breakdown."

The high, medium, and low-level figures would usually correlate with the different hierarchies you see in the flow chart.

The structuring flow should contain the following steps:

Place “High-Level Figures” in the "flow chart" order
These will allow the end-user to see their most influential figures in a single glance
Next, according to the amount of data already in the dashboard, assess whether one (or more) “Mid-Level Figures” can be added
As the “Low-Level Figures” aren’t crucial at first glance – Place them in a different dashboard accessible via an add-on (such as a Jump to Dashboard or an Accordion)

Planning the Data Model Structure

As a BI database structure is different than a conventional database (i.e., facts and dimensions), it must be redesigned to meet the various business questions. The process of designing data models will be covered in a separate knowledgebase article.

Executing the Dashboard Design

Executing the dashboard design includes three repeating phases:

Importing the data required for calculating a single KPI into the data model
Building a widget to present that KPI in the dashboard
Customizing the widget to convey a message best

Delivering the Dashboard

The process of delivering a dashboard to the end-users should include as many steps to drive adoption and useability as possible. These may include:

Performing a User Acceptance Test (a.k.a. UAT)
Training the end-users on how to use the dashboard
Sharing the dashboard and allowing an open communication channel for feedback
And more

Performing a UAT

As the name suggests, the UAT is conducted on the final version of the product by the end-users defined during the dashboard preparation phase. These usually include various stakeholders such as project sponsors, business owners, business analysts, etc.)

The UAT's goal is to provide the final feedback before the dashboard releases. The feedback period is usually limited to a week or two, where the stakeholders operate and challenge the dashboard (and the data model behind it). There are two methods of performing a UAT:

Providing a test document - allowing the users to follow a few predefined tests
Allowing the end-users to "monkey test" the environment.

All issues found are logged and may be fixed to generate a final dashboard version.

Training the End-Users

Employees will feel more confident about using the new software or technology if they’ve been involved in training before the new system goes live. Make sure to:

Assess learning requirements - If people are unwilling or unable to use it, you’ll never be successful, even with the best system in place
Develop a tailored plan - Be clear about what the business expects from the training and what the employee will gain from it - A system is only as good as the people who use it.
Secure resources - Don’t forget practical parts of the new system, such as the suitable access, so that employees can learn the new system without any roadblocks in their way.

It’s essential to ask for feedback from the end-users during the training. Knowing what areas users don’t feel adequately trained on will help mitigate the risk of implementation failing later.

Sharing the Dashboard

Finally, share the dashboard with all end-users.
If this dashboard replaced a previous version or a different product - Allow a transition period

However, do plan a firm date to decommission it

Monitoring the Dashboard

Monitoring the dashboard will be done by:

Tracking the usage of the dashboard
Creating a feedback loop with the end-users
Adjusting the dashboard over time

Tracking the Usage of the Dashboard

Sisense offers Usage Analytics (Link) to track the performance and usage of dashboards. With Sisense Usage Analytics, you can better understand how users interact with Sisense dashboards and optimize the configuration accordingly. For example, you can understand which dashboards impact and how fast the dashboards load.

Creating a Stakeholder Feedback Loop

Communications are everything - Allow the end-users to operate their dashboards for a while before contacting them and asking for their feedback. When asking for feedback, focus on the following questions:

How are you using the dashboard?
How often are you accessing the dashboard?
Are you able to answer your "Call to Action"?
How can I make the dashboard more intuitive?
Is information missing from the dashboard?
Is there data you don't use in the dashboard?

Guide the stakeholders to provide meaningful feedback rather than a general "I like it" or "I use it when I need it."

Adjusting the Dashboard Over Time

A dashboard does get old - Make sure to revisit it once every 6-12 months.
Revisiting it may include major fixes (such as modifying the KPIs or widget types) or minor fixes (such as formatting and visualization).