{"slug":"data-dump","meta":{"title":"Data Dump","slug":"data-dump","kind":"anti-pattern","summary":"Every field the model has, on one screen, at one level of importance — built from the data outward instead of from the job inward.","problem":"The model has twenty columns, so the page has twenty fields, each with equal weight. Nothing on it is wrong and it is still unusable, because with no hierarchy the eye has no entry point and you must read everything to find anything.","family":["scan","inspect"],"principles":["progressive-disclosure","surface-dont-bury"],"status":"stable","visibility":"public","related":[{"title":"Progressive disclosure","url":"/patterns/progressive-disclosure","summary":"The principle this violates, and the four-layer budget that fixes it."},{"title":"Progressive Disclosure for Dense Detail Pages","url":"/cookbook/progressive-disclosure-detail-page","summary":"The implementation guide for rebuilding a dumped page in layers."}]},"body":"## How you get here\n\nNobody designs a data dump. It accretes. The screen starts with six fields, and\nevery subsequent request is individually reasonable — someone needs the tax\ncode, someone needs the created date, someone needs the internal reference. Each\naddition is small and none is refused, because refusing means telling a\ncolleague their need does not matter.\n\nThe underlying error is upstream of any of those requests: **the page was\ndesigned from the data outward.** The question asked was \"where do I put these\nfields\", not \"what is this screen for\".\n\n## How to recognise it\n\n- You cannot say in one sentence what the screen is for without using \"and also\".\n- Everything is the same size, so nothing is first.\n- Someone new has to be told which three fields matter.\n- The most common request about the page is \"can you make it less overwhelming\",\n  and nobody can say which field to remove.\n- Fields are ordered by the order they were added, which is the order of the\n  migration file.\n\n## Why it survives\n\nBecause every individual fact on the page is **true and occasionally useful**.\nThat makes it very hard to argue against any single element, and the page is\ndefended field by field by different people.\n\nThe counter-argument has to be made at the level of the screen: an interface is\nnot a list of true facts, it is a ranked answer to one question. Twenty\nunranked true facts answer nothing.\n\n## The way out\n\n1. Write the **job sentence** — a who, doing what, needing to decide one thing.\n   If it needs \"and also\", it is two screens.\n2. Name the **one question** the screen must answer without scrolling or\n   clicking.\n3. Put at most **five things** at the glance layer. Everything else is demoted,\n   not deleted, and every lower layer gets a visible door.\n4. Do a **subtraction pass** and say out loud what you demoted. If nothing was\n   demoted, you did not design, you rearranged.\n\nThe budget is the mechanism. Without a fixed cap on the glance layer, every\nstakeholder's favourite field returns, and the page rebuilds itself within two\nquarters.\n\n## The cost of leaving it\n\nIt is paid by whoever uses the screen most, every time they use it, and it never\nshows up as a bug. That is why data dumps last for years: the cost is real,\ncontinuous, and invisible to everyone except the person doing the work.\n"}