It is not uncommon to have business users ask for quick and fast delivery of dashboard-style content based on their requirements. At the same time, business users want to be part of the dashboard-building process as well, as they should be. It used to be that business users would just state the requirement and then wait for the final result. That is no longer viewed as the optimal way to build dashboards. As a result, you need to use a process that helps you act on the new requirements, as well as keeping the business users involved in the process.

In this second article in my three-part series, I walk you through the first four steps (of eight) for creating a better dashboard (Figure 1). They are:

1. Observe and understand
2. Define
3. Ideate
4. Prototype

Figure 1

The complete eight-step process for building a better dashboard

Note
In my next and final installment of this three-part series of articles, I cover the details for steps 5 through 8.

Step 1. Observe and Understand

The first step is to understand the actual business problem that your users are trying to solve, as well as how not having a solution for the problem is impacting their work and the company overall. This step is about listening to your users and gathering as much information and requirements as you can to help solve their problems. It is also about taking a look at already-existing solutions and determining what might be missing from them.

Starting with the actual business problem allows you to create common ground and especially helps by bringing together the IT and business side.

• For the IT team, hearing the business problem and the impact those problems have on the company, helps them to understand the urgency of the issue and the reasons for creating the dashboard in the first place.
• For the business users, outlining and documenting the business problems and their impacts, not only is a good exercise that helps to focus on the real purpose of the dashboard, but it also helps set priorities.

When you discuss the business problems, your role is to listen to all the business problems and the impact they have on the business. It is not your goal to offer solutions at this stage. To help tease out some of the issues, ask your audience some crucial questions:

1. What are the key challenges as part of their business area?
2. How do those problems and issues impact the business?
3. Do these problems impact the company’s goals and strategy?
4. Are these problems based on internal or external influences?
5. How are they solving these issues today?

During the discussions, try to document as much as possible as you will have to come back to this list and ask your business users to prioritize and rank these issues once they’ve been identified.

Table 1 shows some examples of four typical business problems and their impacts.

Table 1

Some common business issues and how they impact companies

You notice that, at this stage, I do not advocate defining the key performance indicators (KPIs) that you are going to use for your dashboard. This comes later in step 2. You are also not yet defining the dashboard layout and navigation steps (those come later as part of step 3).

After you document all the problems and their impacts on the business, it is time to add another three columns to your table of business problems:

1. One by one, determine the severity of the business problem. On a scale of 1 to 10, how much pain does this particular problem cause?
2. If this problem is solved, how much of a positive impact would it have on the business?
3. Does this problem impact strategic company goals?

When adding this information, you can use a scale of one to 10 or from one to five to rank the business problems against the first two questions. If you can actually place a true monetary value on the problem, even better.

The third question tries to separate those problems that are related to company strategy from those that are not. The answer to this question helps, in step 2, to keep the focus on those KPIs that are the most important to the business.

With all this information in hand, and now that the business problems have been prioritized, you can move on to the next step: define.

Step 2. Define

Step 2 is really about taking all the business problems that you collected in the first step and focusing on the true KPIs that you have leveraged as part of your dashboard. Before going into the details on how to identify the KPIs for your dashboard, let’s create a definition for the term KPI for consistency:

• A KPI represents a metric that is linked to a company goal.
• A KPI is a measure that indicates how a business is doing.
• A KPI should indicate how the company is doing compared to the agreed-upon goals.

In step 2, you are going one step further and, looking at the problems identified in step 1, attaching specific KPIs to these problems, and seeing what impact these KPIs have. When you discuss the KPI details with your business users, here are some questions you want to ask:

• Who in the organization needs this KPI?
• What is the business problem they are trying to solve when using this KPI?
• How is this KPI defined?
• Where is the data that is relevant for this KPI?
• Are there related KPIs that are often used in combination?
• What are some of the common terms and abbreviations for this KPI?
• How often is the data being updated or calculated for this KPI?
• What is the required granularity for this KPI?
• What are the company goals related to this KPI?
• What are the defined thresholds for this KPI?
• Does the KPI have a particular owner?
• On which organizational level is this KPI being used?
• Which decisions are impacted by this KPI?
• What are the related or supporting measures?
• What are the key influencing factors for this KPI?
• What are the most typical timeframes used for this KPI?

As you go through these types of questions, you notice that you are, at a basic level, trying to get the granular details of each of KPI. In this way, you will gather all the required information that allows you to move forward to the next step and, ultimately, to create the dashboard.

You should meticulously document the gathered information so that you now have two sets of information as part of the process. The first asset is the overview that you created in step 1, where you documented the business problems and the impact to your business. An example of this kind of information-gathering is shown in Table 2.

Table 2

Examples of issues and how they impact businesses

Note
You will note that the Dollar value column is blank in some cases in Table 2. This is because sometimes you are unable to put a concrete money value on a problem or solution.

The second asset that is put together as part of step 2 are the supporting details (e.g., KPIs) that provide the basis for the overview. The process looks similar to the outline in Table 3.

Table 3

KPI definitions

Steps 1 and 2 provide a good overview on the business problems that you need to review and understand, and which KPIs are relevant for your dashboard. From the business users, you also received a clear ranking. This helps you stay focused on and clear about the priorities in the next steps, to ensure your dashboard’s success. In addition, after steps 1 and 2, you have all the information you need in regards to the data-related requirements. You should now be able to articulate which data you need for your dashboard, where the data is stored, and which source systems are involved.

Step 3. Ideate

If you are familiar with design-thinking methodology, then you have heard the term ideate before. At this stage, the requirements have been gathered, the priorities set for those requirements, and the KPIs have been determined, as well as how they relate to the strategic goals. Now it is time to brainstorm about possible layouts of the dashboard and to discuss possible navigation paths for it. The goals for the ideate step are:

• Create an initial navigation path for the dashboard.
• Create an initial list of required filtering capabilities.
• Create an initial list of any additional functional requirements.

Functional requirements, in this context, refer to elements such as being able to print, export, or share the dashboard via email, or any additional capabilities that are required and that do not fall into the navigation or filtering category.

So, now the question arises, how do you now gather those additional requirements for your dashboard? Well, you know exactly where to focus because you ranked the business problems in step 1, and gathered supporting details in step 2. At this stage, you also know which of the KPIs are related to strategic company goals, so now it is all about ideas, and there are no wrong ideas.

Here are some suggestions for how to structure the process in step 3:

• Ideally, you are in a room with a large whiteboard. If this is not possible or not available, use large sheets of paper.
• Create three categories on the whiteboard: KPI, dashboard features, and dashboard navigation.
• Hand out sticky notes to everyone. For the KPI category, prepare a set of sticky notes using two different colors to differentiate those KPIs related to company goals and those that are not. Additionally, create a sticky note for each KPI that was added during steps 1 and 2.
• Again using sticky notes, have all the attendees add their desired features and navigations to the whiteboard. Ideally, use different colors for features and navigations so that they can be distinguished easily.

With this setup, your business users have the opportunity to add their wishes to the dashboard. During this process you should limit the time that your audience has to complete these tasks to keep them focused on the job at hand.

After the initial phase, using a new empty whiteboard, draw a rough concept of a dashboard on (Figure 2).

Figure 2

A representation of a new blank dashboard to help with design efforts

The first thing you ask your users to do is to place the navigation elements onto the dashboard. In your role as dashboard designer, it is your duty is to challenge the users’ ideas and question why they are placing elements in those particular spots on the dashboard. After a healthy discussion about what navigational elements should be placed, and where, and, hopefully, agreeing on a common place for them, continue the discussion about which KPIs should be part of the dashboard. Here again, challenge the number of KPIs and ask your users to provide underlying reasons for why a particular KPI should be part of the dashboard. If no context can be provided, then the KPI is not to be placed on the dashboard.

After a while you should have a set of very good suggestions for the overall design. This includes preventing unnecessary or irrelevant KPIs from being added to the dashboard that do not provide any value for its overall goal. One situation that you should avoid at this stage is to discuss the details on the visualization choices for the dashboard. If users want to make suggestions at this point, they should absolutely feel free to do so. However, the goal of this step is not to make detailed decisions about if, for example, the dashboard is going to use a column chart, a bullet chart, or a KPI tile to visualize specific measures. The goal is to more broadly determine the goal of the dashboard, and how and where it will display the required details.

At the end of step 3 of this process, you should be left with a complete list of functional and navigational requirements for the dashboard, and you should have the narrowed-down list of KPIs.

In other words, you should have answers to these questions:

• Which additional filters are commonly used?
• Which drill-down dimensions are commonly used?
• How will the dashboard be accessed (e.g., mobile, desktop, or browser)?
• How will the information be shared (e.g., Excel, PPT, or email)?
• What are some of the most important questions that the dashboard needs to answer?
• What are the timeframes for the filtering for the used KPIs?
• How is the increase or decrease normally measured for the measures (e.g., month over month, quarter by quarter, or year by year)?

Step 4. Prototype

Now it is time to create the first prototype of your new dashboard and to move beyond a rough dashboard drawn on a whiteboard.

For this step in the process there are some very important rules that you should consider when creating your prototype:

• Prototypes should be interactive so that your business users can follow the navigation path. This should not consist of just switching the slides in a presentation, but instead your prototype should have interactive elements in the same way your final dashboard will have interactive elements.
• Use the correct visualizations as part of your prototype. If your recommendation is to visualize the information in the form of a bullet chart, then your prototype should show a bullet chart and not any other visualization or a placeholder with a comment that this will be a bullet chart.
• Prototypes should leverage sample data from local data sets, such as local spreadsheets. There is no need to worry about connecting your prototype to the data warehouse at this step, but your sample data should be consistent. By consistent, I mean that if you are showing a trend of 12 months of data and the user has the ability to change the prototype to a quarterly view, then the aggregated values for the quarters should match your monthly information. In other words, your sample data should be logical and correct according to the scope of the prototype.
• Do not use a paper-based prototype. There are enough software solutions available—including free ones—that give you the ability to create interactive prototypes so there is no need to create one-dimensional ones.
• Do not use the actual product that you are using to create the final dashboard. Instead, at this stage, use a wireframing environment; otherwise, you end up spending far too much time on technology.

Remember that, at this point, it is about creating prototypes (multiple) and gathering feedback from your business users. The key at the end of step 4 is to be able to provide your business users with an interim result that is very close to the final, actual dashboard, with the least possible effort.

At this point in the process, you should have sign-offs on the following key elements of your dashboard:

• Which KPIs are going to be used.
• The overall dashboard layout.
• Which navigation elements will be available, such as filtering and drilling down.
• What the available access options will be, such as desktop, mobile, or browser.
• What additional features the dashboard will offer.

At this stage, you don’t need to have a sign-off about the final dashboard—that decision is discussed in detail, in step 5, in my next installment of this series.

Ingo Hilgefort

Ingo Hilgefort started his career in 1999 with Seagate Software/Crystal Decisions as a trainer and consultant. He moved to Walldorf for Crystal Decisions at the end of 2000, and worked with the SAP NetWeaver BW development team integrating Crystal Reports with SAP NetWeaver BW. He then relocated to Vancouver in 2004, and worked as a product manager/program manager (in engineering) on the integration of BusinessObjects products with SAP products. Ingo's focus is now on the integration of the SAP BusinessObjects BI suite with  SAP landscapes, such as SAP BW and SAP BW on SAP HANA, focusing on end-to-end integration scenarios. In addition to his experience as a product manager and in his engineering roles, Ingo has been involved in architecting and delivering deployments of SAP BusinessObjects software in combination with SAP software for a number of global customers, and has been recognized by the SAP Community as an SAP Mentor for SAP BusinessObjects- and SAP integration-related topics. Currently, Ingo is the Vice President of Product Management and Product Strategy at Visual BI Solutions, working on extensions to SAP’s product offering such as SAP BusinessObjects Design Studio and SAP Lumira. You may follow him on Twitter at @ihilgefort.

You may contact the author at Ingo@visualbi.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.