Building great dashboards
Building great dashboards
|Description||This document describes best practices for creating dashboards.|
|Version as of||8.5|
The purpose of any dashboard is to tell a story. Thus, all basic principles of storytelling apply to building a great dashboard. This mainly includes knowing your audience, preparing a story and finally, presenting a story through visual design. Let us focus on each one briefly.
Know your audience
This is the first and most important part of great dashboard building. You must know the type of audience, their intent, and finally, the context under which they will consume your dashboard. Your audience might be focused on strategic areas or interested in operational aspects. A dashboard should address these needs differently. A VP of Sales might be interested in sales trends in a certain territory or in products, whereas a Customer Service organizational leader might be interested in agent productivity. Similarly, an airline executive might look for the status and position of aircraft at any given time versus trends in the utilization of aircraft in the past few quarters.
In addition to insights, your audience might be looking for suggested actions to achieve or correct business outcomes. Dashboards must understand and cater to such diverse needs.
Lastly, different audiences operate under different contexts. Your dashboard might be consumed in variety of environments – ranging from a large screen in an executive boardroom to a factory floor. It might even cater to mobile audiences on the small screen of a cell phone or tablet. Most importantly, one must understand consumption patterns – whether it is presented in meetings, sent over email, or glanced at during travel. Such synchronous or asynchronous consumption may lead to various interpretations by your audiences.
Prepare a story
When you know your audience, their intent and needs, and the context under which they will consume the dashboard, the next step is to prepare a story.
There is no one “right way” to prepare your dashboard stories. The trick lies in staying atomic in scope. Less is more when it comes to conveying a crisp message. You should stick to the purpose of the dashboard and keep it relevant.
Most dashboards generate questions like “so what” or “why” in your audience’s mind. You must be able to anticipate and address such questions in your dashboards. This is where data becomes insights.
Lastly, your dashboard should smoothly and appropriately present exceptions, trends, and recent effects.
Focus on visual design
Visual representation of your story is equally (if not more) important as your story. One must consider these dimensions during the visual design of your dashboard.
- First, ensure relevancy. Currency, decimals, and text are presented appropriately per context.
- Second, validate accessibility. This is very important if you have a varied audience consuming a dashboard under different contexts. Size and placement of widgets, color combinations, and scrolling should ensure consistency and readability.
- Third, place an emphasis on aesthetics. Selection of your widgets and color pattern  should attract the attention of your audience and not distract them from the main story.
The type of visualization you chose impacts all three aspects of visual design. Bar charts give an absolute impression of quantity dimension versus line charts that implicitly depict trends over prior data points. Bubble charts give you deeper control by letting you choose the position, size, and color of the bubble. Maps make clear sense as a backdrop when you want to plot data against spatial and geographic dimensions.
Consider technical design factors
So far, we have talked about storytelling through dashboards. The correct technical implementation ensures the smooth functioning of your dashboard. Product owners and engineers (mainly database designers) are accountable for simple and clean design.
While there are a lot of factors for technical design (commonly referred as -ilities in architecture pattern), the key aspects to watch out for are captured below:
Performance: No one likes to wait for systems to stall or slow down during interactions. Interactive dashboards must respond to every click in less than 3 seconds  in various environments (data volume, network considerations, etc.). Appropriate schema design (for example, star schema) and denormalized data structure will help reduce query load and improve performance.
Agility: Once designed, a dashboard will very rarely meet all business needs. New demands to see data in various ways will raise the curiosity of your audience. This necessitates the need for agility in maintaining your dashboard. You should be able to add or alter new visualizations with minimum engineering or deployment effort. Your dashboard should truly be a no-code solution.
Data latency: Your transactional data schema will likely to be different from a reporting data schema (or DataMart schema). Data transformations are inevitable while copying transactional data to reporting schema. This increases the burden of data refresh timings and creates data latency. While this might not be a concern in strategic dashboards, it is certainly a showstopper in operational dashboards. Incremental event-driven refreshes, with optimized data schema, may help resolve this to a certain extent. One can choose either ETL (extract-transform-load) or ELT (extract-load-transform) to get data from transactional to mart. ELT is a modern alternative because storage and compute resources are separate. 
Integrated experience: Finally, a dashboard’s integrated visual experience is very important in a larger enterprise environment. Your dashboards should be developed as loosely coupled components that can be seamlessly embedded into any enterprise system.
A lot of data visualization tools are available in market today. You should ensure that you opt for ones that support no-code dashboard creation and maintenance and offer connectivity with varied data sources. Microsoft Power BI and Tableau are prominent ones that offer SaaS offerings as well.