On an AI support feature last year, I spent two weeks on the panel where staff reviewed the AI’s draft replies: the layout, the confidence indicator, the approve and edit buttons. Then I watched the first real test session. The panel worked. The assistant inside it apologised four times in one reply and offered a refund it had no authority to give.
None of that was in my Figma file. All of it came from a page of written instructions an engineer had put together in an afternoon. These instructions (often called the “prompt”) tell the AI how to behave. That was the moment I accepted the prompt was part of the design, and probably the most important part.
What the instructions decide
Strip it back and the instructions cover the same things I’d normally put in a design spec:
- Tone. How formal, how long, how much it hedges. “Be helpful and friendly” produces something no brand team would sign off.
- Refusals. What it won’t do, and how it says no. A refusal is a screen state. It needs a reason the user can understand and a next step.
- Fallbacks. What happens when it’s unsure, when something behind the scenes fails, or when the user asks about something it doesn’t cover. In a normal flow this is the error state. Here it’s a paragraph of text.
- Hand-off. When it stops and passes to a human, and what context goes with it.
If a designer wouldn’t let an engineer improvise the error states, they shouldn’t let anyone improvise these either.
Traditional feature
- Error states drawn in Figma
- Copy written per screen
- Behaviour fixed in code
AI feature
- Fallbacks written as instructions
- Tone set by a few sentences
- Behaviour changes when the words change
How I document it now
I keep a behaviour spec next to the Figma file. Same project, same review process. It has four parts:
- The instructions Saved as versions, with a short note on why each change was made.
- A behaviour table Each situation, what the AI says, what the screen shows, what the user can do next.
- Example conversations Good and bad, written by hand, like annotated screens.
- Test questions Twenty or thirty, rerun whenever the instructions or the AI change.
The behaviour table’s rows are situations: the normal case, a vague request, a request it shouldn’t handle, a sensitive topic, and something breaking behind the scenes. The test questions matter because a tone fix can quietly break a refusal, and you won’t know unless you check.
The behaviour table is the part stakeholders actually read. It turns “the AI” into a set of states people can argue about, which is the conversation you want.
Who owns it
In practice the instructions end up shared. I write the behaviour, engineering owns the technical side, and anything touching risk gets reviewed by whoever owns policy. What matters is that someone with a design brief is in the room when the words are chosen.
Writing these instructions has made me a better writer of ordinary interface copy, too. You learn quickly how much a single vague word lets the system get away with.
The takeaway: the instructions are the spec for everything the screen can’t control. Design them, review them and version them like one.