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'll likely change as more details are received.
Building a useful Planning Dashboard will be successful if the dashboard allows users to highlight and Analyze exceptions (issues, alerts, warning), then 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 2 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 needs are here to answer the needs of the user story.
Use best judgements to determine the amount of groupings added to one dashboard. A maximum of 2 to 3 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.
Write a short sentence describing task to be completed within this grouping. Use Heading 2 format.
Warning: Users may ask for 20+ KPIs, and need these KPI's 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; 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 reffered 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:
Color code cells that specifically require data entry
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 100's or 1,000's 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 terriories 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.