Five Key Analytics Dashboard Best Practices to Consider
This is part of Solutions Review’s Premium Content Series, a collection of reviews written by industry experts in maturing software categories. In this submission, 2nd Watch Managing Consultant Rachel Stewart offers key analytics dashboard best practices to consider.
So you’ve been tasked with creating an analytics dashboard. It’s tempting to jump straight into development, but wait a minute! There are many pitfalls that are easy to fall into that can ruin your plans for an attractive and useful dashboard. Here are five important dashboard development principles to keep in mind whenever you open Power BI, Tableau, Looker, or any other BI tool.
- Stay focused and defined
Before you start answering questions, you need to know exactly what you are trying to find out. The starting point for most dashboard projects should be a whiteboard session with end users; the dashboard becomes a collection of visuals capable of answering their questions.
For each visual you create, be sure to answer a specific question. Every graph should be intentional and useful, and it’s very important to have your KPIs clearly defined long before you start building. If you don’t include your stakeholders from the start, you’ll likely have a lot more to rework after the initial production is complete.
- A good database is essential
Generating meaningful visualizations is almost impossible without a good database. Impure data means holes and glitches will need to be patched and patched further down the pipeline. Many BI tools have functions that can format/prepare your data and generate some level of relational modeling to create your visualizations. However, too much modeling and logic in the tool itself will cause significant performance issues, and most BI tools are not specifically designed for data management. A well-modeled semantic layer in a separate tool that handles all the necessary business logic is often essential for performance and governance.
Don’t underestimate the semantic layer!
The semantic layer is the preparation stage where business logic is executed, joins are defined, and data is formatted from its raw form so that it is understandable and logical for users in the future. For Power BI users, for example, you’ll likely generate tabular models in SSAS. With a solid semantic layer in place before even accessing the BI tool, there will be little to no data management to do within the tool itself. This means there is less processing for the BI tool to handle and a much cleaner governance system.
In many BI tools, you can load a raw data set and have a working dashboard in 10 minutes. However, building a semantic layer requires you to slow down and spend time defining, developing, and thinking about what the data and insights you are trying to get for your business are. This ensures that you are actually answering the right questions.
This is one of the many strengths of Looker, which is specifically designed to handle the semantic layer and create visualizations. This forces you to define the logic in the tool itself before you start creating visuals.
It’s often tempting to skip data preparation steps in favor of getting a finished product out quickly, but remember: your dashboard is only as good as the data it contains.
- PLEASE declutter
There are a lot of obvious issues with the dashboard below, but there’s a lesson to be learned that many developers forget: embrace white space! White space wants to be your friend. As in web development, trying to cram too many visuals into the same dashboard is a recipe for disaster. Edward Tufte calls it the “data to ink ratio” in his book The Visual Display of Quantitative Information, one of the earliest and most important resources on data visualization.
Basically, just delete anything non-essential or move important but irrelevant information to another dashboard/report page.
- Think before using this overly complicated visual
Are you about to use a tree diagram to demonstrate the relationships between three variables at once? What about a representation of sales in 3D and on three axes? Most of the time: no. Visualizing data isn’t about creating something flashy, it’s about creating something simple that someone can get a glimpse of at a glance. For almost all complex visualizations, there is an easier solution, like splitting the chart into several more focused charts.
- Keep your interface clean, understandable and consistent.
Along with keeping your data clean and your logic well-defined, it’s important to make sure everything is understandable from start to finish and easy for end users to interpret. It starts with simply defining dimensions and measurements in a logical and consistent way, as well as hiding excess and unused columns in the final product. A selection panel with 10 well-named column options is much easier than one with 30, especially if end users will be doing the editing and exploring themselves.
You might notice a theme with most of these dashboard development principles: Slow down and plan. It’s tempting to jump straight into creating visuals, but never underestimate the value of planning and defining your steps first. This will help ensure that your dashboard is clean, consistent, and most importantly, valuable.