Dashboards for Business Intelligence: 18 Design Don?ts (part one)

Posted by: Yellowfin Team

Personalized dashboards are critical delivery mechanisms for Business Intelligence (BI), allowing decision-makers involved in different business functions throughout an organization, to stay abreast of relevant KPIs at a glance.

But what constitutes an effective BI dashboard? What are the essential inclusions and omissions in terms of both process and design?

Dashboard don’ts: The front nine

We’ve compiled a shortlist of fundamental flaws and oversights to avoid when constructing a BI dashboard. When planning and compiling a dashboard, don’t:

  • Use flashy visuals and chart types when simple alternatives are capable of conveying the same message: Meaning must be derived from dashboards quickly. If charts or graphs are overly garish or complex, interpretation is hindered and usage rates will decline. When considering data visualizations for your dashboards, ensure that you:
    • Reduce the data to ink ratio: Follow the advice of Edward Tufte in his renowned The Visual Display of Quantitative Information: Remove anything that isn’t absolutely central to the interpretation of the data. Only display objects that are vital to the accurate interpretation and contextual understanding of the underlying data – avoid all design aspects that are unconnected to the task of analytic communication.
    • Use color sparingly for maximum contrast to highlight important data
    • Make your data standout from chart and dashboard background
    • Use gradients and gridlines carefully
  • Think that a dashboard is final: Reporting needs constantly change and dashboards have to change in accordance, to ensure the right metrics are being reported on and displayed in the most appropriate manner, to support current business strategy. To accommodate the inevitability of changing business needs, adopt an iterative approach to dashboard design.
  • Select visualizations to represent metrics without considering the values themselves: Different types of graphs highlight different types of data, and features within a data set, in distinctive ways. Carefully consider the information and message that each chart is attempting to derive from your chosen metrics and values.
  • Measure metrics that are not linked to specific business objectives: The worth of even the most engaging dashboard will be severely diminished if it reports on metrics unrelated to core business objectives.
  • Forget to secure agreement on dashboard KPIs and their definition: Reaching consensus on the most crucial metrics and benchmarks will allow you to produce understandable, actionable and uniform KPI reports. Additionally, don’t assume that if everyone agrees on the same KPIs that they also agree on how they should be measured.
    • Use / display obscure metrics: Even if agreement is reached amongst user groups regarding dashboard KPIs and metrics, ensure that the most straightforward metrics are used to monitor progression towards business goals. If users are unable to decipher the significance of a report with a momentary look, its usefulness and purpose is moot.
  • Deliver reports underpinned by poor data: Once management and various business groups have reached consensus on the metrics that each departmental, strategic or operational dashboard should measure and monitor, ensure you are collecting the data needed to compile the necessary reports. Incomplete or poor quality data will lead to inaccurate dashboards and distrust amongst business users, who will proceed to search elsewhere for their answers, rendering your dashboards redundant.
  • Design a dashboard that is complicated and cannot fit on a single screen: The KPIs and values displayed on a BI dashboard are meant to be able to be consumed quickly for understanding-at-a-glance. Whilst users may choose to drill into a particular chart for extra detail, they should be able to gain a high level overview quickly and effortlessly.
  • Include too many alert scenarios: It’s like the boy who cried wolf. If people are regularly ‘alerted’ to events that most often require no action, eventually, people will stop paying them attention.
  • Include no alert scenarios: If users are not notified of action that needs to be taken as a result of a report, what’s the point of the report? As stated before, reports need to be goal oriented. Users need to be alerted to events that diverge from projections and desired objectives, or when a predefined benchmark is reached.

Keep a vigilant eye out for the second half of this two-part blog series, Dashboards for Business Intelligence: 18 Design Don’ts (part two).

Also worth reading: