Testing a mobility product: design the trial with the people doing the work

A field test enters a working environment with existing obligations. Vehicles still need care, Captains still need understandable arrangements, and customers still expect the agreed service. The test therefore needs two plans: how the team will learn, and how everyday work will continue while it learns.

Builders approaching Sparrow Mobility Labs can make the conversation more useful by stating both. Access, participation and responsibilities would need to be agreed for the particular setting; a promising idea alone does not establish that a live trial is ready.

Choose a question that fits the setting

Define the decision the test should inform. “Should this handover tool enter a wider trial?” is more useful than “Does the technology work?” because it brings users, workflow and the next commitment into view. Specify which location, vehicle group and working window are included.

HM Treasury’s evaluation guidance recommends planning evaluation early and choosing evidence around the question. Apply that principle proportionately: establish the current process, identify what will change and decide what observations are needed before introducing the change.

Design participation into the working day

Walk through the proposed test with the people expected to use it. Check the time required for training, entering information, reporting problems and giving feedback. A short interaction repeated throughout a shift can become a substantial additional task. Decide which existing step it replaces, if any.

Explain what participation means and how observations will be used. Provide a route for raising concerns that does not depend on praising the experiment. The people doing the work should be able to describe confusion, extra effort or an unhelpful result without those observations being treated as resistance.

Keep a workable fallback

Identify the person who can pause the test and the conditions that require a pause. These might include unclear vehicle status, missing essential information or a tool that prevents someone completing the agreed handover. Define how the team returns to the established process and who tells affected participants.

The fallback should be usable with the people and equipment actually available. A named coordinator cannot cover every working window automatically. Check availability, backup responsibility and the route for urgent issues. Broader service dependencies belong in the partnership discussion, alongside the product experiment.

End with an interpretable review

Record interruptions, workarounds and incomplete observations as well as successful uses. Note whether someone from the building team was constantly present to help; that assistance may explain part of the result. Ask participants what became easier, what became harder and what they would need before using the tool independently.

Schedule the review before the test starts. The result may justify a wider trial, a smaller redesign or stopping. Preserve the original question and explain the decision against it, so the next team can understand what was learned and what remains unresolved.