AirtableProduct Thinking6 min read

One table, many opinions about it

Views let a team disagree about layout without forking the data.

The surface: Starting from a template, typing fields into a grid, and creating kanban, calendar and form views over the same table.
What the user wants: I want a shared system for tracking our work without asking engineering to build one.

The template gallery

New users can start from a prebuilt base for a recognisable use case, arriving at populated tables with sensible field types rather than an empty grid.

Example over instruction

A blank relational database is a worse starting point than a spreadsheet, because the user has to invent a schema before they can type anything. A populated example lets them learn by deleting and editing, which is a much cheaper mode than designing. It also demonstrates field types they would never have discovered from a menu.

The grid that looks like a spreadsheet

The default view is rows and columns with in-cell editing, matching the interaction model of a tool nearly every knowledge worker already knows.

Borrowed mental model

Familiar surface makes an unfamiliar engine approachable. The user believes they are using a spreadsheet, which means they start typing instead of reading documentation. The database concepts are introduced later, once there is data worth structuring.

Field types as constraints

A column is declared as a single select, date, attachment, checkbox or link to another record, and the cell editor changes accordingly.

Constrain at the point of entry

The reason a shared spreadsheet degrades is that every cell accepts anything, so status becomes Done, done and DONE within a week. Typed fields make bad data hard to enter rather than something to clean later. The changed cell editor teaches the constraint without a rule anyone has to read.

Views over the same records

A view is a saved configuration of filter, sort, grouping and layout, and switching a table to kanban or calendar changes presentation while the underlying records stay single.

Separate presentation from the record

Teams fight about layout because in a spreadsheet the layout is the data, so one person's sort ruins another's. Named views let everyone have their own lens with no copies to reconcile. This is the feature that turns a spreadsheet replacement into a small internal tool.

Form view

A form view generates a fillable form from the table's fields, and submissions arrive as new records.

Turn the schema into an input surface

The hardest part of collecting structured data from colleagues is getting them to respect the structure. Deriving the form from the fields means the constraints are enforced at the moment of entry by someone who never opens the base. It also gives the base an audience beyond the person who built it.

Sharing a view instead of the base

An individual view can be shared with a link, exposing a filtered slice without granting access to the whole base.

Permission by projection

Row and field level permission systems are notoriously hard to understand, and users get them wrong. Sharing what you can already see is a model a non-admin can reason about correctly. It trades expressiveness for a permission decision people actually make accurately.

Views, or five diverging copies

When two teams want different layouts, the default move is to duplicate, and duplication is how the numbers stop agreeing by the end of the month. Views give each team their own arrangement while leaving exactly one set of records underneath.

What not to copy

Bases grow past the point where anyone understands them. There is no schema documentation, no migration story and no code review, so the person who built it becomes a dependency nobody planned for.
Record limits and per-seat pricing hit right when a base becomes load-bearing. Discovering the ceiling after a department depends on the tool is a bad moment, and the alternative at that point is a rebuild.
The spreadsheet disguise sets the wrong expectation for performance and formulas. Users arrive expecting Excel behaviour and hit different formula semantics and slower large-table interaction.
Views multiply without governance. A table with forty views has the same discoverability problem as the shared drive Airtable replaced.

The takeaway

When people fight over layout, check whether you can give them views instead of copies.

Finished the teardown? Bank it and the day counts toward your run.

Where the principles come from

The Design of Everyday Things (constraints), Don Norman
Badass: Making Users Awesome, Kathy Sierra
Progressive Disclosure, Jakob Nielsen, NN/g

Written from public behaviour of the product, not from inside it. Interfaces change often, so treat the flow described here as of the time of writing and check the live product before quoting it.