Dashboard Design Tips

When designing a set of dashboards, I like to include an “at-a-glance” or summary page as the first dashboard a user sees when they log on each day. This page should include a condensed version of the user’s key performance indicators as well as any generated alerts. Users should then have the option of drilling down or to additional detailed reporting. In order to encourage usage of the dashboards, embed your dashboards as a link within the corporate portal so users have one click access to the information

Consider the page placement of your key performing metrics based on web page eye movement. The diagram below shows how the human eye views a web page, based on level of priority. Place the most important elements for viewing in the upper left hand corner and the least important in the lower right corner to mimic the way the eye scans a page.

Some additional design guidelines are:

• Ideally, the dashboard should fit on one page. Try to avoid any scrolling from left to right.
  

• The best screen size for the dashboard window is 1024 x 768.

• The ability to drill is critical to the success of your dashboards. Users need to know that the underlying data is going to be available to them. Some projects I’ve worked on have been very successful when allowing the users to drill not only to the detailed data but also back to the source transactional systems.

• Introduce competition by using Top 10 reports, conditional formatting, etc.

• Avoid decorative dashboard elements cluttering the screen like dials, gauges, excessive colors and images. Your dashboard can still be visually interesting while following standards.

• Speaking of standards, it’s important that dashboard standards and best practices be defined early in the design process. This ensures consistency among various groups within your organization. I recently worked on a project where OBIEE had been in place for over a year, being used by a few departments. Additional teams were being brought on board and new development had already started. There were no design guidelines in place and the new dashboards were completely different among each of the teams. One of our exercises was to look at what was in production today and identify standards to be used in future development. This also caused a little rework on the production dashboards to meet the requirements of all teams, resulting in a consistent approach for the organization as a whole.

As a little bonus, I’ve included a few tips from Dashboard expert Stephen Few:

Characteristics of A Well-Designed Dashboard

• Exceptionally Well Organized

• Condensed, Primarily in the form or Summaries and Exceptions

• Specific to and Customized for the Dashboard’s Audience and Objectives

• Displayed Using Concise and Other Small Media that Communicates the Data and Its Messages in the Clearest and Most Direct Way Possible

Common Mistakes in Dashboard Design

• Exceeding the Boundaries of a Single Screen

• Supplying Inadequate Context for the Data

• Displaying Excessive Detail or Precision

• Arranging the Data Poorly

• Highlighting Important Data Ineffectively or Not at All

• Cluttering the Display with Useless Decoration

• Misusing or Overusing Color

• Designing an Unattractive Visual Display

High Level OBIEE report design strategy

So often an organization will take on the task of installing OBIEE, establishing the infrastructure to support it, and even re-organizing their data appropriately. But when it comes to the actual report design, standards fail to be established, reports and dashboards become awkward and cumbersome, and user adoption suffers.

Since OBIEE is often seen as an Ad-Hoc reporting tool, this problem can often be the result of many developers developing with an Ad-Hoc mentality. The result is mismatched dashboards and confusing layouts. Other times, it’s the result of too many people involved in the development process. Once something gets approved by 15 people in a Power Point mock up, it’s difficult to get changes approved when something doesn’t pan out as expected. As a result, the small imperfections get set aside, but never fail to add up.

The following is a high level list of items to keep in mind when entering the report development stage of any OBIEE project. Keeping each of these items in mind will help you design attractive and useful reports and dashboards, which will ultimately lead to greater user adoption and pervasive use of the tool.


1. Trust your users - If your users don’t use your BI or other technology systems, it’s because they either get no value from it, or the system is too slow. These same users will spend their evenings shopping online and paying bills over the internet. It’s ignorant to believe they can’t use a well designed online reporting tool.

2. Think Insight, not Reports - Take the time to understand what the business user searches for, what they mark up with a yellow highlighter, and what they look at next after discovering an “exception”

3. Move Business Skills into your IT shop, not IT skills into your Business – Make an effort to understand the business needs, and then apply the technology accordingly. Don’t ask the business to “make due” with what IT provides.

4. Design your Dashboard in OBI EE itself using an iterative methodology – Don’t use Power Point to design your reports. Designing directly in OBIEE allows you to know immediately what will and will not work. Plan to make a series of adjustments throughout the design process, using feedback from the business users.

5. Establish a set of standards – If your users can’t derive insight in the first few seconds of looking at a Dashboard, it’s a bad design. This is no longer a world in which IT programmers lead the user’s impression of standards. Amazon, Google, Yahoo!, Apple iPhones, etc. all lead the pack when it comes to quality interfaces and standardized interfaces.