Pressure Testing Your Own Decisions

Stop asking it to make things

Most designers meet these tools as generators. Make me a flow, make me some copy, make me twenty concepts. That is the obvious use and, as the last three lessons showed, a fairly ordinary one. The output is competent and average, and you spend your time reworking it.

The more interesting use is the opposite. Stop asking it to produce and start asking it to attack.

This works better for a structural reason. When you ask for a design, you are asking for taste, which it does not have. When you ask for objections, you are asking for the recall of every objection anyone has ever written down about designs like yours, which is much closer to what it actually is. A patient, well-read, slightly pedantic adversary who never gets tired and has no political interest in the outcome is a genuinely rare thing to have available at 9pm before a review.

Three critiques worth running

The case against. Describe your decision as neutrally as you can and ask for the strongest argument that it is wrong. Not a balanced view: the strongest case against. Balanced views are where good objections go to die.

The stakeholder rehearsal. Ask it to play the specific person you are worried about. Not "a stakeholder" but "an engineering lead who has been burned twice by scope creep on this team and thinks research is a delaying tactic". The more concrete the role, the sharper the questions, and the less it defaults to generic scepticism.

The accessibility sweep. Describe the flow and ask what would exclude someone. This is one of the most reliable uses in the whole course, because much of accessibility is a checklist against known guidance rather than a matter of judgement, and checklists are its home ground.

I have made a design decision. Do not tell me whether you agree.
The decision: [state it in one or two sentences, without saying why you
like it].
Build the strongest possible case that this is the wrong call. Give me
five distinct objections, ordered by how much damage each would do if it
turned out to be right. For each one, say what evidence would confirm it
and what evidence would rule it out.
Do not soften anything. Do not end with a summary saying it is broadly
sensible.

Here is a flow: [describe every screen, every control, every state, and
what happens on each interaction].
Tell me who this could exclude and how. Cover at least: keyboard-only
use, screen reader use, focus order, whether anything is communicated by
colour alone, motion and animation, time limits, form labelling and error
identification, touch target size, and content that assumes fluent
reading.
For each problem, tell me whether you are inferring it from my
description or whether it follows directly from something I told you.

That final instruction is the important one, and it generalises well beyond accessibility. Forcing the model to separate what it was told from what it assumed is one of the few reliable ways to see where the critique is grounded.

The failure mode: it wants to agree with you

Now the honest part, and it undermines everything above if you ignore it.

These systems are tuned to be agreeable. That tuning does not switch off when you put on a critic's hat. Ask "I think we should put the filters in a side panel, do you agree?" and you will get agreement, with three supporting reasons and an appreciative note about your thinking. Ask "I think filters in a side panel is a mistake, am I right?" about the same design and you will get agreement with that too.

This is sycophancy, and it is the reason most AI critique is worthless. The model is not evaluating your design. It is completing your sentence.

Worse, it survives contact with pressure. Push back on a correct answer and it will frequently reverse, apologise and adopt your position. So you cannot even use its persistence as a signal, because it does not have any.

Three habits contain it.

Withhold your preference. State the decision, never the reasoning that made you like it, and never which option is yours. The moment it knows what you want, the critique becomes a performance of critique.

Present rivals neutrally. If you are choosing between two approaches, describe both as though a third party proposed them, in the same amount of detail and the same tone. Uneven detail is a tell, and it will read the tell.

Ask for the objection before the verdict. "What is the strongest argument against this?" gets you something. "Is this good?" gets you a compliment. Never ask the second question first, because once it has praised something it will defend the praise.

What it cannot do, no matter how you prompt

Three limits are permanent, and no phrasing gets round them.

It cannot see your interface. Everything it says about your design is a response to your description of your design. Your description was written by the person least able to see it freshly, and it omits precisely the things you have stopped noticing. That is not a small caveat. The most common real-world usability problems live in the gap between the design you think you described and the one on the screen.

It has no users. It cannot tell you whether your users will understand a label, because it has never met them and has no access to how anyone behaved in your product. Anything it says about "users will likely" is a statement about what such sentences usually say. Lesson one made this point and it is worth making twice, because roleplay makes it very easy to forget.

It has no stake. It does not have to live with the decision, support the feature, or explain it to a customer in eight months. A critic with nothing to lose will produce every objection, including the ones that do not matter. Ranking them is your job, and it is the part where actual design judgement lives.