SAP BI 2017 congress – Takeaway 1: Top Do’s and Don’ts when creating a Dashboard

Last week, McCoy consultants have visited the SAP BI 2017 Congress in Amsterdam. In three consecutive takeaways, Arie Heutmekers will inform you regarding some of the highlights of this conference. The main intention to visit the conference was to get more information on SAP Analytics Cloud (= formerly known as SAP BO Cloud) and Dashboarding. 

This blogpost will inform you about the most important do’s and don’ts regarding Dashboard creation.

Let’s start with the, sometimes obvious,the DO's:

• Tell a story

• Focus on negative KPI’s. Most users want to know what is wrong/ below target so they can act on that

• Keep it simple: remove unnecessary objects

• Remove all Chart Junk: Remove grid lines, legend

• Put the most important KPI or visualization on the Top left of the dashboard

• Check color.adobe.com for best color matches

• Use goal lines and thresholds

• Use multiple Color Blocks in the dashboard

• Limit the amount of KPI’s in a dashboard to max 5 or 6.

• Build all dashboards for I-Pad viewing purposes

• Personalize a dashboard for a user

• Make sure you have actionable visualizations: What will you do differently based on changes in the metric?

• Only choose actions you can measure.

• Start your dashboard project with a detailed requirements session, followed by agile development iterations.

• Dashboard performance is key: if needed pre-aggregate the data

• Give the user what they need, not only what they ask for

Besides do’s, there always are DON'Ts

• Do not use 3D charts

• Do not use Pie Charts unless you want to compare max 2 or 3 values

• Use exception aggregation to get focus and attention. Only use color red because other colors will just distract attention.

• Do not use “Cool” charts for the sake of looking cool. Keep it simple. Most of the users will probably not understand complex charts like Radar or Spider Charts.  Stick to bar charts instead.

• Limit the use of infographics

• Don’t discuss data availability when discussing the requirements. Check it afterward and if needed go back to the drawing board.

• White boarding does not start with placing graphs on the screen: investigate the KPI wish list, research the industry standards, learn about the KPI sources, etc.

One of the most interesting sessions on this topic was organized by Mico Yuk from BI Brainz. According to her, most of the BI dashboarding projects fail because there is no focus on action. She stated:

“ The purpose of a dashboard is not to tell you how to think, but to give you questions to think about.”

In her session, she explained that showing a dashboard with KPI’s is not enough. The dashboard should focus on actions to get a certain KPI back on track. The key to a successful dashboard is to translate actions into visualizations.  Before starting to build a dashboard, for each KPI, it should be clear:

• what do you want to achieve (which list)?

• what are the fallbacks?

• which actions can you take to get the KPI back on track?

• how can we measure the actions?

Furthermore, she provided a dashboard design template which addresses all of the above questions. When requirements and associated actions are clear, the time for building a successful dashboard can be reduced up to 60%!

At the end of this blog, I will share some good and bad examples of visualizations. Can you spot the difference?

For more info on dashboarding and visualizations, feel free to contact us.