A mobility assessment decides which work benefits from being completed at the point of activity. Begin with the workflow, the people doing it and a measurable problem. The useful output is a decision to pilot, revise or defer a specific workflow, with evidence explaining why.
This is a discovery exercise for a team considering mobile work. Bring a person who does the task, its operational owner and someone responsible for the systems it touches. Observe real work before choosing an app or device.
Describe the work as it happens
Follow a task from its trigger to its accepted result. Record where information originates, where people re-enter it, where approval happens and what causes rework. Include exceptions: an unreadable label, an unavailable supervisor, a lost connection or a customer who changes their request.
The UK Government's discovery-phase guidance emphasizes understanding the problem, users and constraints before committing to a solution. Its approach is useful here as a discovery method; the decisions below are a practical adaptation for a mobile workflow.
Write a short outcome: “The stockroom assistant can confirm a received item at the shelf, and the inventory owner can reconcile it without retyping.” That identifies a person, a location, a handoff and a result that an observer can verify.
Measure the starting point
Choose a small set of meaningful observations: elapsed completion time, active handling time, re-entry count, error or rework rate, and the time until another person can use the result. Separate waiting from active work. Record the observation period, number of tasks and which unusual cases were included.
Ask who may be excluded by the proposed interaction. Gloves, bright sunlight, noisy rooms, movement, screen-reading needs and language can change the design. Check whether people can complete the task while paying attention to the physical work around them. A desk task with little delay may gain less from a handheld interface than a field task with repeated transcription.
Scroll the table horizontally; keyboard users can focus it and use the arrow keys.
| Area | Evidence to collect | Decision it supports |
|---|---|---|
| Task and users | Observed steps, exceptions, accessibility needs and who accepts the result. | Whether the mobile interaction fits the actual work. |
| Information | Required fields, authoritative system, ownership and correction process. | Whether captured data can be trusted and reconciled. |
| Connection | Where service exists, interruption duration and work needed while disconnected. | Whether an offline design is essential. |
| Operations | Device custody, charging, shared-user sign-in, support and replacement. | Whether the workflow can run beyond a demonstration. |
| Access | Who may see, submit, correct and approve each record. | Whether permissions and accountability are defined. |
Compare candidates using evidence
Fictional assessment: a team observes 40 stock receipts and 40 monthly report reviews. Receipts take 8 minutes of active handling on average, including 3 minutes of later transcription; 4 of 40 need a correction. Report reviews already happen at a desk using large reference documents and take 12 minutes each. These invented baselines illustrate a decision method, not measured improvements.
The team nominates stock receipt capture because its repeated re-entry creates a clear hypothesis. Removing that whole 3-minute step would represent 40 × 3 = 120 minutes across the observed tasks, before allowing for new scanning, review and support work. This is an upper-bound opportunity for that step, not a forecast of savings. The team defers handheld report review because the observed task has little need to move.
A numerical readiness score can help organize discussion, but define what each score means and retain the underlying evidence. A high total must not hide a blocking dependency such as an unavailable system interface or an unresolved correction owner.
Specify a pilot that can change the decision
For the fictional receipt workflow, a pilot might require at least 40 representative tasks, an average active handling time of 6 minutes or less, no increase above the observed 4-in-40 correction count, and a successful reconciliation after a planned connection interruption. These are illustrative project criteria. Choose your own thresholds from the service need and baseline, and use a larger evaluation where the consequences or variability warrant it.
- State the hypothesis and success criteria before the trial.
- Include typical users and difficult cases, with a supported fallback when the trial cannot complete a task.
- Measure the complete workflow through acceptance in the authoritative system.
- Record extra review, exception handling, support and device-management work.
- Discuss results with the people doing and receiving the work. Decide whether the evidence supports a larger pilot, a redesign or stopping.
Make the handoff actionable
Use the workflow-assessment worksheet to document the candidate, baseline, constraints, pilot criteria, owner and decision date. Mark assumptions that remain untested and assign a concrete next check to each.
A pilot approval should identify its scope and exit criteria. A revision decision should name the issue to resolve, such as record reconciliation. A deferral should explain the evidence that would justify reopening the question. For a workflow that depends on coverage at specific locations, use a task-based wireless site survey as one input to discovery.