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.
Main Grid(s)
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:
Vertical Scroll
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:
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.
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.
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:
Place it on the right of the main grid, above or below an info grid.
Specific Action Buttons
Individual Line Items
Light Instructions
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.
I'm an Anaplaner since 2012. As a Master Anaplaner, I focus on complex model building implementations, help our customers & partners on model best practices and COE, contribute to building scalable architecture and usable applications. My key focus is to make our Connected Planning story a reality at our biggest customers.