Design a delightful doc

Explore

Views
Views

Different users get different views. End users focus on taking action on their work and stakeholders see the big picture.

Different users get different views. End users focus on taking action on their work and stakeholders see the big picture.

Within

Tables⁠

, we were likely looking at a Base Table: a core data table that powers your doc. For example, if you have built a CRM, your base tables would be Companies, Contacts, and Activities. A Product Roadmap would have Products to Launch, OKRs, and Epics.

You then create Views that are portals into parts (or if you want, all) of the Base Table.

⁠

⁠

Base vs. View Table Principles

The rule of thumb is that you should leave Base Tables alone as they are. Think of them as tucked away, all-inclusive, tables that drive the rest of your doc (learn more in

Front / back stage⁠

Apply all your refining to Views:

Hides columns in Views, not Base Tables. Hide columns in views, but keep all columns available in the base table so that when you or others go to it, they can immediately understand the full breadth of the table. You can always hide columns in the views of the base tables. In the example above, we are Content, Lots of Content, Scale, and Number within the view but keeping them in the base table. More on

hiding columns⁠

Filter Views, not Base Tables. If you filter a base table, that filter will apply to all other views. Also, it's just confusing to come to a table that should include all of the data (your customers, all product launches) and you can't find them. More on

filters⁠

Sort Views, not base tables. This isn't that big of a deal, but can mess up filters and other queries sometimes.

Conditionally Format Base Tables, not Views so that all views can inherit those formats. Otherwise, you'll need to re-color each view. More on

conditional formatting⁠

⁠

Types of Views

A view is a place for different users and stakeholders to interact with the doc from their point of view. These views take two forms:

User View

Stakeholder View

User View

Give a home-base for users to add and view their data. Here's an example below of setting up a place for users to add a bug that they find in the software.

⁠

⁠

Makers often include the following components:

A how to that explains what actions you want to user to take.

An add row "form"

Create a

button⁠

in the canvas to add new rows (with includes user being auto assigned to the new row).

Right click the button to edit it

Create a modal adding experience if there are a lot of fields by turning Open Row for Editing on.

Use

Layouts⁠

by clicking on the three dots in the popup window and Custom Layout to customize this view

⁠

Change the information hierarchy by selecting the Quick Styles or by dragging and dropping the fields. Increase information density by placing fields side by side, especially if they relate to each other, users will be able to more quickly update and add data.

Hide fields (columns) that don't pertain to adding a new item so that you don't distract the user.

Turn off Comments & Activities.

Turn off Allow Viewing Hidden Columns

Create a button(s) to add / close / cancel the modal.

These are normally placed in the bottom right of the popup modal and the trick is to make it a hyperlink button that "opens" up the current section that the user is on.

A relevant view of the base table. This can be achieved by filtering down the table to just the

user's view⁠

hiding columns⁠

that don't pertain to the user, and making it time-based such as only showing items that have been added recently or are a certain status like "New."

⁠

You can find fully-built example here's:

Add new item user view⁠

⁠

⁠

Stakeholder Views

You can share a section of the doc / data with stakeholders that are Views so that they can focus on getting insight and understanding what's happening in the doc.

⁠

⁠

⁠

Makers often include the following components:

Summarize the data in an aggregate table through the

filter formula⁠

⁠

Charts⁠

are often the best way to visualize large amounts of data. Consider creating a chart for the summary table.

Add

Canvas controls⁠

to help these users play around with data without needing to go into the table / chart filters.

Put in a written section that summarizes the data in prose using normal paragraph writing mixed with

canvas formulas⁠

. Hint:

BulletedList⁠

formula is really magical.

The stakeholder view doesn't have to be in your core tracking doc. Use

Cross Doc⁠

to sync out data into another doc for groups you don't want (or who don't care) about your main hub.

Enable

Locking⁠

so that stakeholders don't accidentally delete the views.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

ViewsViews

Base vs. View Table Principles

Types of Views

User View

Stakeholder Views

Views
Views