Designing Dashboards (General)

[#1]

Note that this article uses a planning dashboard as an example, but many of these principles apply to other types of dashboards as well.

Methodology

User Stories

Building a useful planning dashboard always starts with getting a set of very clear user stories, which describe how a user should interact with the system.

The user stories need to identify the following:

• What the user wants to do.
• What data the user needs to see to perform this action.
• What data the user wants to change.
• How the user will check that changes made have taken effect.

If one or more of the above is missing in a user story, ask the product owner to complete the description. Start the dashboard design, but use it to obtain the answers. It will likely change as more details arrive.

Product Owners Versus Designers

• Modelers should align with product owners by defining concrete roles and responsibilities for each team member.
• Product owners should provide what data users are expecting to see and how they wish to interact with the data, not ask for specific designs (this is the role of the modelers/designers).
• Product owners are responsible for change management and should be extra careful when dashboard/navigation is significantly different than what is currently being used (i.e. Excel^®).

Pre-Demo Peer Review 

• Have a usability committee that:
  • Is made up of modeling peers outside the project and/or project team members outside of modeling team.
  • Will host a mandatory gate-check meeting to review models before demos to product owners or users.
• Committee is designed to ensure:
  
  • Best design by challenging modelers.
  • Consistency between models.
  • The function is clear.
  • Exceptions/calls to action are called out.
  • The best first impression.

Exception, Call to Action, Measure Impact

Building a useful planning dashboard will be successful if the dashboard allows users to highlight and analyze exceptions (issues, alerts, warning), take action and plan to solve these, and always visually check the impact of the change against a target.

Dashboard structure

Example: A dashboard is built for these two user stories that compliment each other.

• Story 1: Review all of my accounts for a specific region, manually adjust the goals and enter comments.
• Story 2: Edit my account by assigning direct and overlay reps.

The dashboard structure should be made of:

• Dashboard header: Short name describing the purpose of the dashboard at the top of the page in "Heading 1."
• Groupings: A collection of dashboard widgets.
  • Call to action.
  • Main grid(s).
  • Info grid(s) : Specific to one item of the main grid.
  • Info charts: Specific to one item of the main grid.
  • Specific action buttons: Specific to one item of the main grid.
  • Main charts: Covers more than one item of the main grid.
  • Individual line items: Specific to one item of the main grid, usually used for commentaries.
  • Light instructions.

A dashboard can have more than one of these groupings, but all elements within a grouping need to answer the needs of the user story.

Use best judgements to determine the number of groupings added to one dashboard. A maximum of two-to-three groupings is reasonable. Past this range, consider building a new dashboard. Avoid having a "does it all" dashboard, where users keep scrolling up and down to find each section.

If users ask for a table of contents at the top of a dashboard, it's a sign that the dashboard has too much functionality and should be divided into multiple dashboards.

Example:

General Guidelines 

Call to Action

Write a short sentence describing the task to be completed within this grouping. Use the Heading 2 format.

Main Grid(s)

• The main grid is the central component of the dashboard, or of the grouping. It's where the user will spend most of their time.
• This main grid will display the KPIs needed for the task (usually in the columns) and will display one or more other dimension in the rows.

Warning: Users may ask for 20+ KPIs and need these KPIs to be broken down by many dimensions, such as by product, actual/plan/variance, or by time. It's critical to have a main grid as simple and as decluttered as possible. Avoid the "data jungle" syndrome. Users are used to "data jungles" simply because that's what they are used to with Excel.

Tips to avoid data jungle syndrome:

Make a careful KPI election (KPIs are usually the line items of a module).

Display the most important KPIs ONLY, which are those needed for decision making. Hide the others for now.

A few criteria for electing a KPI in the main grid are:

• The KPI is meant to be compared across the dimension items in the rows, or across other KPIs.
• Viewing the KPI values for all of the rows is required to make the decision.
• The KPI is needed for sorting the rows (except on row name).

A few criteria for not electing a KPI in the main grid are (besides not matching the above criteria) when we need these KPIs in more of a drill down mode; The KPI provides valid extra info, but just for the selected row of the Dashboard and does not need to be displayed for all rows.

These "extra info" KPIs should be displayed in a different grid, which will be referred to as "info grid" in this document. Take advantage of the row/column sync functionality to provide a ton of data in your dashboard but only display data when requested or required.

Design your main grid in such a way that it does not require the user to scroll left and right to view the KPIs:

• Efficiently select KPIs.
• Use the column header wrap.
• Set the column size accordingly.

Vertical Scroll

• It is ok to have users scroll vertically on the main grid. Only display 15 to 20 rows at a time when there are numerous rows, as well as other groupings and action buttons, to display on the same dashboard.
• Use sorts and a filter to display relevant data.

Sort Your Grid

• Always sort your rows. Obtain the default sort criteria via user stories. If no special sort criteria is called out, use the alphanumeric sort on the row name. This will require a specific line item.
• Train end users to use the sort functionality.

Filter Your Grid

• Ask end users or product owners what criteria to use to display the most relevant rows. It could be:
  
  • Those that make 80 percent of a total. Use the RankCumulate function.
  • Those that have been modified lately. This requires a process to attach a last modified date to a list item, updated daily via a batch mode.
  • When the main grid allows item creation, always display the newly created first.
  • Status Flag.

• If end users need to apply their own filter values on some attributes of the list items, such as filter to show only those who belong to EMEA or those whose status is "in progress," build pre-set user-based filters.
  • Use the new Users list.
  • Create modules dimensioned by user with line items (formatted as lists) to hold the different criteria to be used.
  • Create a module dimensioned by Users and the list to be filtered. In this module resolve the filter criteria from above against the list attributes to a single Boolean.
  • Apply this filter in the target module. 
  • Educate the users to use the refresh button, rather than create an "Open Dashboard" button.

Color Code Your Grid

• Use colored cells to call attention to areas of a grid, such as green for positive and red for negative.

• Color code cells that specifically require data entry.

Display the Full Details

If a large grid is required, something like 5k lines and 100 columns, then:

• Make it available in a dedicated full-screen dashboard via a button available from the summary dashboard, such as an action button.
• Do not add such a grid to a dashboard where KPIs, charts, or multiple grids are used for planning. 
• These dashboards are usually needed for ad-hoc analysis and data discovery, or random verification of changes, and can create a highly cluttered dashboard.

Main Charts

The main chart goes hand-in-hand with the main grid. Use it to compare one or more of the KPIs of the main grid across the different rows.

If the main grid contains hundreds or thousands of items, do not attempt to compare this in the main chart. Instead, identify the top 20 rows that really matter or that make most of the KPI value and compare these 20 rows for the selected KPI.

• Location: Directly below or to the right of main display grid; should be at least partially visible with no scrolling.
• Synchronization with a selection of KPI or row of the main display grid.
• Should be used for:
  • Comparison between row values of the main display grid.
  • Displaying difference when the user makes change/restatement or inputs data.
• In cases where a chart requires 2–3 additional modules to be created: Implement and test performance.
  • If no performance issues are identified, keep the chart.
  • If performance issues are identified, work with product owners to compromise.

Info Grid(s)

These are the grids that will provide more details for an item selected on the main grid. If territories are displayed as rows, use an info grid to display as many line items as necessary for this territory. Avoid cluttering your main grid by displaying all of these line items for all territories at once. This is not necessary and will create extra clutter and scrolling issues for end users.

• Location: Below or to the right of the main display grid.
• Synced to selection of list item in the main display grid.
• Should read vertically to display many metrics pertaining to list item selected.

Info Charts

Similar to info grids, an info chart is meant to compare one or more KPIs for a selected item in the rows of the main grid.

These should be used for:

• Comparison of multiple KPIs for a single row.
• Comparison or display of KPIs that are not present on the main grid, but are on info grid(s).
• Comparing a single row's KPI(s) across time.

Place it on the right of the main grid, above or below an info grid.

Specific Action Buttons

• Location: Below main grid; Below the KPI that the action is related to, OR to the far left/right - similar to "checkout."
• Should be an action that is to be performed on the selected row of the main grid.
• Can be used for navigation as a drill down to a detailed view of a selected row/list item.
• Should NOT be used as lateral navigation between dashboards; Users should be trained to use the left panel for lateral navigation.

Individual Line Items

• Serve as a call out of important KPIs or action opportunities (i.e., user setting container for explosion, Container Explosion status).
• If actions taken by users require additional collaboration with other users, it should be published outside the main grid (giving particular emphasis by publishing the individual line item/s).

Light Instructions

• Call to action.
  • Serves as a header for a grouping.
  • Short sentence describing what the user should be performing within the grouping.
  • Formatted in "Heading 2."
• Action Instructions.
  • Directly located next to a drop-down, input field, or button where the function is not quite clear.
  • No more than 5–6 words.
  • Formatted in "instructions."
• Tooltips.
  • Use Tooltips on modules and line items for more detailed instructions to avoid cluttering the dashboard.

[AnyaS]

We have used Guillaume's dashboard planning methodology recently with two of my CS customers across 6 different use cases. It seems counterintuitive to many at first but always works like a champion.

One of the major challenges (that at the same time represents a transformational  opportunity) is user's attachment to their current process. A typical mentality when it comes to analysis is "Ok. This is my data. What can I make out of it?".

Starting with UI and Dashboard design turns it all around and makes the user think of the ideal state aka "What do I want to analyze to be effective in my role?" and then subsequently think of how to get there. 

The ability to take this approach is one of the biggest strengths of Anaplan due to its flexibility.

At the same time, starting with UI enables creative thinking which always is a great start for a positive experience.