Designing for two audiences: the human and the model

There's a moment in a lot of AI products that feels almost frictionless.

The tool asks you a few questions. What are you trying to do. Who is it for. What matters most. A few seconds later you have something genuinely useful.

Most people close the tab and move on.

But stay with that moment. You didn't write a prompt. You answered questions. The interface turned your answers into a prompt, fed it to a model, and handed you the result. You got the output without ever touching the input.

The wizard pattern is older than most of us

Tax software. Installation flows. Account setup screens. Anywhere a task was too complex for a non-expert, a wizard showed up to break it into steps.

The logic was simple. Take a hard thing. Sequence it. Surface one decision at a time. The output was always concrete: a config file, a database record, a submitted form. What happened to that data afterward was someone else's problem.

One reader. The human filling it in. That's how it worked for thirty years.

Then the output changed

At some point the output stopped being a database record and started being a prompt.

This sounds like an implementation detail. It isn't.

A database doesn't care how you phrased something. It stores what you gave it. A language model interprets, weighs, and responds to the structure of what it receives. Vague input produces vague output. Missing context produces confident hallucination. A well-structured prompt produces something that feels like the model actually understood you.

The quality of what comes out is directly shaped by the structure of what goes in.

So the wizard isn't just reducing cognitive load anymore. It's shaping the model's input. Managing what gets included, in what order, with what framing. Doing prompt engineering on behalf of the user, invisibly, in real time.

Full width image placeholder

Nobody tells the user this is happening

Most users have no idea. They think: I answered some questions, I got a great result.

What actually happened: the UI assembled their answers into a structured prompt the model could reliably parse. Every question was chosen not just because it was easy to answer, but because the answer was load-bearing for the output. The sequence wasn't arbitrary. The framing wasn't accidental.

I've started calling this prompt scaffolding. A guided interface that constructs a well-formed model input from structured human responses, without the human ever seeing the prompt itself.

You've seen it everywhere. It's proliferating because it works. Without it, most users produce inputs that quietly under-perform, and blame the AI.

Here's where it gets interesting for designers

Traditional form design has one reader. You optimise for the human. Is the language clear. Is the sequence logical. Will they drop off at step three.

Prompt scaffolding has two readers. The human and the model.

You still optimise for the human. But now you also have to think about how the model reads each piece of information. What happens when someone gives a vague answer to question two. Does the model recover, or does it cascade into a worse output. What context goes missing if a user skips a step.

This is a new design constraint. It doesn't replace the old ones. It sits alongside them.

And most design systems haven't caught up yet.

In most teams, the designer and the prompt engineer are different people. The designer thinks about the human. The prompt engineer thinks about the model. Nobody is holding both at the same time.

That gap shows up in the product.

Full width image placeholder

The tradeoff every team hits eventually

Too much structure: consistent outputs, but nuance gets lost. The user's actual situation is more specific than your questions allow. The output is technically correct and practically unhelpful.

Too little structure: rich input, wildly inconsistent outputs. One user writes three sentences. Another writes three paragraphs. One mentions the detail that changes everything. Another doesn't know it's relevant.

The design challenge is finding the minimum structure that maximises output quality. Not the most thorough intake. The most efficient one, where every question earns its place by materially improving what the model produces.

That's not a UX question alone. It requires someone who understands what the model needs, working alongside someone who understands what a human will actually answer. Most teams aren't set up for that conversation.

A few things worth naming directly

01	Designing the intake	Designing the intake is designing the model's input. The questions you ask, the order, the constraints on answers: these are prompt design decisions. Test them accordingly.
02	Testing the output	Test for output quality, not just completion rate. Most teams test whether users finish the flow. Fewer test whether the flow produces good results.
03	Blank states	The blank state is now a model quality problem. When a user skips a question or writes something vague, the output degrades.

Why the wizard came back

It never really left. It just found a new reason to exist.

Thirty years ago, wizards existed because tasks were complex. Today they exist because model inputs are fragile. Same pattern. Completely different rationale.

We've spent years making interfaces clearer, faster, more forgiving for humans. Now we're learning to optimise them for a second reader: one that never complains, never drops off, but quietly produces worse results when we get the input wrong.

That's a new kind of design responsibility. It probably deserves its own pattern in your design system. Somewhere between form design and prompt design, because that's exactly where it lives.

Building something in this space or thinking about it on your team? I'd like to hear about it.