When people repeatedly struggle with a system, many businesses reach for the same solution: more training. They create another guide, record another video, add another module to the learning platform and remind everyone to follow the correct process.

It looks like action. It can also avoid the more important question.

Why is the system so difficult to use in the first place?

Training puts the onus on the user

William Harkness raises this issue in Why Training Gets Funded When Design Is the Problem, published in January 2026. His article made me think about how easily responsibility can be transferred from a poorly designed system to the people expected to use it.

If users need to remember an unusual sequence, consult a separate document or complete mandatory training before performing a routine task, we start to judge their ability to follow instructions. When something goes wrong, the conversation becomes about whether the user completed the training, read the guidance or followed the correct process. We stop questioning whether those instructions should have been necessary.

That puts the onus on the user rather than the system.

If several people struggle at the same point, make the same mistake or need the same workaround, that is design evidence. Providing the explanation again may help somebody complete the immediate task, but it does not remove the underlying problem.

Good design reduces cognitive effort

Every system requires some thought. The aim of good design is not to remove every decision, but to avoid making users spend mental effort on things the system could make clear.

A well-designed process is easier to understand, easier to follow and more efficient to complete. It presents relevant information at the right time, uses consistent language and makes the next action clear. Users can concentrate on the outcome they are trying to achieve rather than remembering how the interface expects them to achieve it.

A poorly designed process transfers more of that work to the user. They may need to remember what they were told during training several months ago, translate internal terminology, keep track of information across several screens or recall that one button behaves differently from similar buttons elsewhere.

That additional cognitive effort matters because people do not use systems under perfect conditions. They may be busy, tired, distracted, unfamiliar with the task or working under pressure. Some will have cognitive, visual, motor or other disabilities that affect how they perceive, understand or interact with the process.

The World Wide Web Consortium’s guidance on clear and understandable content recommends understandable words, short sentences, unambiguous content and clear layouts. These choices reduce barriers for people with cognitive and learning disabilities, but their value is much wider. Clearer information and predictable interactions reduce the effort required from everyone.

The harder users must work to remember, interpret and navigate around a design, the more opportunities there are for delay and error.

That is not simply a user problem. It is a design outcome.

Inclusive design works for more people

Designing with a range of users, including people with disabilities, helps organisations understand where unnecessary effort has been built into a product or process. This involvement needs to happen early enough to influence requirements and design, not only when a nearly finished system is presented for accessibility testing.

The W3C guidance on involving users in accessibility evaluation recommends including people with disabilities throughout development and asking them to complete realistic tasks with prototypes. It also notes that evaluation with people with disabilities often uncovers general usability problems that affect users without disabilities.

This does not mean that testing with a few people replaces accessibility standards or a proper audit. Different people have different needs and experiences. User involvement should complement technical evaluation against the Web Content Accessibility Guidelines, commonly known as WCAG.

However, involving a range of users challenges assumptions about what people can see, remember, understand or operate. It allows a team to observe where instructions are unclear, where a sequence creates unnecessary effort and where the design expects users to adapt.

As a screen-reader user, I can sometimes learn how to navigate a badly designed process. I might remember that an unlabelled button performs a particular action or that keyboard focus moves somewhere unexpected after I submit a form.

Learning the workaround does not make the system accessible. It means the design has transferred work to me.

The same principle applies more widely. Clear labels help somebody using a screen reader, but they also help a new employee understand an unfamiliar process. Consistent navigation supports people with cognitive disabilities, while also helping someone working quickly. Clear error messages help more users recover without having to contact support.

Inclusive design does not only make systems possible for more people to use. It can make them easier for more people to use with less effort.

Workarounds have a business cost

It is tempting to treat training as the cheaper option because it is a recognisable and measurable intervention. A course has a defined budget, an owner and a completion rate. Improving the design may require changes to requirements, software, content, testing and established project plans.

The cost of poor design is harder to see because it is distributed across the business. One employee may lose only a few minutes looking for an instruction, repeating a failed action or asking a colleague for help. One support request may not appear significant, and one incorrectly completed form may be easy to correct.

Multiply those moments across hundreds or thousands of users and over several years, and the cost changes considerably. The business is paying through repeated training, avoidable support requests, slower onboarding, reduced productivity, errors, individual adjustments and time spent maintaining workarounds.

The original design cost may have been paid once. The cost of using that design is paid every day.

The GOV.UK guidance for internal government services makes this connection directly. It says that good internal services reduce training costs and the time spent dealing with errors, giving staff more time to provide the service itself. Although written for government teams, that is a useful commercial principle for any organisation.

Training people to work around a problem does not eliminate the expense. It converts a design problem into an ongoing operating cost.

It can also hide the scale of the issue. When experienced employees learn how to compensate for poor design, their workarounds become normal business practice. The system appears to function because its users are investing additional time and mental effort to keep it functioning.

That is not efficiency.

Training still has an important role

Training is valuable when it develops genuine knowledge, skill or judgement. People need it to perform specialist roles, understand important responsibilities and handle complex or unusual situations. Designers, developers, product managers and content authors also need accessibility training because informed teams are more likely to make inclusive decisions.

The distinction is about what training is being asked to achieve. It should help people use a well-designed system effectively, not teach them to compensate for a system that is unnecessarily confusing, inefficient or inaccessible.

Before funding another course, I would ask:

1. Where are users losing time or making mistakes?
2. Are different users struggling with the same parts of the process?
3. How much information must they remember instead of receiving it when they need it?
4. Could a design change remove the need for an instruction or workaround?
5. Have people with a range of needs and abilities helped design and test the process?
6. What is the cumulative cost of training, support, errors and lost productivity?
7. Who has the authority and budget to address the underlying design?

These questions help distinguish a genuine knowledge gap from a design problem. They also move the conversation from whether users followed the process to whether the process properly supports its users.

Fix the system, not the user

Training is easy to count. A business can report how many people completed a course and how many hours of learning it delivered. Those figures do not show whether the underlying system is good.

The more useful measures are whether users can understand the process, complete tasks independently, avoid mistakes and achieve the intended outcome without unnecessary effort. When the same workaround appears in every induction session, support document and accessibility adjustment, the training material is telling the business something important about the quality of its design.

Better design places responsibility back where it belongs. It reduces cognitive effort, saves time, prevents mistakes and allows a wider range of people to use the system effectively. It also removes costs that would otherwise continue for as long as the poor design remains in place.

Do not keep training people to compensate for the system.

Improve the system so they no longer need to.

Sources and further reading

• William Harkness, Why Training Gets Funded When Design Is the Problem, 5 January 2026.
• World Wide Web Consortium, Use Clear and Understandable Content.
• World Wide Web Consortium, Involving Users in Evaluating Web Accessibility.
• GOV.UK Service Manual, Services for government users.