Data is design and design is product

McDonald Creek showed up twice in A Better Camper. One record came from BC Parks and could be booked. The other came from OpenStreetMap, and its page had no booking panel. They sat 932 m apart.

That's one campground.

Neither source says so. Somebody decides.

That's the design work I'd now do first: what exists in the product, what counts as one, what it's called and who owns each fact about it.

Sophia Prater, who gave Object-Oriented UX its name, calls them nouns: "it's way easier to figure out the verbs in a system if you've already defined the nouns, and then you can iterate back and forth."

What exists	What counts as one	What it's called	Who owns each fact
Campground	What counts as oneOne place to sleep, however many sources list it. Under a kilometre apart is one. Over three is two.	What it's calledA site in the tables, a campground on the page.	Who owns each factTen public sources, corrected by readers who email.
Bike route	What counts as oneOne loop, matched by the shape of the ride. Every effort on it sits under it.	What it's calledA bike route. Strava ranks segments.	Who owns each factGarmin, for the bike route line, heart rate and power.
Wine	What counts as oneOne vintage. The pH and the sugar below it change year to year, under the same name.	What it's calledA mix of brand, growing conditions, style and more. It's an artistic expression of food.	Who owns each factThe winery that entered it. Customers flag what is wrong.
Recipe Post	What counts as oneOne time you cooked or ate something.	What it's calledA post in the tables, a plate in the copy.	Who owns each factThe person who posted it.

In 2026 models read that list, and they can generate the interface in front of it.

For most of my career the first reader of a database table was another engineer, who could walk over and ask what a column meant.

Now models read those tables more than any person does. They act on the name as written.

Researchers at UC San Diego tested how names affect the SQL that models write, on 503 queries across nine real databases. The link was statistically significant. The more readable the names, the better the queries.

One table, from an SAP training database, is called ADOC. Their readable version is invoice_history.

A person reads a bad name once, asks and remembers. A model reads it on every call and guesses each time.

Luke Wroblewski described the upside for design systems in October: "Design teams have spent years trying to get people to actually read their design system documentation. Agents read it every single time."

The clearest comparison I've found comes from dbt Labs. On one insurance benchmark, models answered plain questions by writing database queries. A little over two years of LLM progress took their accuracy from 32.7% to 64.5%.

Then an LLM added three data models. Accuracy on the same questions went to 90.0% on Claude Sonnet 4.6 and 84.1% on GPT-5.3 Codex.

dbt sells this kind of structure. The benchmark has only 11 questions, and the new data models were built to answer them. I take the direction from that and discount the size.

A form held decisions.

Its labels named things. Its required fields marked what a record can't exist without. Its dropdowns listed the categories that exist.

When a model fills in the record, those decisions move into the schema. The field list a person used to fill in is now an instruction to a model.

Forms were where designers met the data model. Arguing about whether a quantity is one field or two is data modelling, whatever the job title says.

If the form goes and the designer doesn't follow the decision into the schema, somebody else makes it. More and more, that's an agent taking a reasonable guess.

Wroblewski, who wrote Web Form Design in 2008, described a meeting in May where the backend engineer and the product manager each brought a mockup. So the room talked about "the system, its objects, and the mental model that made most sense for our target users".

When everyone can bring a mockup, the meeting moves to the data design.

Yelp, Google Maps, Resy and The Infatuation all answer the question of where to eat. Matt Webb wrote in April that they "are all more-or-less equivalent for answering that question but clearly they are completely different".

Webb argues that "apps and services are all going to have to go headless": no visual interface, just access for personal AI agents.

Without their screens, those services are still built on different nouns.

On the riding coach I built, the Lakeshore loop is one bike route with 192 efforts under it (one of my favourite rides).

Wine is where I learned this. In the Global Wine Database, each wine's top line was its vintage. Each vintage is unique and the variables below it change year to year.

A 2014 and a 2015 can be a very different wine with the same name.

So wines and vintages were separate items. So were wineries and companies (and growers if you want to get deep into wine nerdery).

Conflating either messes everything up.

GET /v1/vintages/helios-nero-davola-2019.json

{
  "vintage": {
    "year": 2019,
    "slug": "helios-nero-davola-2019",
    "wine": { "name": "Helios Nero d'Avola" },
    "winery": { "name": "Di Giovanna", "region": "Sicilia, IT" },
    "appellation": { "name": "DOC Sicilia" },
    "abv": 13.5,
    "ph": 3.78,
    "acidity": 3.95,
    "sugar": 1.2,
    "varieties": [
      { "name": "Nero d'Avola", "percent": 85 },
      { "name": "Syrah", "percent": 15 }
    ],
    "appearance": "Deep ruby red.",
    "nose": "Violets, black cherry, blackberry, sweet spice, chocolate.",
    "palate": "Decisive yet elegant. Velvety tannins, lengthy finish.",
    "pairing": "Roasted eggplant, wild boar ragu, grilled lamb.",
    "winemakers": [{ "name": "Aurelio Di Giovanna" }]
  }
}

Di Giovanna · Sicilia, IT

2019 · DOC Sicilia

Helios Nero d'Avola

ABV13.5

pH3.78

Acidity3.95

Sugar1.2

Varieties

85% Nero d'Avola15% Syrah

Appearance

Deep ruby red.

Nose

Violets, black cherry and blackberry, with sweet spice and chocolate.

Palate

Decisive yet elegant, with velvety tannins and a lengthy finish.

Pairing

Roasted eggplant, wild boar ragu and grilled lamb.

Winemaker · Aurelio Di Giovanna

Better models will fix some of the naming problem. The UC San Diego study found "more recent and more capable LLMs showing less sensitivity" to bad names.

I expect a model will soon read ADOC without help. It still won't decide whether McDonald Creek is one campground or two, because the answer depends on what the product is for.

Someone looking for a place to sleep wants one. An agency issuing permits may want two.

That answer isn't in the data.

A stronger objection says to skip the schema and let a model query the raw sources. That moves the decision to query time, where a model makes it again on every call and nobody reviews it.

McDonald Creek can be one campground on Tuesday and two on Wednesday.

My virtual coach has a field called Feel: strong, normal or struggled, tapped once after a ride.

It's the most useful field I've added, because the numbers can call a ride easy while my legs disagree. No power file holds that fact. It exists because I named a field for it.

I run several agents at once, on different models. Each one reads the names in the code and makes a reasonable guess about what the product is. Without a shared spec the guesses diverge. I measure their output against locked-in specs and the general UX.

When an agent generates an interface from a schema, a column name can reach the screen without anyone choosing it. Jorge Arango writes that "The purpose of information architecture is increasing agency by making systems more legible."

That sentence now covers column names.

Strava moved its API behind a paid subscription this year, and I rebuilt my coach around Garmin. Garmin now owns heart rate, power and the bike route line. Strava is optional.

On the Global Wine Database, moderation blocked ingest. We removed it and let customers flag what was wrong.

A model writes records faster than any queue can review them. I'd make the same call now, with a source on every field and a way for readers to correct it. That's how I'd prove the data is trustworthy.

Andrej Karpathy's pattern for an LLM-maintained wiki has three layers. Raw sources are immutable. The wiki belongs to the model: "The LLM owns this layer entirely." The schema is shared: "You and the LLM co-evolve this over time".

Even there, a person stays on the schema.

dbt compares text-to-SQL with its Semantic Layer, a defined list of metrics and entities that a model picks from. "With text-to-SQL, failure looks like a plausible but incorrect answer," dbt writes. "With the Semantic Layer, failure looks like an error message."

I can design for an error message. A plausible wrong number shows up looking like success.

Data is design and design is product.

John Maeda's proposal for the 2027 Design in Tech report already describes the job as "designing less for direct use and more for systems that agents act through".

You can't design without understanding the data layer. I've been saying this for years.

If you only had words to design with, what would you say? How could you make an interface with just words?

I used to say: design a movie poster, then take away all the visuals except the words. Do you know what the movie is about?

One title and eight words give you the setting, the genre and the threat. Take away the words instead and you have an egg.

The same test works on a campground.

McDonald Creek has 112 sites on a paved road. Some you can book and some are first come.

That's an interface. It's four fields written as a sentence.

To write it you have to know what counts as a site, what counts as paved and what "mixed" means. Those answers sit in the data layer.

I've spent twenty years on the layer under the screen because of what happens on the screen.

Nobody driving up a logging road wants to hear about a noun list. They want to know if it needs 4x4.