Summary: Discusses why technology alone can’t make great products. (4 printed pages)
We all love technology. That’s why we’re in this industry. We have an unspoken belief that technology will save the world from all of its problems. We excel at creating technologies and packaging them into boxes or Web sites, but we often fail to put them together in ways that our customers can easily use and appreciate. Sometimes we respond with awe at things we know were hard to implement or difficult to build, without regard for the purpose they might serve. Over the years I’ve noticed that our love for technology doesn’t always lead us in the right direction. In this column I’ll try to describe the kind of thinking that’s missing.
The Fun Employment Clause
Your manager has probably expressed a desire for you to have fun and to work on cool projects. That’s not quite the whole story. The hidden truth is what’s known as the fun employment clause: You are hired to have fun if, and only if, you’re making sure the user has an enjoyable experience with the product. This is because end users pay your salary—they pay all of our salaries. It means that everything you do should ultimately benefit the user and, therefore, your company. You want to focus on growing the intersection between your company’s goals and your users’ goals.
Each line of code you write, every bug you find, and any market research you do should help the user in some way. No matter how obscure or indirect your work is, you’re still bound by the fun employment clause. For example, fixing a device driver, improving reliability, or optimizing server performance makes the product better in measurable ways for any user. Doing market research helps focus the product on the right set of people so you can satisfy their needs. If you can’t connect the dots between the work you do and how it helps the customer, consider investing your time somewhere else. The more frequently you think of your work, and your team’s work, in end-user terms, the more likely you are to help create a great product.
We Are Not Our Users
We develop inbred thinking in this industry. We spend most of our time with people who scored over 700 on their math SATs, we know people involved in IPOs and stock options, and we work with folks who take computers apart for fun. We forget that the people within our industry are very different from the rest of the world. That’s why going into the usability lab or a focus group seems like a trip into the twilight zone. It seems like those users are in the minority, visiting us from some twisted and slower universe. The reality is this: We are the overwhelming minority. Those visitors in the usability lab are the majority, and they are the folks using our products and paying our salaries.
There is no substitute for watching someone use something you’ve built. It’s the only way to see how your intended goals match with the reality. Would you want a surgeon to operate on you without examining you before as well as after the surgery? Would you want a building contractor to remodel your kitchen without discussing your plans and making sure you got what you needed? Good craftspeople want to understand the world in which their product will be used before building it. We have the amazing power to create things, and it’s easy to fall into the trap of building things that appeal to us as creators, instead of things that will appeal to our customers. There’s no way to know how biased you are without working through usability engineering and other forms of customer feedback. You must spend time with users throughout the product cycle, repeatedly refreshing the team perspective on what you’re building and for whom.
Which Came First: the User or the Technology?
There is a fundamental difference in how technologists and true designers approach making products. Technical people tend to start with technologies. We take teams of developers, build a technology, and then shoehorn a user interface and a user experience onto the framework dictated by the technology. This guarantees that the user experience will be a poor compromise. The product won’t be designed for use, it will be designed as a ship vehicle for a package of technologies. It’s a value proposition: We behave as if it’s more important for technologies to be shipped than for products to be used. What great products are designed this way? Do master chefs wait until the last minute to figure out how the food will taste to their customers? Do tailors measure their clients after the suit has been sewn together?
A good craftsperson in any trade understands that people will consume their work, and every decision is made with that type of person in mind. Software or Web development is no different. The people who go to restaurants or movies are the same ones who use our products. We need to cultivate an interest in how products in other fields are developed, and how they achieve the results that they do. Makers of automobiles, CD players, and appliances all have the same challenge of balancing engineering, business, and usability, except they’ve been doing it a lot longer than we have. We can learn a lot from their successes and failures, and by recognizing the differences in approaches they use.
Why Simple Products Are Great Products
The most powerful engineering feats are the ones we don’t notice. The real power of engineers and developers is in turning something incredibly complex into something amazingly simple. The automatic transmission in a car represents significantly more engineering work than a manual transmission. The best works of the automobile industry, urban architecture, and consumer electronics express how great engineering is focused on hiding complexity, not reveling in it.
The best approach to adding value to products is to add power without adding complexity. When you want to add a new feature, is there some way to add it without adding a user interface for it? Can it be reliably automated? Or is there some other feature we can modify or remove to include the new feature, replacing something old with something new and improved? Think of automobiles and how they add significant features with minimal user impact. Anti-lock brakes are a supplement to the standard brake pedal UI, just like power steering is an addition to the usual steering wheel. No training or relearning is required on the part of the driver to get the benefits of these new features. This kind of design effort—where complex features appear simple to the user—makes great products.
The Real Meaning of Software as a Service
When you walk into any sporting goods store and have a question about the backpack you purchased, you expect to be treated with respect. You want the salespeople to talk to you at your level, deal with your issues, and in a polite and fair way do everything in their power to resolve your problem. Software or Web users are no different. They expect to be treated with respect and to get quality service. The customer, or in this case the user, is always right.
We make a critical mistake when we think of error messages as user errors instead of developer errors. If the user is trying to purchase something from a Web site, and there is a problem with the server database, whose fault is it, really? It’s our fault. We weren’t smart enough to ensure that the user would never encounter this problem. Either the project manager and designer failed to create the right interface design, or the development and test teams failed to find an important defect in how the system works. Web site error messages are just as bad, if not worse, than the ones found in software. When an error occurs in our products, we are like the service person at the REI counter. Do we provide courteous and helpful support? Do we treat users as though they’re always right? Almost never. Usually we respond with an error message like this:
Server error 152432. Scripting service failure.
Every error message is a user in trouble. Imagine your user, sitting there, late for a meeting, frustrated because they can’t do the thing they desperately want to do. What would you want your user to see at that moment? What kind of service should they receive? Every error message you put into your product is an opportunity for good service. You have to plan error messages and error handling into your schedule if you want to provide quality service as part of your Web site or product. Project managers should always add error coverage as a feature that is officially entered in the schedules for the dev and test teams. But keep this in mind: There is no such thing as a great error message. A great error is one that has been eliminated through superior error-handling code and product design.
Service goes beyond error messages that provide great support instead of blaming the user. There are countless opportunities throughout a user’s experience to provide great service. Watch someone using the key features of your Web site and ask yourself how it compares to the level of service you’d expect at a good store or restaurant. A good waiter knows when to interrupt you, when to leave you alone, and how to do it all in a courteous and respectful way. The closer your Web site or software quality comes to the levels of good service people get in their daily experiences, the closer you’ll be to having a great product.
Making Time to Create Great Products
Doing anything well is hard. Writing good code takes more time than writing bad code. If your team’s management is dedicated to making a great product, then it will do the work to align team goals and schedules into a reality that creates that product. That’s their job. If they fail to do this, it’s your job to let them know. If the problem is learning about how to integrate the UI, interaction design, or usability into the development process, then ask your design and usability folks if you have them, or send me your questions. Good product design comes from good team process, and many teams still have not figured it out. In many cases, investing in usability engineering saves time and money, because you design things well the first time, instead of trying to patch things up release after release.
A team with good leadership directs everyone to understand how their individual contributions affect the customer. There should be a framework in place before development begins—provided by project management, product planning, and usability—for what problems users have and how the features and technologies the team is building can solve those problems. Without a framework, you’re guaranteed to build technologies that don’t solve any problems. Once a day, you should ask yourself what problem you’re solving, whose problem it is, and whether it makes sense for you to invest your time there.
If your goal is to make something useful, and you know how to make something useful, then you should schedule your project so you can make something useful. Saying, “We don’t have time” to develop a critical aspect of the product is always a cop-out. It really means that your team doesn’t plan well, or its goals and schedule were not designed to match. If the user’s experience of your product is a low-priority item, then maybe it’s time to reassess your project’s priorities. If you believe something is important, you can schedule and plan for it.
Where Does Greatness Come From?
You can help make great products happen by becoming a user advocate. I’m convinced that it’s the team’s collective awareness and dedication to their users that makes all the difference. Send this article to people on your team. Go to usability tests or learn how to conduct one if no one else on your team knows how. Talk to product designers about what’s going wrong. Ask your usability engineer how they do what they do and how you can help support them. Your official job title doesn’t matter; users pay your salary no matter what you do. If you work in a UI discipline, help others on your team broaden their perspective, and invite their participation. When you read a good book or article about design, pass it on to those who need it the most. If you’re one of the few on your team who feels passionately about good design, the challenge is yours—but I’m here to help you however I can.
Human Factor Information
Scott Berkun is currently the UI design and usability training manager at Microsoft. He was a usability engineer on Internet Explorer versions 1.0 and 2.0, UI program manager on Internet Explorer 3.0 to 5.0, and lead program manager for Consumer Windows before moving to his current position.
This article is from MSDN: http://msdn.microsoft.com/en-us/library/ms993293.aspx
