Design the wrong answer first

On a lot of teams, kickoff for an AI feature still looks like this: someone runs the model a few times, picks the response that looks best, and it goes into the mockup. After that, the mockup becomes the spec.

Real use doesn’t look like kickoff. Run the same feature against fifty real requests, and the good answer turns out to be one of several kinds of result, and not always the most common one.

We ask everyone in the course to start the other way around. Before designing the screens people will use, run a rough prototype against real requests and sort what comes back. Start with three piles, and add a pile whenever a failure doesn’t fit.

Wrong. The answer is incorrect, and the person may not know it. This pile decides whether the design shows evidence, requires a review step, or shouldn’t offer an answer at all. On a clinical documentation tool I worked on, a wrong medication dose looked exactly like a right one. No citation style fixed that. Clinicians confirmed every dose before the note was saved.

Partly right. Most of the answer is useful, and one part isn’t. This pile decides how easy correction has to be. If fixing one part means starting over, people will either accept the bad part or give up on the feature.

Correct, but unhelpful. Accurate, and still not what the person needed: too long, too general, or an answer to a slightly different question. Often it means the interface never asked for the task, the constraints, or the format. Better questions help, and so do better defaults, the right context, and a narrower job for the model.

Once the piles exist, the design conversation changes. Instead of debating whether a response looks trustworthy, the team can ask what a person needs to catch the wrong answer, fix the bad part, and redirect the request.

A few things teams tend to add after doing this:

• a way to open the sources an answer used, where there are sources

• a way to correct one part of an answer without losing the rest

• suggestions for narrowing a request, shown after a vague answer rather than before

• a review step for answers that would be expensive to get wrong

If the mockup only has the good answer, none of these have a job yet.

If you try this, don’t write the fifty requests yourself. Take them from real logs, with personal details removed, or ask the people who will use the feature to write them. The requests you’d think of are the ones the model already handles.