需求不等于功能

需求不等于功能，或者说你最终设计出来的跟用户告诉你的他需要的“功能”一模一样的功能并不等于他真正想要的功能。

用户告诉福特，他需要一匹更快的马，最终福特给用户的是汽车。

用户告诉你，他需要一个公告板，他要用来展示自己的新产品、自己的新资质荣誉、自己的特价供应、…，你就给他一个公告板，允许展示图片、超链接、产品、视频的“公告板”？

用户告诉你，他需要一个可以收藏自己喜欢的商品、可以合并在一起付款的功能，你是给他一个购物车还是给他一个收藏夹还是同时给2个？

产品设计人员在产品规划的初期直奔功能和表象而去，把自己的思维限定在一个很狭小的范围之内，用户想要什么就给什么，最后只能被用户带到沟里。何 况，很多时候其实用户是不知道自己到底需要一个什么样的功能的。如果我们能试图去挖掘一下用户提出需要“XX功能”背后的需求来设计一下，把他提到的这个功 能进行延伸与扩展，给他一个全新的不一样的功能，反而会获得更好的效果。

我们可以把得到的需求可以分为三个主要类别：

1）最显而易见的是人们讲述的、他们想要的东西。这中间有一部分是非常清晰的好想法，会寻找各种途径进入最终产品。

2）有时人们口中说出来的、所期望的功能并不是一个很好的主意，但是它们代表了一条通向下一个版本的路径：用户实际想要的东西。用户的需求有时是行不通的或者治标不治本的，通过与用户探讨这些建议，有时可以得出真正解决问题的、完全不同的需求。

3）人们不知道他们是否需要的特性。

因为用户群体之间存在着很大的差异性，所以确认用户需求是复杂的。我们可以把大量的用户需求划分成几个可以管理的部分，这样通过用户细分来完成。把用户分成更小的群组，每一群用户都由具有某些共同关键性特征的用户所组成，可以通过人口统计学的标准来划分，也可以通过心理方面的数据来描述。

细分用户不仅仅因为不同的用户群有不同的需求，还是因为有时这些需求也是相互矛盾的。对新手用户而言他可能需要把一个系统分成若干简单的步骤，而相对于专家级用户而言这样的分解可能会妨碍他的快速操作。很明显的是，我们无法提供一种方案来同时满足这两种需求，此时，我们需要要么选择针对单一用户群设计，要么为执行相同任务的不同用户群提供不同的方案。

撰写需求的几个原则：1）乐观。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是“不应该”做什么不好的事情。比如，“这个系统不允许用户购买没有风筝线的风筝”替换成“如果用户想买一个没有线的风筝的话，系统应该引导用户到风筝线页面”效果会更好。

2）具体。尽可能详细第解释清楚情况，这是决定一个需求是否被实现的最佳途径。

3）避免主观语气。需求必须可验证，就是说，它必须要能证明这个需求可以被满足。比如，“这个网站的风格应该是时尚、闪耀的”这样的需求是无法被验证的，我对于史上的定义也许并不符合你的，而Boss对时尚可能有完全不同的看法。

4）用量化的术语来定义需求。比如，“具备高级别的执行能力”可以用“要求这个系统的设计至少要支持1000个用户同时使用”来代替。

搞清楚了“用户具体需要的是什么”、“企业需要得到什么”这样2个问题之后，我们才能配合着网站的运营开始把用户需求和网站目标转变成网站应该提供给用户什么样的内容与功能，进入到具体的功能设计层面。

本文来自：http://www.ikent.me/blog/1546#ixzz0HFXgvPCV&B

评论

1 楼 metadmin 2009-06-13  

呵呵，这个很多人容易犯错。就像“答案”并不是“问题描述”一样。记得有本书《你的灯还点亮着吗？》，讲了这些问题。


我博客里面有很多细粒度权限管理讨论，欢迎做客