Streamline Training & Documentation: Best Practices for Your Dashboard

Wednesday, September 19, 2007

Best Practices for Your Dashboard

As a follow-up to yesterday's post, here are somewhat edited best practices for designing a business performance dashboard. They come from "Best Practices for Using WebSphere Business Modeler and Monitor" and are well-worth consideration (as are all the best practices covered in the document).

First, keep in mind that you want to end up with a dashboard for which the answers to all of the following questions are in the affirmative:

Does the dashboard provide decision makers with relevant performance-related data and facts?

Does the information inform the end user as to what actions are required to keep operations on track?

Does the information make it clear when no action is required?

Does the information make it clear when particular values are good or bad so that the end user knows whether he/she has to be concerned?

Does the information help the end user optimize the business or identify a performance issue?

A general question: How does the dashboard help the user to work smarter?

Next is a set of additional guidelines for your dashboard and its use:

Executives should not be the first to drive action from what they see on the dashboard. By the time it gets to them, subordinates should already be working the problem.

Generally, a dashboard should focus on a single user role. Do not cross roles in the dashboard unless necessary (for example, when the users want to be able to see both a business and an IT view of performance).

A portal displaying your dashboard should be task-based. Do not mix a lot of news portlets, stock tickers, instant messages, and so forth, with portlets with business content. Create separate pages for like-content.

Watch out for portlets on a page that should be connected (for example, because all show the West Region). If they should be connected by shared information, be sure to identify this.

Only show a trend if you can reasonably get trend data and it makes sense in-context. Make sure the trend symbol is understandable.

Symbology should be consistent across all of your dashboards.

Do not overcrowd the dashboard. Five to nine elements is a good rule of thumb because people, on average, can handle only about seven items at a time. (A group of related elements can be considered a single element.)

Limit the use of red and amber (bad and near-bad) results on the screen. The dashboard is supposed to be pro-active, allowing users to head off problems. A dashboard designed so that it often shows red and amber can come across as accommodating reactive behavior.

Make sure charts and graphs have clearly understood meaning and units of measure.

Make legends available as hyperlinks or flyovers. This helps keep your display uncluttered.

Consider providing data annotations for out-of-norm values so that everyone knows that any such values are being addressed.

Have colleagues and end users give the dashboard design a stringent review. In light of their feedback, perfect the design before taking the dashboard live.

###

Labels: Decision-making, Management practices, Systems thinking

<< Home