-
How I Built It: Method for branched development within ALM
Author: Noah Jackson is a Certified Master Anaplanner and Principal Data and Insights Architect at Anaplan.
Hello Anaplan Community!
Since the release of the “unlink revisions” feature, it is possible to do branched development within Anaplan ALM. This is most useful when you are beginning work on a larger change or new feature, but want to retain the ability to sync small maintenance changes or hotfixes to production without interrupting the new development work. Below I share a write-up on this topic and below that, a video overview.
The method will use two Dev models; I’ll refer to them as the “Maintenance” Dev and the “New Build” Dev. Changes can be synced from Maintenance Dev to Prod, and then when the new development in the New Build Dev is ready the Prod can be switched over to it. The video below explains the method and some background to it, but for easy reference I will also detail it in text here.
First it is important to understand the limitations:
This method will not merge changes between the two Dev models. The structural changes from Maintenance Dev will be removed, and the Prod model will be fully synced to the New Build Dev. Any changes made in the Maintenance Dev that are needed moving forward will need to be replicated in the New Build Dev.
Additionally, even if the hotfix line items are replicated identically in the New Build Dev, when you switch branches the process involved will delete and then re-create them. This has potential negative impacts:
* If the hot-fix line item is non-formula and has data entered into it, that data will be cleared
* The hot-fix line items may disappear from UX pages depending on how they are displayed
To reduce the risk of lost data and duplicated work efforts caused by those limitations, the timing for switching to the New Build Dev should not be too long and the work in the Maintenance Dev before then should be limited to minor changes. Additionally, when you are ready to sync the New Build you should sync to a UAT model first and look for these impacts and make a plan to address them.
Instructions for branched development
Assuming a starting state of one Dev model, one UAT model, and one Prod model, all on revision tag R1. The exact model names and revision tag names are not critical, as long as you use clear naming to avoid confusion. This can be done without a UAT model but it is not recommended.
* Make a copy of Dev named Dev MAINTENANCE, then change the name of the original model to Dev NEW BUILD. Begin development of the larger change or new feature of the model in Dev NEW BUILD.
* When minor hotfixes or model maintenance needs arise, build them in Dev MAINTENANCE and sync to UAT / Prod as normal, using revision tag R2, R3, etc.. Keep track of these changes so that any relevant ones can also be built in Dev BRANCH.
* When the Dev NEW BUILD new feature is ready for release, create revision tag Branch1
* Then prep UAT model to sync:* Take UAT out of Deployed mode, set into offline mode.
* Use History menu to identify a point in the model after R1 revision tag and before R2. Restore back to that point, and make sure "Unlink Revisions" is checked.
* Do a second History restore back to the "present" (i.e. last normal history ID), again making sure “Unlink Revisions” is checked.* After this action, the model should be identical to the state it was in Step A except that the tags for R2, R3, etc. no longer exist in Revision tags settings area.
* Use "Revert to Last Revision" to set the structure back to R1, while retaining all production data that has been entered since then in the rest of the model.* If the production data in the model is easy to re-import or does not need to be preserved, you can skip Steps C and D and sync immediately after Step B.
* Put UAT model back into Deployed mode, then sync Branch1 revision tag from Dev NEW BUILD into UAT
* Examine the UAT model to confirm that the changes synced correctly, and identify anywhere that cell data in hotfixes may have been cleared or lines may have disappeared from the UX. Record any cell data in those corresponding lines in Prod that needs to be preserved.
* Repeat Step 4 with the Prod model. Set the Prod model back online once all changes have been verified.
* The Dev MAINTENANCE model will now be incompatible with UAT and Prod, so should be locked and/or archived. The Dev BRANCH should be renamed to Dev and used as the singular development model going forward.
Video tutorial
https://play.vidyard.com/iyFeskPpNooYAdKYhcMiqj
I’d love to hear your thoughts on the method, how you might use it and/or any questions you have!
-
UX best practices for building impactful dashboards in Anaplan: Part 1
Author: Arjun Gandhi, Certified Master Anaplanner with over a decade of experience leading enterprise Anaplan implementations across industries.
———-
“If your dashboard doesn’t tell users what to do within 10 seconds, it’s already failed.”
🧭 Introduction: Why UX design in Anaplan matters
Anaplan’s UX is more than just the surface layer of your model — it’s the gateway to planning adoption, collaboration, and decision-making. Whether it’s a CFO reviewing revenue trends or a territory planner inputting quotas, your dashboards are the interface through which users interact with your logic, assumptions, and outcomes.
Despite powerful back-end models, poor UX can cause users to:
* Feel overwhelmed by too much data
* Make errors due to unclear inputs
* Miss insights due to poor visual structure
* Abandon the tool altogether
As a Master Anaplanner with over ten years of experience deploying and scaling enterprise models, I’ve seen one truth hold everywhere:
“If your dashboard doesn’t tell users what to do within 10 seconds, it’s already failed.”
This guide is divided into two parts, and walks through essential UX best practices in Anaplan — covering layout, inputs, interactivity, and visual clarity. You’ll get practical guidance with direct links to official documentation so you can apply changes immediately, with confidence. Look for part two later this week.
I’ll share proven UX best practices from over a decade of real-world model building and enterprise enablement. Whether you’re an experienced model builder or just starting to design dashboards, these tips will help you deliver smart, scalable, and beautiful user experiences in Anaplan.
In part one, I cover:
* Choosing between Boards, Worksheets, and Reports
* Optimizing layouts with page sections and context
* Field cards, descriptions, and instructional guidance
* Formatting to focus user attention
Ready to build dashboards your users will love? Let’s begin.
🧱 Section 1: Choosing between Boards, Worksheets, and Reports
Anaplan’s UX offers three types of pages: Boards, Worksheets, and Reports. Each serves a unique purpose and should be used intentionally depending on your audience and the type of interaction required.
Page Type
Best For
Pros
Considerations
Board
Executives, summary consumers
Great for visual storytelling, combining charts, KPIs, and grids
Not ideal for editing large data sets or lists
Worksheet
Analysts, operational users, planners
Enables in-line editing, filtering, quick access to related data
More functional than visual; needs guidance for usability
Report
Presentations, print-outs, formal reviews
Supports formatted slides and narratives
Static—no interactivity or real-time filtering
🔍 When to Use Each
* Use a Board when you want to deliver insights at a glance — ideal for decision-makers. Boards let you combine KPIs, charts, and narrative to tell a story or track performance.
* Use a Worksheet when your user needs to interact deeply with data — think detailed forecasting, manual overrides, or list-based planning. Worksheets offer filtering, context panes, and editable grids.
* Use a Report when you need a clean, printable or presentation-friendly output — great for monthly business reviews or board decks.
Additional resources in Anapedia:
📘 Learn more about Boards
📘 Explore Worksheets
📘 Create Reports
🧩 Section 2: Structuring pages with sections, context, and categories
Designing a useful UX page goes beyond just placing cards. The structure and context of your page determine how easily your users can process information and complete planning tasks. To optimize user flow, you should strategically use page sections, context selectors, and application page categories.
✅ Use page sections to group content with purpose
Dividing content into distinct page sections — like “Top KPIs,” “Input Forecast,” or “Review Assumptions”—creates natural breakpoints and focuses user attention.
This modular structure allows you to:
* Visually separate decision points
* Simplify navigation across content types
* Reinforce logical planning flow
Best practices:
* Add only what’s necessary; don’t create clutter with unused section space.
* Keep each section to a single use case — don’t mix inputs, outputs, and actions.
* Use clear titles to guide the user's thought process.
Steps to add a section:
* Enter Designer Mode on a UX page.
* Hover between cards and click “Add Section”.
* Label the section meaningfully and begin adding relevant cards.
Additional resource in Anapedia: 📘 Create a page in the User Experience
🗂️ Leverage Application page categories
When creating pages, Anaplan allows you to assign them a category to reflect the type of planning activity they support. This helps both model builders and end users quickly understand a page’s function in the broader application.
Common page categories:
* Planning: for day-to-day data entry and driver adjustment
* Reporting: for visualization and KPI tracking
* Review: for historical comparison or what-if outcomes
* Workflow: for submission, approvals, or process control
Categorizing pages:
* Helps with sorting and navigation inside the app
* Clarifies intent for the user before they open the page
* Reinforces UX consistency in large applications
Recommendation: Always set a category when building a page — it shows up in the app’s side navigation and improves clarity at scale.
🎯 Configure context selectors thoughtfully
Context selectors filter content by dimension — like Region, Product, or Time — and appear at the top of the page. These should be configured to simplify, not overwhelm.
Best practices:
* Minimize selectors to those that matter for this page
* Fix dimensions when possible (e.g., always show “Current Year”)
* Synchronize selectors across cards so users don’t need to reselect
* Clearly label selectors, especially if multiple are present
Additional resource in Anapedia: 📘 Configure context selectors in apps and pages
💬 Section 3: Field cards, descriptions, and instructional guidance
Even the best dashboards fail when users don’t know what to enter, where, or why it matters. That’s where field cards, descriptions, and embedded guidance become essential. This section is about turning your UX pages from passive displays into interactive, intuitive experiences.
📝 Use field cards for targeted inputs
Field cards are a powerful, flexible way to surface inputs — especially when you want a single value editable directly on a board or worksheet.
Use cases include:
* Adjusting an assumption like “Growth %” or “Discount Rate”
* Setting scenario toggles or flags
* Capturing simple annotations (e.g., “Manager Comment”)
Why field cards work well:
* They’re compact and visually distinct
* You can add data validation logic behind them
* They prevent accidental grid edits by isolating the input
Additional resource in Anapedia: 📘 How to use a field card
💡 Add descriptions to guide user action
Field cards, KPIs, grids, and charts can all include card descriptions—short text that appears on hover or next to the card title. These can serve as inline help, task instructions, or policy references.
Example:
“Use this input to set Q4 price assumptions. Defaults pulled from Actuals Q3.”
Best practices:
* Be clear and concise (1–2 sentences max)
* Use descriptions to answer “what am I supposed to do here?”
* Standardize tone across all cards for professionalism
Additional resource in Anapedia: 📘 How to configure a field card (includes description setup)
🧠 Bonus tip: Instructional-only sections
If your page contains advanced logic, consider adding a dedicated info panel or instructional section using text or field cards. This reinforces the model’s business logic and helps with onboarding new users.
You can even include:
* Model assumptions
* Version control notes
* Hyperlinks to SOPs or external docs
🎨 Section 4: Formatting to focus user attention
Great dashboards don’t just display information — they guide the eye and signal what matters. With the right formatting, users can instantly identify what needs attention, where to act, and how to interpret results without getting lost in a sea of numbers.
🟥 Apply conditional formatting to highlight decisions
Conditional formatting allows model builders to visually emphasize data based on logic—like alerting users when a forecast exceeds budget or a metric is outside its tolerance range.
When to use it:
* Flag high/low variances (e.g., over 10%)
* Color-code input status (e.g., incomplete = red)
* Surface issues like missing assumptions or late submissions
Best practices:
* Avoid color overload: limit to 2–3 conditions per card
* Use consistent logic across pages (e.g., always use red for errors)
* Preview conditional logic in context with real data
Additional resource in Anapedia: 📘 Apply conditional formatting
📊 Style grid rows, columns, and summaries for clarity
Grids are one of the most frequently used components in Anaplan UX — make sure they’re clean and scannable.
Styling options include:
* Bold row headers to distinguish hierarchies (like regions or products)
* Alternate row shading to improve readability
* Distinct summary rows with border lines or highlight formatting
This kind of styling helps users:
* Differentiate parent vs child rows
* Quickly find totals and key calculations
* Avoid accidental edits by identifying read-only rows
Additional resource in Anapedia: 📘 Set the style of grid card rows and column headers
🖍 Quick formatting wins
* Use pale yellow or soft blue as background for editable cells
* Style read-only data with light gray or muted formatting
* Place important KPIs in their own card with bold, large font
* Separate input sections from output sections visually on the page
📌 Pro tip: Always test formatting in dark mode and light mode to ensure accessibility for all users.
Conclusion of part one
Stay tuned for part two, in which I’ll cover:
* Dynamic Cell Access (DCA) and visibility control
* Scaling UX with consistency and reuse
* Mobile optimization and responsive design
* Polaris UX considerations and exclusive capabilities
* User feedback and iterative UX improvement
Questions? Leave a comment!
-
UX best practices for building impactful dashboards in Anaplan: Part 2
Author: Arjun Gandhi, Certified Master Anaplanner with over a decade of experience leading enterprise Anaplan implementations across industries.
Anaplan’s UX is more than just the surface layer of your model — it’s the gateway to planning adoption, collaboration, and decision-making. Whether it’s a CFO reviewing revenue trends or a territory planner inputting quotas, your dashboards are the interface through which users interact with your logic, assumptions, and outcomes.
This guide is divided into two parts, and walks through essential UX best practices in Anaplan — covering layout, inputs, interactivity, and visual clarity. You’ll get practical guidance with direct links to official documentation so you can apply changes immediately, with confidence.
If you missed Part 1, you can find it here. It covers four ideas:
1. Choose between Boards, Worksheets, and Reports
2. Optimize layout with page sections and context
3. Field cards, descriptions, and instructional guidance
4. Formatting to focus user attention
In Part 2, we’ll cover ideas five through nine:
5. Dynamic Cell Access (DCA) and Visibility Control
6. Scaling UX with Consistency and Reuse
7. Mobile Optimization and Responsive Design
8. Polaris UX Considerations and Exclusive Capabilities
9. User Feedback and Iterative UX Improvement
Let’s get started.
🔐 Section 5: Dynamic Cell Access (DCA) and visibility control
An intuitive UX isn’t just about what users see, it’s about what they shouldn’t see or touch. That’s where Dynamic Cell Access (DCA) plays a critical role. It allows model builders to define exactly when and where users can read, write, or hide specific data points — all based on logic within the model.
🔒 What is Dynamic Cell Access?
DCA lets you control cell-level visibility and edit-ability using Boolean logic (TRUE/FALSE values). Rather than blocking access to an entire module or list, you can tailor it with surgical precision.
This is vital for:
* Preventing accidental edits to actuals or locked periods
* Displaying override inputs only when needed
* Securing sensitive values by user role or approval status
Example scenarios:
* A field is editable only if the current version = “Forecast” and a “Planning Open” flag is TRUE
* A manager sees override fields only after the analyst completes their input
* Read-only summaries are shown, but input cells are hidden from unauthorized users
Additional resource in Anapedia: 📘 Dynamic Cell Access (DCA) – Anaplan Documentation
🧠 Why DCA matters for UX
When applied correctly, DCA enhances the user experience by:
* Reducing noise: Hiding unnecessary or irrelevant inputs
* Protecting data integrity: Preventing changes to finalized values
* Clarifying responsibilities: Users see only what they are expected to interact with
Combined with conditional formatting and card descriptions, DCA enables intelligent UX that adapts to context, decision logic, and user roles.
Best practices:
* Name DCA line items clearly (e.g., Write Access - Forecast Only)
* Test thoroughly across roles and versions
* Pair DCA with visual cues (e.g., gray formatting for locked fields)
🚀 Section 6: Scaling UX with consistency and reuse
As Anaplan implementations expand across various use cases, models, and business units, maintaining a consistent and scalable UX becomes essential. A well-designed UX not only enhances user experience but also simplifies maintenance and promotes adoption.
🧩 Standardize UX patterns
Consistency across dashboards ensures that users can navigate and interact with different pages without confusion. Establishing standard UX patterns helps in:
* Card layouts: Maintain uniformity in placing inputs, outputs, and KPIs.
* Naming conventions: Use clear and consistent naming for pages and cards.
* Context selectors: Position selectors consistently across pages.
* Section titles: Use standardized titles for similar sections across different pages.
* Formatting styles: Apply consistent styles for fonts, colors, and grid layouts.
Implementing these patterns facilitates easier onboarding for new users and streamlines the development process for model builders.
🧠 Reuse pages and templates
Leveraging existing pages as templates can significantly reduce development time and ensure consistency. You can duplicate pages to:
* Create similar planning cycles (e.g., Q1, Q2, Q3 forecast input pages).
* Develop role-specific views (e.g., Manager vs. Analyst dashboards).
* Replicate layouts for new models that follow a similar structure.
How to duplicate a page:
* Navigate to the app containing the page you want to duplicate.
* Hover over the desired page and select the ellipsis (...).
* Choose Duplicate page from the dropdown menu.
Additional resource in Anapedia: 📘 Duplicate a page
🔄 Move pages between Apps
Organizing pages within appropriate apps enhances clarity and user navigation. Moving pages allows you to restructure your UX as your organizational needs evolve.
How to move a page:
* Open the app containing the page you wish to move.
* Hover over the page and select the ellipsis (...).
* Choose Move page and select the destination app.
Additional resource in Anapedia: 📘 Move a page
🛠 Design for maintenance
A scalable UX is one that can be easily maintained and updated. Consider the following practices:
* Group cards by data source: Organize cards based on their source modules for easier updates.
* Include "Last Updated" indicators: Display timestamps to inform users about the freshness of data.
* Implement a UX QA checklist: Regularly review pages for consistency, functionality, and performance.
👥 Empower power users
Design your UX to enable power users to:
* Filter and explore data: Allow users to customize views to their needs.
* Conduct what-if analyses: Provide tools for scenario planning and forecasting.
* Navigate seamlessly: Ensure intuitive navigation between dashboards and detailed views.
By creating a user-centric UX, you foster an environment where users can confidently interact with the platform and derive actionable insights.
📱 Section 7: Mobile optimization and responsive design
As business becomes increasingly mobile, users expect their planning tools to work seamlessly on the go. Whether it's a sales executive reviewing pipeline or a regional planner entering forecast updates from the field, Anaplan's UX must adapt.
While the Anaplan Mobile App provides responsive rendering, your design choices still directly affect usability across devices.
📐 Design with mobility in mind
Mobile screens demand simplicity, stackable layouts, and minimal interaction friction. You should build UX pages that anticipate tap-based navigation and tighter screen real estate.
Design guidelines for mobile-friendly pages:
* 🧱 Use vertical layout orientation: Stack cards logically from summary KPIs → charts → inputs
* 👆 Avoid wide tables: Grids with horizontal scroll are hard to use on small screens
* 🔢 Minimize visual noise: Fewer sections and cards are better for scanability
* ✅ Prioritize read-only views: Editing is limited on mobile — design for consumption
Additional resource in Anapedia: 📘 Best practices for building UX for mobile
🧪 Test on multiple devices
Before publishing a new dashboard, validate the experience across form factors:
* 🧭 Use Page Designer's device preview to simulate tablet and phone
* 🧍♂️ Ask mobile-heavy users (sales, execs) to test interactions live
* 🔄 Consider creating mobile variants of key dashboards for performance and readability
🔄 Build for touch, not click
* Replace dropdowns with selectors
* Use charts or KPIs for quick views, rather than full grids
* Increase card spacing to allow easy tapping
Remember, your mobile dashboard should answer this question:
Can the user get what they need in under 15 seconds, without zooming or scrolling sideways?
✨ Section 8: Polaris UX considerations and exclusive capabilities
The Polaris Calculation Engine isn’t just a back-end performance upgrade — it opens up new possibilities for UX design. Polaris enables deeper, denser planning models without sacrificing speed, and offers exclusive features like zero suppression, which directly influence how users experience data.
If you're designing UX for a Polaris model, you can create cleaner, more responsive, and more powerful dashboards by leaning into what Polaris does best.
⚙️ What Polaris unlocks in UX
Here are some key capabilities in Polaris that enhance dashboard design:
Capability
UX advantage
Zero suppression
Hides rows/columns with no data — automatically simplifies views
High-dimensional modeling
Enables broader planning combinations (e.g., product x region x version)
Faster sparse calculations
Lets you expose more granular inputs without sacrificing performance
No need for fake hierarchies
Cleaner list structures = cleaner UX logic
Additional resource in Anapedia: 📘 Polaris Calculation Engine overview
🧠 UX design best practices in Polaris
To get the most from Polaris in the UX layer:
* ✅ Use zero suppression: Automatically hide zero-value intersections to reduce scroll and noise. Additional resource in Anapedia: 📘 Suppress zeros in Polaris
* 🧱 Expose more granularity: Since Polaris handles sparsity efficiently, you can show more detailed views — like SKU-by-region — without performance penalty.
* 🔁 Avoid workarounds for hierarchies: Polaris lets you build natural, deep lists. This simplifies filtering and navigation in UX pages.
* 🔒 Leverage DCA without overhead: Polaris processes logic more efficiently, so you can apply cell-level controls (via DCA) even in large views.
✨ Example use case
In a traditional engine, exposing a 4-dimensional revenue planning grid would tank performance. In Polaris, you can build a page that shows Customer x Product x Region x Scenario, apply Zero Suppression, and still deliver real-time interaction.
🔄 Section 9: User feedback and iterative UX improvement
A great UX isn't just built — it's evolved. Your first version may meet the spec, but only real-world usage reveals where your dashboards shine or fall short. The best Anaplan teams treat UX as a living product, improving it based on ongoing feedback and usage patterns.
👂 Gather feedback from real users
Insightful feedback isn’t just about surveys, it’s about watching how users interact and where they hesitate or make errors. Bake feedback into your design cycle with these methods:
* 🎥 Observe real usage: Sit in on planning sessions or record walkthroughs
* 🧭 Ask simple questions: “What are you trying to do here?”, “What confused you?”
* 🗣️ Create feedback modules: Add comment fields on dashboards for in-app suggestions
* 📊 Use audit events to infer engagement: Review user activity logs to understand who’s interacting with what
Additional resource in Anapedia: 📘 Tracked User Activity Events (Audit)
♻️ Iterate like a UX product manager
UX is not a one-and-done activity. Use agile cycles to continuously release improvements:
* 🧹 Simplify interactions with each revision — fewer clicks, clearer steps
* 🆕 Label changes clearly: A “What’s New” card helps users reorient
* 📅 Schedule UX review cycles quarterly or biannually
* 🧪 Try A/B testing of page layouts or visual styles when usage is unclear
🛠 Use a UX QA checklist before going live
To reduce user frustration and rework, validate each page before release:
* Are all context selectors scoped appropriately?
* Do DCA rules behave correctly across roles?
* Is conditional formatting triggering as intended?
* Does the page render cleanly on mobile and tablet?
* Are labels, tooltips, and field descriptions present and helpful?
When feedback loops are tight and users feel heard, adoption goes up, errors go down, and the UX becomes an asset, not a bottleneck.
✅ Conclusion and wrap-up
A high-performing Anaplan model doesn’t succeed on logic alone — it succeeds when users engage, understand, and act. That’s the power of great UX. Whether you’re building for finance, supply chain, sales, or HR, your dashboards are the front line of planning.
Throughout this guide, we’ve explored how to:
* Choose the right page type (Boards, Worksheets, Reports)
* Structure content using page sections and context
* Make inputs intuitive with field cards and descriptions
* Drive clarity with conditional formatting and grid styling
* Control access and flow using DCA
* Build mobile-responsive pages for on-the-go decision-making
* Leverage Polaris-exclusive features like Zero Suppression
* Scale your UX with reuse and consistency
* Continuously improve with user feedback and audit data
“If your dashboard doesn’t tell users what to do within 10 seconds, it’s already failed.”
That quote captures it all: good UX isn’t optional — it’s how you turn planning models into business outcomes.
💡 Final tips from the field
As a Master Anaplanner who has worked with global enterprises for over a decade, here’s what I’ve learned:
* Treat UX like a product: it should evolve with user needs.
* Less is more: don’t overcrowd pages with logic or visuals.
* Design for how people work, not just how models calculate.
* Invest in UX early: it pays dividends in adoption and trust.
……………
👤 About the author
Arjun Gandhi is a certified Master Anaplanner with over 10 years of experience architecting, deploying, and enabling enterprise-wide planning solutions across industries. He specializes in large-scale UX design, connected planning strategy, and performance optimization.
-
Using Left for Different Number of Characters
I have account strings that are separated by a different number of characters for each string. I need to pull everything left of a colon ":" to get the first piece of the account strings. Some of the accounts are 3 characters and some are 4. Ex. AAA:BBB:CCC; AAAA:BBB:CCC. I need to pull all the A's for everything left of the first colon. How would I do this?
-
How to set a unique code based on Store/date information ?
Hi everyone,
Does anyone know how I can generate a unique code by Store/date combination, knowing that the date is a current date that will be changing every day, it's going to be the order ID and and it going to have to start by a #:
Thank you for the help :)
-
Has anyone taken a stab at Master Anaplanner Recertification exam yet?
Just curious :)…
-
Design standards for a superior user experience — Part 2: UX page standards
Author: Aaron Overfors is a Certified Master Anaplanner and Principal Architect at Spaulding Ridge.
In my first article, we detailed how to create a robust design for the user experience; now comes pulling it all together and building the actual pages! We will examine the concepts and ingredients of a strong page to focus your users, as well as techniques and approaches to avoid in order to not cause confusion to them.
Dashboard layout
To begin, it is generally best to have a defined starting point or Landing Dashboard, depending on the role type. Landing dashboards should have a hub-and-spoke approach to allow users to take action where necessary and easily return to a summarized view.
Generally, dashboards should help the end users to draw insights from the model and provide the means to do their jobs intelligently and easily.
* Create a clear navigation path for end users. Start with a landing dashboard that links to the next dashboard/step within the process. Numbering the dashboards helps users know where they are and what is next in the process (if there is a linear flow to the business process).
* Be consistent. If users are used to seeing a title, instructions and logo on every dashboard ensure every dashboard contains a title, instructions, and logo. This is visually more appealing and will allow users to feel more comfortable working within the tool.
* Clear instructions will prevent future headaches and reduce questions. Determine a format for instructions and consistently place those instructions on every dashboard near the very top.
* Generally, a tops-down and left-to-right flow to dashboarding works very well. Start with a high level and progress to more detail as they move down and to the right through the dashboard.
* The ultimate test of sound dashboard layout is whether someone who is unfamiliar with Anaplan can open the dashboard and use it without struggling. This should be the goal. It does not matter how great the architecture is and how impressive the functionality is; all your hard work will fall short if the final product (dashboard) is viewed as clunky and confusing. Dashboards are the ultimate object with which end users interact and what they use to form an impression of the tool.
* Additional tips:* Real-time data synchronization vs planned data imports should be clearly indicated if both exist on a dashboard (or even within the App).
* If two models exist within the same application, indicate that model 1 does not feed model 2 automatically (real-time).
Specific starting point
* The layout of the page should clearly convey and communicate where the user should start on the page and the intended points of interest/order an end user should follow to complete their given tasks on the page.
* There should be page and card grid titles that indicate the specific purpose of a page and card grids.
Specific areas of focus and actions to take
* It should be clear what data needs to be understood and what actions need to be taken based on the page which the user is on.
* Therefore, end users should be able to clearly and quickly understand what their roles and tasks are on the page. Whether it be for analyzing data, inputting data, or running actions.
* There should be a clear definition of which roles will be users of a page.
* A good test is to see if a page can be explained in a concise sentence.
Page instructions
* Each page should provide clear, concise instructions of what an end user will need to do and what steps they should take to fully utilize the page.
* For smaller pages, instructions near the top of the page will suffice. For a larger page with multiple points of interest, multiple instruction cards may be helpful, placed near their intended grid/card/module.
Visualizations appropriately placed
* Typically, each board should have data visualization components which allow end users to quickly assess and understand data/inputs.
* Visualization can include a degree of subjectivity, so model builders should communicate with end users on what they would like to see.
Elements should be presented clearly
* Titles on grids (rows/columns) should not be cut off.
* If the contents of a grid can be displayed in a reasonable amount of space, expand the vertical height to display the entire grid so an end user does not have to scroll within the grid.
* Chart legends should clearly display all items.
* Chart axes should be cleanly labeled.
Image: User experience schema
Common dashboard mistakes
* Too many charts or unorganized grids creates visual clutter.
* Basic questions such as “what is the total amount of sales?” take much more than 5 seconds to answer.
* No organizing principle behind the visual layout — cards seem to be strewn randomly.
* Tables in the bottom add very little business insight.
Review the below example:
Some problematic design aspects in this dashboard:
* There are no instructions or labels, which makes the purpose and function of the dashboard unclear.
* There is no focal point for the user, so it will take time to review the dashboard and figure out how it should be used.
* There are card titles, but no headers or dividers to help organize the dashboard.
* The layout does not intimate a flow, which makes it difficult to tell which steps are next.
* The title is on the far left and is not fully displayed leading to a scroll bar to be show on the card.
* There are missing images on the dashboard, missing card dimension labels and card titles.
* There are random images that do not align to the content of the dashboard.
* The colors don’t match across the dashboard and should be consistent between titles, grids, and charts.
Takeaway
Remember that effective dashboarding allows for a smooth user experience and tells a comprehensive story across the app as it enables its constituent business users to perform their planning functions. Each UX page should have a meaningful part of that planning story and be clear, concise, and purposeful in its objective. Simplicity is key; a high volume of dashboards in an App typically comes from a lack of proactive planning on their collective purpose. Purposeful planning of the UX typically results in fewer but more impactful pages, allowing planners to do what they need to do most effectively in an efficient manner.
What tips would you add? Leave a comment!
-
How I Built It: Number format converter (thousands and millions)
Hello Anaplanner Community! I’m excited to participate in another ‘How I Built It’ video with a Number Format Converter (thousands and millions) tutorial.
This video walks you through how to dynamically update UX grid number formats on all tables and charts. This enables users to have different number formats enabled for each line item.
Key features:
* Users can choose which line items they would like to see numbers in thousands or millions.
* Allow users to easily see larger values in small Anaplan UX grids.
* You can design for each line item you would like to have this for.
* Check out my idea in the Idea Exchange and upvote: Number scale line item format.
https://play.vidyard.com/dDXJDFqms1HSkfNC2aG7Jc
I have another ‘How I Built It’ tutorial on dynamic month, quarter, and year filters here.
All the 'How I Built It' tutorials can be found here.
…….About the Author: Arjun Gandhi is a Co-Founder and Certified Master Anaplanner at Tekplanit and has been in the Anaplan ecosystem for 8+ years. He has deployed hundreds of applications across 16+ industries for finance, supply chain, and sales use cases.
.png){kind=icon}
