Before You Build, Test the Assumption That Could Break the Idea

01Separate a promising idea from its fragile assumptions

Imagine a service owner considering a customer portal. The proposed features sound sensible: request a visit, upload photographs, track progress and receive documents. It is tempting to start choosing a platform. But the idea depends on several assumptions that software cannot settle by itself.

Will customers have the information needed to submit a useful request? Will the team respond through the same process? Can a photograph support the decision being asked of it? Does the customer even need an account for an occasional interaction?

List these assumptions before building. Prioritize the ones that are both uncertain and consequential. The first prototype should investigate a question whose answer could materially change what you make—or whether you make it at all.

02An illustrative example: the request that arrives incomplete

Consider an illustrative equipment servicing company. It receives requests with missing model details, unclear symptoms and no indication of access constraints. The team proposes a portal to reduce the back-and-forth. The risky assumption is not that customers enjoy attractive screens. It is that a guided request can collect useful information without making the task too difficult.

A first prototype could be a simple form followed by a manually prepared response. It needs no account system or automated scheduling. Use realistic, consented scenarios and avoid collecting sensitive information that the test does not require. Explain that the process is a trial and which parts are handled manually.

Ask participants to submit a request using information they can actually obtain. Observe where they pause, what they misunderstand and what they cannot provide. Then ask a service team member to work from the resulting request. The form succeeds only if the information is useful on both sides of the interaction.

03Define what an observation would change

Before running the exercise, write down the decision you face. Perhaps you need to decide whether to require a model number, offer photo assistance or provide a “not sure” route. State what observations would support each option.

If participants cannot locate the model number, making that field more prominent may not solve the problem. If technicians still need a call to understand the symptoms, the form might be useful for triage rather than diagnosis. If completing it takes more effort than calling, the right design might be a short callback request.

Record observable behaviour separately from interpretation. “Participant left the model field blank” is an observation. “Customers do not care about accuracy” is an unsupported explanation. Follow-up questions can help establish the reason, but should not steer the participant toward defending the design.

04Match the prototype to the question

A paper sketch can test the order of a conversation. A clickable screen can reveal navigation problems. A manually delivered service can expose handoffs. None automatically proves that the final system will be reliable, affordable or usable at scale.

This is also the counterexample to “always start with the cheapest prototype.” If the uncertainty concerns integration reliability, a paper sketch is inadequate. If it concerns accessibility with assistive technology, a decorative mock-up cannot establish working accessibility. Build enough fidelity to answer the chosen question, and be explicit about what remains untested.

Manual work can temporarily stand in for automation, but its effort must be recorded. Otherwise a seemingly smooth trial can conceal an operating model that would overwhelm the team.

05Finish with a decision, not a gallery

Bring the observations back to the original assumption. Continue, revise, narrow the offer or stop. A small qualitative test can expose important problems; it cannot establish how common those problems are across the whole market.

In the illustrative example, the result might be a shorter request form and a clearer callback process, with no portal needed yet. That would be a useful outcome. The purpose was to improve the service, not to justify the feature list.