Writing · 7 min read

What does a design system need once AI is in the product?

Once AI hands a design system claims instead of facts, its components need six things they were never asked for. The SAP program is the account this draws on. Second Look, a dispatch prototype, is where the six were tried on one screen.

Key idea 1 of 7

The components were built for facts, and AI hands them claims

A design system that has held more than forty apps together is a system for facts. Its data table shows a value. Its status shows a state. Its button does a thing. Every component in it assumes the number in the cell is true, because for twenty years the number came from a record.

An AI feature hands the same components something else: a claim. A recommended truck, a suspected cause, a drafted correction, a summary of a document. The value looks the same in the cell.

A claim is a different kind of thing. A system that cannot tell the difference will show a guess in the typography of a fact. The first thing AI asks of a design system is a way to say what kind of thing this is.

Across the SAP Fiori program, the hardest agreements were about states. What a warning is, when a field is read-only, what a row looks like when its record is locked. The next round is about claims, and I would open with the six below.

This article is about AI inside the product. A second problem shares the words: AI building the product. There, a coding agent writes the interface, and the design system has to make its decisions legible enough for the agent to inherit them.

The two want different things from the same system. The first wants new states. The second wants the existing ones written down where an agent will read them. Agent Review is where I took up the second.

Key idea 2 of 7

A claim carries its source and its age, so the component needs somewhere to put them

In Second Look, three of the five factors behind a recommendation carry a line saying where they came from and how long ago. The position is from the GPS four minutes ago. The driver’s hours are from the logging device forty-five minutes ago.

That line is the difference between a figure a person can act on and one they should check first. It is a slot in the component, not a note on the screen.

What a fact component holds, and what a claim component adds

A fact

The value
Its label and its unit
Its state: editable, locked, invalid
Where it goes when you press it

A claim adds

Where the value came from
How old it is, and when it goes stale
Where it stands against its peers
What to check before acting on it

The component question is where that line lives when it matters and where it goes when it does not. In Second Look, the forty-five-minute-old reading is raised into a note on the card in the close call, where it could change the answer. The note says what margin it left and what to check.

A confidence percentage is a claim about the system, and there is nothing on the screen to set it beside. A source and an age are claims about the world. The person already knows what to do with those.

Key idea 3 of 7

Pending is a state, not a spinner

A model takes a moment. Second Look’s ranking is instant because it is arithmetic on the page. A real one would not be. The row would have to show that it is still thinking, not that it has nothing to say.

A spinner says busy. A pending state says what is coming, what it will replace, and what the person can do in the meantime. It settles without moving what they were reading.

That last part is motion. The motion spec needs a duration for it and a rule about interruption. An answer that arrives while a person is reading the row above cannot shove it down the page. Streaming text is the extreme case. A system with no pending state gets one improvised in every feature, each a little different, and the product learns four ways to say wait.

Key idea 4 of 7

In Second Look, the one truck a rule removes takes the one caution ground on the screen. No suggestion ever does. A stale figure takes the caution ink, not the ground.

That is a system rule, not a screen rule. A hard requirement and a suggestion cannot share a style. The day they do, a person learns to press through the caution color, and then the rule is gone.

The system needs the vocabulary before the screens do: which treatment is a refusal, a doubt or a suggestion. The spec has to say so in a way a check can read. Once an interface can refuse, refusal is a state, and a state is a token before it is a screen.

The terracotta pegboard with its row of six black hooks each holding a small cream tag, the fourth tag filled dusty rose, and a seventh cream tag hanging from a hole in the board to the right of the row where there is no hook. — Six components, six states, and the one thing the system was never given a hook for, hanging from the board itself.

Key idea 5 of 7

A reversible action needs a pattern, and the pattern has to say what reversing means

Second Look’s Undo takes Assign’s place on the row. It is inert for half a second after the press, so a double-click assigns once rather than assigning and undoing. That is a pattern, and it belongs in the system, because every AI feature has an action a person will want back.

But stopping a pending action and reversing one that already happened are different promises. A system needs both patterns, under different names. Undo, cancel, revert and stop are four words and four promises:

The thing never happened
The thing will not happen
The thing happened and has been put back
The thing is in progress and will go no further

The pattern’s job is to make the promise legible before the press. After the press is when the person finds out which one they had.

The second prototype taught me the difference the hard way. In the first version of the Deploy Console, undoing a rollback removed it from the history, as if it had never happened. It had happened. Services had moved.

Undo there is now a new deploy of the old commit, with the rollback kept in the history under it. That is a revert, named as one.

Key idea 6 of 7

Text the system wrote is a fourth ink

A system has inks. Text on its ground, a muted one for the secondary line, a caution for the thing that is wrong. Text the system wrote is a fourth.

It needs a treatment that reads at a glance. The treatment has to survive being copied into an email. A screen reader has to announce it as what it is. That is an ink and a label in the tokens, not a sparkle icon in the corner.

Second Look does not generate text, which is one reason it could be built without a model. The version that drafts a correction beside the original would need this ink before anything else. That is because a drafted sentence in the typography of a written one is the guess-as-fact problem again, one level up.

Key idea 7 of 7

The checks have to reach the new states

The checks that hold this site measure the rendered page, and for one page they had to learn to press things. Second Look renders its comparison, its refused button and its opened rows from a press. Twelve of its states were in no page the checks ever saw.

Every check said the page passed after measuring a sixth of it. The fix was a registry of the states a press can reach. It found a live hover at 1.29:1 on its first run.

What the checks learned from one screen

12: states in Second Look that no check had ever seen, because each one takes a press to exist
1.29:1: the live hover the checks found on their first pass through them, against a 4.5 floor
7: reachable states the page registers now, each measured on its own fresh load

A system for AI features has more states than a system for facts. None of the new ones are on screen when the page loads. Pending, stale, refused, drafted, undone: each is a state a check has to reach before it can measure it.

A state the checks cannot reach is a state the system does not have, whatever the documentation says.