Writing the system prompt is UX writing nowWriting the system prompt is UX writing now

The most consequential copy in an AI product is usually a block of plain-language instructions that no user ever sees, because it decides how the product refers to itself, how long its answers run, what it opens with, and what it does when it can't help, and every one of those is a writing decision that most companies leave to an engineer who was never trained to make it.

The prompt I know best is the one behind a daily audio show on this site, which I write and revise the way a writer revises product copy, with the reason for every line recorded in a comment above it.

One constant for names, one test for the text

Names live in one constant, since the prompt, the fixed disclaimer in every sign-off and the labels in the transcript all use them, and when those three drift apart an episode ends up crediting someone who is not in it. That is a terminology problem a UX writer already knows from product copy, where the same feature gets three names across three screens, and the fix is the same: one source, referenced everywhere.

A test then holds the assembled prompt character for character to a fixture of the text the show has aired with, and the fixture changes only when I change the prompt on purpose. A fixture test is a heavy rule for a block of prose, and it makes the prompt safe to edit, since a copy change that slips in from a merge or a well-meaning tidy-up fails a test before it reaches a listener. A product team that treats its system prompt as a config string anyone can touch is running without that protection.

Write the moment the model can't help

The failure paths have the least precedent and need the most care. A generated answer can be wrong, out of scope or blocked, and each of those needs wording that gets the person somewhere. A refusal worth shipping says what the assistant can't do here, gives one sentence of reason the person would accept, and names the next move, whether that is rephrasing, switching tools or reaching a person. "I can't help with that" leaves the person with nothing to do next, which is the gap that "Invalid input" leaves, so the guidance in how to design error states that actually help people recover applies to it directly. For the few high-stakes cases, write the response by hand and put it in the prompt as fixed text so the model never gets a vote. List every situation where the assistant should not answer freely, write the response to each, and run real conversations through the result, because the cases you missed will show up there.

Bring a comparison to the engineering conversation

If the engineers building your AI features have not invited you in, take the current prompt, rewrite its three weakest instructions in positive, specific language, replace the inconsistent examples with ones in your voice, and hand over the before and after outputs side by side, so the case for including a writer rests on two answers the team can read next to each other. The opening lines of the prompt are the place to start, since they set the register of every answer that follows.