How to build good dashboard. Part 3: Zoning.

In Part 2 I mentioned that prioritization is the key thing in building dashboards. Prioritization of content has to be supported first of all by right layout and zoning of a dashboard. Let's talk about this a little bit.

Zoning
Think about your dashboard like if it was a house. Unless you're a very original person, in your house you typically don't want to keep car accessories in the bedroom, dinner table in the bathroom and washing machine in your dining room. Instead, you keep car stuff in the garage, have meals in dining room and do your laundry in the basement or laundry room, because your house has logical and functional zones. The same should be applied for dashboards as well -- define logical and functional zones on your dashboard. Usually there are not more than 5-6 of them on a single sheet. Here is an example:

As you can see on example above there are 6 zones. Notice, however, that some zones can also be logically grouped -- e.g. Suppliers and Inventory, Sales and Cash flow, Context selection and Alerts. Sometimes these logical groups can overlap -- when a certain zone can belong to two logical groups. Here is an example:

In this case cash flow has two major components -- incoming money (from sales) and expenses (money that mostly go to suppliers). Therefore, Cash flow zone can be shown as overlapping segment from both Sales and Suppliers zones.

So, what should be size and position of the zones? Regarding size -- let's use our analogue with house once again. Typically you don't want your laundry room be the biggest room in the house. Why? Because your house is for living, not for laundry (unless you operate a laundry business and live there). The same is true for dashboards. As screen size is limited, you should allocate the largest zones for the most important information and keep less important data in smaller zones (however it doesn't mean that you should have an important pie chart that occupies 60% of your screen room).

In Part 4 I will talk about positioning zones and elements -- which is layout.

For those who monitor QlikTech's stock price

Many visitors of this blog are very loyal to QlikView. For those of them who are interested in QlikTech's share price trends -- here is embeddable widget that updates automatically every day. The widget is interactive -- try clicking comment, scroll, zoom, click dots or select rectangular areas. I create comments to it from time to time. Feel free to grab the chart and embed anywhere you like and make your own comments (you need to have account on Explainum for this).


This is the HTML code you should use if you want to embed this widget into your web-page. Width and height of the widget can be adjusted by according parameters.

<script type="text/javascript">
//<![CDATA[
explainum_chart_id = 38;
explainum_widget_width = 500;
explainum_widget_height = 350;
//]]></script>
<script type="text/javascript" src="http://explainum.com/scripts/loader.js">
</script>

How to build good dashboard. Part 2: Usage scenario

Once you've decided to build a dashboard you need to plan it. Planing a dashboard actually means two tasks: defining usage scenario and zoning.

To understand usage scenario you'll want to have answers to these questions:

• Who will use the dasboard? What are their roles in the organization?
• What are business goals of each user or each particular group of users? What kind of tasks are they trying to accomplish?
• What information is of primary importance for the user? What is of secondary importance? What is nice to have but not very important?
• What kind of troubles do users need to identify?

Let's take a closer look at these questions.

User roles
In majority of cases there are 3 main groups of users: regular users, analysts and management users.

Regular users usually work with relatively narrow subject area and always need detailed information about it. They do not do much of ad hoc analysis and usually have pretty straightforward workflow. In terms of dashboard content they usually need balanced mix of gadgets, charts, tables with a few filters.

Analysts work a lot with detailed information in ad hoc manner. Usually dashboards are not the best main tool for them -- they need powerful query & analysis applications. However, dashboards can be good for quick identifying of problems and starting point of analysis. Analyst dashboards usually contain a lot of tables, charts with actual numbers and many filters.

Management users often track set of key performance indicators. They also constantly check actual numbers versus planned/estimated numbers. Besides KPIs they usually want to know best (or worst) products/customers/dealers/etc. So typical management dashboard has a lot of gadgets and charts with actuals and estimates and a few tables with lists of top products, customers, etc. Management users rarely work with detailed data so it's better not to use large tables for them.

Goals and Tasks
Make sure that dashboards have obvious and distinct indicators that show progress towards reaching strategic and/or operational goals. These goals can be either rarely changed -- "static" goals like annual targets or operational benchmarks, or "dynamic" goals like goals of short-time projects, marketing campaigns, reorganizations etc. When planning a dashboard keep groups of "static" and "dynamic" goals separately.

Priority and Importance
Prioritization is a key to building good dashboard. When designing a dashboard we need to deal with 2 key limitations: a) limited screen space, and b) limited human ability to read and prioritize information from many visual objects. And keep in mind that b) is more significant than a) -- Moore's low doesn't work for humans (unfortunately). Hence, it is very important to make more important information more eye-catching, easy to read and understand. However, we can't have 500 or 100 very important things in our dashboard -- average human can't track more than 20 important indicators and even 20 is a lot. Therefore, we need to prioritize carefully and plan working space of a dashboard accordingly. The less important is information -- the more clicks/actions/time should be necessary to get it.

Identification of Troubles
Make sure that you understand what are major problems/troubles that users want to identify with the dashboard. Try to make list of them -- it shouldn't be very long. Then make sure that every trouble will be obviously indicated in the dashboard -- either with different color or shape, special gadget, eye-catching flag or alert message that is invisible in normal conditions.

In Part 3 I will talk about zoning.

How to build good dashboard. Part 1: Dashboards vs reports

For majority of BI developers Business Intelligence have roots in building static reports which mostly contain tables with aggregated data from SQL queries. While static reporting still remains as a significant portion of data visualization in a large organization, dashboards continue to gain popularity, especially with wide adoption of tools like QlikView which simply doesn't have any other form of data visualization except dashboards (don't tell me about reports in QlikView -- they're barely usable).

However, building a dashboard requires different approach than creating a table-based report, because the way users work with dashboards noticeably differs from the way users work with reports:

1. Reports usually have multi-page content, dashboards are single-page (dashboards can have several sheets or tabs but usually they can be considered more or less independent as they need to answer different questions)
2. Dashboards are intended to give answers at first sight, at the same time reports can contain a lot of detailed data that might require more thorough analysis
3. Reports are often designed to be printed while dashboards are designed for screens; despite printing dashboards is rather common practice, I think this is done because of lack of social features in BI suites
4. Dashboards are interactive; reports, despite often having filters and drill-down capabilities, are more static by nature
5. Dashboards tend to be similar to applications, reports tend to look like a document.

Generally, I consider dashboards as a more progressive way of data visualization than static reports (excluding cases when basic documents such as invoices or regulatory reporting are needed) because visual representation of numerical data is better than textual one, especially when we need to catch deviations from a pattern, which is very common case in business data analysis. Many years BI vendors had been diminishing role of dashboards -- luckily in recent 2-3 years they changed their mind and greatly developed their offerings. SAP, Oracle, IBM, Microsoft -- all of them now offer dashboarding tools, but none of them is so advanced as QlikView is.

In Part 2 I will talk about planning a dashboard.