Most of the best practices standards we’ve provided, once learned, can be quickly implemented on each new dashboard created. Others will take some practice, but all have been proven in production implementations, each of which have received overwhelming user acceptance. Our advice is to avoid the approach of “getting something out the door” and then going back later to apply best practices; instead, we recommend using these standards and best practices from the very start with the first release. The fact is, once you’ve learned the ideas in this document (in particular our section on “Shortcuts, Cheats and Other Tips & Tricks”), you’ll discover that you can build a powerful, flexible, and aesthetically pleasing report in the same time it takes to build a clumsy, static, low-functionality report.
There are six main Tenets of good Dashboard Design best practices and are as follows:
I. Provide insight, not reports.
When a key user drops off a stack of Excel spreadsheets in response to your request for “requirements”, take the time to understand what results they are trying to derive from that content. Understand what they search for, what they mark up with a yellow highlighter, and what they look at next after discovering an exception. With the best practices that follow, you’ll discover that you can offer multiple ways of providing insight from the same content packed into one Excel spreadsheet (which offered no insight, just data); and that you’ll be able to compact multiple Excel spreadsheets into a single, flexible report module that can fit into the upper left hand corner of a dashboard. Column selectors, view selectors, and bubble charts are not complex. If you think they are, see Tenet #3.
II. Protect your real estate and eliminate the white space.
Unlike printed reports where you can get away with saying “the answer is on page 42”, the same is not true for online dashboards where you will most likely be restricted to what you can fit into an 1024 x 768 pixel screen (or 1024 x 2304 if your dashboard is three pages long). If your users can’t derive insight in the first few seconds of looking at a dashboard, the design could use improvement. If your dashboard has large patches of white space, it will look incomplete to the users and you are wasting space. If you believe that it’s impossible to fit meaningful content into 1024 x 2304 pixels, go check out popular Internet portals like MyYahoo, Google, or MSN.
III. Trust your users will get it.
Most users in today’s business world are familiar with browsing the web and the typical controls used to shop, bank, research, and consume information. Controls like dropdowns, buttons, checkboxes, and text fields are all used on popular sites throughout the Internet – and on OBIEE, too! Trust your users. If you’ve followed rules #1 and #2, your users are going to get it.
IV. Merge business skills into your IT skills.
In order to create the insightful reports we discussed in Tenet #1, report designers need to know more than what the business users are asking for on a report. A highly successful BI project will have designers who know the business side well and can develop new reports and enhance existing ones without explicit instruction from the business users. In Business Intelligence, we need to move away from simply asking what the user wants the report to look like and what data they want in the database. We need to move toward understanding the business processes and determining what data and reports will bring the insight the users need. Once you’ve gotten to know the processes driving the reports, you can make suggestions to the users on what they need to be successful. Most of your users have no idea what kind of reports Oracle BI is capable of producing when utilized to its full potential. With a time spent getting to better know the business, you’ll be able to deliver powerful, insightful reports the users hadn’t considered or didn’t even know were possible.
V. Design your dashboard (and insight) in Oracle BI itself using an iterative methodology.
Dashboard design requires multiple iterations to be successful. Business users often don’t know or realize what they want until they can see something they like or something they recognize needs to be changed. It’s important that you have a plan in place during the build process that allows for several levels of refinement. This plan should include a sound strategy for capturing and documenting user input, prioritizing the changes, and determining the complexity. Careful planning of this process will ensure that all iterations run smoothly and add as much value as possible.
VI. Be prepared to review, refine, and re-do.
After you’ve rolled out your BI project, if the implementation is viewed as a success by the users, you’ll notice that BI slowly becomes more pervasive throughout your organization and is eventually no longer thought of as BI - it’s simply part of the way the business is run. But the business focus can change, processes change, needs change. A periodic review should be done to asses whether the dashboards are still meeting the needs of the business as well as when they were first deployed. Refinement may be needed to evolve the dashboards with the business, and sometimes even more dramatic re-do’s are necessary.
One of the most important aspects of a BI project is the underlying data warehouse model. This may seem like a no-brainer, right?
Posts
