{"slug":"consistency","meta":{"title":"One consistent pattern","slug":"consistency","kind":"principle","summary":"The same thing should look the same everywhere it appears, and you should be able to change it where it lives. Viewing and editing are one surface, not two mental models for one object.","problem":"Viewing an invoice looks one way; changing it bounces you to an edit form that looks nothing like the invoice. One object now has two mental models, and the person has to learn both and hold the mapping between them.","principles":["consistency"],"status":"stable","visibility":"public","related":[{"title":"UX Principles Guide for Building Web Software","url":"/wiki/ux-principles-for-web-software","summary":"The customer-facing version, with an invoice and a calendar-booking demo."},{"title":"High-Quality Inline-Editable Table","url":"/cookbook/inline-editable-table","summary":"The implementation of editing where the value lives."}]},"body":"## What you see is what you get\n\nThe classic trap: an invoice renders as an invoice, and editing it opens a wall\nof inputs that shares no layout with the thing being edited. The person has to\nmap \"the third input\" onto \"the line item total\" and back again, and they have\nto do it every time.\n\nThe better shape is that **editing happens on the object**. Change a price on\nthe line, add a line item in place, watch the total update where the total\nlives. One layout, one mental model, and the arithmetic is visible while you\nmake it.\n\nThe same argument explains why clicking a calendar slot beats filling in a\ndatetime field. The calendar already shows availability, adjacency and conflict.\nA form field discards all three and asks you to reconstruct them from memory.\n\n## Editing must be a visible state\n\nDirect manipulation has one obligation: it must be **obvious whether editing is\ncurrently on**. If a value looks the same whether or not it is editable, people\neither poke at read-only text or type into something they thought was static.\n\nAn explicit affordance — a focus ring, a hover cue, an Edit toggle that visibly\nchanges the surface — costs almost nothing and removes the entire class of\nconfusion.\n\n## Consistency is a rule about repetition, not sameness\n\n\"Consistent\" does not mean everything looks alike. It means:\n\n- **One object, one component.** A customer looks like a customer wherever a\n  customer appears.\n- **One surface per kind of object.** If a record opens in a drawer from the\n  list, it must not open in a modal from search. Three surfaces for one object\n  is three mental models — see\n  [drawer vs modal vs page](/patterns/drawer-vs-modal-vs-page).\n- **One meaning per signal.** A colour, an icon or a position that means two\n  different things in two places has stopped carrying information.\n- **Same layer, same treatment.** Two things that look different must *be*\n  different. Where they are not, the difference is noise the reader has to\n  discount.\n\n## Why it compounds\n\nConsistency is the principle with the best return over time, because every\nrepetition of a pattern is learned once and spent many times. It is also the\none most easily lost, because losing it never breaks anything — each divergent\nscreen works fine on its own.\n\nOur own audit found the admin had six style families and twenty-four different\n`h1` treatments, none of which was a bug and all of which cost the reader. That\nis what this principle costs when it is nobody's job.\n\n## The test\n\nPick one object. List every place it appears. If the list has more than one\nvisual treatment or more than one editing surface, you have found the work.\n"}