Designing dashboards (general)

No ratings

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


User stories

Building a useful planning dashboard always starts with getting a set of very clear user stories, which describes how a user should interact with the system:
The user stories need to identify:
  • What the user wants to do
  • What data the user need 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 project and/or project team members outside of modeling team
    • will host 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
    • 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 needs are here 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.



gen ex 01.png


General guidelines 


Call to action

Write a short sentence describing task to be completed within this grouping. Use 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 his/her 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:

  • 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
  • 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; 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 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," envision building pre-set user-based filters
    • Warning #1: This will have an impact on the module size and will require a few line items defined by a "user" dimension. Forget about filtering for 500k+ accounts with 2,000 users. Instead, it works well for 5,000 items by 400 users.
    • Warning #2: The grid will become read-only for the line item(s) that are not defined by users, as well as the other required dimensions. The workaround is to publish the subsidiary view, but will prevent editing within the main grid. This might be considered more for read-only grids or reporting dashboards.
    • Display these user-based filters above the main grid, and have an "Apply filter" button that simply re-opens the same dashboard and will apply the filter to the grid. 

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 selection of KPI or row of main display grid
  • Should be used for:
    • Comparison between row values of main display grid
    • Displaying difference when 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 terriories 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 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 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 function is not quite clear
    • No more than 5–6 words
    • Formatted in "instructions"
Labels (1)
Version history
Revision #:
11 of 11
Last update:
‎03-01-2018 07:04 AM
Updated by: