Note that this article uses a planning dashboard as an example, but many of these principles apply to other types of dashboards as well.
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.
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.
Example: A dashboard is built for these two user stories that compliment each other.
The dashboard structure should be made of:
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.
Call to Action
Write a short sentence describing the task to be completed within this grouping. Use the Heading 2 format.
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.
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:
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:
Color Code Your Grid
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:
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.
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.
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:
Place it on the right of the main grid, above or below an info grid.
Specific Action Buttons
Individual Line Items