AI Prototypes Are Fast — But Designers Must Still Validate Real User Scenarios

Challenge Focus: Where Does Design Intervention Add Value?

When AI prototypes already satisfy core project requirements, the value of human design intervention is questioned. Interface production once consumed much of designers' effort and served as a visible moat; as AI replaces that work, designers must articulate what they contribute to business outcomes — making information easier to understand and operations more logical.

Challenge: Intervening After a Solution Is Concretized

AI prototypes shrink the space for team discussion. A runnable prototype has strong "visual adhesion," locking attention onto the existing UI. Although AI shortens production, overturning a concretized solution still carries high communication and collaboration costs.

A Challenge Case: Mini-Program Violation Reporting

In a mini-program violation reporting feature, users must describe the issue, select a report category, and provide evidence for platform handling. The product team aimed to solve two problems: complex platform categories confused users, and submitted evidence was often insufficient for backend processing.

By the time design intervened, the product team had built a multi-turn dialogue prototype using AI: users describe the issue, the system suggests a category, then follows up to gather missing evidence (left side of diagram). The final agreed solution was a form-based approach that presents report content, materials, and category together (right side of diagram).

Solution Approach

1. Trace Original Requirements to Show Design's Value

Revisiting the requirement: users want to finish reporting quickly; the platform needs sufficient information. The prototype used assisted categorization and follow-up questions, but does completing the task require multi-turn dialogue? Mapping the prototype flow revealed users must answer each round and wait for AI responses. For users who already know what to report and have materials ready, these steps add burden. The goal is valid; the path to it still has room for improvement — that is where design intervenes.

2. Define Scope and Compare Solutions

2.1 Keep the Goal, Break Down User Tasks

The problem and goal are real; only the task flow needs adjustment. Setting aside the prototype's interaction form, the reporting process was split into three tasks: describe the violation, determine the category, supplement and verify evidence. Design must reconsider how to organize these tasks so users clearly see what information is needed and can complete reporting more efficiently.

2.2 Re-examine Traditional Forms vs. AI Dialogue

Conventionally, these tasks could be handled by a form: text field for description, options for category, upload for evidence. Information is centralized, allowing review and modification — making forms another candidate path. However, traditional forms leave the categorization problem: users may not understand platform categories, yet the platform needs accurate categorization. The product team introduced AI multi-turn dialogue to interpret user descriptions, guide step-by-step, and fill gaps. Simply switching to a traditional form would not solve the categorization burden.

2.3 Introduce AI-Assisted Categorization Within the Form

Could the form handle information entry while retaining AI's ability to understand user descriptions? Users first describe the issue and attach materials; AI then suggests a category based on the description, with a manual override option. Users don't need to learn category rules upfront and can review and adjust the result. This new form solution emerged: keep centralized, editable information entry; use AI to assist categorization.

2.4 Compare Full Task Completion Against the Prototype

With the new form, both paths were compared under the same reporting task. The dialogue prototype requires users to follow prompts, stepwise describing, confirming category, and adding evidence. The new form presents content and materials together, uses AI for category assistance, and lets users directly verify and edit. The form retains information collection and assisted categorization while reducing round-trip questioning and waiting, offering a more efficient path. Based on this comparison, the product team accepted the form direction.

This choice has clear contextual conditions: if users struggle to organize information and need step-by-step guidance, dialogue may still help. Whether it is more efficient depends on comparing comprehension, entry, and correction costs across the full task.

2.5 Optimize Voice Input After Flow Is Settled

After settling on the form direction, input details were refined. The product team wanted to keep voice input from the prototype. Two options were compared: a prominent voice entry point vs. text input with voice assistance.

A prominent voice entry adds an extra navigation step; for longer reports users may need to recall and organize, making long-press speaking unsuitable. Re-recording risks overwriting existing content, and AI recognition may alter original meaning — all needing further checks. The final choice was text input with voice assistance: users compose and edit around the form, using voice only when needed. With flow direction clear, design focused on these specific interactions.

Revisiting the Case: A Reusable Framework

Though projects and contexts differ, when a finished prototype lands on the table, designers can still use the following steps to understand the requirement and solve problems more appropriately.

1. Trace Problem Source and Separate Goals from Means

First, review original feedback, issue logs, or data with product to clarify what users want to do and where they get stuck. Separate the must-achieve goals from the means the prototype uses, and judge whether the current approach is necessary. If the problem source is unclear, validate it first.

2. Judge Intervention Level and Match Change Scope

After spotting issues, don't immediately redesign everything. If the path is sound but information is unclear, adjust locally; if the goal is clear but the flow burdens users, reorganize steps; if the requirement itself lacks evidence, return to the original scenario to confirm the problem.

These three levels need not be sequential. If the prototype fits the task, do local tweaks; only when the current path hinders the goal is there reason to expand scope, stating expected benefits and costs.

3. Turn Judgments Into Comparable, Implementable Solutions

Place the existing prototype and alternative(s) in the same task, walk through user actions, compare comprehension, input, waiting, and correction costs, then factor in implementation difficulty and schedule. When resources are limited, keep reasonable parts of the existing implementation and adjust only critical points.

Reaching consensus does not equal validated effectiveness. Clearly state what the solution expects to improve and what risks remain; later verify through real usage.

Conclusion

Returning to the opening review scenario: a runnable demo may still leave user difficulties undiscussed. Designers must start from original demands, surface those difficulties, and use concrete solutions to show improvement possibilities.

AI shortens the distance from idea to interface, making designers' professional judgment more critical: seeing the comprehension, operation, and correction costs users may pay behind a smooth demo, translating user situations into concrete design choices. When a solution seems complete enough to push forward, designers can still uncover overlooked problems and propose evidence-based improvements. That is where designers continue to create value after AI prototypes.

Of course, real work may not always allow ample discussion. Urgent demands may leave no time for multi-path comparison; product may have firm direction and resist reopening discussion. This method helps designers make better-grounded proposals, but cannot guarantee adoption. How much improvement gets pushed depends on business priorities, collaboration foundation, and timing of design intervention.