data-before-designlisted

# Data before design Three things decide whether a view of data is any good, and all three are settled before you write markup: **what decision the view serves**, **what is actually in the field**, and **which of several layouts the person wants**. Skipping any of them produces a view that looks finished and is wrong. ## When to use - Any card, panel, table, dashboard or detail view over records you did not author - A stakeholder says "show me X" and X is a column name - You are about to summarise, truncate, badge, sort, colour or count a field - You are choosing between two ways to lay out the same information Skip when the data is your own fixture, or the view is one value you already printed. ## Step 0: name the decision Write one sentence before touching the data: *"Someone looking at this is deciding ___."* If you cannot finish it, you are building a data dump and the layout question has no answer. - **Every field earns its place by changing that decision.** Interesting but decision-neutral belongs in the detail view, not the card. - **Prominence tracks decision weight, not query convenience.** The field that was easiest to fetch is not the field that deserves the largest type. - A stakeholder naming a column has told you the *data* they want, not the *decision*. Ask what they would do differently depending on its value. ## Step 1: profile the field, then design Query before you design. For every field the view will show: | Check | Why it changes the desi