标签归档:需求分析

我要的是葫芦

《我要的是葫芦》是人教版小学二年级语文上册的课文。文章讲述了一个人一心想要心爱的小葫芦长大,认为叶子上的蚜虫与葫芦毫无关联,毫不在乎。最终葫芦被蚜虫蛀了,他的愿望也落空了。

标题里用这个,想要说的事情是,我们要真正的理解目的,才能做出来合适的方案。用比较不人话的话来说,不要站在问题本身看问题,才能真正解决好问题。

最近,我跟小伙伴们讨论一个需求,我表达了我为什么要这么做的原因,然后给出了一个我心目中的方案。

接收到需求的小伙伴拿着我的目的和方案走了,在跟团队其他小伙伴讨论的时候发现,我的方案有瑕疵,实际无法执行,于是,他们又来找我。

这一次,我们讨论的不是「我要这么做的原因」,而是「我的方案」。于是,我们就探讨了半天,实际证明,我的方案确实是有瑕疵的,不能执行的。

搞了半天,我忽然想起来,我们为什么要花这么多时间来探讨我的方案呢?我其实只是想要那个目的啊,我其实并不是很在乎是不是用我的方案去做了。如果大家有更好的方案,那是更好的事情啊。

几个人在一起,复盘了这个事情,不由得觉得好玩。然后我们的一个小伙伴总结了一下关于这个事情的感悟,如下图:

我要的是葫芦.pic
这个事情之后,我做了一下反思,反思我在接收老板的需求的时候,和我作为老板向小伙伴们发出需求的时候,分别是怎样的遭遇。

首先,我们在发出一个需求的时候,都是会描述一个「我们想要的结果」,或者叫做「我们为什么这么做的目的」。为了让我们发出的这个需求看上去不是那么扯淡,我们常常都会附上一个「我们心目中的解决方案」,这个解决方案一方面是一种佐证,证明我们的想法是合理的,一方面也是一个指导,给出了一个大概的实现步骤。

然后,我们大概会遇到3个结果:

1、完全不能理解「我们为什么这么做」,但是,老板交待了事情,我们必须得做,就依着自己的性子,搞了一个方案出来。

不理解为什么,不参考指导方案,只盯着要的那个具象的东西,结果就是一塌糊涂。

2,能理解「我们为什么这么做」,但是,不能理解给出的指导方案的目的是什么,就完全照着指导方案去执行了。

这种是最常见的,这种是号称执行力强的做法。我理解你为什么要这么做,你也给了个方案,我要做的事情就是,二话不说,崛起屁股就干,我完全听你的。

这种强执行力的玩法,需要下发需求的人把事情想的足够明白指导方案给的足够正确,同时,实现路径也足够单一才可以。稍微复杂一点的业务,复杂点的事情,这种状态就会经常出现,我很努力,但是,我好像做的始终不是那么回事。

3,完全理解「我们为什么这么做」,明白指导方案与为什么这么做的关系。

这种是最牛逼的配合,你要的是葫芦,但是,我要帮你除草抓虫,因为,即使你知道种个葫芦很不容易,你也不会知道种个葫芦如此之不容易。

当然,就像我的小伙伴说的,不同类型的老板风格不一样。不过,我愿意善意的揣测说,其实,绝大部分老板是这样,他们想要的是葫芦,他们也知道种葫芦很不容易,他们给了你葫芦籽和种子,至于怎么种葫芦,你可以随意发挥,他们不会去干预,只要你能把葫芦搞出来。

其实,我们延展来看,这个案例,就是我们常说的「需求分析」了。如果我们把「老板」当成是一个用户,我们应该首先通过老板提的要求,去分析他真正的需求,理解了他真正的需求,再去思考怎么解决他的需求。

用户所有的需求都是这样的,我要的是葫芦,反正我要的是葫芦。

之前给新人做分享的时候,我经常会用一个例子来说明如何做需求分析及沟通:

– 客人:服务员,给我来杯水

– 服务员拿来一杯热水

– 客人:我靠,这个水怎么这么烫啊!

– 服务员:不好意思,不好意思,我给你换一杯

– 服务员去换了一杯温水来

– 客人拿起温水给自己的女朋友洗了个手

怎么做沟通,怎么做分析,这个故事你看得懂,就可以了。

— 题外话

每当看到我的团队里,有小伙伴有类似的总结与复盘感悟,我都觉得很有成就感。

我最近在思考,到底我们需要怎么样的成就感?或许在不同的阶段,对成就感的定义是不一样的,当我把我自己放在这个团队里的时候,我想,我需要的是让自己有成就感,让小伙伴有成就感,就是这样。

同时,从私心上讲,我又是很希望我的团队能学会独立思辩、勤于复盘、直接的表达,这些是我的价值观与做事方式,也是我认为一个好的产品应该具备的素质,我希望我能黑化他们。

江湖路漫漫,总希望能有志同道合或者臭味相投的人一起前行,大概就是这么个执念吧。

不知道是好是坏,管他呢!

听白鸦UCD2009广州年会演讲

很遗憾,因为正好公司的年会与UCD2009广州的年会在同一天,加之囊中羞涩,所以没能参加。收到了广州那边发过来的5段视频(已经上传至优酷,在这里),很认真的看了一遍之后,觉得实在是遗憾哇。仔细的听了2遍白鸦的演讲,结合自己的理解与实践,写了个听讲笔记。

1、需求,还是需求,一直是需求
需求是整个产品的根,需求支撑着整个产品设计的成长。在最开始的时候我们是从需求出发,可是很多时候我们做着做着就忘记这个需求了,我们开始纠结在如何展示上,纠结在使用华丽的特效上。这个时候,我们应该回过头来,对照着原始的需求再锊一遍。
2、以用户为中心
产品有三大要素:可行性、可能性和用户的期望值;
产品、运营、体验三者是一体的,必须以用户为中心,以用户的需求为中心进行的;
一个产品设计师是必须要同时具备这3个方面素质的。
3、用户体验的5个层次
需求是根本(有用);
稳定是基础(能用);
难用不会成功(易用);
给人带来愉悦(友好);
建立品牌(品牌)。
4、用户驱动
站在用户的角度思考;
满足用户原始需求,发现新需求;
迎合用户习惯。
5、核心致胜
找准抓稳核心用户,明确目标;
做精做透核心需求;
逐步满足非核心的用户和需求;
不做用户不需要的东西。
6、支付宝的粗略设计流程
1)需求调研:核心用户是谁?在什么情况下,有什么需求?市场目标?技术难度?
2)需求分析:用哪些功能来满足需求?优先顺序是什么?打算怎么传递给用户?该阶段产出设计概要
3)产品设计:概念设计、原型设计、模拟和演示
4)设计实现:反复回归原始需求、效果测试
7、用户研究
什么样的人,在什么样的环境下,得到了什么样的信息,有什么样的困难;
只有定量的数据只能看到现象看不到原因,以表带本;只有定性数据只能以偏概全;
把产品先做出来给用户用,然后再快速的改进,迭代;
8、产品路线图
核心用户的核心需求——添加可能的非核心需求——一定量的积累后添加新的功能
9、以小致胜
小细节;
小团队,小公司

比照我们团队目前的状态,我个人认为核心问题出在需求分析与确认阶段。在这个阶段里我们没有能完成对需求的优先分级、与需求提出方进行确认、与技术沟通 实现手段与时间等问题。于是出现的状态就是产品设计师总是在忙原型,不断修改,技术也在不停的改,导致项目被延迟。
在我刚进入团队的时候我就和另外一个设计师做了约定:在每一个设计开始的时候就我们为什么要做这个?我们需要做的核心是什么?达成一致,然后才开始分工协作。但是,我还是忽略了最最开始的阶段:对需求的比对、确认、沟通。所以,这个做什么还是不是真正需要的做什么…..
关键还是“做什么”,“什么时候出来”。 看来,流程,简单易行的流程势在必行了!

更多关于UCD书友会•2009广州年会的信息,点击这里
更多关于UCD书友会•2009广州年会的心得体会,点击这里
更多关于UCD书友会•2009广州年会的的Twitter互动,点击这里

做最多的,展示最好的

农村过年有个风俗,大年初一要到村里所有人家里去拜年,小孩的特权就是可以拎一个大袋子去装礼物。现在回忆起来有一个很有趣的现象,到家境不太好的人 家去拜年的时候他总会塞给你很多的花生、瓜子、还有便宜的糖,每次都搞的袋子里满满的;而家境比较富裕的人家就给一捧西瓜子就完事了。(我小的时候农村还 是相当不富裕的,每家都会种花生,所以花生特别多,但是西瓜子只能去街上买而且价格不菲。在中国的过年基本上就是在过面子,所以不管怎么样都是要在初一的 时候装一装门面的。)

可是结果呢?我们几个小伙伴总是会在拜完年回家的路上把西瓜子自己留下,其余花生什么的要么拿回家给爸爸妈妈继续待客,要么嫌拎着沉直接扔在路上了,而且最念念不忘的还是那些虽然给的少,但是给西瓜子之类的人家…….

每次在讨论产品的时候总是有人说,我觉得用户需要这个,我们应该给用户什么样的功能,完成之后用户可以用这个怎样怎样;我们在设计页面的时候本身网站的内容非常少,功能也少,但是为了让首页和二级页面看起来都不空洞,我们要把能摆的东西都摆上去,结果首页和二级页面上放的东西基本都一样了,用户在各个页面上跳来跳去,总是觉得还是在一个页面上,总是觉得自己怎么走都走不出去,于是下次再也不来了;如果是我在用完这个功能之后我还想怎样怎样,我觉得我们应该给用户更多的东西可以用,这样他们就不会觉得我们的东西太少了,于是一上线就把所有的功能一字排开,让整个开发团队的人累的半死去做满所有的功能…..

可是结果呢?我们的用户体验,你给我了这个功能没有什么大的用处,我百年难得一用这样的功能,往往我们的产品人员会最后发现,消耗了我们90%以上的精力开发的产品只是为了10%的用户去做的,有时满足甚至更低…..

office有众多强大的功能,可是大约我们90%的用户只用到其中10%的功能,那另外的90%的功能大多数不会用到反而让整个office软件显得臃肿且安装缓慢;百度也有很多产品,但是在baidu.com上我们只看到他摆出来多多少少9个产品而已;google的产品也是如此,前段时间我和稻草在一 个偶然的探讨中骤然发现了google reader的强大功能,我当时感叹,google是怎么做的呢?他做了这么多的功能,但是看上去却如此简单,这太了不起了!

我的意思并不是说我们不要去做复杂的产品,相反的,我们需要做功能足够丰富的产品!一个产品20%的功能是用户常用到的,而另外80%是不常用的,我们称前者为基础功能,后者为扩展功能;而同时又有80%的用户平常也就只用这20%的功能,这是二八原则。我们也完全没有必要去砍掉那80%的功能来满足大部分用户,我们需要一个复杂的产品,但是我们更需要给用户展示一个简单的产品,让用户自己去发现那被“隐藏”的功能,他会说,“哇!太神奇,这个产品居然还可以这么用,太强大!”

我们更没有必要在产品刚刚上线的时候就把能够展示的功能不管好坏一股脑的都摆出来,这样的做法只能是让那80%的不常用的功能吓走用户。这就好比最开始的那个故事,那些塞在袋子里的满满当当的花生一样,只会让我觉得很沉,在有必要的时候我想全部给丢掉,只留下西瓜子。

一个好的产品人员应该知道给用户什么,而不是用户想要什么就给用户什么,给他最需要的或者你做的最好的,提示他去挖掘我们隐藏的好东东,这样才能让用户死心塌地的爱上你的产品。

在产品设计中有个原则,够用就好。在最初和我们的技术团队碰需求的时候需要搞清楚,我们的团队开发这个功能需要多久?我们有多少用户需要这个功能?从整个产品运营的角度看,我们是否需要现在就把这个功能推给用户?不要把某一小撮用户需要的功能当作大众想法提前做出来;不要因为一个不被常用的功能拖延整个产 品的开发进度;不要一下子就把用户喂饱甚至撑死。

需求不等于功能

需求不等于功能,或者说你最终设计出来的跟用户告诉你的他需要的“功能”一模一样的功能并不等于他真正想要的功能。
用户告诉福特,他需要一匹更快的马,最终福特给用户的是汽车。
用户告诉你,他需要一个公告板,他要用来展示自己的新产品、自己的新资质荣誉、自己的特价供应、…,你就给他一个公告板,允许展示图片、超链接、产品、视频的“公告板”?
用户告诉你,他需要一个可以收藏自己喜欢的商品、可以合并在一起付款的功能,你是给他一个购物车还是给他一个收藏夹还是同时给2个?(Via

产品设计人员在产品规划的初期直奔功能和表象而去,把自己的思维限定在一个很狭小的范围之内,用户想要什么就给什么,最后只能被用户带到沟里。何 况,很多时候其实用户是不知道自己到底需要一个什么样的功能的。如果我们能试图去挖掘一下用户提出需要“XX功能”背后的需求来设计一下,把他提到的这个功 能进行延伸与扩展,给他一个全新的不一样的功能,反而会获得更好的效果。
我们可以把得到的需求可以分为三个主要类别:
1)最显而易见的是人们讲述的、他们想要的东西。这中间有一部分是非常清晰的好想法,会寻找各种途径进入最终产品。
2)有时人们口中说出来的、所期望的功能并不是一个很好的主意,但是它们代表了一条通向下一个版本的路径:用户实际想要的东西。用户的需求有时是行不通的或者治标不治本的,通过与用户探讨这些建议,有时可以得出真正解决问题的、完全不同的需求。
3)人们不知道他们是否需要的特性。

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

撰写需求的几个原则:
1)乐观。描述这个系统将要做什么事情去“防止”不好的情况发生,而不是“不应该”做什么不好的事情。比如,“这个系统不允许用户购买没有风筝线的风筝”替换成“如果用户想买一个没有线的风筝的话,系统应该引导用户到风筝线页面”效果会更好。
2)具体。尽可能详细第解释清楚情况,这是决定一个需求是否被实现的最佳途径。
3)避免主观语气。需求必须可验证,就是说,它必须要能证明这个需求可以被满足。比如,“这个网站的风格应该是时尚、闪耀的”这样的需求是无法被验证的,我对于史上的定义也许并不符合你的,而Boss对时尚可能有完全不同的看法。
4)用量化的术语来定义需求。比如,“具备高级别的执行能力”可以用“要求这个系统的设计至少要支持1000个用户同时使用”来代替。

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

《用户体验的要素》