砍掉产品80%的功能 集中力量把那20%做到八十分以上

昨天在微博上发了这么一句话:“砍掉这个产品80%的功能,集中力量把那20%做到八十分以上”。作为一名基层码农,这本是一句对某些产品状况无可奈何的吐槽,没想到收获了很多不明真相群众的赞扬、反驳以及误解。

为什么产品要做减法?

  当然,这的确是一句很没溜的话,砍掉产品功能当然不能儿戏,何况砍掉80%。而80%、20%显然也只是不准确的感性数字。那么为什么要砍掉产品功能,砍掉哪些产品功能,以及如何砍?

  个人认为,根据与用户需求、产品主旨的契合度,产品功能可以分为如下几种:

  1,核心功能:例如搜索引擎的搜索功能、IM的通信功能、电子商务网站的购物功能、门户网站的内容发布功能等等。这些功能直接满足用户需求,是产品最核心的部分。不用说,这些功能只能逐步强化精细化,绝不应该砍掉,除非产品转型;

  2,系统工具:例如社交网站的私密通信工具,电子商务网站的搜索工具、BBS的用户管理功能等。这些工具并不直接满足用户需求,但却是满足用户需求过程中必不可少的环节。这些功能有可能利用的频率并不高,例如网站黑名单功能,但却是一个成熟系统必须具备的功能。绝不可以因使用频率低而更改其主旨,更不应该砍掉;

  3,附属功能:例如QQ的QQ秀与好友印象、微信的游戏、百度的贴吧等等,这些功能满足用户的附属需求,它们附着于主需求之上。良好的附属功能是产品微创新非常重要类型,可以进一步提高用户体验;

  4,附加功能:例如搜索引擎与门户站点的广告功能,给其它产品导流功能,以及“与产品主旨无关的功能”;

  产品做减法,更多的是第四种。部分功能的附加是无奈之举,例如广告,这部分功能不是不应该砍,而是不能。能砍掉的更多的是“与产品主旨无关的功能”。那么,何谓“与产品主旨无关的功能”?为什么又要砍掉它?

  数年以前,谷歌出了一款叫做iGoogle的工具,一时风靡。这款工具上,用户可以把自己需要的功能添加到一个页面上,包括自己的邮箱、日历、天气预报、记事本等等。在这个页面上,可以只登陆一次,做很多工具的事情,非常美好,中国包括百度网易等很多公司都做了类似工具,但逐渐销声匿迹了。为什么呢?

  其实原因很简单:用户不习惯这样用系统,用户只希望在一个平台上满足自己的一个核心需求。去饭店就是去吃饭的,去电影院就是去看电影的,去图书馆就是为了借书的。正如同上百度就是为了搜索,上QQ就是为了通信,上人人就是想看看同学,从来没有一个平台能把所有用户需求都满足。

  产品主旨的选择是非此即彼的,是人人就不能再是微博,是微博就不能再是微信。同样的功能,不同的细节与呈现方式,会使得产品的主旨并不一样。人人、微博、微信都有长短内容发布功能,都能跟用户建立关系,都能看到用户的发布信息,这些功能点很类似,但是其功能的细节不同,于是它们是不同产品,用户对于它们的定位与期待是不同的。

  所以电影院不能再去添加饭店功能。当然,在电影院可以出售饮料与爆米花,因为满足的是用户“看电影时候的就餐需求”。饭店不能再去做电影院,但在饭店放一个电视往往也可以提高就餐者的体验,因为满足的是用户“就餐时的娱乐需求”。刻意的附着与悉心的附加,两者之间差之毫厘,失之千里。

  那么,是不是“附属功能”就越多越好呢?也不尽然。一个系统过多的“附属功能”,尤其是低质量“附属功能“的附着,也是一个灾难。产品功能都是消耗用户资源的,需要消耗用户的认知能力,需要让用户点击,需要消耗系统的位置。如果用户不用,或者用的太少,这些资源就白白浪费,浪费过大的时候,灾难就产生了,用户的将很难辨清产品主要功能,会看不懂系统,直接的恶果就是老用户的厌烦,新用户更是很难融入。

  总体而言,产品功能不是越多越好,不是越多就越能够给予用户更高体验。让产品承载多少附属需求与附加需求,需要良好的掌控把握。

  还有一个很重要的原因,就是研发资源的有限。

  既然产品功能消耗用户资源,那么如果产品消耗的资源不能大于给用户产生的价值,就没有意义,甚至是负分的。如果说一个八十分的产品,可以给用户创造八十分的价值,那么只有六十分的产品,可能并不能给用户创造六十分的价值,甚至不能给用户创造任何价值。

产品设计

把常用的功能放在显眼的位置, 能够轻松触及。 以前用过MS 的 WM, 里面的退出程序按钮真的是让人蛋疼的紧,好像跟你在说,“就是让你关不掉我”

一个好的状态过渡动画会让你感觉更加的舒心,特别是在等待的时候, 漫长的等待时间会让人抓狂,如果有一个动画或者是文字信息会好很多

 

认清市场和自己,界定能力的界限。在可以做的时候不做,是克制的智慧。

什么地方应该深入?什么地方应该浅显?为什么一个点击动作就需要如此心血,大家都喋喋不休的多任务却简单限制?在各种维度上,对“度”做恰到好处的把握,却非平常。

音符的重与轻,词句的增与删,色彩的浓与淡?

自古而来就是艺术

通过眼球运动可以准确掌握此人在看什么

眼球运动研究是基于这样的一个思想,即人的目光一次只能集中在一个非常小的范围内,这个小范围我们称之为“视觉距”。

我们在读书时,目光中一次只能进入一个关键字以及左边4个字和右边的15个字。我们的目光就是从这样的一组字跳跃到另一组字,然后在上面停留片刻以看清楚每个字。我们之所以能够把目光聚焦在那一部分文字上,是因为眼睛中的大多数传感器——那些对眼睛所看到的事物进行加工的感受器——集中在视网膜中央一个叫做中央凹的微小区域里。这就是我们读书时眼球移动的原因。

如果你能跟踪某人中央凹视网膜的运动以有其注视的内容,你就能够极为准确地掌握此人到底在看什么,到底在吸收什么信息。

 

PS:

由此可见,在网站、软件等产品设计时,并不是页面越复杂越好!需要合理的安排空白与内容。尽量吸引住用户的眼球!

眼球

学习总结

今天早上还是按往常一样,打开电脑,拿出这本书——《就这么做产品》——出来看,看着看着发现怎么到参考文献了?突然才意识到我把这本书看完了。每天看一点,每天学一些,积累起来到今天看完了。

看完后感觉脑袋里有所得,但又好像不明确,要说出来大概我学到了什么,需要想一想。

整本书从产品需要开始分析,涵盖开发,测试,营销等IT产品的各个方面,可谓是全。

 

产品开发要结合市场实际,要出在满足基本功能的前提下尽早出一版本,去占领市场,然后根据用户反馈等信息,不断的去修正产品,终于完善优化产品,并在市场上站住脚根.

怎么样去判定一个需求:你现在感觉麻烦不方便恶心的事情里都包含着一个需求,就看你如何去解决。

细分市场,定位目标客户,产品满足目标客户的需求,使客户满意。

 

消费者购买决策过程。 问题识别->信息查询->备选评估->购买决定->购买之后

 

低成本规模经济,模式创新,技术创新,营销创新(渠道,策划),山寨模式(模仿,整合,草根精神),产品设计简单为美

责任要落单

 

先予,后取

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