An innovation workshop can produce dozens of ideas, while the available time and experiment budget can support only a few. A committee may favour the newest technology or the strongest presentation even when the underlying problem and route to testing value remain unclear. A better selection question is: which experiment would help us make a more informed decision, at a cost and level of risk proportionate to what we need to learn?

Selecting an idea for a test does not authorise full implementation. It permits a bounded investigation of an important hypothesis. A short idea card can organise that decision around four elements: the problem, the hypothesis, expected value and testability. The model below is a practical proposal to adapt, not an official standard or a guarantee of success.

Start with a problem worth understanding

Instead of “a new beneficiary app,” describe who faces a difficulty, when it occurs and why it matters. For example: “Some beneficiaries need to reschedule an appointment but do not know whether their existing booking remains available while they search.” This wording leaves room to investigate content, procedure and interface without assuming that a new application is the answer.

Add initial evidence: an observed task, a recurring enquiry or operational data with clear definitions. Separate observation from interpretation. Repeated calls might indicate unclear instructions, but they might also reflect a delayed system. If the problem itself is unverified, the first activity should investigate it. Internal enthusiasm is not a substitute for evidence from affected people.

Write a hypothesis that could be wrong

A useful hypothesis connects a change, an expected result and a reason: “Explaining that the existing appointment remains booked until a replacement is confirmed may help beneficiaries select another slot more confidently.” The team can test comprehension and behaviour, while checking that the real process supports the statement.

Avoid “the technology will improve the experience.” Identify the assumption that could undermine the idea: do users need the change, are alternative appointments available, and can operations retain the original booking until confirmation? If the last assumption is false, clearer wording alone cannot solve the problem. Test important uncertainty, not merely the easiest component.

Describe value without promising it

Expected value might mean completing a necessary task, reducing rework or making a decision understandable. Specify who benefits and how that benefit becomes visible. “A better experience” is less useful than “rescheduling without unnecessary assistance while keeping cancellation clear and intentional.”

Separate beneficiary value, operational value and implementation cost. Fewer calls do not demonstrate improvement if help has become harder to obtain. Removing an interface step may simply transfer work to an employee. Pair an outcome measure with a safeguard against potential harm. Treat estimated savings or adoption as estimates, recording their basis, range and reasons they might not materialise.

Give every idea the same card

A common card helps reviewers compare substance rather than presentation skills. Use language a service owner, operational representative and researcher can understand.

Element	What to record	Review question
Problem	Beneficiary, situation, difficulty and initial evidence	Is the problem evidenced or assumed?
Hypothesis	A specific change, expected outcome and plausible reason	What evidence could challenge our expectation?
Value	A beneficiary or operational benefit and an interpretable measure	Are we measuring an outcome or just activity?
Testability	Question, method, resources, limits and next decision	Could the result change a real decision?

 

Add an owner, time limit, data source, dependencies and stop conditions. A simple tool is sufficient if versions, decisions and evidence remain traceable. The number of completed cards is not itself a measure of innovation success; their purpose is to improve experiment selection and explain decisions.

Conceptual illustration of recording the problem, hypothesis, value and test consistently.

Match the test to the question

Nesta’s Standards of Evidence recommends evidence proportionate to the innovation’s stage, with a coherent account of intended value important early on [3]. Its guide to testing methods distinguishes approaches such as proof of concept, prototyping and pilots according to what teams need to learn [4]. These are methodological references, not Saudi regulatory obligations.

If the question concerns understanding instructions, a prototype and realistic task may suffice. Technical integration may need a focused feasibility test. A change to a live service requires an appropriate measurement design, comparison and operational safeguards. Do not build a complete product to answer a smaller question, or treat appreciation of a prototype as evidence of actual future use.

Prepare experiment data before involving participants

In a Saudi organisation, first decide whether the experiment needs real personal data at all. Interface comprehension can often be tested with fictional appointments and records. If real records are anonymised, removing names alone is insufficient: the implementing regulation requires checking that individuals cannot be re-identified [5].

Define who can observe sessions and receive the findings, and separate task observations from unnecessary participant information. Before changing a live service, record the service owner’s authorisation, impact boundaries and recovery route. These responsibilities belong in test feasibility rather than being postponed until an idea has been selected.

An illustrative rescheduling experiment

Suppose a team decides to test a prototype explaining that the current appointment remains booked until a replacement is confirmed. Every detail in this example is hypothetical; it describes no client project or result. The team might allow one week for task sessions with eight relevant participants, using fictional appointments and data without changing live bookings.

Before testing, it records two questions: do participants understand when the booking changes, and can they distinguish rescheduling from cancellation? An illustrative working threshold might be six of eight completing the task without facilitator hints, with no unintended cancellation in the scenario. This is a practical criterion for improving the prototype, not statistical proof of impact or an expected success rate across all beneficiaries.

If understanding fails, revise the hypothesis or wording. Successful tasks would justify operational checks and an appropriately designed broader test, not automatic scaling. If alternative slots are unavailable, the team may need to investigate capacity policy instead. The experiment has then revealed a more important question.

Compare learning opportunities as well as value

When selecting experiments, assess strategic relevance, evidence of the problem, importance of the assumption and whether a useful answer is achievable with bounded resources. Treat safety, data access and implementation authority as prerequisites. A highly attractive idea cannot compensate for their absence.

An idea with moderate potential value may deserve an earlier test if it resolves an imminent decision. A more ambitious idea may need additional discovery because its proposed test cannot distinguish success from failure. A committee can record three decisions: test now, obtain specified evidence, or do not proceed with reasons. For close choices, ask which test reduces uncertainty affecting other decisions, while preserving room for unconventional ideas rather than always favouring the easiest.

Conceptual illustration of ending an experiment with a decision to continue, adjust or stop.

Close with a traceable decision

Keep the pre-test expectation, observations, limits of the participants or environment, and what the team learned. Do not quietly redefine success after seeing the results. If a new question emerges, make it a new experiment. Connect scaling to appropriate evidence, operational needs and resources; stopping an unsuitable idea can be a useful learning outcome.

RMG’s Innovation Strategy Development and Institutional Innovation Framework Development services connect innovation direction with plans, success criteria and working processes [1, 2]. A practical conversation can begin with a few ideas, each supported by a problem, hypothesis, test and next decision. Those elements make experiment selection reviewable and give innovation a process that evolves with evidence.