From Research to Requirements: Using AI Without Inventing User Needs

A persuasive summary is not the same as research evidence. AI can turn an untidy set of notes into themes, questions and draft requirements. It can also smooth away disagreement, invent a quotation or give an unsupported assumption the appearance of a finding. For designers and developers, the useful question is not whether a summary sounds convincing. It is whether every important decision can be traced back to something real.

Separate observations, interpretations and proposals

Start with three explicit categories. An observation records what a participant said or did. An interpretation suggests what that might mean. A proposal describes what the team could change. Keep these separate even when one tool produces all three.

Consider an illustrative document-upload flow. A participant repeatedly checks whether an upload finished. That is an observation. “The completion state may not be clear” is an interpretation. “Add a persistent completion message” is a proposal. “Users need an AI document assistant” does not follow from that evidence.

This distinction gives both disciplines something concrete to challenge. A designer can question whether the interpretation accounts for the whole session. A developer can ask whether latency, rather than the visual treatment, caused the confusion. Neither needs to accept the first generated explanation.

Give the model a bounded research task

Use only research material you have permission to process. Remove unnecessary identifiers, check the tool's data-handling terms, and preserve a controlled copy of the original evidence. Redaction should happen before material reaches an unapproved service, not after a summary has already exposed it.

A useful instruction is:

Group these de-identified observations into possible themes. Reference the supplied observation IDs for every theme. Preserve conflicting evidence. Do not invent quotations, participant attributes or prevalence. Put unanswered questions in a separate section.

Observation IDs are more useful than an instruction to “be accurate.” They make verification possible. Ask for a table containing the proposed theme, supporting IDs, contradictory IDs and open questions. Then open the original notes and check each connection. A citation generated by the model is a claim to verify, not proof by itself.

Use synthetic perspectives as prompts, not participants

A model can suggest interview questions or imagine reasons a workflow might fail. That can help prepare a study. It does not establish what actual people need.

NN/g's comparison of synthetic and human respondents found that generated responses could reproduce a broad conclusion while missing the variation in human answers. This is a warning against treating plausible agreement as representative evidence. The study is not a universal score for every model or research method, but its limitation matters: uncommon perspectives may contain the most important design problems.

Label generated scenarios as hypotheses. Do not mix synthetic statements into participant quotes, research counts or evidence repositories. A developer imagining a slow network and a designer imagining a distracted user are contributing useful possibilities; neither has conducted a usability study by doing so.

Translate a finding into a testable requirement

For the upload example, a draft requirement might say: “After the server confirms successful storage, show a persistent completion state associated with the uploaded document.” It should also specify what happens while processing continues, when the request times out, and when storage fails.

Attach the evidence, the unresolved assumption and a validation plan. The assumption might be that visibility is the main problem. A follow-up usability session can test whether people correctly understand the difference between uploaded and processed. Engineering checks can verify that the interface never shows completion before the corresponding backend event.

Ask AI to critique the requirement for ambiguity, not to declare it validated. “Which terms could be implemented in more than one way?” usually produces a more useful review than “Is this good UX?”

Checklist before a requirement enters delivery

• Trace each finding to original, permitted evidence.
• Separate observed behaviour from interpretation and proposed features.
• Preserve outliers and contradictory accounts.
• Label synthetic scenarios and unresolved assumptions.
• Agree on observable acceptance criteria with design and engineering.
• Decide how real users and technical checks will validate the change.

AI can reduce the clerical effort around research. The team still owns recruitment, interpretation, consent and the decision about what evidence is strong enough to build on. A clear evidence trail makes those responsibilities easier to share.