{"slug":"exemplar-airtable","meta":{"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."}]},"body":"## The insight\n\n**The spreadsheet is not the problem; the lack of structure underneath it is.**\nEveryone in the business already knows how to read and edit a grid. Throwing\nthat away and asking them to learn a form-based tool is a large cost for a\nbenefit they did not ask for.\n\nSo keep the grid as the primary surface, and put a real data model behind it —\ntyped fields, relationships, validation — without making anyone learn a new\ninteraction model to get them.\n\n## What is worth stealing\n\n**Editing where the value lives is the default, not a feature.** The grid is the\nediting surface, so there is no view mode and edit mode, no round trip, and no\nsecond mental model for the same object. This is the WYSIWYG principle taken to\nits conclusion.\n\n**Keyboard traversal is finished work.** Arrow keys, Tab, Enter to commit,\nEscape to cancel, selection that survives the save. It feels like a spreadsheet\nbecause every convention people already have works exactly as expected — and\nthat is a large body of unglamorous detail, not a coat of paint.\n\n**Views are per-person and per-purpose.** The same table is a grid, a calendar,\na gallery or a kanban, each with its own fields, filters, sort and grouping.\nThis is the honest answer to the reality that operations, sales and finance want\ngenuinely different slices — rather than one compromise table nobody likes.\n\n**Import is the front door.** The data already exists. A tool that cannot accept\nit will run alongside the spreadsheet forever, and then the spreadsheet is still\nthe real record.\n\n## Where it does not transfer\n\nFlexibility has a curation cost. A base with forty views needs an owner, and\nwithout one it becomes the same mess as the shared drive it replaced. If nobody\nis going to prune, fewer, fixed views serve better.\n\nThe grid also assumes homogeneous records with comparable fields. For a record\nwith genuine depth — a case, a contract, a patient — a grid row is the wrong\ncontainer, and a [hub page](/patterns/hub-and-spoke) is right.\n\nAnd \"anyone can restructure it\" is a feature until the structure is load-bearing\nfor a business process. At that point you want the constraints a purpose-built\ntool provides.\n\n## The extraction\n\n\u003e **Meet people in the interaction model they already have, then add the\n\u003e structure underneath.**\n\nBefore designing a form to replace a spreadsheet, ask what the spreadsheet was\nletting people do that the form will not — usually see everything at once, edit\nanything in place, and rearrange without permission. Those are requirements, not\nbad habits.\n"}