Listening to the Receiver
A message sent to a human being is aimed at the most complex, most variable receiver in the universe.
Whether it’s delivered in the form of a traffic signal, an annual report, a printed social invitation, or an e-mail, every message will be interpreted within a context, and its effectiveness will be determined by how well it relates to the people to whom it’s directed: their abilities, their knowledge, their culture, their needs, their preferences, and their physical environment. Yet many of the messages delivered by software are produced without adequate consideration of their context and without a full understanding of how they will be received.
Researching the needs of people who use software is crucial. Business executives and software developers might think they know exactly how their software will be used, but only research can confirm their hypotheses. Whether software is designed to operate a password system or to record clinical data, it’s important to answer these questions:
Who will use this software? Are they members of a highly diverse group of individuals (employees of a large company, including summer employees) or a group that’s more uniform (emergency-room physicians)? What information do they have that will help them use this tool? What else do they need to know? What will help them understand?
What are they trying to do? What task are they trying to perform? Why do they do it? Exactly how do they do it? Do they all perform this task in the same way? How often do they repeat the process? What do they need to do the job more quickly and more accurately?
What’s the context? Where are the people who are using this software? Are they at their desks, or on their feet? What is their physical environment like? What’s happening around them? Are they under time pressure? Are they trying to do anything else at the same time? How does what they’re trying to do relate to other tasks? What does the workflow process look like?
What’s the status quo? If the purpose of a software product is to improve efficiency, what benchmark information is available to measure present performance? How long does it take, on average, to complete a certain task? What is the average success rate? What’s the rate of error? How much time do these errors cost? How are they resolved? What kind of workarounds do people use to complete the task? How long does it usually take to learn to use the current tools?
The more precisely these questions are phrased and the more accurately the answers are measured, the more valuable the information will be. You’d think that it would make sense to find out exactly how a product will be used before releasing it into the marketplace, and you’d be right. But much of our software is developed through a process that neglects to gather basic information about the people who will use it and the work that it’s intended to support.
—Excerpted from Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate by Harold Hambrose (John Wiley & Sons, Inc., New York). Order your copy of this book.
