By Donna Boyette
If you were asked to estimate how much of the code you developed was ever used by the intended end user, what would your estimate be? Some studies show that more than half of the code developed never reaches an end user—and communication could be a big part of the problem.
Users must understand developers, and developers must understand users. How can you do your part in making yourself understood? Here are seven tips to increase the chances that your work won’t be wasted.
Tip #1: Get some humility
As technical people, we’re quite confident in our activities involving technology. The user, however, may be feeling out of place. If you don’t remember what it feels like to be out of your depth, you can’t understand what your user is going through. So connect with nontechnical users and coworkers by remembering what it feels like to be clueless.
Put yourself in the user’s place. Sit in the cockpit of a passenger airliner, visit a phlebotomist’s lab, or talk with a writer about kill fees and queries (a different kind of query). Have mercy on the folks who are trying to understand you. You might need their help someday, and to make your project a true success, you need their help right now.
Tip #2: Talk about people and actions, not systems and code
Speak in terms the user will understand. Try this: Instead of saying, “The system will” start every sentence with “The user will.” Instead of “It’s coded like this” or “Its sorted by that,” explain the interactions from the user’s point of view.
One of my colleagues suggested that we “Talk about what the technology can do for [users]” not about how the technology works. A coworker agrees. “Instead of describing the process to make it happen, describe the result the user sees.”
Tip #3: Learn about your customer’s world
You can’t write an application for someone if you don’t truly understand what he or she does. Increased understanding of the customer’s work can only improve your communications with them. I remember using a new application and, amid groans of agreement from my coworkers, saying, “You can tell the developer never sat with anyone who uses this system.” Never let this be said about one of your applications.
Tip #4: Translate and educate
List some of the technical terms you use most often, as well as any terms that always result in blank stares from your listeners. Take your list and log on to Whatis.com. Use the definitions you find the next time you are trying to explain a new process.
In addition to learning how to say things so that regular people will understand you, learn about your customer’s world. If your users will be installing telecommunications circuits, you can do a quick investigation that will take you through T-carrier technology. Many of the definitions at Whatis.com include links to related concepts and terms. Use this and other resources to further your knowledge about your user’s business. When your customers see you making an effort to learn their language, don’t be surprised if they are more willing to learn yours.
Management’s lack of technical understanding can be an even bigger problem than dealing with nontechnical customers. Even for very knowledgeable development managers, that knowledge can quickly become obsolete. It is crucial that you successfully communicate interactions and risks to the decision makers. Keep your manager in the loop as much as possible when changes in technology affect key components of your programming or design. And don’t forget to talk in terms your manager will understand.
Tip #5: Use creative communications tools
In the March 2001 issue of Presentations magazine, David McIlhenny observed, “If our audience members aren’t paying attention, we may as well stop speaking, go sit with them, and start doing whatever they are doing.” Use props, pictures, and stories—whatever it takes to engage your listeners while sticking to your subject.
Paper prototypes offer one creative means of communication. Users can easily grasp the flow of the tasks, and when a flaw is discovered, changes in design can be made instantly. In addition to helping users easily grasp design concepts, this tool can help you more easily involve them in creating the design.
Tip #6: Create a project site
In her book Collaborative Web Development: Strategies and Best Practices for Web Teams, author Jessica Burdman recommends creating a project site to enhance communication with your clients. In addition to the items she suggests, such as the roles of your project team members, site architecture, the project schedule, and a link to the staging site, I would add a project glossary.
To help your project team understand the customer’s work, include terms and acronyms that are unique to your customer as well. Your investment in defining your team’s portion of the glossary will be time well spent because once created, you can use it for every project and on every project site.
Tip #7: Get some training
Find a good soft-skills class or book, such as The Essence of Technical Communication for Engineers: Writing, Presentation, and Meeting Skills, by Herbert L. Hirsch.
As one of my systems engineer friends says, “Not everyone has the patience to talk to a nontechnical person.” Enhance your usability by taking a course, reading a book, or by using some of the tools mentioned here.
Involving your users does not come automatically—and perhaps not easily either. But just as you can find ways to program better, you can also learn to improve communication with your nontechnical users.
Look at it this way: You’re outnumbered. You’re also in demand, and you increase that demand when people know what you’re talking about.