chou.design

Abstract or exact

A model can answer the same request in many shapes. A paragraph is the default, and it's usually the weakest one. Most of what I've learned working with AI comes down to asking for the shape that lets me judge the answer.

Some answers I judge by looking. A layout or a transition has better and worse directions, and my eye decides. I call that output abstract. Other answers I judge by checking. A total or a list of tasks has one right version, and it lives in a source outside the answer. I call that output exact.

Both get more solid when the output takes a form made for them.

Directions

Before anything visual gets built, I ask for versions side by side and pick one by looking. The first answer from a model tends toward the middle, and asking again gives you the middle again. Versions that disagree with each other show directions the first answer would have skipped.

Take the study screen of a flashcard app for learning Mandarin. The expected answer is a card in the middle with two buttons under it. Asked for range, the model also tried a card that fills the screen and one you swipe away. Seeing each one move made the choice take seconds.

Directions for the same screen, each moving the way it would in the hand. They should be different enough that one is clearly better.

These examples also need time. A screenshot shows a screen, but an experience happens across seconds. I once reviewed a design editor where every screenshot looked right. A short clip of someone dragging a button showed the real problem: the click grabbed the label inside the button, and the label came out on its own.

The same editor, still and moving. Only the clip shows what's wrong.

Data

Data goes the other way. Hand a model a month of card statements and the useful answer is a table: every line sorted into a category, the amount for each one and the sum at the bottom. A total that matches the one printed on the statement tells me the whole table holds.

A month of statements as one table. The sum at the bottom is the number to compare with the source.

Once the months are checked, a chart turns them into something I can read at a glance. Six statements become one shape, and the question becomes why October was higher.

Six statements as one chart. The table made the numbers solid, and the chart makes them easy to read.

Projects

A project is data too, even when it starts as a page of loose notes. Asked for a kanban board, a model sorts those notes into columns, and the state of the project becomes visible in one look.

The board is still exact output, and its source is the notes. Counting tasks in the notes against cards on the board takes a second, and it catches the task that would otherwise disappear.

Fourteen tasks in the notes and thirteen cards on the board. The count finds the gap the layout hides.

Systems

Some things are both abstract and exact. A design system's tokens are the clearest case I know. A button's colour points to a name that says what it means, and that name points to a raw value in the palette. Each value is exact, and the system only makes sense when you can see how the values connect.

I've tried to look at that in Figma and in Notion. Both store the tokens well, and both show them as long lists. The path from a button to its base colour, and everything that would change with it, stays in my head.

That's part of why I'm building Draw, a UI design app I'm writing from scratch. Its design system window shows each token with the path it takes down to its base value and how many layers follow it. Change the base value and you watch everything that depends on it move.

A component token, the meaning it points to and the base value under both. One change at the bottom reaches every layer above it.

Before asking

The useful question now comes before the request: will I look at this, or check it? If I'll look, I ask for versions that disagree and for something that moves. If I'll check, I ask for a table with the source beside it, and a chart or a board once the numbers hold.

In the last article I wrote about designing what comes back from a model. This is the step after that. Know which kind of output you're about to get, and give it the form that lets you judge it.