From a promising idea to a testable concept

A testable concept explains who an idea is for, what would change for them and how the proposed product or service would work. It is specific enough for someone to question, compare or try, while keeping untested assumptions visible. You do not need a finished specification. You do need more than a memorable name and a list of features.

Consider the equipment-hire business from our articles on brainwriting and idea evaluation. Its team wants customers to know that their reserved kit is ready before travelling. “Build a readiness app” is an idea. A concept must explain what ready means, who establishes that status, how the customer receives it and what happens when the kit is not ready. The business and all events below are fictional.

Start with a situation, not a solution category

“Busy customers” is too broad to guide a concept. A more useful starting point is a person trying to do something under particular conditions: a small contractor collecting hired equipment before a morning job, with limited room to rearrange transport. That description suggests questions about timing, reliability and the cost of a wasted journey.

Keep the starting description separate from the proposed solution. The contractor might need dependable confirmation, not another account or another app. A call, a text message or a better preparation routine could all contribute. If you put the preferred technology inside the problem statement, you have already narrowed the answer.

GOV.UK’s introduction to user research emphasizes understanding what people are trying to do, their existing approach and their wider context. It also includes the people who provide or support the service. Applied here, that means looking at both the collection journey and the staff work that makes a reliable confirmation possible.

Use actual research when you have it. Otherwise label the situation as a working hypothesis and arrange customer interviews or observation. Do not turn an internally invented persona into evidence by giving it a name and a photograph.

Write the benefit in the customer’s terms

A feature describes something offered. A benefit describes why that offer could matter. “Automated status notification” is a feature. “Find out about a missing item before setting off” is a proposed benefit. The second statement is easier to challenge: does the message arrive early enough, and does the customer have a useful alternative?

Strategyzer’s Value Proposition Canvas distinguishes the customer’s situation from the offer designed to address it. Its current guidance also treats the match between them as something to test. The useful discipline is not filling every space on a canvas; it is making the connection between a need and a proposed response explicit.

For the hire business, a working concept sentence might be: “For contractors collecting a reserved kit, a pre-collection confirmation reports whether the complete set has been checked and put aside, so they can decide whether to travel or contact the branch.” This is an original example, not a validated formula.

Notice the modest promise. The service does not guarantee an uninterrupted working day. It proposes a more informed collection decision. If the team cannot reliably reserve the checked equipment, even that smaller promise may be too strong.

Describe the experience and the work behind it

Walk through one ordinary use from beginning to end. What triggers the service? What does the person see or receive? What action can they take? What happens next? Include the handoff back to the organization rather than ending the story at a screen.

In our example, a branch employee checks the reserved kit, marks any missing accessories and puts the complete set in the collection area. A message then tells the customer what has been confirmed and how to raise a problem. At collection, staff match the reservation to the prepared set. A notification without those supporting steps would describe communication, not a dependable service.

Then walk through one exception. Suppose a damaged accessory is discovered after confirmation. Who changes the status? Who contacts the customer? What is the fallback if the message is not delivered? You do not need to solve every exception now, but the concept should reveal where its promise depends on someone doing additional work.

For a physical product, make the same distinction between the visible object and the conditions of use: installation, storage, replenishment, maintenance or disposal may matter. For an internal service, consider the colleague who must maintain the information after the project team leaves.

Avoid specifying everything at the same level of detail. The meaning of “ready” is central to this concept. The colour of a button is not. Spend the early effort on decisions that could invalidate the benefit or materially change delivery.

Keep a real alternative in view

An idea can become more persuasive simply because it is the only one anyone has made concrete. Develop a credible alternative far enough to compare its operating logic, not just its appearance. The Design Council’s Double Diamond separates understanding and defining a challenge from developing and testing responses; it also recognizes that learning can send a team back to the problem.

The hire business could describe two concepts. One sends confirmation after every kit check. The other contacts customers only when the check reveals a problem. Both depend on preparation, but they create different expectations and different amounts of communication. A third possibility is improving the collection promise itself if readiness cannot be established before customers normally leave.

Compare these versions against the same situation. What can the customer reasonably infer from silence? What work does each create at the branch? Which assumptions differ? Do not combine every attractive feature into a single large proposal before understanding those trade-offs.

An alternative can also be a change to the existing process without a new product. Making that option explicit helps the team ask whether the proposed technology is doing necessary work.

Build a concept brief someone else can question

Use a short, dated brief that travels with the concept. The following is a suggested working format, not an official canvas or a scoring instrument. It should be readable by a colleague who missed the workshop.

Part of the brief	Fictional readiness-service example
Person and situation	Contractor collecting a reserved kit before a job
Problem to investigate	Travelling before a missing item becomes known
Proposed benefit	A clearer decision before leaving for the branch
Service promise	Confirmation of a checked, reserved set, with a contact route
Supporting work	A named checker, an identifiable prepared set and a way to update status
Boundary	One branch and selected reservation types during investigation
Uncertainty	Whether confirmation can arrive before customers usually leave
Next decision	Whether to revise the timing, narrow the offer or test a fuller interaction

Add the source of each important belief beside the brief or in a linked evidence note. Distinguish what someone reported, what the team observed and what it inferred. A complaint about a wasted journey supports investigating the problem; it does not prove demand for the concept.

Give the brief an owner and a version date. Record meaningful changes rather than silently replacing the original promise. If the audience changes from occasional contractors to large repeat accounts, revisit the research basis as well as the wording.

Turn uncertainty into a testable question

Read each part of the brief and ask what must be true. The customer must understand the message. The branch must establish an accurate status. The timing must leave room for action. The preparation work must be sustainable. These are different assumptions and may need different forms of evidence.

Use assumption mapping to choose a consequential uncertainty, then match the test to it. A paper message can help investigate interpretation. A walkthrough with staff can expose an unclear handoff. Neither demonstrates that a live service will work reliably across branches.

GOV.UK’s prototyping guidance describes representations ranging from sketches to interactive code. The practical implication is to choose enough realism for the question, not the most impressive prototype available. A polished interface can consume attention that the underlying service promise still needs.

For our fictional team, the first question is whether customers could act on a confirmation at the proposed time. They could walk through recent collection journeys, place the proposed message within those timelines and ask participants to explain what they would understand. Any imagined response remains weaker evidence than observing actual behaviour in a suitably controlled later trial.

Write down what the team will record and what findings would change the concept. If confirmation normally comes after customers have left, improving the wording does not address the main issue. If staff cannot define a stable readiness status, pause the customer-facing promise and investigate preparation first.

Do not call the concept validated because participants understand it or say it sounds useful. Comprehension, preference, repeated use, operational reliability and commercial viability are separate questions. Each deserves evidence proportionate to the next commitment.

Know when the brief is doing too much

Concept development is useful between a loose proposal and a decision to investigate or build something more substantial. It is less useful as a paperwork exercise for an already understood, minor correction. Nor should it postpone repairing a clearly identified service failure that needs immediate attention.

There are important limitations. A coherent brief can make an unsupported idea look mature. Workshop agreement can conceal disagreement about resources. A small prototype cannot establish market size or long-term economics. Safety-critical or regulated products need qualified review and appropriate testing beyond this approach.

The workflow here is a practical synthesis of design and service-development guidance, not an experimentally validated sequence. Adjust its depth to the cost of being wrong. A low-risk internal convenience and a new customer commitment should not receive identical treatment.

Finish with a decision, not just a document: continue with a named test, revise a specific assumption, return to the problem, or stop. A useful concept makes the next uncertainty easier to investigate. It does not make uncertainty disappear.