Writing · 5 min read

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

Six things its components were never asked for. A place to say where a value came from and how old it is. A pending state for an answer that is still coming. A style for a suggestion that can never be mistaken for a rule. A reversible action whose pattern says what reversing means. A mark for text the system wrote. And checks that reach the new states instead of trusting them. The forty SAP apps are the account this draws on, and the dispatch cockpit 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 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. It is not the same kind of thing, and 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 forty SAP Fiori apps I standardized, 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 of those agreements is about claims, and the six below are the ones I would open with.

Key idea 2 of 7

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

In the dispatch cockpit, three of the five factors behind a recommendation carry a line saying where they came from and how long ago: the position from the GPS four minutes ago, the driver’s hours 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, and it is a slot in the component rather than 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 forty-five-minute-old figure is the worked example. When it matters, the card says how old it is, what margin the last reading left, and what to check, and the doubt does not move the ranking. 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, and 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. The cockpit’s ranking is instant because it is arithmetic on the page; a real one would not be, and the row would have to show that it is still thinking rather than 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, and it settles without moving what they were reading.

That last part is motion, and the motion spec has to have a duration and a rule about interruption for it: 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 the cockpit, the one truck a rule removes takes the one caution ground on the screen, and no suggestion ever does. A stale figure takes the caution ink and not the ground. That is a system rule, not a screen rule: a hard requirement and a suggestion cannot share a style, because 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, which is a doubt, which is a suggestion, and a spec that says 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

The cockpit’s Undo takes Assign’s place on the row, and 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, and 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, because after the press is when the person finds out which one they had.

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, an accent for the thing to press, a caution for the thing that is wrong. Text the system wrote is a fourth. It needs a treatment that reads at a glance, survives being copied into an email, and is announced by a screen reader as what it is, and that is an ink and a label in the tokens rather than a sparkle icon in the corner.

The cockpit 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 it needed anything else, 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. The cockpit renders its comparison, its refused button and its opened rows from a press, so twelve of its states were in no page the checks ever saw, and every check said the page passed after measuring a sixth of it. The fix was a registry of the states a press can reach, and it found a live hover at 1.29:1 on its first run.

What the checks learned from one screen

12: states on the cockpit 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, and 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.