AI-assisted practical guide. Examples are hypothetical; these are proposed editorial methods, not reported research results.
User complaints often arrive as a mixture of observed friction and the user's own theory on why that friction exists. When a customer says the checkout button is too small, they are reporting a perceived problem but suggesting a specific solution. To avoid building features based on assumptions, you should use AI to strip away the suggested fix and isolate the core pain point, transforming the complaint into a neutral, testable design question.
Isolating the Core Friction
To begin, feed the raw complaint into the AI and ask it to identify the objective observation versus the subjective interpretation. The goal is to remove any mention of specific UI elements or requested changes. If a user claims the navigation is confusing because there are too many colors, the objective observation is that the user struggled to find a destination. By focusing on the struggle rather than the colors, you open the door to multiple design solutions rather than just changing a palette. For difficult cases where the complaint is vague, such as saying the app feels slow, suggest that the AI generate several possible interpretations of what slow means in that specific context, such as input lag or long loading screens.
Hypothetical example
Imagine the only feedback says, “The search bar is useless because it does not have a date filter.” Ask the model to separate the reported complaint, proposed explanation and questions requiring research. A suitable answer records dissatisfaction with search and the requested date filter, then asks what the person tried to find and what happened. A possible design question is “How could we help this person find the intended dated material?” That question remains provisional until the goal is confirmed. The reviewer rejects statements that all users struggle or that adding a filter would solve the problem.
Verifying the Design Question
Once the AI provides the design question, check the result to ensure it does not contain any prescriptive language. If the question still mentions a specific tool, like a filter or a button, it has failed to separate the problem from the solution. A successful deliverable is a question that describes a desired outcome without dictating the method of achievement. Ensure the question is broad enough to allow for experimentation but specific enough to be measured. The final check is to ask whether a designer could come up with three entirely different ways to solve the question; if only one solution seems possible, the question is likely still too tied to the original complaint.