Learnings from Dashboard Design – things to consider
I have had experiences designing dashboards in Web Application Designer and currently am designing one on the Design Studio. Some of my thoughts on how to approach Dashboard design.
I have summarized my points under various headings – please feel free to add to it if required.
This is going to be an application you are developing. Make sure that users understand the difference between a dashboard and an interface to get to the data. This is not going to be a link where people assume that they can dump the data into an excel file and build off the same.
Understand the target audience – this will give you an understanding of their current needs and how they do things right now and what the dashboard seeks to improve
Is it C-Level or Senior Management or purely operational. Accordingly validations will have to be built in.. Basic questions like – how do you know if the data was incorrect or if it was indeed a lousy day for sales ..?
If your dashboard goes to the CEO or Vice President of Sales , the numbers on the dashboard have to be backed up.
Is the dashboard meant for desktops , e-mail distribution , Mobile devices ( iDevices to be specific ). Accordingly your level of detail will change
Also depending on the device – test the look and feel beforehand and tweak the design if required accordingly.
If possible – develop a simple prototype / wireframe to demonstrate the look and feel of the dashboard. This will help in getting good requirements and also driving usability requirements. This applies to mobile devices too.. This is an application which has equal importance to visual representation and the data being displayed.
Why should users use the dashboard ? What is the Savings in terms of cost or effort that is seen by implementing the dashboard
Establish strong functional ownership for the dashboard application. In almost all cases – there will be a lot of logic in terms of calculations embedded into the dashboard and at some point in time – these will get questioned , make sure that there is a strong functional group who is responsible for the numbers
Also when you have ownership , it will drive usage and establish trust in the data. Also since the data in the dashboard application is going to be summarized at best , have BW / BO reports developed that will give you additional details to troubleshoot / consume. Also if possible have a separate validation report with more details that could be used for validation and the same numbers expressed more visually in the dashboard application.
Preferably – have one style developed for the dashboard and use it across all applications. This helps in driving usage and rapid prototyping
Establish performance expectations upfront – this will drive your data model and also establish variances that are acceptable
Early on – understand expectations on when the users expect the data to be available in the application
Sizing and patch levels
Make sure your systems are correctly patched to ensure that all the promised features work. In one of our projects , we realized that we had to do an SP upgrade on our BO systems to get our Mobile reporting working – after we gave estimates and timelines.
Involve the end users to the best possible extent in defining requirements. In order to drive usage , such projects have to be business driven and not IT driven
Establish certain criteria like – number of users , number of tickets raised , number of times the dashboard application went out on time etc to determine if the initiative was a success. Also ensure requirement sanity – do not try to do all at once if this is the first dashboard that you are doing , take it one piece at a time and establish a rollout schedule
Disclaimer – these are my own views and do not necessarily prescribe things that one should do for designing Dashboard Applications. Do let me know if you found these useful and if you have anything more to add to the same.