Dashboards are key for attaining strong user buy-in. The users of your model will live in the dashboards your team designs for them.
Anaplan dashboards are meant to cover Data Entry, Reporting, and Application administration. Dashboards are visible to all types of users, so special attention should be paid to the design of each dashboard.
These articles exist to define best practices that will ensure high usability, consistent designs, and consistent layouts between all GTM Anaplan dashboards.
If your hear some of the following from the end-users, you'll need to review your design and apply best Practices:
The dashboard is too busy, it's confusing.
It’s hard to understand what I’m supposed to do.
The page is too complicated.
I spend too much time scrolling.
I can’t find what I need. Can I export to Excel?
I only use a tiny portion of the dashboard (Using one dashboard for all user types).
Where do I go next? (Confusing navigation)
Which data can I edit?
How do I know if the change I made is a good one?
Best Design Principles
The general guidelines for building a usable dashboard are described in these 4 areas:
Clarity - Less is best.
Cleanliness - Carefully select data you display to users. Having all the elements properly aligned can make dashboards easier to read and use.
Visualizations - Leveraging charts and conditional formatting.
Simple - Navigation and actions.
Articles about designing specific types of dashboards:
Designing dashboards (General)
Designing a landing dashboard
Designing a reporting dashboard
Designing a instruction dashboard
Example dashboards are displayed in these articles:
Dashboard example: Territory Planning
Dashboard example: Workforce Planning
Dashboard example: FP&A (OPEX Planning)
Note that this article uses a planning dashboard as an example, but many of these principles apply to other types of dashboards, as well.
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 users wants to do
What Data he or she needs to see to perform this action
What data he or she wants to change
How he or she will check that the change he made has 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'll likely change as more details are received.
Product Owners vs Designers
Modelers should find alignment 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 / call to actions are called out
The best first impression is made
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), 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.
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
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
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.
Call to action
Write a short sentence describing task to be completed within this grouping. Use Heading 2 format.
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 KPI's 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 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.
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 KPI's
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 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:
Efficiently select KPIs
Use the column header wrap
Set the column size accordingly
It is ok to have users scroll vertically on the main grid. Only display 15 to 20 rows at a tiem when there are numeeros 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 have rows sorted. 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 who make 80% of a total - Use the RankCumulate function
Those who 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
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 who's 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. So, 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 a "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.
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.
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
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
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)
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'
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'
These dashboards are absolutely critical to good usability of a model. Dashboards are the first contact between the end-users and a model.
What should NOT be done in a landing dashboard:
Display detailed instructions on how to use the model. See "Instruction Dashboard" instead.
Use it for global navigation - built using text boxes and navigation buttons.
It'll create maintenance challenges if different roles have different navigation paths.
It's not helpful once users know where to go.
Instead, what SHOULD be done in a landing dashboard:
Dispay KPIs with a chart that highlights where they stand on these KPIs, and highlight gaps / errors / exceptions / warnings.
Summary/aggregated view of data on a grid to support the chart. The chart should be the primary element.
Short instructions on the KPIs.
A link to an instruction-based dashboard that includes guidance and video links.
A generic instruction to indicate that the left-side sliding panel should be opened to discover the different navigation paths.
Users who perform data entry need to be exposed to the same KPIs as what execs are looking at.
Landing dashboard Example 1:
Displays the main KPI, which the planning model allows the organization to Plan.
Landing dashboard Example 2:
Provides a view on how the process is progressing against the calendar.
Landing dashboard Example 3:
Created for executives who need to focus on escalation. Provides context and a call to action (Could be a planning dashboard, too).
Reporting dashboards provide the ability to do immediate/at-a-glance analysis of planning activities.
Provide real-time collaboration on the plan across the user community
Use same best practices as Planning Dashboard; de-clutter, highlight exceptions, main display grid vs informative data grid, commentaries
Dashboard Content flow
One Key Analysis per dashboard
Should be used when a global context must be set for the entire dashboard; i.e. Time Period or Territory
Page selectors should be ordered based on usage and should be consistent across dashboards
Display grid (below charts)
Navigation to Instructions where necessary
Dynamic navigation in the plan across the hierarchies; i.e. Click on a level 1 item in one grid, will display relevant L2's and below
Below is an example taken from a Customer POC with two synced grids, and associated chart panels with color coding.
Notice that displaying when the data was last refreshed is a popular technique, especially if dashboards are refreshed daily or weekly.
Reporting dashboard example:
A complex dashboard may require numerous instructions that users need to read, as well as legal instructions that users have to read and ackowledge they have read. U sers should not be exposed to instructions every time they visit a dashboard, especially if they are lenghty instructions. So, a dedicated "Instruction dashboard" will provide instructions to end-users on demand.
Dashboard Content Flow
Users should not be exposed to instructions every time they visit a dashboard
Dashboard Content Flow
Title; Heading 1, 'Instructions Dashboard'
Heading 2, break up of instructions content
Module or Chart requiring instructions
Only Display Grid, Line items, and KPIs that require instructions
Remove unnecessary information; i.e. page drop downs
Instructions directly to the right of object which it is explaining
Single concise sentences in 'Instruction' format
Large blue box is not preferable, break it up in separate smaller boxes to improve readability
Do not clutter with too many instructions
Short Videos can be added to the instructions dashboard that show a 30-60 second demo of basic user functions
Create a module dimensioned by user
Use Conditional formatting to display red when user has not acknowledged instructions
Publish line item at the bottom of instructions page for user to acknowledge viewing of dashboard
Give Admin ability to clear all acknowledgements when instructions are added or changed
Automate your custom users list by exporting/importing daily out of the actual user's view in settings
Example of a Instruction Dashboard
Example #1: Account Assignment
Problem to Solve:
Operational task to complete - "I need to Assign Territories to a list of Accounts I'm in charge of".
Usability issue addressed: The user has a list of 400k Accounts to plan on. Cannot be done by simple scroll or search.
Is addressed by setting up a user-based filter:
User enters filter criteria in a dedicated dashboard that displays a floating palette using an "undock" functionality. Filter by Region, sub-region, and current Territory are the useful filter criteria, as well as showing only those accounts for which data entry is incomplete.
The model calculates a boolean to TRUE when the account matches the criteria. The boolean is dimensionalized by user and Account. The impact that this makes on the model size should be carefully monitored.
The grid then filters and only display accounts that match the filter criteria.
Call to Action:
Step 1: As a sales Ops manager, I filter my list of accounts based on an import of some Customer ID, or by manually setting up a filter. Then, for this account selection, I need to enter a Territory, Country, City, and method for the account selected. Once complete, I commit my changes to recalculate all of my impacted territories.
Step 2: Once committed, I need to fine tune and finalize my sub-Accounts and ensure that they are properly assigned by looking at only sub accounts that have been assigned to a different territory than its parent.
Visual cues to highlight invalid data entry (Usability guideline): Done by providing a user-based filter option that only displays invalid data entry.
Visual cues to indicate when I need to submit changes that have been made
Example #2: Capacity Planning for a Territory
Problem to solve:
As a Sales Ops Mgr, I should make a plan that will show how I will meet the target amount.
Call to Action:
Adjust Productivity, Ramping profile and Resources until my capacity matches my target.
Main chart showing capacity vs target
Capacity alert color coding
Warning message: Updates real time as end-users use any of the 3 options
Problem to Solve:
As an HR manager, I need to enter the Salary raise numbers for multiple regions that I'm responsible for.
As a domain best practice, my driver-based model helps me to enter raise guidelines, which will then change at the employee level.
Usability issue addressed: I have 10 regions, 8 departments in each, with a total of 10,000+ employees. I need to align my bottom up plan, to the down target I received earlier.
So, I need to quickly identify what region is above/behind target and address the variance. My driver-based raise modeling is fairly advanced and I need to see what the business rules are. I need to quickly see how it impacts the Employee level.
Call to Action:
Step 1: First, spot what region I need to address.
Step 2: Drill into the variances by department.
Steps 1 & 2 are analytics steps - "As an end-user, I focus first on where the biggest issues are." This is a good usability practice that helps users.
Step 3: Adjusting the guidelines (drivers)
There are not excessive instructions on how to build and use guidelines, which would've cluttered the dashboard. Instead, the "view guideline instruction" button was created. This button should open a dashboard dedicated to detailed instructions, or could be a link to a video that explains how guideline works, instead.
The chart above the grid will adjust as guidelines are edited. That is a good practice for impact analysis: no scrolling or clicking needed to view how the changes will impact the plan.
Step 4: Review a summary of the variance after changes are made. Putting steps 1-4 close to each other is a usable way of indicting to a user that he/she needs to iterate through these 4 steps to achieve their objective, which is to have every region and every department be within the top down target.
Step 5: Is a detailed impact analysis, which is placed directly below steps 3 and 4. This allows end-users to drill into the employee-level details and view the granular impact of the raise guidelines.
Notice the best practices in step 5:
The customer will likely ask to see 20 to 25 employee KPIs across all employees, and will be tempted to display these as one large grid. This can quickly lead to an unusable grid made of 1000's of rows (employees) across 25 columns.
Instead, we have narrowed the KPI list to only 10 that display without left-right scrolling.
Criteria to elect these 10: be able to have a chart that compares employees by these KPIs.
The remaining KPIs are displayed as an info grid, which only displays values for the selected employee. Things like region, zip codes, and dates are removed form the grid as they do not need to be compared side-by-side with other KPIs or between employees.
Deal with Monthly dashboards
Many FP&A dashboards will need to display all 12 months in the current year, as well as Quarter, Half, and Total Year totals. Doing this is likely to create a very large grid, especially if more than 1 dimension is nested on the rows.
The grid displayed here is what may be requested when Anaplan is replacing a spreadsheet-based solution. The requirement being "At minimum, do what we could do in the spreadsheets".
Avoid the trap of rebuilding this in Anaplan. Usually, this simply creates an extra requirement to export this into Excel, have users work offline, and then import the data back into Anaplan, which kills the value that Anaplan can bring.
Instead, build the dashboard as indicated below:
Have end-users view the aggregated values on the Cost center (the first nested dimensions) that will provide an overview on where most OPEX are spent
Have end-users highlight a cost center, and enter its detailed sub-accounts
Visualize the monthly trend using a line chart for the selected sub-account
I am working on a dashboard and I do not want to show every line item or list item included on a module. What is the difference between using the Hide functionality and the Show functionality?
There are two main differences. The first is what happens when you add a new line item or item to a list. If you've used Hide, you will see new items or line items added to the module. If you've used Show, the new item will not appear.
Let's say I have a module with 5 line items and I only want to see line items 1, 2, and 5. In this example, I choose to hide line items 3 and 4. If I were to add a new line item to this module I will see that new line item appear. In this same senario, if I were to select to Show line items 1, 2, and 5, I would not see the new line item appear. I could also reorder the line items with the Show functionality if I wanted to. The other difference is that by using Show you can change the order of the items based off of the order that you select them.
Try this: Select multiple line items by holding down Command (Mac) or Control (Windows), and then right-click or choose the drop down option and click on Show Selection. The line items will appear in the order you selected them.
We explain here a dynamic way to filter specific levels of a hierarchy. This provides a better way to filter & visualize hierarchies.
This tutorial explains how to calculate the level of a list in a hierarchy in order to apply specific calculations (custom summary) or filters by level.
In this example we have an organization hierarchy of 4 levels (Org L1 to Org L4). For each item in the hierarchy we want to calculate a filtering module value that returns the associated level.
Context & Notes
This technique addresses a specific limitation within dashboards where a composite hierarchy's level cannot be selected if the list is synchronized to multiple module objects on the dashboard.
We show the technique of creating a static filtering module based on the levels of the composite structure.
The technique utilizes the Summary method Ratio of line items corresponding to the list levels to define the value of the filtering line items. Note that it is not a formula calculation but a use of the summary method Ratio applied to the composite hierarchy.
We defined in this example a 4-levels list as follows:
Defining the level of each list
In order to calculate the level of each item in the lists, we need to create a module that calculates it by:
Creating as many line items as level of hierarchy + one technical line item.
Changing the settings in the blueprint of those line items according to the following table:
Summary method Setting Ratio
Technical line item
Level or L4 (lowest level)
L3 / Technical
L2 / Technical
L1 / Technical
L1 / Technical
When applying these settings, the calculation module looks like this:
*Note that the Technical line item Summary method is using Formula, Minimum Summary methold can be used but will return an error when a level of the hierarchy does not have any children and the level calculated is blank.
We can now use the line item at the lowest level (“Level (or L4)” in the example) as the basis of filters or calculations.
Applying a filter on specific levels in case of synchronization
When synchronization is enabled, the option “Select levels to show” is not available. Instead, a filter based on the level calculated can be used to show only specific levels.
In the example, we apply a filter on the level 4 and 1:
This gives the following result: