The oldest skill in design is the one AI needs most

In 2012 I spent a week in a training room with Chris Noessel, then of Cooper, the consultancy Alan Cooper founded. The course was goal-directed design, the method Cooper set out and Kim Goodwin documented in Designing for the Digital Age. I went in expecting a week on personas and interaction patterns. I came out convinced that the core skill of a product designer is storytelling. Not decoration, not presentation polish. The disciplined act of describing a person, a goal, and a sequence of events clearly enough that other people can act on it.

That conviction has held for over a decade. What has changed is who the audience for the story now includes. It used to be developers, stakeholders, and the occasional sceptical executive. Now it includes the AI that writes the code. And AI, it turns out, is the least forgiving audience a story has ever had.

Stories work because readers fill the gaps

Whitney Quesenbery and Kevin Brooks make a point in Storytelling for User Experience that I have not been able to unsee since I first read it. Ordinary stories, they argue, invite the audience to add richness, to use their imagination to fill in detail. Storyboards do the opposite. They are explicit, because the author needs everyone to see the same detail in the same way.

That distinction is the whole game when the reader is an AI.

A human designer reading a loose scenario fills the gaps with judgement. They know that "the terminal is activated" implies a status change, a billing trigger, and probably an audit entry, because they have context and they infer generously. An AI fills the same gaps too, but it fills them arbitrarily. It resolves ambiguity by guessing, and it guesses differently every time. The tools that have grown up around spec-driven development exist precisely because AI models are non-deterministic and struggle to follow complex requirements when those requirements are vague. Vague in, inconsistent out.

Loose narrative that a good designer would have quietly corrected becomes, in front of an AI, a set of decisions made without you.

Two artefacts, two jobs

Goal-directed design gives you two scenario types that do different work, and the boundary between them is the useful part.

A context scenario describes what a person is trying to achieve in the future state. It is deliberately technology-agnostic and interface-agnostic. It captures goals and outcomes, not clicks. The format I use puts the narrative in one column and, alongside it, the abilities the system must have for that narrative to be true. You write the story of a plausible day, then extract from it the capabilities it demands.

Here is a shortened example from recent work on an enterprise merchant services platform. The names and systems are abstracted, but the structure is exactly as used.

The left column is the story. The right column is what the story quietly assumes must be possible. Extracting the right column is the analytical act. It is where a vague narrative gets forced to declare its requirements. If a sentence in the story implies a capability you cannot name in the right column, the story is hiding a decision.

A key path scenario picks up where the context scenario stops. It takes the same person and the same goal and walks the precise sequence of steps that fulfils the goal inside the designed solution. Present tense, plain language, each step pairing what the person does with what the system does in response. Where the context scenario said "investigate a discrepancy between the two systems' records," the key path scenario names the page she opens, what she sees, what she clicks, what changes, and how the audit trail captures it.

The word "key" is doing work. These cover the most important paths, not every path. Edge cases and error states get flagged inside each scenario for separate treatment as validation scenarios later. That restraint is deliberate. You are not trying to specify the whole system in prose. You are trying to make the spine of it concrete enough that everyone, including the machine, sees the same thing.

Quesenbery and Brooks describe the same progression in different language. Generative stories open up possibilities early. Expressive stories firm a concept up. Prescriptive stories document the design as it heads toward specification, keeping the real-world context attached as the conversation turns technical. Context scenario, key path scenario, spec. The lineage is the same, whether you learned it from Cooper or from Rosenfeld.

Feeding the story into the build

The prototype I have been describing was built with AI, structured through OpenSpec.

OpenSpec is a spec-driven development framework. It adds a lightweight specification layer so a human and an AI agree on what to build before code is written. Each change gets its own folder holding a proposal, the specs, a design note, and a task checklist, and those files live in the repository next to the code rather than evaporating when a chat session ends. The point of it is alignment. You are structuring your thinking in one place before a line of code exists, and giving the agent a stable reference it can return to.

The scenarios fed that layer directly. We gave the AI the context and key path scenarios and had it draft the OpenSpec specs, which we then reviewed and corrected. This is the part worth being precise about, because it is where the storytelling pays off. OpenSpec's spec files hold requirements and scenarios, often in a given-when-then form. Our key path scenarios were already in that shape. A step pairing a user action with a system response is a given-when-then scenario wearing plain clothes. The ability lists from the context scenarios became the requirements the specs had to satisfy. The narrative had done the hard thinking, so the spec the AI drafted had something solid to be drafted from.

The result was a working prototype of the inventory management flows, built quickly, that behaved the way the scenarios said it should. Not because the AI is clever, though it is, but because it was given a clear story instead of a vague prompt.

Handing scenarios to an AI to draft specs does not remove the review. It relocates it. The AI will add rationale to decisions you never made and quietly assume context you did not give it, so every drafted spec has to be read against the scenario it came from. The scenarios make that review fast, because you are checking the draft against a concrete story rather than against your own memory of what you meant. But the review is not optional, and a team that skips it is back to guessing, just with more steps.

AI produces the story too

Everything so far treats AI as the reader of the story. It is also, increasingly, a drafter of it, and that cuts the other way in the designer's favour.

The artefacts in this method used to be slow to produce. A first-pass set of context scenarios was hours of writing before you had anything to react to. Line-drawing storyboards, the quick explicit panels that force a sequence into the open, needed either drawing skill or the patience to fake it. Both are now fast. An AI will draft a first pass of context scenarios from a brief and a handful of goals in minutes, and it will produce clean line-drawing storyboard frames on demand. The blank-page cost, which was often the reason these artefacts got skipped under deadline, is largely gone.

What has not moved is the judgement. A first-pass scenario drafted by AI is a starting point, not a finished one, for exactly the reason the drafted specs needed review. The machine fills the gaps arbitrarily. It will invent a plausible-sounding forecasting step that does not match how the business actually forecasts, or draw a storyboard panel that smooths over the awkward real-world handoff that was the whole point of the scenario. The designer's work shifts from producing the artefact to interrogating it. Is this the real goal or a generic one? Does this sequence match how the work is actually done? Is this the happy path standing in for a problem that lives in the error state?

That is a better use of the designer's time, not a smaller one. The hours that went into the first draft now go into pressure-testing it. Used this way, AI does not replace the storytelling. It removes the friction that stopped people from doing it at all, and leaves the part that was always the point.

What this means for designers

The skill did not change. The stakes did.

Writing a clear scenario was always the discipline underneath good product design. For years you could get away with a loose one, because a capable development team absorbed the ambiguity and made reasonable calls on your behalf. That safety net is thinner now. When the thing reading your scenario is an AI drafting specs and writing code, the precision of the story is the precision of the product.

That is good news for designers, if we choose to see it that way. The most durable skill in the discipline, the one that predates every tool and survives every platform shift, is now the highest-leverage input into how software gets built. The story is the interface between what a person needs and what a machine produces. Learning to tell it well was never optional. It is just no longer possible to fake.