Innovation
How to design a low-cost process improvement test
Test one process change before expanding it: record the current handoff, compare a small trial, check hidden work and decide what to keep, revise or stop.
Make the next decision smaller than a full rollout
A process improvement can begin with a modest question: would a clearer handoff remove one recurring difficulty? You do not need to replace an entire workflow to examine that question. You do need to know what is changing, what you will observe and how you will return to the previous arrangement if necessary. Low cost should describe a limited commitment, not an excuse to ignore the people doing the work.
This guide offers an original editorial exercise within the George Antonio Nehme publication's innovation theme. It is not an account of his personal experience. The aim is to design a small, inspectable test and make its limits visible before deciding whether to extend it. It does not promise savings or establish a research standard.
Describe one difficulty in the current process
Choose a task with a recognizable start and finish. Instead of writing communication is inefficient, identify the point where information is missing, a request returns for clarification or a person cannot tell who should act next. Record what normally arrives at that point and what the next person needs to continue.
For a hypothetical example, imagine a small design team passing approved work from a coordinator to a production colleague. The request sometimes lacks a clear approval reference. The colleague asks a follow-up question before starting. This fictional situation gives the test a specific focus: whether an explicit approval field makes that handoff easier to understand. It says nothing about a real organization's performance.
Keep a usable record of the starting point
Before introducing the change, inspect a limited set of ordinary handoffs using the current method. Write down which information was available, whether clarification was needed and what work happened outside the main request. If you record time, define the start and finish consistently and distinguish active work from waiting. Otherwise, a shorter elapsed period may simply reflect a quieter day.
Keep the record proportionate to the decision. You are not building a surveillance system or a ranking of colleagues. Describe the process difficulty without collecting unnecessary personal information. Explain to the people involved what you are examining and invite them to identify work that the record might miss.
Change one part and state what remains unchanged
For the design-team example, the proposed change could be one field that identifies where approval is recorded. Keep the delivery tool, review responsibility and definition of ready work unchanged during the first trial. If several changes are introduced together, the test will not let you clearly separate their contributions. A useful result may still emerge, but the explanation must reflect that limit.
GOV.UK's guidance on the alpha phase describes focusing a prototype on an uncertain part rather than reproducing an entire service. That is a helpful reference for limiting scope here, not a requirement that a small team adopt government delivery phases. Choose the smallest version that can expose the specific difficulty you want to understand.
Set the boundary, owner and pause condition
Write a short test brief before anyone starts. Name the handoff being examined, the person coordinating the trial, the intended review point and the work that is outside scope. Decide who can pause the trial and how requests will return to the established method. A shared document or temporary template may be sufficient; buying a tool is not the starting requirement.
For an initial walkthrough, use fictional requests if real material would create unnecessary exposure. Do not turn the exercise into an unapproved change to a customer-facing or high-consequence process. If the test depends on another team's responsibilities or access, agree those boundaries first. A low-cost experiment still needs appropriate permission and care.
Give the task without explaining the answer
Ask someone who would normally receive the handoff to work through the trial request. Explain the goal, such as deciding whether the request is ready for production. Avoid pointing directly to the new field before they have examined the material. If you must explain every step, record that assistance rather than treating the task as independently completed.
GOV.UK's moderated usability testing guidance recommends clear, realistic tasks that do not reveal the intended route to completion. This exercise borrows that limited principle; it is not a substitute for a complete usability study. Ask what information the person relied on and where they were uncertain. Keep observations separate from your interpretation of why a difficulty occurred.
Compare the handoff and inspect the work around it
Use the same observation fields for the original method and the trial. In the fictional example, note whether the receiver could locate approval, whether a clarification was needed and whether the coordinator had to duplicate information elsewhere. Also ask whether the change made an exception harder to manage. A cleaner request can still move effort into a different part of the workflow.
Do not report an early trial as proof that the new field caused a general improvement. The requests, workload or participants may differ. Record those differences and narrow the conclusion accordingly. The useful finding might be that the field is understandable, that its wording needs revision or that the real obstacle lies in how approval is obtained rather than how it is recorded.
Choose a next step and retain the learning
At the review point, decide whether to stop, revise the change or continue with a further limited trial. Explain the reason using the observations, not just a preference for the new format. If the information is inconclusive, identify what another test would need to distinguish. An inconclusive result does not require pretending the idea succeeded or abandoning it without explanation.
Keep a brief record of the original difficulty, the changed step, the conditions observed and the decision. Note who would maintain the method if it were extended. Connect the next test to the innovation guide, and use the journal's proposal-assumptions and reflection articles when the question shifts toward planning or reviewing experience. The goal is a better-supported next choice, not an impressive rollout announcement.
Sources and context
- George Antonio Nehme — innovation and continuous learning profile
- GOV.UK Service Manual: How the alpha phase works
- GOV.UK Service Manual: Using moderated usability testing
This is an editorial guide, not a statement of personal experience by George Antonio Nehme.
