I was on a call with one of our international partners, watching them work through the sequence I'd helped design. They reached a step where they had to make a choice. In my mind, the answer was crystal clear. They were scratching their head.
They didn’t have enough context to make the choice. Or they couldn’t tell which context the system needed to know before it could go on.
Of course it was clear to me. I’d been practicing this way of framing choices for several years, and I’d spent a year building this sequence with a team who shared all that knowledge and experience. On my screen, the logic was airtight. It made perfect sense to everyone who already thought like us.
Most people don’t. Why would they?
I think that gap is where a lot of AI products go wrong right now, and most teams I see don’t treat it as a design problem at all.
The screen moved
Most of the talk about AI products is about models and agents. The interface gets treated as a chat box, and the thinking stops there.
In an AI product, the interface is the order of the conversation, and someone has to design it on purpose.
What the assistant asks first. What it waits for. What it refuses to do until you tell it to. What lands in front of you when it’s done, and whether you know what to do with it.
That’s interaction design, and we’ve been doing it for decades with forms, wizards, and checkout screens.
The trouble is that a prompt looks like a paragraph. So it gets written by whoever is closest to the model, tuned until the demo works, and shipped.
What it asks, and when
The assistant I’ll walk through is a decision coach, one of a suite of AI strategy assistants I designed for leaders in professional services. Its job is to help someone make a defensible choice: frame the decision, generate real alternatives, test what must be true, score the options, and leave a record of the reasoning.
It opens with one question and three answers:
- Already decided. Reverse engineer it.
- Competing alternatives. Need to choose.
- Problem to explore. Need solutions.
That menu is triage. Someone defending a call they already made needs a different conversation than someone staring into fog. It also wasn’t there at the start. More on that in a minute.
From there, the assistant shows one phase at a time and stops. It won’t move on until the person replies “Advance.” Every phase ends with a single line saying exactly what to do next.
Left alone, a language model will hand you the framing, the options, the tests, the scores, and a recommendation in one long scroll. It looks generous and reads like a wall. Nobody can push back on step two once step five is already on the screen.
There’s one deliberate exception. If you pick “competing alternatives,” the assistant asks for your options, then reflects the decision back and generates alternatives in a single reply. You arrived with options in hand. An extra stop would just slow you down.
What it refuses to ask
The assistant gets one clarifying question. One. Only during framing, and only if it’s essential. Otherwise it makes an assumption, labels it, and keeps going.
Every fact it works with carries a tag: ✅ confirmed or ❓ assumed. It never invents. If it doesn’t know something, it says so out loud and proceeds.
An interview feels thorough to the person who designed it. To the person answering, it feels like a deposition. Worse, a good answer to most clarifying questions requires the person to have already framed the problem, which is the very thing they came for help with.
A visible assumption works the other way around. You can glance at a ❓ and say “no, actually, it’s the opposite.” Correcting is easier than answering. It also keeps the person in the author’s chair. The assistant proposes. You decide what’s true.
It holds back one more thing: its opinion. It stays neutral until scoring, with no nudging and no early recommendation.
What watching people changed
That call showed me my blind spot.
When we built the first versions, I was looking at the logic the way the model would execute it, and it looked clean. What I couldn’t see was how much of our own context was baked in. Years of practice and a year of shared work had done the problem framing long before anyone wrote an instruction. That framing leaked into every step. The sequence assumed the user showed up with it, too.
The partner on that call didn’t. They showed up with a messy situation and none of our framing.
It’s the curse of knowledge, and it’s especially sneaky when you’re turning an expert’s way of thinking into a system for someone who doesn’t have that experience. What’s obvious to you is invisible to you.
The biggest change landed in the very first thing the assistant says. That three-way opening, already decided, competing alternatives, or problem to explore, came out of this feedback. The early sequence assumed everyone arrived at the same starting line, because we always did. Real people showed up at different points in their own thinking. So the tool had to ask where they were before it asked anything else.
That feedback forced a reframe I didn’t expect to need after 25 years of doing this work.
Onboarding to the interface was the easy part. The hard part was onboarding people to the problem.
Most UX literature and best practice grew up around screens: buttons, workflows, states you can see. A conversation sits at a different level of abstraction. In a conversation, you’re guiding someone through a frame of thought and a sequence of thinking. The text box hides all of that, which is exactly why it has to be designed on purpose.
The output is the next screen
If the sequence is the flow, the output is the screen. So it gets an output contract, the same way a design system gets component specs.
Every phase opens with the same title and a one-line subtitle that says why the phase exists. Alternatives come in exactly two or three, never more, and each one has to state its trade-off in plain words. If you only bring one option, the assistant adds a “do nothing” option and a radical one, because a choice with one option isn’t a choice.
Tests use a fixed card: hypothesis, method, owner, duration of two weeks or less, a small budget cap, a pass/fail line, and a next action. Scores use a visible formula, so anyone can see how the number was built and argue with it. The assistant always invites the person to override.
At the end, it produces a decision log with the problem, the options, the assumptions and how they were tagged, the scores, the final choice, next actions, and a review date about ninety days out.
I designed all of it for one moment: a partner walking into a meeting who has to show their logic and back up their thinking in front of other partners. They needed something they could put on the table and defend.
The trade-off line is there so nobody can pretend an option is free. The review date means the decision gets looked at again instead of becoming folklore.
Every one of those decisions came from asking what that partner needed to be holding when the conversation ended.
Who owns the sequence?
If you’re building an AI product, try three questions with your team:
- Can you write down what your assistant asks, in order, and why each question is there?
- What does it deliberately not ask, and what does it do instead?
- When the output lands, does the person know what to do next?
If nobody can answer those, nobody is designing your product. The model is doing it for you, and it has never met your users.
I’ve been doing this work long enough to be suspicious of anything that claims to change everything, and this doesn’t. Watch what people actually do, and make the next step obvious.
The material just talks back now.
