---
title: What Airtable Figured Out
slug: exemplar-airtable
kind: exemplar
summary: That people already know how to use a grid, and that the winning move is to make the spreadsheet a real database rather than to replace it with forms.
problem: >-
  Businesses run on spreadsheets and internal tools try to replace them with
  forms and lists. People resist, because the spreadsheet lets them see
  everything, change anything and rearrange the whole thing without asking
  anyone — and the replacement lets them do none of that.
family: [edit, scan, capture]
principles: [consistency, friction]
status: stable
visibility: public
related:
  - title: Inline Editing
    url: /patterns/inline-editing
    summary: The grid model, and the keyboard traversal that makes it work.
  - title: Saved Views
    url: /patterns/saved-views
    summary: Their answer to "everyone needs a different view of the same data".
  - title: Spreadsheet Import
    url: /patterns/spreadsheet-import
    summary: The on-ramp that makes adoption possible at all.
---

## The insight

**The spreadsheet is not the problem; the lack of structure underneath it is.**
Everyone in the business already knows how to read and edit a grid. Throwing
that away and asking them to learn a form-based tool is a large cost for a
benefit they did not ask for.

So keep the grid as the primary surface, and put a real data model behind it —
typed fields, relationships, validation — without making anyone learn a new
interaction model to get them.

## What is worth stealing

**Editing where the value lives is the default, not a feature.** The grid is the
editing surface, so there is no view mode and edit mode, no round trip, and no
second mental model for the same object. This is the WYSIWYG principle taken to
its conclusion.

**Keyboard traversal is finished work.** Arrow keys, Tab, Enter to commit,
Escape to cancel, selection that survives the save. It feels like a spreadsheet
because every convention people already have works exactly as expected — and
that is a large body of unglamorous detail, not a coat of paint.

**Views are per-person and per-purpose.** The same table is a grid, a calendar,
a gallery or a kanban, each with its own fields, filters, sort and grouping.
This is the honest answer to the reality that operations, sales and finance want
genuinely different slices — rather than one compromise table nobody likes.

**Import is the front door.** The data already exists. A tool that cannot accept
it will run alongside the spreadsheet forever, and then the spreadsheet is still
the real record.

## Where it does not transfer

Flexibility has a curation cost. A base with forty views needs an owner, and
without one it becomes the same mess as the shared drive it replaced. If nobody
is going to prune, fewer, fixed views serve better.

The grid also assumes homogeneous records with comparable fields. For a record
with genuine depth — a case, a contract, a patient — a grid row is the wrong
container, and a [hub page](/patterns/hub-and-spoke) is right.

And "anyone can restructure it" is a feature until the structure is load-bearing
for a business process. At that point you want the constraints a purpose-built
tool provides.

## The extraction

> **Meet people in the interaction model they already have, then add the
> structure underneath.**

Before designing a form to replace a spreadsheet, ask what the spreadsheet was
letting people do that the form will not — usually see everything at once, edit
anything in place, and rearrange without permission. Those are requirements, not
bad habits.