[翻译]不要为了让用户高兴,就添加功能

标签: My life 产品 功能 用户 翻译 | 发表时间:2011-01-30 13:42 | 作者:mikespook cong
出处:http://www.mikespook.com

原文在此:http://www.zurb.com/article/561/dont-add-features-to-make-customers-happy
原作者:Dmitry Dragilev

公司中午年饭,喝了几杯红酒……借着酒劲,七里咔喳把这篇早上看到的关于产品设计的文章翻译了出来。大家凑合看,我睡会了……

—-译文分割线—-

这是迷思,不要沉迷于此。在将来的产品策略中,你其实不需要为了让你的用户开心,而添加他们要求的功能。不,你的用户并不总是正确的。不,你的用户并不总是知道他们要什么。不,你的用户不会因为你没有实现他们所有的需求而愤怒。

让我们讨论一下你的用户的功能需求,以及他们有一个好点子,你应当如何做?这是通常的商业思考:

1. 我们需要让用户开心
2. 他们对于这个功能有个极好的用例!
3. 可能其他用户会使用这个功能。
4. 我们需要更多的功能以便做更多的改善。
5. 想要这个功能的人可能很多。
6. 好吧,让我们添加这个功能,让我们的用户开心!

如果你刚刚开始一个产品,添加更多的功能并不会带来更多的回报。你应当关注于产品的核心功能。这里有一段摘自 Recurly.com 创始人 Isaac Hall 的谏言,Recurly.com 有着跟 Dropbox 相同的功能,但是由于在一开始添加了太多的功能从而输掉了这场游戏。

最终,这是由一个非常难以置信的想法而决定:Dropbox 决心限制其功能集合。它只有一个同步从来不会出问题的文件夹——这就是魔法。Syncplicity 可以同步你电脑中的每个文件夹,除非你取消这个设置(不幸的是,有一堆使用这个功能的用户通常会同步 C:\Windows\ ——噢!)我们的公司有太多的功能,同时这导致用户最根本的混乱。在这个环节中,需要足够的用户支持而导致我们不能专注于产品,我们太忙了,以至于不能修复任何错误。–Isaac Hall

每个公司都会增加功能以便创造额外的收益,但是你必须在产品变得成熟之前保持克制。Syncplicity 就是血的教训。

商业上来说,在游戏的初期,都是很害怕拒绝用户的功能请求。为什么?这有一些关于这个问题的迷思:

为了让用户开心,我们需要满足他们的所有需求

请相信,你不必实现用户告诉你的所有功能从而让他们开心。倾听,就像在和你的另一半在争执中时那样,然后说“对不起,我会为这个做些事情,这里有一个替代的解决方案。”如果你不能在给定的时间里,完全满足用户的需求,那就给他们替代的办法。一个极好的例子:我给 Zappos 打电话为了我妻子订购靴子。他们没有我想要的尺码。电话另一头的那位在 Google 上在竞争对手的网站上找到了我要的尺码,同时价格更便宜。于是我决定在他们竞争对手那里买这双鞋,同时也感谢了她的好心。但是,你认为我不会再给他们打个电话买其他的鞋吗?

用户会变得疯狂,同时我们会有公关危机

许多生意人害怕他们的用户烦躁,然后在 Twitter 上抵制他们的工具,或者发表一些对于产品和用户服务不满的言论。我们都听说过糟糕的公关将产品杀死的恐怖故事。但是多数情况下不是这样的。一个要点是让用户知道你会在将来考虑他们的建议,可以立刻加强他们对于你产品的信心。

用户会在接下来的几个月的时间里关注,但也可能不在乎。如果他们关注,你可以让他们知道你已经考虑过他们的建议,并且这时可以决定添加这个功能。在公司已经考虑了用户需求的功能,并且决定不实现它的时候,是不会出现公关危机的。

用户知道什么是最好的

不,绝对不是!谁这么说的?用户在提出需求的时候已经用了你的工具多久了?一个星期?几个月?一年?你自己用了多久?你是你的产品的超级用户。你知道你的产品要比任何人的好。你有产品的远景。你明白最初创建产品的要点。所以,我问你,谁最懂你的产品?你还是用户?

因此,你是产品的第一号用户,添加的任何功能都是增强产品的体验。你明白工具的核心用例。如果功能不能帮助你使用工具,那又如何帮助其他人像你一样的尝试使用它呢?

好奇 – 你向产品添加功能的条件是什么呢?

相关 [翻译 用户 高兴] 推荐:

[翻译]不要为了让用户高兴,就添加功能

- cong - Some reminiscences, some memories
原文在此:http://www.zurb.com/article/561/dont-add-features-to-make-customers-happy. 原作者:Dmitry Dragilev. 公司中午年饭,喝了几杯红酒……借着酒劲,七里咔喳把这篇早上看到的关于产品设计的文章翻译了出来. 在将来的产品策略中,你其实不需要为了让你的用户开心,而添加他们要求的功能.

用户为什么不高兴:中国B2C电商六大不爽!

- - 互联网的那点事
编者按:电子商务已经给我们的工作生活带来不少便利,但未来的发展方向在哪里. 也许从用户的角度出发,从知乎用户徐孜望给出的这些问题( 知乎链接),更能够看出电商未来的发展阻碍. 对于电商从业者而言,如何解决这些问题,是他们需要思考的. 用户想的是“擦,不爽啊,不爽”,创业者想的是“擦,成本啊,成本”,完美的东西很难存在,有些问题大家都看到了,但是未必有人能有很好的解决方案,所以大家凑合着看吧.

翻译《The rsync algorithm》

- AWard - CSDN博客推荐文章
     最近在学习Rsync工具,在对Rsync算法大加赞赏之余,决定将《The rsync algorithm 》翻译,有不正之处 还请指正. 安德鲁Tridgell 保罗马克拉斯  部计算机科学 澳大利亚国立大学 堪培拉,ACT 0200,澳大利亚.        本报告介绍了将一台计算机上的文件内容同步到另一台机器上的文件的算法(同步后保证文件内容需要一致).

闲谈翻译

- Frank - 乱象,印迹
算起来,我也算有一些翻译经验的人了,最近接连做了两次关于翻译的分享,发现对翻译有兴趣的人很多,索性,将自己关于翻译的经验做个总结,发在这里. 我是因为很偶然的机会接触翻译的. 当时还在学校,考完了TOFEL和GRE,美国对伊拉克动武,国内的报道非常奇怪,为了在论坛上争论,我开始翻译一些外国媒体的报道,发在论坛里.

翻译:WebKit for Developers

- - TaoBaoUED
Paul Irish 大湿为我们带来了这篇开年大作,文章深入浅出的阐述了各 Webkit port 的迥异,文笔细腻,是一篇不可多得的 Webkit 入门开胃菜. 为了让大家第一时间更好的品尝这道大菜,一丝特别邀请了几位 Webkit 专业开发人士作为本文的翻译顾问,在此表示由衷的感谢. 原文链接:  http://paulirish.com/2013/webkit-for-developers/.

翻译与字体

- Chenta - Apple4.us
胡天翼今天在 Twitter 上说:. 这次关于《乔布斯传》的讨论怎么都在讲翻译. 我以前从来没见过大家对一本书的翻译那么痛心疾首且富有参与精神地讨论,以至于产生了两种幻觉:1. 以前人们读的译本都很好,这次的翻译烂到让人不能相信;2. 这么多年头一次读厚书一定要抓紧机会多叫几声. 我认为这个设问的答案很明显,但不在于上述两点.

Google翻译的内涵

- hahahaha哈 - 大家都是中国人
非PS图,可以自行前往http://translate.google.com/验证.

英文笑话,带翻译

- iSingle - 河蟹娱乐
感谢河蟹网友moai的分享,来源Misc Joke,译者heather_pan,转自译言. A few days after Christmas, a mother was working in the kitchen listening to her young son playing with his new electric train in the living room.

[转载]The C10K problem翻译

- jin - 新浪开发者博客
如今的web服务器需要同时处理一万个以上的客户端了,难道不是吗. 毕竟如今的网络是个big place了. 现在的计算机也很强大了,你只需要花大概$1200就可以买一个1000MHz的处理器,2G的内存, 1000Mbit/sec的网卡的机器. 让我们来看看–20000个客户,每个为50KHz,100Kbyes和 50Kbit/sec,那么没有什么比为这两万个客户端的每个每秒从硬盘读取4千字节然后发送到网络上 去更消耗资源的了.

[翻译]Is the KDD Cup really music recommendation?

- Forrest - Resys China
原文链接:http://musicmachinery.com/2011/02/22/is-the-kdd-cup-really-music-recommendation/. KDD Cup 2011的主题是音乐推荐,虽然数据集还没有正式公布,但相关的讨论已经开始预热了. 本次数据集合的一个特点,是评分对象不光是歌曲,还包括专辑、艺术家和音乐流派,这使得用户的偏好相对更丰富和层次化;但content-based的研究者意见很大,音乐信息也被搞成匿名使得他们基本没法玩了.