III · Trust

Behavior Is the Design You Can't See

What a system does on its own, every time

If there's one term I end up explaining more than any other, to designers and to the AI agents I work with, it's system behavior.

It isn't a screen. It's what the system does: when the person acts, when something happens without them, when something fails, when it needs them. Where a message lands, how loud it is, whether it waits, what it says after a click, what it does at three in the morning when nobody is looking. None of that lives on any single screen, which is exactly why it so often goes undesigned. Every screen gets its own answer, made by whoever built that screen, and the product ends up with as many behaviors as it has screens.

Three facts in, one place out

When I wrote the brand book for my own company, I didn't write behavior as a list of components. I wrote it as a model, and the model is short.

Every message the system has to deliver is decided by three facts. What is it? A release, a merged change, a deploy, a failed check, an issue. Who is saying it? The person themselves, an agent, the system, an outside signal. What does it want from the person? Nothing, a glance, a decision, or everything they've got. Those three go in, and one place comes out.

The places are few, and each one means something. A word that pops out of the button you pressed and is gone in a second. A bubble in the corner, the only place the system raises its voice. A feed of messages with names on them, that stays. A short list of the things waiting on the person. A log, everything that happened, one line each. And a panel that slides in from the edge and stays until a human closes it.

Nobody picks a toast. The facts pick the place.

So a release, which customers will see and which is hard to walk back, is a ceremony, and it gets treated like one. A real question from an agent is asked once, with the options right there, and then it waits instead of nagging. A failure shows up on the button that failed, not in a corner somewhere else. And an incident, where customers are affected, changes the whole vocabulary: a panel that stays until a person closes it, the facts and the owner and the next update in it, and everything playful on the surface switched off while it's open.

Where did the facts come from?

Look at the three facts again and they're the first two parts of this book.

What is it is meaning: the nature of the thing, the question Design What It Is keeps asking. A release isn't a row in a table, for the same reason the team isn't a list of contacts. Who is saying it, and what it wants from you is the relationship: what this thing owes the person, and what it asks of them in return. And the six places are what Part II spent its time on: where something lands, what that says about the place the person was standing, how heavy it is, whether it can be walked back.

Behavior is what the system does with all of that on its own, when nobody is designing that particular moment. It's the meaning and the relationship, turned into a decision the system makes the same way every time.

Why is this trust?

The person never sees the model. They see a release land like a release, every time. A failure appear where it happened, every time. A question asked once and left alone. After enough times, they stop checking where the next message will be, and they stop bracing for how it will sound. That not-checking is the trust the essay before this one was about.

That's why behavior can't be left to each screen. A promise kept on one screen and broken on the next isn't a promise. The person doesn't experience screens; they experience the system, and the system is whatever it does most of the time, including the times nobody planned.

And the agents?

This matters more now than it did. An AI agent builds one screen at a time, fast, and does a good job of each one. Ask it for a success message and you'll get a good success message. Ask ten agents on ten screens and you'll get ten good success messages, in ten places, at ten volumes. Each is reasonable. Together they're a product that behaves like nobody's in charge of it.

Written behavior is what an agent can't invent on its own: a decision made once, above the screens, that every screen inherits. Which is the same thing a new designer on the team needs, and the same thing the developer who adds a keyboard shortcut late on a Thursday needs. The model doesn't have to be mine, or this size. It has to exist.

Where this bends

A small product doesn't need six places. It might need two: a word by the button, and a panel for when things go wrong. And some moments really are one-offs, a launch, an apology, a first time, that deserve a shape of their own. That's fine, as long as they're the exception the model allows, not a model nobody wrote.