!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 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: , ,