Customer interviews are dangerously satisfying. Everybody has spoken. The transcript is full. Several sentences have been highlighted. A quotation has been promoted to a slide. Research, it would seem, has occurred.
Then somebody asks what the product should do.
That was the difficult part of my work on an AI co-pilot for contract negotiation. Procurement, Legal, Finance, category managers and operations teams could describe where deals stalled, which concessions made them nervous and why a commercially attractive decision could become rather less attractive once delivery, liability and ESG entered the room.
The difficulty was not getting people to talk. It was turning what they said into something a product could reliably do.
An interview gives you material. It does not automatically give you an insight, a requirement or a design decision. Those have to be made with enough discipline that a memorable quote does not acquire the constitutional power to redesign the product on its own.
The interview is the beginning of the work
Before the research, the brief could be summarised rather neatly: create an AI co-pilot that helps people negotiate contracts.
It also concealed nearly every important question.
What exactly should the co-pilot help with? Finding precedent? Comparing terms? Recommending a counter-offer? Writing an email? Making the decision? If it recommended a position, what evidence would make the recommendation credible? Which concessions could it propose, and where should it stop? What would Legal need to approve the result? What should be retained afterwards for audit and training?
Asking users which AI features they wanted would have produced a lively catalogue and perhaps a tasteful sparkle. Instead, I asked participants to walk through their last stalled deal. Who needed convincing? Which evidence was missing? What had to be known before signing? Where should AI never act alone?
That shift—from imagined feature to recent behaviour—changed the evidence. People reconstructed the work: the email to Legal, comparable deals, the call to Operations, uncertainty around delivery cost and the point at which a buyer’s authority ended.
This is why the Nielsen Norman Group recommends concrete research goals focused on specific behaviours and attitudes. “Learn what users think about AI” produces interesting conversation and little direction. “Understand what evidence a buyer needs before countering a supplier” is narrow enough to change a design.
The useful unit is a decision, not a quote
The co-pilot became clearer when I stopped treating the interview transcript as the product’s input and started treating decisions as the unit of analysis.
For each important moment, I asked:
What decision is the person trying to make?
What evidence do they use today?
Which trade-offs must remain visible?
What makes the decision unsafe or unauthorised?
What should happen after the decision is made?
In the case study, this exposed a recurring structure. A buyer was not merely asking, “Is this a good deal?” They were choosing between accepting the supplier’s package, countering with different terms or holding the current position. They needed comparable deals, commercial impact, delivery consequences, clause-level risk and a clear view of their mandate. Legal, Finance and ESG needed the same evidence, but for different reasons. The outcome and rationale then needed to remain on the deal record.
The design response was not a more persuasive chat window. It was a stable decision workspace.
That workspace kept three negotiation paths visible at once. It gave each option equal weight, placed consequences in a consistent order and attached evidence to the recommendation. Approve, counter and escalate were not decorative actions beneath an AI answer; they represented the actual authority model of the work.
This was the most important move from research to product: a collection of opinions became a model of a decision.
Customers rarely describe the interface you actually need
An early concept used a conversational thread. This was entirely defensible. The product contained AI; chat is a familiar AI pattern; the industry has spent considerable effort training us to place a text box beneath anything remotely intelligent.
The interviews made its weakness obvious.
Buyers had to hold one option in mind while reading the next. They repeated questions about ESG because the answer had drifted out of view. They scrolled backwards to recover actions and evidence. Conversation was flexible, but the decision was comparative. The format required users to provide the memory that the interface had failed to provide.
The research did not produce a sentence saying, “Please replace this conversation with three identically structured cards.” It revealed behaviours—backtracking, repeating, holding values in memory—and those behaviours implied a design principle: the alternatives needed a stable, visible home.
This is why synthesis demands judgment. Customers are experts in their work and experience. They should not be expected to arrive with a completed interaction model tucked discreetly behind the transcript. The designer’s responsibility is to preserve the truth of the problem while exploring a better form for the answer.
Look for constraints, not just requests
The most actionable interview material was often a boundary.
Participants needed the AI to explain why it recommended a counter-offer. They needed to inspect comparable agreements and assumptions. They needed to know when the system had reached the edge of the buyer’s mandate. They needed escalation to feel like control, not failure. And they needed a record of the evidence and rationale after the decision.
Those needs became three product requirements:
Visible reasoning: show relevant precedent and assumptions so a recommendation can be challenged.
Clear authority: define what the co-pilot may suggest or do, and when a person must take over.
Auditability: retain the evidence, assumptions and rationale behind the chosen position.
These are more durable than a feature list. A feature can change shape; the constraint it serves remains useful. “Add an evidence drawer” is a solution. “A reviewer must be able to verify the recommendation without leaving the decision” is a rule against which several solutions can be tested.
Constraints are particularly important in AI products because the happy path is unusually persuasive. A prototype can generate a confident recommendation long before the team has decided what confidence means, who carries responsibility or how a mistake will be corrected. The interview work must locate those boundaries before visual polish gives the system more authority than it has earned.
Make every finding earn its place
I now find it useful to push each significant finding through a short chain:
Observation → Meaning → Product consequence → Test
For example:
Observation: buyers repeatedly move between a deal, comparable contracts and messages from other teams.
Meaning: confidence depends on connected evidence, not merely the AI’s explanation.
Product consequence: keep comparable deals beside the recommendation and preserve context when users return.
Test: can a buyer identify the evidence behind a recommendation, challenge an assumption and resume the decision after an interruption?
Or:
Observation: buyers may have four hours to move a negotiation forward, much of it spent waiting for other teams.
Meaning: the first read must be fast, but the supporting detail cannot disappear.
Product consequence: design for a ten-second orientation, progressive evidence and a stable deal state.
Test: can participants understand the deadline, compare the paths and find the escalation route without being coached?
This prevents insights becoming tasteful wall art. If a finding cannot influence a decision, change a design or define a useful next question, it
may still be interesting—but it is not yet carrying product weight.
Prototypes are part of the analysis
Synthesis did not finish when the notes were grouped. Working prototypes became a way to continue it. A conversational approach and a structured workspace could be placed in front of users rather than debated as abstractions. Testing revealed the memory burden of chat, the need to keep three paths visible and the importance of putting evidence close to the final action.
The early workspace was not right either. It placed charts before the reasoning and clipped the third option. Each prototype expressed a theory about the research, and each session showed where that theory failed.
This is a healthier relationship between research and design than treating interviews as a requirements vending machine. Research frames the problem. Design proposes a response. Testing produces new evidence. The team learns by moving between them.
Actionable does not mean obedient
There is a small danger in demanding that all research be actionable: teams may only value findings that fit the current sprint. Action might instead mean changing the roadmap, challenging the proposition, measuring an unknown or admitting that the original brief was wrong.
In the co-pilot work, the reported results—31% faster offer closing, 82% recommendation acceptance and a System Usability Scale score of 71—were encouraging. They did not prove that every accepted recommendation produced a better commercial outcome. That distinction generated the next research questions: repeat use, overrides, disputes, review workload and realised outcomes over time.
An acceptance rate is a behaviour. Whether accepting was wise is a different question. Do not stop at what happened; ask what it means, what it changes and what evidence would prove the response was better.
Better interviews end in better decisions
Customer interviews were essential to designing the co-pilot. Without them, the product could easily have become a fluent assistant with weak evidence, vague authority and an impressive ability to make contract risk sound reassuring.
But the value did not come from the conversations alone. It came from turning them into a model of the work: three visible paths, comparable evidence, explicit trade-offs, authority boundaries and a durable decision record.
That is the less photogenic part of user research. The transcript is only raw material. The insight is an interpretation. The requirement is a choice. The prototype is a test of that choice. The product is what remains after reality has objected several times and the team has listened properly.
Customer interviews do not tell you what to build.
Done well, they tell you what the product must help somebody understand, decide and safely do next. That is harder to extract than a good quote. It is also considerably more useful.
An interesting comment is not yet an actionable finding
One of the strongest research themes was that a headline saving could disguise a worse overall deal.
A supplier might offer a five per cent discount while also weakening liability protection, removing ESG reporting and moving delivery by eight weeks. Everybody understood the principle. The hard part was deciding what the interface should do with it.
“Users care about trade-offs” is true, but inert. It does not tell a team what to design. The finding became actionable only when it was translated into a product response:
show the net consequences of every option together;
use the same field order so alternatives can be compared without mental gymnastics;
place ranges and assumptions beside the recommendation;
make delivery, liability and ESG visible alongside headline saving;
explain what would cause the recommendation to change.
Now there was something to prototype and test.
That distinction matters. Raw observations describe what happened. Findings explain what the observations mean. Product implications state what must become possible. A design hypothesis proposes how the product might make it possible. When those layers collapse into one another, teams leap from “a participant said this” to “therefore we need a dashboard”, usually with the confidence of a detective who has found one footprint and already chosen the culprit.
The GOV.UK Service Manual’s guidance on analysing research makes this progression explicit: organise observations, determine findings, then decide actions. It is not glamorous, but neither is discovering that the roadmap was built from three eloquent anecdotes.
