Why Great Technologies Don’t Make Great Products

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

01300000173868121198548127271

产品设计过程

用行业、市场、创新三个实战流程来抽象整个产品的设计过程。首先从行业获得vision, 因为行业先于客户,解决we should do 的问题,引领客户需求;其次,市场先于客户,从细分市场和目标客户获得focus的需求,解决we must do的问题;最后根据公司战略、核心竞争力等有组织、有目的地系统化创新,解决we can do的问题。

产品设计

产品设计的关键,不是使用最先进的技术,也不是开发最全面的功能,而是给客户最好的体验,即好产品就是起用起来简单、简单、再简单而又产生出蒙太奇般用户体验的产品

用户体验是一个复杂的问题,而且是一个越来越受到关注的问题,但是真正能做好这一点的企业并不多。用户体验不需要震撼性创新,而是把众多不被重视的细节做好,就是说“重要的不是你能实现什么, 而是你怎么实现

 

我们一直在使用别人的成果。使用人类的已有经验和知识来进行发明创建是一件很了不起的事情

初心

初心来自日本禅者铃木俊隆的书,《禅者的初心》英文是“ Zen, Beginner’s Mind” 这本书当时在美国引起了很大的轰动,乔布斯深受这本书的影响。书中围绕初心有很多的解释,初心,即“初学者的心”, 修行的目的就是要始终保持这颗初心,其中举例假如你只读过一遍《心经》,可能会深受感动。但当你读两遍,三遍,四遍的时候,说不定你会失去对它最初的感动。
同样的情况也发生在生活中,当我们还是小孩子时,接触到的任何东西都是新的,对事物没有任何先入为主的概念,我们就可以以纯净的心去接触事物和问题。长大之后反而被各种名词和概念所禁锢,抓不到事物的本质。
从另一个角度,初心就是开放的心,而不是封闭的心,是颗空的心,是颗随时准备好去接受的心。初学者对一切持敞开的态度,初学者的心充满各种可能性,老手的心却没有多少可能性。如果用杯子来比喻,那么初心就相当于一个空杯子,随时可以接受新的事物。初心的作用就是教育人们以Beginner’s Mind 去看待事物。
乔布斯的伟大就是能够通过他个人以Beginner’s Mind来看透事物的本质,他将大家都认为理所应当的事情重新从本质上思考,颠覆了人们对音乐,娱乐和沟通的理解,创造出ipod, iphone和ipad。
当我们在做产品或者服务的时候,需要用初心去体会人到底需要什么,只有初心才能体会到本质的东西。如今媒体上铺天盖地的名词和概念,什么SOLOMO,什么O2O,什么Mobile-Commerce等等,伟大的企业家永远不会被这些概念所左右,乔布斯从来不会去讲我这个产品是结合了SOLOMO,而是用抓住人们对于娱乐或者生活的渴望。
所以初心对我的启示就是,不被名词或者概念所控制,从内心去思考这些人们行为背后隐藏的哲理。这也就解释了为什么抄袭来的idea并不会做的非常成功的原因,同样那些把玩概念和名词的,也就并不会做的长久。