Users Should Not Have to Learn Software
The users aren't at fault, the software is
Users should not have to learn software in order to do their work. If software requires learning, the software is poorly designed.
The idea that people must “learn computers” in order to function has been treated as normal for decades, but it reflects a deeper problem. Responsibility for unusable tools has been shifted onto the user. Systems that are unnecessarily complicated are presented as inherently complex, and people are encouraged to assume that their own lack of knowledge is the issue rather than the design of the tool itself. Over time, this has normalized a pattern in which difficulty is expected, dependence is built in, and complexity is mistaken for sophistication.
A tool is expected to perform its function without requiring the user to absorb its internal complexity. Software is unusual in having been allowed to escape that expectation.
This shift has had broad consequences. People routinely blame themselves when software fails, describing themselves as “not computer literate” rather than recognizing poor design. Businesses hire support staff to compensate for defects in the tools they use. Organizations reshape their work to fit the limitations of software rather than expecting software to adapt to their needs. In this environment, frustration becomes routine, and the expectation of clarity is gradually abandoned.
In other domains, this pattern does not exist. People do not need to understand automotive engineering in order to drive a car, or electrical systems in order to use a light switch. A tool is expected to perform its function without requiring the user to absorb its internal complexity. Software is unusual in having been allowed to escape that expectation.
Software has failed to account for the way people actually work.
The approach taken here is different. The goal is to build a system in which future editors do not need technical knowledge in order to maintain the site. They only need to understand their own work. This is not a simplification of the system in the sense of removing capability. It is a matter of placing complexity where it belongs—within the system itself, rather than on the user.
The custom image insertion tool is one example of this approach. Editors do not resize images, write HTML, insert markers, or select technical settings. They do not need documentation in order to perform basic tasks, and they are not placed in a position where they are likely to make errors or blame themselves for problems. The system handles those concerns internally and presents a simple interface.
The instinct behind this approach is that the problem should not exist in the first place. Tasks such as managing image pipelines, handling responsive behavior, or adjusting layout rules are not inherently part of editorial work. They have been imposed on users because software has failed to account for the way people actually work.
Designing the Saving Birds Thru Habitat website so that non-technical people can maintain it over time is a direct response to that failure. It is an attempt to build a system that supports its users rather than burdening them.