显性需求和隐性需求
好设计应该懂得拒绝
很多人都想方设法要把人留在自己的网站，不惜代价“迷惑”、“欺骗”用户，填写更多的资料，做更多地点击，到最后用户一边骂娘一边离开。在中文互联网中处处见到这样的“流氓拉客”方式。
好的设计应该是直接了当，在用户进门的时候，直接告诉用户，我这是饭店，可以让你解决饥饿，要洗头、蒸桑拿上隔壁！
怎么判断用户有没有需求？
把需求分成显性和隐性。
显性需求是说，用户清楚自己想要什么，用户是带着期望来的。
比如：“我要申请一张奥运门票！”
“我要发布一条租房信息！”
“我要下载一首MP3！”
……
隐形需求是有两种：
一 用户不清楚自己想要什么，用户怀着一颗“随便逛逛”的心态来到你的网站。
二 用户带着目的A来，得到更优方案B。（白鸦和angela都拿吃做过比喻）
我再罗嗦两个例子：
A 用户带着的目的是下载一首MP3的歌，下载到本地听是用户的固定思维（显性需求），其实用户真正的目的是想听歌，如果你告诉用户：网站同时提供在线听，而且速度快。这时候用户需求发生转化，激发了用户的隐性需求。
B 用户搜索《青花瓷》到了网站，这是用户的显性需求，而用户的潜在需求可能是：我要听点新歌或者是来点周杰伦的歌。如果你告诉用户：流行的歌还有《菊花台》、《牛X很忙》等等，用户立马精神崩溃：这网站太TMD了解我了。很显然，在这个过程中，网站激发了用户的隐性需求。
结论：
1 满足用户的显性需求是底线。
2 隐性需求是培养用户忠诚度的最好武器。
3 对于隐性需求一，很多网站可能有些小创意在里面，或者有些新的概念想让用户了解，然后拼命地告诉用户：你先读这个，再点那个，填一下资料。不是说这么做不行，得有两个先决条件：
A 用户已经清楚操作完成之后得到什么东西。
B 让用户觉得操作的代价很值。
还拿听歌举例，有一个网站想做音乐社区，作为站方的目的是想让用户转化成注册用户，如果一个陌生用户对该网站没有任何了解。一进门就需要注册，填个人信息等等，尽管首页上用很酷很炫的banner告诉了用户，这是一个音乐社区，可以根据你的喜好推荐音乐，可以通过音乐交朋友等等。
用户是很无情的：NO，太麻烦！我不需要！（尽管很多网站会说：注册只需要10秒钟）
最直接的方式就是试玩，直接让用户感受到价值。
4 对于隐形需求的度的把握是最难的，并不是所有的需求都是受欢迎的。正因为如此，在做需求分析时候，需要拆分需求。
嗯，Tony 不仅仅是个设计师。
嗯 tony还会修马桶，换灯泡，代写作业，传四级答案…
说明白点就是，有目的性的浏览和无目的性的浏览。
如何去发掘这些 隐性需求？
发现有个叫 gravatar的 tooltip是啥意思？
最直接的方式就是试玩，直接让用户感受到价值。
友播这点就做得不错，很吸引人注册。
结论：
1 满足用户的显性需求是底线。
2 隐性需求是培养用户忠诚度的最好武器。
4 对于隐形需求的度的把握是最难的，并不是所有的需求都是受欢迎的。正因为如此，在做需求分析时候，需要拆分需求。
学习了。 需求怎么拆分？能举个例子吗？
@逍遥灵
可以关注ucdchina的话题：期望值。
或许你能得到一些高手的经验。
回楼上的:
我个人认为期望值不是一个好的办法.到底期望在哪里,是个很难界定的东西.既然用户也不清楚,那对于没表现出来的东西,用户如何来表示他的评价呢?实际上,这主要还是靠分析人员的经验和猜测来决定的.有没有好的在这方面的方法论呢?我认为是没有的.结构化分析方法,面向对象分析方法,工作流分析方法,面向方面的分析方法,数据流分析方法等等,这些实际上都在做一个事情,即对显性需求的分析,根本没接触到关键位置.这些方法的成功,大多数还是其他方面的看起来成功,而从来不在分析领域.一个很值得注意的数据是,89年以前,根据在一本书中的数据,大约只有1/3的项目成功了.很不幸的是,到了07年,在面向对象方法大规模流行以后,这个数据掉到了30%(微软中国研究院提供的数据).无论怎么说,随着时间的发展,新的方法论并没有给我们带来更高的成功率.当然,和5%的研究成功率比,我们还是可以接受这个30%的结果,但是和90%以上的工程化的 成功率比,这个数据简直让人作呕.
我的观点是,方法论必须要革新,自顶向下的方法要被彻底的革命.
希望能有人愿意和我讨论一下.
我的邮箱 dqw1984@163.com , QQ 99470140.
1 国内有几个公司真正地用你说的那些分析方法？
2 分析人员的经验是怎么积累起来的？
3 你举的国内的例子不具备说服力，89年前中国是什么状态，下海的人不赚钱的话那真是没脑子，竞争能跟现在相比吗？创业的人的数量级也不是在一个档次上。
Tony,我承认是我的观点没有表达清楚,我在这里忏悔一下.
关于需求分析国内的现状,我承认确实很扯淡.基本上在分析这一方面,国内几乎没有任何可以称道的地方.甚至就我所了解的情况来看,在国内,那些做需求获取,分析的人,很多根本就对这个行业不清楚,他们大多数时候的选择就是重复客户的话,然后把这些转给设计人员,这种情况比较悲剧.不用不表示不好,可能是因为其他的原因没有用,比如你说的第3点.就我所了解的情况来看,企业级的SOA,工作流还是用得比较广泛的.
分析人员如何积累经验?这个问题问得很好,我也一直在考虑这个问题.按照工程化的观点来看,经验应该蕴涵于方法论和工具中,这样任何人都是可插可卸的.当然,我个人认为这个观点很扯,但是至少,良好的方法论在一定的程度上可以对分析分员快速积累经验起到帮住作用.比如工作流,即使你不明白SOA的精髓,但是工作流也可以让你偏离得不太远.当然,分析人员如何能更好的积累经验,我还有一些更好的方法,但是太多了,这里暂时就不写了.
我举的例子,统计的不是中国的数据,是世界范围内的数据,我说的是,在全世界范围内,生产效率没有明显的提高.当然,确实存在一个问题,能力越大,野心越大,最后造成的结果是,在一个更大的复杂环境下,效率的增长被抵消了.这个时候,或许是应该换个方法来跳出这种你追我赶,永远又赶不上的时代了.曾经有行业这样成功过吗?我可以告诉你是有的,一个最古老的行业之一,出版印刷行业.
你把需求分成了显性和隐性.我以前也这么干过的,但是现在我不会了,因为显性和隐性之间很难有严格的界限.如果真的存在严格的界限的话,那么在系统还在开发过程中时,从理论上来说,用户就不应该会对需求进行修改,这个时期需求根本就不应该产生演化,演化只发生在体验以后,事实不是这样的.如果真的是这样的话,敏捷开发就不会那么的强调要把用户加到开发项目中来,边体验边开发.
需求到底是什么?其实很难说清楚.这个行业普遍的倾向于严格的细致的定义,或许是我们过多的关注细节了,忽略了他的本质.下面是我个人的理解:
需求是什么?这个问题是个很难回答的问题.在历史上关于需求的定义有无数.最近的关于需求的定义是在1999年,IEEE将需求定义为:(1) 用户用来解决问题或达到目标所需要的条件或能力；(2) 为了满足一个契约、标准、规格或其它正式定义的文档，系统或系统构件需要满足和具备的条件或能力；(3) 对(1)或(2)中的条件或能力进行的文档化描述。关于IEEE的定义,2,3不用管,因为这两个定义提到了文档,而文档并不是需求里面所必须的,所以我们需要关注的是定义(1),即”用户用来解决问题或达到目标所需要的条件或能力”.
上面的定义还是很抽象,没说得太清楚.Gerald M. Weinberg对于需求有着自己的理解，他认为，问题就是”期望和感受到的之间的距离”。问题和需求在这里可以作为近义词.有人根据这个定义,进而得到了一个关于满意度的公式,在这里我要说明的是,这个定义本身是存在问题的,实际上,这个定义和IEEE的定义还是存在明显的区别的,所以,那个公式也不怎么正确了.
将给出我个人认为的关于需求最准确的定义,并举出相应的例子来说明.
1.需求是一个屏蔽了底层实现的操作,它实现了状态的转换.(很抽象吧,那是当然的,因为我们平时说的根本就不是需求,而是另一个东西)
2.用户(提出)的需求是用户个人认为的对自身目标的最佳解决方案中,自己不能或者不愿意完成的部分,目标和解决方案具有相对性.
需求的定义应该由上面两部分组成,而我们平时说的,其实是第2个部分.例子,一个人肚子饿了,他提出一个需求,说他”要吃米饭”.我想,如果你不给他吃米饭,你给他吃肉的话,他可能会更加的乐意,而这个满意度根本没办法计算,这里实际上存在了两个期望.而事实上,看得更远一点,所做的这些都是为了消除他的饥饿感,于是,生理盐水+葡糖糖也是一个不错的选择,如果这个人没有口感味觉方面的需求的话.事实上,在医院里面,那么胃功能丧失的人还就是这么干的.这里需要罗嗦一下的是,期望本身就是不确定的,甚至是随时变化的.在这个例子中,用户的期望是什么?吃饭?填满肚子?消除饥饿感?为身体补充能量?活着?…事实上,这个期望是可以无限制的抽象上去的,当然,领域可以作为界限,但是跨领域融合难道不也是我们需要干的事情吗?这里于其说是期望,还不如说是目标与实现的关系,并且是存在相对性的,对于不同的东西,目标也可以变为实现,实现也可以变为目标.同时注意最佳,这在一定程度上体现了用户的自大,专制等等.IEEE的定义和Gerald M. Weinberg对于需求的定义,都不能很好的解释这个例子.事实上,为什么系统的演化显得那么的困难?或许还真的是因为我们选择了错误的定义.
如果你对这个东西感兴趣的话,我们还可惜继续讨论.
汗，好长~ PFPF~
不错的了解.
我对这些了解不多.看了之后又激发我现在的了解欲望…
期待你继续更新.
恩好 好 我很喜欢这样的 交流 。
希望有时间给你们聊。
qq 121765924
ҽ
ҽ
引用此文章的博客