Skip to Content
Author's profile photo Arun Varadarajan

Designing Dashboards … Black art or common sense ?

A stab at defining a dashboard methodology:

How do you go about defining a dashboard?
I found an interesting article which set some thoughts rolling about how to go about conceptualizing a dashboard:

It basically talks about the basics which are nothing but a series of questions to be asked:

1. What would you like to monitor?
Very vital questions, this basically decides what you want to see on your dashboard. The responses could be specific KPIs or generic terms like – “I want to monitor my sales “.

Both are fine because you get the flavor of the dashboard that is wanted by the end user. Also this makes the dashboard end user oriented, rather than a dashboard that someone high up decides and gives it their blessing.

Typically a dashboard should be driven by Business management and at the same time tight control on requirement is required so that the dashboard is not intended to do too much or too little – this will destroy the usability of the dashboard with either too much information or too many interactions.

2. What are the measures for Monitoring the same?
This would be the KPIs , ideally a mix of trend values and values for the selected period would make sense here since dashboards provide a snapshot of the information along with decisionable information regarding past performance etc.

Points to consider :
A dashboard is meant to be a visual representation of information , the KPIs should ideally be representable in the form of charts etc. Here also high level information would be available in the form of charts while providing for a drill down to the base data after applying necessary selections. The idea is to have the user be able to zero in on the necessary detailed records easily by applying necessary filters on the graphical data first.

Try to limit the number of records processed – this increases the performance of the dashboard ( not exactly but as a thumb rule… yes ) , no one wants a dashboard that takes ages to open up.

3. Layout of the dashboard…
Layout is critical to a dashboard , things that you should consider are :
Real Estate available:
On a dashboard every pixel is valuable and has to be used properly.
Mode of presentation :
Is this going to be a desktop application by way of Widgets / FLEX / AIR or exposed on portal ? this is because users tend to use Print Screen and would not want to many scrolls on the dashboard.
Colors are vital to a dashboard and need to be used correctly …
Layout :
try and prioritize the measures in terms of Primary Measure and supporting measures : A primary measure would be the key KPI being monitored and supporting measures will be KPIS that provide additional information on the Primary KPI…
An example would be :

A primary measure would be Quarterly trend of sales and supporting measures could be the same for each quarter separately..

Or stock position at warehouses supported by goods in transit…

On a typical dashboard – the primary measure should have 1/3 rd the space and the rest clustered around the same. PowerPoint templates – the default layouts will offer some guidelines on the same…

4.Analyze the decision pattern of the user
This would be what the end user intends to use the dashboard for , the decision points being looked for and actions that h/she would take based on the information shown.
Something like :

Warehouse stock position seems depleted –> analyze in transit stock –> check on the pending orders yet to be fulfilled –> Check for any production issues at plant –> Check for any sudden spurt in sales in the last quarter / Month –> Revise production estimates / Demand Planning
A storyboard ( not the Visual composer Storyboard ) can be composed based on chronicling a day in the life of the decision maker.

5.Performance :
Performance is key for a dashboard – ideally have the initial view to be at a high level so as to reduce the number of records processed by the dashboard application and then have the option for a drill down or have supporting reports on portal for the user.

6. Ease of Access:
The dashboard should be easily accessible either through a portal link or even better if it can be accessed on the desktop as a widget / AIR application. Typical decision makers ( the strategic kind ) would love to access the information through a desktop application without having to go through logon procedures every time they run the application , or access the same through a shortcut on their desktop. Typical business folks as we call them are meant to spend more time on business issues than being asked to navigate through portal. Nothing against portal , but the idea of logging on to a portal to access information sometimes seems to put people off . If the same can be presented as both options , then it makes even more sense and value.

7. Small things add a lot of value
Things like mouseovers , click through etc add a lot of value and usability to the application / dashboard. Put yourself in the shoes of the user when designing something for them.

8. Should be extendable
It should be something that other teams can also derive value out of by extending the same. It is not easy to do so but something like just changing the queries for the same should make it work for someone else and thereby spawn multiple dashboards

9. Ensure uniform presentation
In some cases there will be issues of client specific settings that make the colors etc display differently in different machines / do a proper test of the same across multiple systems before deploying , or publish a set of minimum requirements.

10. Make the Dashboard lightweight

In many cases the dashboard is to be executed on the browser , and if the dashboard is in FLASH etc then the size of the dashboard will add to the load timing for the same and sometimes be seen as a put off.

These are some points that I thought were relevant for dashboard design and also more can be found from a very useful site that is dedicated to dashboards:

Here a lot of dashboards are chronicled and we can see examples for dashboards as seen by millions of others across the world and draw inspiration from the same.

These are somethings I found very useful when approaching to create a dashboard , hope it helps you also….

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Just went through all the points which you have considered for creating a dash board. All were good.

      I have few concerns regarding security aspect. As you have mentioned, their should not any logon procedures for accessing a dashboard, because if the dashboard shows daily sales of your client, if anyone knowing your desktop password(Administrator), can have easy access to production data without any issue.

      Thanks and Regards

      Author's profile photo Arun Varadarajan
      Arun Varadarajan
      Blog Post Author
      I mentioned " Without having to logon repeatedly " - typical of a widget .. but then the widget / AIR application is installed onto your desktop alone and we cannot guarantee security of desktop / laptop , we could look as a call service to the SAP helpdesk to reset the password if the laptop is lost!!??
      Author's profile photo Kenneth Murray
      Kenneth Murray
      Biggest issues I have seen developing Dashboards were not having the intended audience directly involved in the Dashboard Design.  Some higher ups believe they know how the audience analyzes their data and they really don't.  Also, a real big deal is what screen resolution to standardize on.  I'd be interested in how the screen resolution issue was handled by others.
      Author's profile photo Arun Varadarajan
      Arun Varadarajan
      Blog Post Author
      I could not agree with you more .. Requirements is the biggest Achille's heel for a dashboard , incomplete requirements leads to disaster ( but then isn't it the same for all projects and shuld dashboards be any different ) , the differentiating factor here is that dashboards need to be approaches as a WEB APPLICATION and not an SAP BI report or something like that... will seeif I can publish something on that as well ... quite interesting cllecting requirements for dashboards ...