Many executives reason that their employees can learn to operate almost any business system, given the right training, and that if technologists can deliver sophisticated electronic tools that automate routine tasks, the least people can do is to put up with a few quirks in the way the software performs. Some employers expect workers to recognize that it is in their best interest to adapt to whatever challenges their tools present to them: After all, what choice do they have?
According to this philosophy, most of the problems that people have with software can be explained in terms of a learning curve, and as workers become more familiar with the software they use, their proficiency will improve. When this doesn't happen - when significant numbers of workers have trouble using a business system, and familiarity breeds only frustration, resentment, and hostility - the common assumption is that more training is needed. All too often, the result is low productivity and an endless cycle of training as experienced workers are replaced by new hires.
It's true that some people manage to adapt surprisingly well to even the most counterintuitive software, and it's not unusual for some to become experts in navigating the maze on their desktops. But asking people to use inferior tools, or placing the right tools in the wrong hands, can have unintended consequences.
When we find ourselves facing a barrier that seems insurmountable, we look for ways to work around it. When software raises an obstacle, business executives, brokers, lawyers, physicians, and other professionals often work around the problem by delegating the task. Those who can't delegate must find other alternatives.
Business software that's easy to use lowers the cost of training and raises productivity. Sales agents who can do their jobs without assistance feel less stress and provide better customer service than agents who need to put their prospects on hold and interrupt their co-workers to ask for help. Software that's intuitive also promotes innovation by creating opportunities to think creatively about new ways of gathering, organizing, and using information. But when the act of using software is a struggle, most people simply leave it to someone else to rise to the challenge, master the system.
Some idealists believe that all software should be so easy to use that there would be no need for manuals or training sessions. That's a realistic goal for software that runs an ATM, a search service, or a website. However, we accept that it takes training and practice to drive a car and to operate most other complex machines, so even though manufacturers may claim that their software is easy to use, it's reasonable to expect that some training will be needed for most new technology. The question is, how much training-and how often? More importantly, what is actually being trained, and what will it cost?
Training is a major portion of the cost of implementing most business software.
As a rule of thumb, the process of implementation usually costs at least as much as building, buying, or licensing the software - sometimes twice as much. For software with a price tag of seven figures or more, the training costs can be staggering.
Why does it take so long to learn to use so much of our business software?
If the people who use these products are the source of the problem, then there's little that businesses can do to avoid making continuous investments in training. But if the problem is caused by a failure of communication between the partnership of business and technology and their intended audience, there's a better solution.
Architects who specialize in commercial buildings are expected to organize the interior and exterior spaces of their buildings in logical ways and to observe other conventions that will enhance the tenants' experience of occupying these spaces, and long before they begin to write specifications they meet with their clients to define their needs and learn about their preferences
The best business software is built through a collaborative process that parallels the architectural process, both in its methods and in its division of responsibilities. The most effective development teams include not only the client (stakeholders and subject-matter experts from the business side) and the builder (software developers), but also designers who can interpret, balance, and communicate to technologists the business requirements as well as the needs of the people who will use the product.
The designer's job is to find out what the client wants, identify what the client genuinely needs, and to design the physical form of the product-and in doing so, to also design the experience of using it. Accomplishing this requires close communication between business, design, and technology, with visual prototypes and frequent reviews. Most software, however, is developed without Designers or their methods, with Business Analysts and programmers inappropriately assuming this role and its responsibilities.
In a perfect world, during the design phase of software development the client will be shown prototypes for evaluation and testing at regular intervals so that adjustments can be made to match the technical performance of the software to the work processes of the company and the needs of the people who use it. In the real world, deadline pressures compress the review process, and despite the best intentions of stakeholders, life gets in the way: Travel schedules, sales conferences, and other priorities intervene. Even worse, the development process may be organized in a way that excludes some of the people who need to be at the table. Those most likely to be left out of the process of developing software are the people who will use it.
Unless the business requirements and the technical requirements are informed by human considerations, the finished product can roll off the assembly line, a piece of solid technology that fully complies with every business and technical requirement, before its fundamental deficiencies are discovered and its full potential can be explored
• This article is an extract from A Wrench in the System by Harold Hambrose, CEO and founder of Electronic Ink. ISBN: 978-0-470-41343-2