Board Page vs Worksheet Page?
The new user experience provides two different types of layouts. A model builder's first step is to decide whether to build something as a board or a worksheet. It might seem as though this is a big decision to make at the outset, but it becomes clear almost immediately when to use each type of page. The other important thing to remember is that it's really quite simple to build things out in the new user experience, so when in doubt, you could always build something as a board and as a worksheet, and then decide which one is the best fit.
If you are redesigning an existing dashboard, before jumping in take a step back and think through the purpose of the dashboard. Write down the user story that the dashboard is trying to accomplish. This will help you to determine which elements are necessary to include and what type of page it needs to be.
Let's take a deeper dive into the types of pages and when to use each one.
You can think of this as a standard business intelligence dashboard.
They should be used for things like...
- KPI review
- Graphical, visual reporting
- Viewing data
- Reviewing related data from multiple modules
- Call-outs of specific metrics
- Landing dashboards
They should NOT be used for ....
- Reviewing large data sets
- Editing large data sets
- Inputting multiple rows of data
Board pages can hold anywhere from one to many pieces of information. The information shows up as cards (be it KPI cards, grids, graphs, or text) and can be easily rearranged within the screen. When building a board page make sure the cards you are including on the page are related to one another. Be careful to include only the most important information and not to overwhelm users with too much to choose from. You can always use navigation between pages to access related information. Any card can be linked to another page; the link is activated by simply clicking the title of the card.
You can think of this as highlighting a specific module where an end user can edit data or complete planning activities.
They should be used for things like...
- Entering or editing data within a module
- Reviewing large, detailed, data sets
- Filtering large data sets
- Running actions on data sets
They should NOT be used for ...
In addition to choosing the main module for the worksheet, the side context panel provides loads of extra functionality:
- Related Information - Additional modules (or views from the same module) can be linked using the "related information" option. When a user opens a grid view from a related content module, it appears below the primary grid on the worksheet. Only one related content module can be displayed at a time, but multiple view/modules can be listed as related content. Think about where your users perform 80% of their work and make this the primary worksheet grid; the related content should be linked to any input overrides or assumptions that affect the primary grid, for example.
- Go To (Navigation) - Set up links to other related worksheets or boards within the UX app. If a user opens a navigation link from the context panel, the UX will take them away from the current worksheet and directly to the linked page. The user can then return to the original worksheet using the back arrow next to the page name or by using the breadcrumb navigation dropdown on the top of the screen.
- Cards - Add any type of card (KPI, grid, graph, text) that might be related. Here are a couple ideas for context panel cards:
- Show a graphical representation of an important KPI from the primary grid view. This could be a trend or variance chart, for example.
- Use a text card to add information, directions, or links to an external URL.
- Use a grid card for user-based filtering.
- Use a grid card to show properties for specific list items (i.e., if you have products in the primary grid, the grid card could list out the product attributes).
As a recap, you can use the table below as a simple way to determine which type of page to use. Remember, this is just a guide, and you will encounter user stories could be built in either page type.
|Will end users want to...||Board||Worksheet|
|Review high level KPIs||X|
|Review high level data||X|
|See advanced formatting or charts||X|
|Compare data from multiple modules||X||X|
|Review detailed data||X|
|Edit large data sets||X|
|Filter large data sets||X|
|Drill down to detailed data||X|
I second @Misbah comment.
Also, I really like how you simplified the decision making process.
One question I'm constantly asked is whether a board or worksheet is better for the mobile app? Seems like the board is the way to go for now since it's mostly read-only but was wondering what you thought.
Thank you for creating this. I'm linking your best practice to my favorites.1
Great article @Fwolf !
What would be the implication of using a board instead of a worksheet in cases where you advised (above) against it? Is the impact more on the user experience, or will the page load/run slower? For example, suppose I used a board instead of a worksheet for inputting/viewing multiple rows of data - is the worksheet a better option because the page loads faster?
I tend the think the same way as you do, its not so comfortable for anyone to review or edit large datasets via mobile. We should discourage use of worksheet pages in mobile.
Mobile pages are handy to quicly get a summary or a KPI, not for detailed planning
You have the right idea, the impact will be on the user experience. Worksheet Pages are designed with the concept of having a large grid of data to manipulate so naturally they are a great selection for this.
Over time the functionality of boards and worksheets has evolved with new features. One example is being able to maximize a card, using this functionality makes it easier to make edits in a grid that may have been too large in the past to edit on a Board Page. The above table still holds true but with the enhanced features that have been released page builders can start to use both Board and Worksheet pages interchangeably.0
Great clarification - thanks!0