Make AI argue against your favorite design without confusing critique with research

Write the decision before defending it

Describe the decision in one sentence: We are considering a guided setup because new administrators must configure three dependent settings. Then separate observed facts, constraints, assumptions, and preferences. An interview finding belongs in the first group only when it is supported by the actual research record. A teammate’s enthusiasm belongs somewhere else.

Give the model a compact evidence packet with source dates, relevant excerpts, known limitations, and the alternatives you can realistically build. Do not upload raw participant information without the appropriate permission and approved environment. Remove your favorite option’s flattering label; call the concepts A and B.

Ask for the strongest case on both sides

Telling AI to be brutally honest can produce confident negativity rather than better judgment. Ask it to apply the same criteria to both options, identify uncertainty, and state what evidence could reverse its recommendation. Review the reasoning against the supplied material instead of accepting its confidence score.

Useful criteria include task success, reversibility, learnability, accessibility questions, support burden, and implementation cost. Decide which matter most before seeing the answer. Otherwise, it is easy to change the scoring system until your preferred design wins.

Prompt to try

Evaluate design A and design B for [decision and audience]. Evidence: [dated sources]. Constraints: [constraints]. Criteria and priorities: [criteria]. For each design give the strongest supporting case, strongest objection, assumptions, and unanswered questions. Cite the supplied evidence by identifier. Separate observations from inferences. Do not invent users, quotes, research, or numerical probabilities. What evidence would make you reverse your recommendation?

Worked example: guided setup or open dashboard?

Imagine a hypothetical reporting product. Design A requires a four-step setup before showing the dashboard. Design B shows an empty dashboard with a setup checklist. The team knows that a data connection is required to display reports. It does not yet know whether most administrators arrive with the access credentials they need.

AI might argue that A creates useful sequence and that B lets people explore while waiting for access. Neither statement establishes which design works better. The important discovery is the shared assumption about readiness. If many administrators need help from an account owner, both designs need a clear way to pause, request access, and return.

A third candidate becomes possible: show a preview with clearly labeled sample data, explain what connecting an account unlocks, and let the administrator resume later. That concept also needs evaluation. The critique has expanded the options and isolated a research question; it has not selected a proven winner.

Convert objections into questions you can investigate

Take the three assumptions most likely to change the decision. For each, choose an evidence source and a decision rule. Existing support tickets may reveal repeated setup blockers. Observing likely administrators can reveal whether they understand the next action. Instrumented product behavior may show abandonment, but a drop-off alone does not explain the cause.

GOV.UK’s user-research guidance distinguishes assumptions from needs supported by research and recommends learning from actual or likely users. Apply that discipline to generated critique: keep it in the assumption log until evidence supports or challenges it. A conversation with a model does not become an interview because the prompt assigns a persona.

Prompt to try

Turn these three design assumptions into a research plan: [assumptions]. For each suggest the smallest useful investigation, suitable participants or evidence source, a neutral task, what to observe, and what finding would change our decision. State limitations. Do not propose leading questions, fabricate findings, or treat synthetic responses as participant data.

Leave a decision record someone else can challenge

Record the choice, supporting evidence, remaining uncertainty, owner, and review trigger. A trigger might be a new customer segment, repeated support issues, or a planned research round. Avoid inventing a percentage threshold when you do not yet know the baseline or whether the sample could support that comparison.

Use a final rubric: is the argument traceable, is the comparison fair, are important consequences covered, and is the next investigation feasible? Mark each pass, revise, or unknown. An unresolved concern can coexist with a sensible reversible decision; hiding it creates unnecessary certainty.

Beginners can apply this process to one navigation or onboarding choice. Experienced designers can add an assumption register to design reviews and revisit previous predictions after research. The learning comes from seeing which concerns mattered and which did not, then improving the next decision.

Try it on one real task

1. Anonymize two design alternatives as A and B and write the evaluation criteria first.
2. Run the balanced critique, then flag every claim without a supporting evidence identifier.
3. Select one assumption to investigate and save a decision record with a review trigger.

Check before you use the result

• Observed evidence, assumptions, and preferences are separate.
• Both alternatives receive the same evaluation criteria.
• Research tasks do not reveal the desired answer.
• The final decision names uncertainty and the evidence that could change it.

Take the next step

Download the UX Design Coach AI practice pack for these prompts, exercises, and review checklists.

New to AI? Take the free first-workflow course at AI Teachers. Already using it? Practice building a repeatable workflow.

Sources and further reading

• GOV.UK: learning about users and their needs

Sources support the principles discussed; the examples and suggested workflows are original teaching exercises.