Overview 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. Common Mistakes 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: Key points: 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. Methodology 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 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. Dashboard structure 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 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 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. Example: 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 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 Vertical scroll 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 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 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. 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 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 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'
Overview 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).
Overview 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 Components: Title Viewpoint 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 Chart panels Display grid (below charts) Color coding 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:
Overview 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. Users 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 Acknowledgement Process 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. Impact Analysis: 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. Impact analysis: 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. Impact Analysis: 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. Avoid this: 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
Question 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? Answer 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.
Summary We explain here a dynamic way to filter specific levels of a hierarchy. This provides a better way to filter & visualize hierarchies. Overview 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. Example list 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: Line Item Formula Applies to Summary Summary method Setting Ratio Technical line item 1 (empty) Formula Level or L4 (lowest level) 4 Org L4 Ratio* L3 / Technical L3 3 Org L3 Ratio L2 / Technical L2 2 Org L2 Ratio L1 / Technical L1 1 Org L1 Ratio 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: