Choose a Product Prototyping Agency by Naming the Decision First

A product prototyping agency should start with one expensive decision

The first deliverable should be a sentence, not a screen: “We need to decide whether this workflow is understandable enough to build.” That sentence identifies who will use the prototype, what they must try and what the team will do with the result.

Imagine a hypothetical B2B platform that lets finance managers approve supplier payments. The risky question is not whether a dashboard looks credible. It is whether a manager can identify an unusual payment, inspect the evidence and approve or reject it without accidental action.

The GOV.UK Service Standard recommends quick, throwaway prototypes to test hypotheses before teams lock onto a solution. A product discovery workshop should come first if the team still disagrees about the problem, user or decision.

Choose prototype fidelity from the risk, not the presentation

Higher fidelity is not automatically better. A sketch can settle page order in an hour, while code may be necessary when the question depends on responsive behavior, input states or a realistic handoff between systems.

For the payment example, a clickable design can test whether managers find the evidence. A coded prototype may be justified only when the team needs to test keyboard use, loading states or the transition from review to approval.

GOV.UK’s prototyping guidance says to choose the format that meets the current need and warns that prototype code may not meet production standards. Ask the agency why each extra layer of realism changes the evidence you can collect.

Write the test task before the agency designs the happy path

A useful prototype gives a participant a believable goal without telling them where to click. If the task says “use the warning panel to reject this payment,” the test measures obedience. If it says “decide whether this payment should proceed,” the participant must find and interpret the evidence.

The GOV.UK guide to moderated usability testing says tasks should have a clear goal, feel relevant and avoid giving away the answer. The agency should write tasks, recruitment criteria and observation notes before the first session.

For a complex workflow, ask for the normal case, a plausible exception and a recovery case. The payment prototype might include a routine invoice, a changed bank account and an accidental approval that the participant must undo.

The proposal should connect every prototype screen to evidence

A comparable proposal names the research question, participant group, task, prototype boundary, observation method and decision rule. “Interactive prototype with five screens” tells a buyer almost nothing about what the engagement will resolve.

The Design Council Double Diamond separates understanding and defining a problem from developing and testing possible answers. An agency should show where the engagement begins, which assumptions are already supported and which remain open.

For the finance workflow, one screen may need three variants because the evidence hierarchy is uncertain. Another screen may need none because it only confirms a completed action. Effort should follow risk, not page count.

• Decision: what will the team build, change or stop after the test?
• Participants: which real behaviors, roles or access needs must be represented?
• Tasks: which normal, exceptional and recovery journeys will people attempt?
• Evidence: what will be observed, recorded and compared across sessions?
• Boundary: which integrations, data and production qualities are intentionally simulated?

Demand a decision record, not a theatrical handoff

The final meeting should not be a tour of screens. It should show what participants attempted, where behavior changed, which findings repeated, what remains uncertain and which product decision follows.

A hypothetical result might show that four finance managers found the bank change, but only one understood why the supplier was flagged. That supports keeping the evidence visible while changing the explanation. It does not prove a percentage improvement or justify an automatic payment block.

GOV.UK advises teams to define actionable research objectives and decide what they need to know before choosing what happens next. A specialist UX research agency may be the better purchase when recruitment, sensitive contexts or longitudinal behavior matter more than making the artefact.

Prototype code is evidence until production engineering proves otherwise

The seductive mistake is to treat a realistic prototype as the first version of the product. A prototype can omit authentication, permissions, data integrity, monitoring, performance and recovery because those details may not be part of the current question.

In the payment example, simulated approval can be safe during research. Copying that route into production without authorization checks would be reckless. GOV.UK explicitly warns teams not to copy prototype code directly into a live service.

If production reuse matters, ask the agency to label every component as disposable, reference-only or a candidate for engineering review. A web app development agency proposal should price the real system separately, including roles, integrations and operating ownership.

Use this checklist before selecting a product prototyping agency

A strong proposal lets another team understand the learning plan without seeing the prototype. Use the checklist below before approving scope.

• The proposal names one decision and the cost of getting it wrong.
• The participant criteria match the people who face that decision.
• The tasks include a normal case, an exception and a recovery path where relevant.
• The chosen fidelity is justified by the evidence it enables.
• The plan states what is simulated, excluded or unsafe to reuse.
• The final deliverable includes findings, limits and a build, change or stop recommendation.

Bring Seuil the decision that still feels expensive

If a team is debating a feature, workflow or product direction, send Seuil the decision, the people affected and the evidence currently missing. That is enough to identify the smallest credible prototype and decide whether prototyping, research or an AI proof of concept is the right next step.