In most of the organizations we encounter during our consulting work, programmers tend to think they’re the best-qualified people to design the form and behavior of a product. In the absence of trained interaction designers, they may be right. They know from experience that no one else is going to think through all the implications of serving up that snippet of data in just the right way, and no one else questions the idea of programmers doing the interaction design because they assume it’s a technology problem. As a result, executives who lead technology initiatives believe that they already get interaction design for free from their programmers. In their opinion, having interaction designers is unnecessary; if the product happens to be hard to use, they assume the programmers just need some sensitivity training. Having programmers design the product is anything but free, though; it’s ineffective, inefficient, and risky.
It’s ineffective because programmers don’t think like designers (or users)
Considering the importance of keeping your users and customers happy, you want your products to be designed by people who understand your customers and can see the world from their point of view. The problem with programmers doing this work is that they don’t think like other people. In fact, programmers think so differently they’re like a separate species. Alan Cooper calls them Homo logicus. What differentiates H. logicus from Homo sapiens isn’t an addiction to caffeine or an aversion to daylight; it’s a difference in how we look at the world. Most of us sapiens value being successful with our software. We don’t care how it does what it does; we just want it to do what we tell it to do. A successful specimen of H. logicus, on the other hand, is deeply interested in the inner workings of software.
A good programmer juggles a dozen variables in his head and thinks about all of the bizarre edge cases that could possibly break the software. What programmers often don’t consider, though, is that just because something is possible doesn’t mean it’s probable. To use a simple example, Apple’s iPhoto has easily accessible tools for the things most users want to do, such as cropping and rotating photos. If a programmer had designed iPhoto, a seldom-used tool for adjusting color depth would be on the screen right next to the "rotate photo" tool. An interaction designer would either hide the function in a menu or, better yet, drop color-depth adjustment altogether, thereby saving the cost of developing and supporting that feature.
It’s inefficient because there’s no blueprint
Having programmers design the product lengthens the development timeline in several ways. First and most obvious is that programmers spend valuable time laying out screens and selecting widgets when they could be writing code. The greater inefficiency, however, lies in iteration. Imagine hiring a building contractor to construct your house but not handing him a blueprint. When you reject the first iteration of the house, he says, "OK, so you didn’t want a second story—we’ll tear it down and get closer next time." The process is less visible when it’s done in software code, but it has an even more disastrous effect on your budget and timeline.
"But we give them specs," say the marketers. "They just don’t build what we tell them to!" To be fair to the programmers, they’re not working trial-and-error because it’s fun. They’re doing it because they can’t read minds, which is what it would take to turn the average Marketing Requirements Document into a product people can see and use. If Steven Spielberg handed his camera crew a feature list that included a chase scene, a love scene, something blowing up, and a happy ending, he wouldn’t exactly have a blockbuster film on his hands.
Programmers should be working from blueprints—form and behavior specifications that illustrate what every screen looks like and describe the states and behaviors of every control. With such specifications, our clients have observed incredible reductions in the time wasted on iteration and uncertainty. Some tell us development time was cut in half; others say they saved a year or more.
It’s risky because the executives aren’t in control
Most executives—the non-technical ones and even the majority of the technical ones—will secretly admit to feeling like they’re not in control of the development process. They’re right. They may control the deadlines, but the programmers control everything else. This control isn’t necessarily intentional or overt; if it were, the executives presumably would have taken steps long ago. This control is invisible because product definition issues are treated as technical issues and are therefore assumed to belong in the hands of the programmers.
The problem is exacerbated by the developer’s mindset, which is one of scarcity—there is never enough time to write code, never enough memory to run a process, never enough anything. If a marketer says, "Can we do drag and drop, or is it too hard?" the programmer says, "Nope, not technically feasible," but what he really means is, "Within the ridiculous timeframe I’ve been given, I can’t do that and the 20 other things you’re going to want me to do." That belief in the scarcity of time has led to an invisible product decision being made without the executives even realizing it. What if drag and drop would enable your shopping Web site to kill the competition? What if that alternate design could have saved you $20,000 a month in customer support calls? Most executives would prefer to ship a success a month later than to ship a failure on time.
By introducing designated designers who are not programmers into the process, executives regain control of product decisions. Armed with objective behavioral research, designers can sit at a table with the marketing lead, the technical lead, and a cross-functional executive to make the case for why doing something a particular way is best for the users or customers. In that same meeting, the technical lead can estimate the effort involved, the marketing lead can estimate the impact on sales, and the fully informed executive can determine with confidence whether the trade-off is worth it.
Hiring interaction designers winds up being far more cost-effective than using your programmers to do design because it makes development more efficient, results in products that inspire customer loyalty and reduce support costs, and makes the entire product development process more predictable and easier to control. So why not call the HR department and list that new position?