Designing for two audiences: the human and the model

I keep noticing the same pattern in AI products. Instead of asking you to write the perfect prompt, the interface asks a few questions.

• What are you trying to do?
• Who is it for?
• What matters most?

You answer them, click continue, and a few seconds later you get something useful. If it works well, you probably don't think much about what happened in between. You didn't really write a prompt. You gave the interface pieces of information, and the product turned those pieces into something the model could work with.

I find that interesting because the interface is doing more than making the task easier for the user. It is now also shaping the model's input. And that changes what we are designing.

The wizard pattern isn't new

We've used wizards for a long time. Tax software, installation flows, account setup, configuration tools. Whenever something was too complex to deal with all at once, we broke it into smaller steps. The pattern is familiar:

1. Take something difficult.
2. Break it down.
3. Ask one thing at a time.
4. Turn those answers into structured data.

The interface helped the human complete the task, while the system on the other side usually expected predefined fields, values, or rules. With AI, that last part changes.

The system is interpreting the input too

In an AI product, the information collected by the interface may become part of a prompt, structured context, variables, instructions, or some combination of them. The implementation can be different from product to product. But from a design perspective, the interesting part is the same.

What we ask the user directly affects what the model knows when it generates the result.

If important context is missing, the model has less to work with. If a question is vague, the answer may also be vague. If the interface collects the right constraints and context, the model has a much better chance of producing something useful.

So the wizard isn't only reducing cognitive load anymore. It's also helping construct the model's input.

I think of this as prompt scaffolding

Rather than expecting people to know how to prompt well, the interface helps them build the prompt through interaction. The user doesn't need to think:

• What context should I include?
• How should I structure this?
• What does the model need to know?

The product can help ask those questions instead. I think of this as prompt scaffolding: using the interface to help collect and structure human intent into something the model can work with. You can already see variations of this in many AI products.

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.

The tradeoff is structure

This is where I think the design problem gets interesting. Add too much structure and you can make the interaction rigid: the user's situation might be more nuanced than the options you've provided. They understand their problem, but your interface doesn't give them enough room to explain it. Add too little structure and you push the work back onto the user. One person gives you three words. Another gives you three paragraphs. Someone includes the detail that completely changes the answer. Someone else doesn't realise that detail matters.

So I'm less interested in asking how much information can we collect? and more interested in what is the minimum structure that meaningfully improves the output? Every question should earn its place, not only because completing forms takes effort, but because every question should contribute something useful to the context the model receives.

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.

It also changes what we test

This has made me think differently about some familiar UX practices.

The wizard has a different job now

The wizard pattern never disappeared. What I think has changed is what we're asking it to do.

Before, it mainly helped people move through a complex process and turned their decisions into structured data. In AI products, it can do something else at the same time. It can translate human intent into model-ready context. That makes something as familiar as a multi-step form suddenly much more interesting to me.

Because I'm no longer only asking whether the interface is understandable for the person using it. I'm also asking what information is being passed through the interface, what gets lost along the way, and how those design decisions affect what the model eventually produces.

We are still designing for the person on the other side of the screen. But when AI sits behind the interface, we also have to design what the model receives. And increasingly, I think good AI product design lives somewhere between those two.

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