How to Build Software That Employees Will Actually Use

Watch the work before writing requirements. A process document or a manager’s summary describes how work should happen, while the person at the desk relies on workarounds, shortcuts and undocumented steps that no description recorded. Count the sticky notes on the monitor, because the gap between the documented version and the daily version is usually wider than either side expects.

Gather requirements from a representative group. That means the dispatcher, the newest hire and the person who complains most, not only the managers who approve the monthly budget. Staff asked for input before any screen exists treat the finished tool as theirs, whereas staff who were never consulted treat it as something imposed on them from above.

Do not copy the paper form. A paper form carries sign-off boxes that exist only because paper is slow and easy to lose, so a faithful digital copy preserves every delay the original had. Copying is not simplifying. Ask of each field who reads it. Delete the fields nobody reads, merge approval steps that one person signs in the same sitting, and move checks to where data is first typed.

Duplicate entry is the biggest single saving. Staff often type the same customer details into the billing package and again into a dispatch spreadsheet because neither system talks to the other. Each retyping invites a wrong digit. Connecting those two systems, or merging them into one record, removes friction that people feel every hour of the working day, and no interface polish can hide it.

Clean demos prove almost nothing. Test the messy cases that recur weekly: the order with a missing postcode, the customer who changes their mind twice, the refund needing approval. Vendors show the happy path. Ask to see the unhappy one. Give testers a list of real tasks and watch where they hesitate, because a pause on one screen, repeated all day, becomes the complaint that sinks the rollout. Hesitation is data.

Consider a warehouse trialling a stock-taking app. A pilot that scans only a tidy shelf will look successful and fail, because real counts involve damaged barcodes, misplaced items and partial counts interrupted by a forklift. Run those conditions before rollout, not after.

Name one or two champions per team. Train them early, ideally from the people who already gave requirements, so they hold a peer’s authority and know why each screen looks the way it does. A champion gives colleagues a neighbour to ask instead of a manual or a distant help desk, and hears complaints that staff would never raise formally with management.

Roll out in stages. Start with one team or one site, with the champion sitting inside it, and widen only after the first group has stopped asking the same three questions. Fix problems while few people feel them. A company-wide launch makes every friction point everyone’s problem on the same morning, with no tested fix in hand and no experienced colleague to copy.

Adoption is not a yes or no. Track whether staff use the software for the task it replaced, or keep the old spreadsheet open beside it, and whether tasks finish faster or with fewer corrections. Compare weekly completed tasks per user with what the old process handled, and ask anyone who falls to zero what stopped them, since silence usually hides a workaround. Silence is not approval. Ask for friction reports monthly.

Watch for the drop-off. Usage often dips three or four weeks after a good launch, which usually means an early friction point stayed unfixed and staff drifted back to the old way. Catch it inside month one.