Choosing the First Version of a Staff-facing Tool

Imagine a commercial removals business handling this situation. The proposed internal app includes route planning, payroll, stock and customer messaging before anyone has tested the job briefing screen.

For a commercial removals business, this fictional situation could begin with a perfectly sensible shortcut. The difficulty emerges when more people rely on the result, because an informal understanding is no longer enough to support the next decision. It helps to examine what the next person needs, rather than simply adding another notification.

Several different problems have been combined into one release. Staff cannot evaluate the essential workflow without waiting for everything else.

A complete narrow workflow teaches more than several unfinished feature areas. Users need to experience the handover and outcome, not simply inspect a collection of screens.

Users need enough of the task to evaluate the result in context. A prototype can be deliberately narrow while still showing assignment, correction and completion. Adding unrelated feature areas first can delay the very feedback needed to decide whether the core workflow is useful. The cost is not limited to entering a value incorrectly. Staff also spend effort deciding whether they can trust the next step. When that confidence disappears, they start checking routine work manually even on days when the information happens to be correct.

Define one usable task from start to finish and prototype it with representative users. Defer additions that do not affect that task's success or safety.

Permissions, recovery and operational support belong in the design from the beginning. Keep the scope narrow enough that users can evaluate one complete workflow before more features are added. Describe the required relationship between records before discussing a new screen. The proposed tool should make its current state understandable rather than hide important uncertainty behind a simple button. An existing application may already provide the needed structure through configuration or a supported extension. If a small custom component is justified, define what it owns and what remains maintained elsewhere. Use realistic records to check that staff can complete the whole task, including correcting a mistake.

A smaller release still needs the permissions, data handling and recovery necessary for its real use.

For background relevant to first-release scope, see The Cost of Building Software Nobody Uses. The issue here is the narrower workflow described in this example.

Ask a coordinator and a mover to complete an actual-style job handover using the prototype. Use a small representative sample before changing the live workflow. Ask the person doing the work and the person relying on its output to examine the same result. They may notice different problems, so record what each needs to see before calling the trial successful.

For first-release scope, review the proposed outcome with the staff responsible. Check what an authorised user can see, change and recover in the proposed tool. The result should remain understandable to a colleague who did not create the record, including when the task is corrected or handed over. Check that the proposed improvement does not create a second private list for unresolved cases. Relevant staff should be able to see the next action in the agreed place.

At Software Logic, we explore how small internal tools can support everyday work, including the decisions that should remain with the people responsible. What is the smallest complete task your first release should make easier?