Nitty gritties of Dashboard Design..

A Key Performance Indicator (KPI) on a Dashboard is typically a metric which monitors a certain aspect of you System Landscape. In its basic state, a KPI shows 3 kinds of information:

The metric it is monitoring

1. The value of the metric at that given time
2. The status of the metric (in comparison to the thresholds set)

Apart from this, there are other kinds of information required to make a KPI more effective:

• The Threshold values
• The age of the KPI value (i.e, how old is the data)

Primarily there are two kinds of KPIs on a Dashboard:

1. KPIs which show Availability information
2. KPIs which show Performance information

Availability KPIs

Availability KPIs typically show whether a system/service/software component is up, down or in warning state.

Since they don’t have any value attached to them, they are the simplest KPIs to represent.

They are most commonly represented with Red and Green Traffic lights; although my opinion is to just show Red lights when appropriate; since that is what the Admin is interested in anyways…and also it avoids unnecessary clutter on the UI

Performance KPIs

A Performance KPI can show either a percentage value, or an exact value. Sometimes (but not always) it is a good idea to represent the percentage values using Progress Indicators. The idea is to draw attention only to the most crucial KPIs, so use special controls like progress indicators or pie charts only for certain key KPIs and not all of them to avoid visual noise and distraction.

But the problem with progress indicators existing today is that they are difficult to read and do not capture Threshold information at all. I have redesigned the Progress Indicators and adapted the Pie chart so that it can be used conveniently in a Dashboard context.

Dashboard Design: Too much in too little?

I have been working in the Administration and Monitoring domain for a while, and have been dealing with the problem of representing the enormous data which needs to be displayed on a Dashboard in an effective manner.

The purpose of a Dashboard is three fold:

1. Give a complete overview of overall health of your landscape

2. Highlight the critical information such as exceptions and error

3. Provide the possibility of a further drilldown to investigate and identify the root cause of the errors

Based on my experience, I have come up with certain Rule of Thumbs while designing a Dashboard. From a UI perspective, the problem needs to be tackled at multiple levels:

1.What information needs to be shown?

2. How it needs to be shown?

3. What would be the interactions?

Lets see each of the problems one by one:

1. What needs to be shown?

The most efficient way to determine this really is to do a lot of User Research to find out what information in general and KPIs (Key Performance Indicators) in particular do the Administrators want to see. From my experience, this usually varies to a great extent with only about 60-65% of commonality in the responses as to what the users would like to see on a Dashboard.. The easiest way out of this problem is to give a default set of KPIs but simultaneously provide the flexibility of Customization at the users’ end.

Next, out of this entire information that needs to be shown, segregate the information on the basis of criticality so that you know what needs to be highlighted.

In cases where the amount of information that needs to be shown on a Dashboard exceeds the available screen real estate, employ the technique of Progressive Disclosure. Show only what needs attention, what went wrong or what is most crucial upfront. Everything which is fine can be hidden until it goes wrong :)

2. How it needs to be shown?

This can be further broken down into 2 layers:

1. How does each KPI needs to be displayed
2. How does the overall information needs to be layout on the limited screen real estate

i). KPIs themselves can be classified into:

a) Availability KPIs

b) Performance KPIs

These need to be represented differently. I have explored a few possibilities for effective KPI representation, which I will discuss in another post.

ii).Further, there needs to be separate areas for different kinds of information. Utilizing the rule of eye movement across the screen, the most crucial information (i.e. errors and alerts) needs to be shown at the top of the screen

Also, different kinds of information can be grouped and represented in different iViews.

3. What kind of interactions?

The whole idea of a Dashboard is to give a complete overview of the landscape in one go, without the user having to do any clicks. So at the first level, there should be the need of as minimum interaction as possible.

At the same time, there should exist possibility to drill down to a second level to the relevant reports, monitors or systems for further investigation in case of errors or problems in the ladscape.