Design a Management Dashboard in 7 Steps

Share on LinkedIn0Tweet about this on TwitterShare on Google+0Share on Facebook0

Guest post by Mark Vovsi

I’d like to walk you through the management dashboard design process my team recently used to build a loyalty rewards program dashboard.

It is an iterative approach with prototypes that has 2 benefits.  First and most importantly, it will allow the dashboard audience to make sure it answers the right questions. Second, the dashboard team will be able to quickly assess feasibility and translate the business needs into data and technical requirements.

Since a management dashboard is a summary view using graphs, charts and heat maps, visuals should be included early on to simplify and speed the design process.

The 7 Step Management Dashboard Design Process

1. Create a dashboard shell

After understanding the purpose of the dashboard, create simple mockups as soon as possible to drive discussions with the teams. Don’t waste time - get creative, think out loud, and use a white board in your initial meetings!

Hand-drawn Dashboard Prototype Example

  • With a business executive, make sure that all key functions and levels of information are represented (e.g. new accounts, reward redemption trends, operational metrics). Ask the marketing executive (in our example) which decisions she wants to make for each function. Then talk through the metrics that will allow her to make those decisions
  • With IT, make sure that it’s actually feasible to obtain this data. Will the team be able to automatically aggregate all data using an in-house reporting solution? If not, is the management dashboard customer willing to invest in custom development or will someone be preparing it manually every month? Answering these questions will help to define the scope and associated cost of the dashboard effort early.

2. Fill in the shell with metrics

After the initial discussions, create a more complete prototype to facilitate the remaining design discussions. Draft up this prototype in Excel and include some real metrics.

Excel-based Dashboard Prototype Example

Further refine and structure the design:

  • Define the categories for each dashboard section (e.g. for reward redemption, the marketing executive may want the numbers broken out by Merchandise, Travel, Gift Card redemption)
  • Define the columns (e.g. for a monthly dashboard - current month, trend from prior month, YTD data, and % of total are common columns)
  • Fill in with realistic metrics and make sure that the data ‘adds up’, since you’ll be using this prototype to verify how the data is laid out.
  • Review this prototype with the business users. Is it answering all key questions? Should the data be categorized differently? Is there a need for a ‘level 2’ dashboard with more detail?
  • Update after the discussion and discuss with IT. Is it possible to aggregate and graph the data according to the business needs?
  • After these alignment sessions, the revised mockup may look like this:

Revised Excel Dashboard Mockup Example

In our client case example, key sections and metrics were clarified, and the business team decided to not even include any charts in the final dashboard.

3.  Demo the dashboard

By this point, both business and technology teams are familiar with the needs, but both sides likely have outstanding questions. It’s a good idea to talk through the dashboard requirements after demoing with a live reporting tool. Having the visual provides context around capabilities (e.g. drag and drop, dynamic vs. static). The visual demo will set expectations with users for what they’re getting and build confidence. The demo may showcase certain capabilities (e.g. charting) that present a more powerful way to communicate information.

You’ll also notice that the dashboard development team often thinks and communicates in the language of the reporting tool. The team will use the demo session to validate certain assumptions with the business and to translate the needs into their development mental model.

4. Conduct a detailed requirements session

Get the business and technology folks together, get into the weeds, and make sure that the development team understands all calculation.  Document the calculation formulas.

5. Follow an iterative development approach with business users

During development, make sure that there are 3-4 prototype sessions w/users, where the business team can validate format and calculations.  It’s also helpful to have the business acceptance testers get raw data that they can manipulate and sum up to make sure the dashboards show what’s been intended.

6. Validate the dashboard with a cross-functional team

Management dashboards and reports are a funny thing - true needs always seem to be determined after they’re already in use. Prototyping will help, but it’s not until the dashboard is used in the board room, that it becomes apparent, that some metrics are unnecessary, while some are missing.  It may help to hold a soft launch and listen in on a few “live” meetings to see how the dashboard is used.

7.  Plan for updates

After the dashboard is launched, keep the development team engaged part time at least for 3 months in case there are revisions or it becomes apparent that certain dashboard sections need to be displayed in greater detail (level 2 detail).

These seven steps worked well for our team.  One dashboard lesson learned is to ensure that the person driving the design process has the skill set to both guide an executive through defining the dashboard requirements of the dashboard and also have a solid understanding of existing reporting capabilities and available information.

For further reading, check out the CIO Guide to IT Dashboards.

cc licensed flickr photo shared by Scott McLeod

Share on LinkedIn0Tweet about this on TwitterShare on Google+0Share on Facebook0
  • You mention under step 2.) Fill the Shell with Metrics that it is important to use realistic metrics. I couldn’t agree more ! I have suffered through design sessions where business users just wouldn’t even begin to think about the presented concept if the data presented was unrealistic. They are used to seeing real metrics about their business and if one tries to make up data that doesn’t make sense to them they will often not conceptualize but rather declare the whole design as ‘not working for me ….’. Great post !

  • You mention under step 2.) Fill the Shell with Metrics that it is important to use realistic metrics. I couldn’t agree more ! I have suffered through design sessions where business users just wouldn’t even begin to think about the presented concept if the data presented was unrealistic. They are used to seeing real metrics about their business and if one tries to make up data that doesn’t make sense to them they will often not conceptualize but rather declare the whole design as ‘not working for me ….’. Great post !

  • Reggie Panaligan

    Mark, great post. From experience, these steps are a great “path to glory” when it comes to management reporting and dashboarding. To add to the lessons learned from this post, it also important to design a reporting process that is flexible enough to potentially produce multiple dashboards drawing from the same information to address different audience-levels. Additionally, during the requirements review, it is essential that the roles and responsibilities of management reporting are clearly defined, so that the owners of the data/information clearly understand they are on the hook whenever dashboard update-time rolls around. While this should be a given during the requirements phase, companies often overlook the R&R/operating model aspects in favor of the nuts and bolts of calc definition/dashboard aesthetics.

  • As an ex-CTO and CEO since 1989 I would say allowing IT to drive the dashboard design is a mistake. The first step is to look at the Strategic Plan of the organization and from that (top down) determine the metrics that frame and measure success. Often the department heads are stuck in a frame of mind that is based on history, not innovation and progress. We have put a full set of training video together on dashboard and certify consultants in this. Using a consultant is highly recommended because they are not steeped in the organization’s history, politics and group-think. Here is a link to video explanations of what I am talking about. airtightmgt com (back-slash here) what-is-airtight-management/dashboards-and-metrics.html
    I have been designing business models and dashboards since 1989 and grown two companies to over $100MM in sales, so I understand the issues with growth and various size businesses. The purpose of dashboards is not well understood, in fact lots of dashboards are not even really dashboards that serve a very specific high-level, summary purpose, they are a wide variety of reports and graphs. When we merge the functions of reports and dashboards we lose the power of both. The process of developing a powerful dashboard is complex and I agree with many f the sites here, however, this must be a business drive process, not an IT driven one. In fact a dashboard design should be completed 100% (1st iteration) in a spreadsheet with no technology in the way.
    Don’t let the IT tail wag the business purpose dog!