TLDR: This is a framework that I have deployed in the past. By embedding thoughtful dashboards & data directly into employee’s day-to-day activities it allows for a unified organizational understanding and informed decision making.
the two types of dashboards: informational & research-analytical
It’s important to understand that dashboards can serve two distinct purposes.
- The first one: is to inform and provide actionable data.
- The second: is to diagnose, research, and find anomolies and/or patterns.
When I structure embedded informational dashboards, I like to remove complicated filtering & customization. The reasons for this is because informational dashboards are about providing a unified organizational or departmental understanding. They are about providing the same unified experience. An informational dashboard which requires too much analysis is a failed informational dashboard. It might make sense to use a library and “hard-code” these charts & dashboards.
BI tools that analysts use are an example of analytical dashboards. The goal of these dashboards isn’t to inform every team member, but to arm the data-focused team members with the capabilities to find additional information. If they happen to find a useful and sustainable trend/graph/chart – it can be promoted into the appropriate informational dashboard.
hierarchical dashboards
The primary idea behind this framework is that there is a hierarchy to dashboards.
In the example we will use for today’s explanation we have a fictitious ecommerce company backend. The framework however holds true for most saas companies.
summary/overview-level dashboards
There are a few things to note in particular about the structuring of this summary-level dashboard.
- dashboard hierarchy – inside each dashboard it is still important to have hierarchy. A good practice is to include a summary row that highlights a few areas to review below in sections below.
- row-level explanation box – each row on a dashboard should be focused on a single topic (except the summary). A good practice is to have a text box that adds explanatory text. If possible this explanatory text could be auto-updated via code, but it could also be updated manually. It is a good place to mention/call-out anomalies and their causes. This alone will prevent the majority of questions from executives.
- summary-level – for the summary row on the overview dashboard one has the opportunity to build out something special by including company goals directly into the interface the its employees use on a daily basis. The framework in the picture shows off one approach:
- Goal: the target amount for the (quarter/year)
- Current: the current amount
- Per Day Needed: this is an interesting metric that can be really useful for aligning the team on the lift between the current & the goal. For this example, if the goal is $120,000,000 in revenue this year and the current revenue on the last day of November is $90,000,000 then the Per Day Needed is $967,742. Watching this number increase/decrease helps to show momentum towards the goal.
- non-entity/external section-level – some of your company goals may not be directly tied to an entity/table in the saas. If that is the case, it makes sense to consider how to add a row to your dashboard from external sources. This could be true of traffic analysis presented in the image above.
- entity/table section-level – these sections can be directly powered by the entities/tables that are part of your saas. In the example provided, partners may be organizations that sell on your website/platform. Partners need to be set-up. The partner goal could be around partner expansion. And the section row could be about new partners or partner-related store item growth/sales. The beauty of this system is would allow you to provide a link to the entity/table-level dashboard to get more relevant information on the topic of interest.
entity/table-level dashboards
Clicking on the “Store” level menu would bring you to a “Store” specific dashboard. This level of dashboard becomes much greater in detail than the information that could be seen at the summary/overview dashboard. It becomes possible to consider adding new types of data:
- Best Sellers
- Best Selling Categories
- Top Referral Sources
- Sales by {x}
The point isn’t that this entity/table-level dashboard is fixed, but that it is fixed in-scope. It is related to the Store portion of the application.
It still makes sense to build this dashboard with the best practices identified previously:
- dashboard hierarchy
- row-level explanation box
- summary-level
- entity/table section-level – this section-level changes because now it becomes much more focused. If someone spots something interesting here it becomes a call-to-action to the analysts to study it and find out more information.
object-level dashboards
Object-level dashboards seem like overkill. I assure you that in many cases they become the catalyst for enhanced understanding. The ability to quickly dive from:
summary of sales ➡ detail of sales ➡ detailed breakdown of a particular SKU
In a matter of 3 clicks, but have pre-structured graphs/reports – changes organizational understanding of the way the company operates. In the example below consider a stacked chart for:
- Sales by day
- Available stock by day
This could automatically show the relationship between average sales and potential lost sales when inventory becomes unavailable. Importantly this happens automatically.
don’t make me think
The concept behind this is that it is important to have someone critically thinking about the data and it’s relationships, but that shouldn’t be everyone in the organization at all times. By pre-defining the data and reports you lead to enhanced understanding and alignment. By all means, go through the change process:
- unfreeze
- change
- refreeze
But when you go through that process, embed it into the platform that is directly used by the purchasing {or insert any other} department. Do not make them hunt for information.