需求不等于功用，或者说你最终设计出来的跟用户通知你的他需求的“功用”如出一辙的功用并不等于他真正想要的功用。
用户通知福特，他需求一匹更快的马，最终福特给用户的是汽车。
用户通知你，他需求一个公告板，他要用来展现本人的新产品、本人的新资质荣誉、本人的特价供应、…，你就给他一个公告板，允许展现图片、超链接、产品、视频的“公告板”？
用户通知你，他需求一个可以收藏本人喜欢的商品、可以合并在一同付款的功用，你是给他一个购物车还是给他一个收藏夹还是同时给2个？
     
产品设计人员在产品规划的初期直奔功用和表象而去，把本人的思维限定在一个很狭小的范围之内，用户想要什么就给什么，最后只能被用户带到沟里。何 况，很多时候其实用户是不知道本人到底需求一个什么样的功用的。如果我们能试图去挖掘一下用户提出需求“XX功用”背后的需求来设计一下，把他提到的这个功 能进行延伸与扩展，给他一个全新的不一样的功用，反而会获得更好的效果。

 我们可以把得到的需求可以分为三个次要类别：
 1）最不言而喻的是人们讲述的、他们想要的东西。这两头有一部分是非常清晰的好想法，会寻觅各种途径进入最终产品。
2）有时人们口中说出来的、所期望的功用并不是一个很好的主意，但是它们代表了一条通向下一个版本的路径：用户实际想要的东西。用户的需求有时是行不通的或者治标不治标的，通过与用户探讨这些建议，有时可以得出真正处理问题的、完全不同的需求。
 3）人们不知道他们能否需求的特性。

由于用户群体之间存在着很大的差异性，所以确认用户需求是复杂的。我们可以把大量的用户需求划分成几个可以管理的部分，这样通过用户细分来完成。把用户分成更小的群组，每一群用户都由具有某些共同关键性特征的用户所组成，可以通过人口统计学的标准来划分，也可以通过心思方面的数据来描述。
      细分用户不只仅由于不同的用户群有不同的需求，还是由于有时这些需求也是互相矛盾的。对老手用户而言他可能需求把一个系统分成若干简单的步骤，而绝对于专家级用户而言这样的分解可能会妨碍他的快速操作。很明显的是，我们无法提供一种方案来同时满足这两种需求，此时，我们需求要么选择针对单一用户群设计，要么为执行相反任务的不同用户群提供不同的方案。

 撰写需求的几个准绳：
 1）乐观。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是“不应该”做什么不好的事情。比如，“这个系统不允许用户购置没有风筝线的风筝”替换成“如果用户想买一个没有线的风筝的话，系统应该引导用户到风筝线页面”效果会更好。
 2）具体。尽可能详细第解释清楚情况，这是决定一个需求能否被实现的最佳途径。
 3）避免客观语气。需求必须可验证，就是说，它必需要能证明这个需求可以被满足。比如，“这个网站的风格应该是时髦、闪耀的”这样的需求是无法被验证的，我对于史上的定义也许并不符合你的，而Boss对时髦可能有完全不同的看法。
4）用量化的术语来定义需求。比如，“具备高级别的执行能力”可以用“要求这个系统的设计至少要支持1000个用户同时使用”来代替。
 
搞清楚了“用户具体需求的是什么”、“企业需求得到什么”这样2个问题之后，我们才能配合着网站的运营开始把用户需求和网站目标转变成网站应该提供应用户什么样的内容与功用，进入到具体的功用设计层面。