Dashboards are a hot topic and are referenced by almost every business intelligence vendor and analyst who covers the BI industry. However, there is a lot of confusion about what a dashboard is and how they are implemented. Is a dashboard a portal style interface where the user can choose what components or even applications are viewable like Yahoo’s portal? Is a dashboard simply a report shown in a browser with charts on it? Does a dashboard contain aggregate information or detailed data?
A dashboard should be a high level view of the current most vital information about the data needed to easily identify problem areas. A report on the other hand is based on detail data generated from specific searches and parameters and although it may contain graphs or charts the main component is showing detail data with summaries. It is often scheduled and printed, which in these cases may not show current data when viewed.
Actually there are no specific technical requirements for an application to be a dashboard. A dashboard could be implemented as a report that is scheduled and available for a manager to display in his Web browser each morning. A dashboard could allow the user to move components around and choose components to add and delete or it could be totally fixed by the IT department. It may refresh frequently or it could be static and updated daily.
Stephen Few who has written several books on dashboards provides this definition:
“A dashboard is a visual display of the most important information needed to achieve one or more objectives, consolidated and arranged on a single screen so the information can be monitored at a glance.”
There is nothing other than the terms visual display and single screen that indicate what technology is needed for a dashboard. It could be a browser or it could be a thick client application or possibly even a PDF file containing links. The key points are that it needs to provide a visual display of summarized information that can show at a glance if there are any problems that need to be addressed.
Gartner has a very similar definition: “This subset of reporting includes the ability to publish formal, Web-based reports with intuitive interactive displays of information, including dials, gauges, sliders, check boxes and traffic lights.” Gartner goes on to say that 4-6 KPIs should be enough for most users and more than that tend to be distracting and make it more difficult to pick out the key indicators. This means it is best if the user can easily choose which components he wants to see at any given time rather than go back to IT to change it as his requirements change.
In JReport we show examples of dashboards that are written as Page reports, Web reports and our newest product, JDashboard. Each of these allows the user to drill down to more detail and isolate the root cause of any issues highlighted by the dashboard. However, even though this level of interactive analysis is not specifically required for a dashboard according to Few’s definition, JReport does in fact provide this in all reports and dashboards. JDashboard actually extends this by enabling users to create their own dashboards by dragging components from existing reports or component libraries, while still allowing users to quickly drill into the detailed data to identify problems.
With a scrollable chart, users can scroll and zoom in to different parts of their data.
Why is JDashboard the best solution for making a dashboard then if any technology can be used for a dashboard? Take a look at another portion of the description and it becomes clear. “… the most important information needed …”. What this implies is that the requirements of what goes into the dashboard changes over time, role, and market conditions. The best person to decide what is most important is the end user looking at the dashboard and using the information to make decisions. Thus it isn’t really practical for a user to constantly go to the IT department to ask them to modify the dashboard if it is designed as a Page report or Web report. Using JDashboard, the user can easily select from predefined components designed by IT or by other users or can create his own components in a Web report and drag them into his dashboard. Lots of choice and flexibility. As his roles or needs change he can easily replace components he is no longer interested in and add components that are useful for current decisions.
Dashboards should show groupings of strategic items with objectives such as provided by a budget or a plan, key measures, metrics (KPIs), and graphics such as stoplights that provide quick identification of each measure’s performance. For example, we may have a goal of 10% year over year sales growth so we would need last years sales, this years sales, % growth and a graphic showing red, yellow or green for each product or product category and capability to drill down to more levels of detail to identify root cause of any issues. A particularly good component for dashboards is the bullet chart that easily shows poor, average or good performance with the actual values, plan values and at-a-glance view to identify problems.
A stoplight chart.
What else should we look for in a well-designed dashboard? Besides how we are doing according to our plan, it is often important to visually see trends so our mind can easily identify where problems will occur in the future even if the KPI is currently ok. These tend to be charts displayed over time. With JReport’s live chart features users can play a chart over time using a motion chart or a scrollable chart to drill into specific time intervals so the user can easily see trends before they become major problems. Bar charts, line charts and bubble charts are well suited for visualizing trends.
A motion chart can help visualize how data trends over time.
Often the relationship between values is not over time but between geographic areas or categories such as products or expenses. In these types of charts we are not looking for trends so line charts and bubble charts tend to not make sense. Most common is vertical bar and horizontal bar (bench) charts. Although pie charts are popular consider, using a bench chart instead to show the relative size of each group within the whole. It is easier to visually measure the width of each bar than estimate the area of each pie segment.
A particular general consideration in creating effective dashboards is color. Use color only when the color can add value and meaning to the dashboard. Using color just to add bright images probably will get some wow factor the first day or two of usage but quickly become bothersome and distracting. Keep in mind the main point of the dashboard is communication in a simple, easy to understand way with whatever combination of text, charts, and tables that communicate the information needed to make decisions.
Hopefully this breaks down what a dashboard is and gives a sampling on some good design decisions. For an in-depth review on designing dashboards, attend my session “Designing Dashboards as Effective Visual Tools” at JReport Summit 2013, our online conference in April.
Ref: Information Dashboard Design, Stephen Few, 2006 O’Reilly Media, Inc.
Ref: Gartner RAS Core Research Note G00171685
