Build for the people doing the work

A workaround is evidence. Staff who keep a separate spreadsheet may be preserving a view the new tool lost, protecting unfinished work or avoiding a step that makes little sense during a busy shift.

The workaround may also create problems. Understanding why it exists gives you a better chance of removing it. “Resistance to change” is a conclusion to examine, not a useful default explanation for behavior the design failed to anticipate.

Ask who receives the benefit and who does the work

A reporting system may give managers better visibility while asking operators to enter information twice. From one role it looks like progress; from the other it looks like extra administration. A technically correct rollout can fail because those costs and benefits fall on different people.

Look at the whole exchange. Can the same records help the operator complete their task? Can information be captured once? Is the new requirement replacing an old one, or merely joining it?

The GOV.UK guidance on learning user needs emphasizes the work people are trying to accomplish. That includes their environment and constraints: interrupted tasks, shared devices, missing information and the pressure to keep moving. Training can explain a useful process; it cannot make a needless burden disappear.

Test with real tasks

Give someone a realistic task and let them attempt it without a guided demonstration. A demonstration proves that the presenter knows the route; it does not establish that the interface makes that route clear.

Use representative information in a safe environment. Include an ordinary case and a common exception. Ask where the person expected to find something, what they thought a status meant and what they would do if they became stuck.

Fix recurring obstacles in the product where possible. Training can explain a business rule, but it should not have to compensate indefinitely for an unnecessarily confusing screen.

Plan the transition

Decide when the new system becomes authoritative and what happens to the old process. Running both for a short comparison period can be useful. Leaving both active indefinitely can create conflicting records and double the administrative work.

Name someone who can answer operational questions during the change. Give people a clear place to report problems and distinguish urgent defects from requests that can wait.

For the Community Thanksgiving Dinner Foundation, familiar Google-based working tools were part of the approach alongside the custom web and operational system. The choice of tools reflected the team’s needs and technical comfort rather than requiring a larger stack for its own sake.

Look for independent use

Completion of a training session is a weak measure of adoption. Look for people completing the important tasks correctly without assistance. Examine repeat questions, abandoned steps and work that still happens outside the system.

Some workarounds expose missing capabilities; others preserve a useful practice that should be incorporated. Ask what the workaround accomplishes before removing it.

Keep the first instructions short and task-focused. Documentation and handover explains how to make them usable. If adoption remains difficult, return to the problem definition and check whether the proposed system solves the problem people actually experience.