Tag Archives: 产品

从需求到网站:(二)产品和原型

接上文:从需求到网站:(一)需求

现在有了原始需求,接下来,我们就要设计产品了。如果你看到现在,还对“产品”的含义不是很理解,可以参考我之前写的一篇文章:什么是互联网公司的产品经理?

产品人员的产出物

设计产品一般产出物就是需求文档和原型。啊嘞?需求不是上一节讲过了么?那是原始需求。梳理完原始需求,接下来要设计产品,一般会画出产品原型,交给交互设计/视觉设计;以及需求文档交给程序员。

需求文档确实力求忠于需求,但同时,产品人员在撰写需求文档时,已经在心中勾勒出产品的摸样。需求文档中有时会涉及到流程图,其实已经开始对解决方案建模,最终,流程会体现在原型设计中。

与此同时,需求文档和原型也需要最终跟需求方确认,毕竟谁提出来要做的是吧,万一有偏差。如果是消费级产品,需求方是大众,这种确认就得找用户研究团队来做了。创业公司才不管呢,哪有时间做用研,完全看产品人员的自身素质。

需求文档

说了半天需求文档,需求文档里面写些啥?其实就是把用户出现什么问题,要怎么做解释清楚。几个W嘛是吧,干什么职业都得围着What/Who/When等等这些东西转。

需求神话这个产品的一个需求用例可以描述如下:

当用户想修改某一个需求用例的优先级时,通过界面上的控件选择优先级,分为1、2、3、4、5个优先级,优先级修改完毕后,该需求的显示状态发生变化,提醒用户修改已经成功。

这一段描述很抽象,没有指明特定的交互。书里面大约会强调,需求文档就描述需求就好了,不要跟交互扯上关系,不要有“按钮”这种词汇。这种思路大约是不想限制交互人员的发挥。与此同时,后台开发人员其实不需要知道交互上发生了什么,这段需求只要体现出修改了需求用例的状态变化就行了,因此需求文档的任务也就完成了。

当用户想修改某一个需求用例的优先级时,通过界面上的笑脸和哭脸按钮选择优先级。笑脸有三种含义:功能完成后用户非常高兴/用户感觉开心/用户觉得无所谓;哭脸有三种含义:功能不完成用户极度失望/有点失望/无所谓。每种含义依次代表0、1、2,通过两个按钮状态的搭配,可以加和出0、1、2、3、4五种优先级。例如感觉开心+有点失望 = 1 + 1 = 2,即该需求优先级为2。点选后,根据优先级的不同,需求卡片的背景颜色变成对应的颜色。

这是一段包含了交互的用例描述。不过这个例子跟上面的例子对比可能有点不恰当,因为通过两个按钮来组合出优先级这个需求,实际上是对优先级重新定义了。所以,上面两个例子不是描述的相同的需求。(我真失败啊= =b)

这两种需求描述都可以。如果你一定找个标准文档,我只好说我从来没找到过╮(╯▽╰)╭。标准都是人定的。Get things done. 事实上,用例这个词就是一种需求描述形式(来自UML),还有用户故事(来自Scrum),那些搞软件工程的人到今天还在吵来吵去敏捷和传统软件工程哪个好的问题。想干活的,还是自己习惯咋样就咋样写吧。

额,你说不写需求文档?一个人自己玩玩小项目还可以,多人协作的、需要长期维护的项目你试试看。新来的程序员/产品问你为什么要有这个功能,你说这个我们当时做的,我也忘记了。于是从前大家开了两天会定下来的feature又开了两天会。╮(╯▽╰)╭

原型图

现在的产品人员必备技能就是画原型了。一说搞产品,必须Axure。文艺青年说我用Balsamiq Mockups。原型说白了就是界面草图。草稿纸上也可以画。除了画出样子,网站原型另一个任务就是要画出交互。Axure的好处是,可以快速的帮你把点击某个按钮或者链接之后的界面反馈、跳转等动作做出来。很牛逼,用鼠标就能搞定。很多人说我靠原型啊好难啊,其实优酷上搜个教学视频,2小时包教包会啊。

产品人员要画原型,交互设计师也要画原型,他们俩最后是要打架嘛!其实产品人员的原型的目的是展现出功能,交互设计师才是确定交互。普通交互设计师可能会讨厌产品画原型,尼玛限制我思路嘛。牛逼交互设计师可以做到完全不理会产品给的交互,一坨shit,我理解清楚需求就可以扔掉了。

创业公司,对不起,哪养得起交互设计师啊,用研都没人做呢。产品大兄弟就靠你了啊!

搭配本例子的原型一瞥:

enter image description here

嗯,我是文艺青年。

产品孵化、微博营销和人际网络

好吧,这种标题的文章我一般不怎么看。不过考虑到3 Dumbass Start-up Mistakes That You’re Probably Making上了hacker news,还是看了一下,觉得讲的还是有道理的:) 但我实在不愿意起这么傻的对应中文标题,还是换个名字吧。

1. idea incubation

idea孵化,在正式发布产品之前,把产品孵化好。孵化这个词时髦而恰如其分,但是,说了相当于啥也没说,因为孵化具体如何操作谁也说不清楚。不过文章中提到的一点就在于,在baby孵化好之前,早产儿一般容易挂。在正式发布产品之前,对需求、市场做好功课,不断精炼等等。什么时候算是孵化好了,这个指标文中没有说。似乎可以一些孵化器的标准,例如xx工场。

2. social media marketing

这里文中提到,社交账号需要尽量少的提到个人信息。同时,要显得自己是一个guru。似乎国内的社交账号一般都要显得自己是心灵鸡汤。社交网络中一个重要的一点是,创造social proof,就是要人们按照你说的去做,例如“别担心,第一次你是不会怀孕的,相信我,我在健康课上学过。[链接]”。而创造social proof的一个方法就是,让账号是一个guru,想象自己是马丁路德金,然后号召大家:

@MLKjr: Injustice anywhere is a threat to justice everywhere. Here’s an article for my followers to consider [insert link].

不要提自己的个人信息,例如我今天吃了啥。Nobody cares。

3. networking

创业初期构造自己的人脉= =?或者这里的词:network很重要。糟糕的是,人脉的含义是利用别人带来的资源,完成自己想要做的事,这往往行不通的。就像在人人上加了一个人为好友,就直接要求资源或者长时间的咨询。我对这种人真是无语至极,到后来就只好呵呵了。文中打了一个比喻,人就像网络中的一个节点(事实上也是),信息、资源在节点之间来回的传递,而不是单向的传递到你这里。这就是所谓的win-win。你首先得为其他人提供价值,别人才会回馈于你。

长杯子和用户需求层次

前几天向同学抱怨,说没法在淘宝上搜索到一个“长”杯子。同学Y怪异的看着我说,我都没明白你想要什么,更何况淘宝的搜索引擎。这倒是提醒我思考。假设我是用户,Y是产品经理,那么Y就需要考虑,我真正的需求是什么?

backpack

一个足够长/高的水壶

于是我开始叙述:去年买了一个瑞士军刀的电脑包,随身背,但是两侧放水壶的地方的设计很奇怪,没有松紧带,拉链只有一侧有,又很短,半个瓶子都套不住,但是上面有一条带子,如果水壶足够长或者高,就能用带子拴住。之前买的普通水壶,因为不够长,里面有水的时候,就很容易摔出来,然后就变形了。

听到这里,Y产品经理就明白了,原来你是要一个尺寸上很长的水壶,刚才说“杯子”明显是没描述对。此时Y产品经理可以去跟开发说,开发出来一个足够长的水壶吧~

一个能够放在包上的水壶

但Y转念一想,用户真正想要的是什么呢?其实用户是希望水壶能够放在包上,方便携带。那这样的话,就不一定要弄一个长水壶了。只要能够放在包上,我们为什么不做一个有扣子的,可以扣在书包的那条带子上的水壶呢?这样更稳固,就算书包倒过来放,都不会摔出去。还可以在扣子上动动脑筋,让水壶很容易从扣子上取下来,不要因为扣子降低了用户体验。这个时候,Y已经觉得差不多了,给出一个更好的解决方案,并且问题解决的更彻底。于是Y可以跟开发说,开发一个带扣子的水壶吧,扣子要牢固,而且容易解开和扣上。

随身带水

但Y吃完饭的时候突然又想到,其实用户真正想要的是能够把水随身携带,从而在外面或者不容易喝道水的地方,能够有水喝。水壶是一种很传统的解决方案,那有没有更好的呢?或许可以设计一种袋子,能够把水装进袋子里,然后有一个壶嘴,用户可以方便喝,也方便用户灌水。看西域的那些羊奶,不就是装在那种牛皮袋里嘛,我们的袋子可以设计的更小更好看。袋子是可以放在书包里的,因为形状不是很固定,塞在任何一种包里都可以,还减轻了总重量。于是Y大喜,这是颠覆性的产品,我要改变世界了。于是Y跟开发说:不要开发水壶了,开发一个不会破的水袋吧,弄一个壶嘴,方便用户喝也方便用户灌水。

喝水

受到水袋的激励,Y开始进一步思考,用户到底要的是什么?其实用户就是想在口渴的时候能喝水,那怎样才能让用户不会口渴呢?可不可以发明一种糖果,让用户吃了一天就不用喝水!?没错,就这样!半个月后,Y拿出一本《糖果水》的科幻小说,寄给了出版社。

总结

经过这一番思考,我想产品经理的思路已经比较明白了。只有通过不断的追问,才能够给出真正优秀的解决方案。福特说,如果我当年去问顾客他们想要什么,他们肯定会告诉我:“一匹更快的马”。然后福特发明了汽车,让顾客不用骑马了。从文中可以看出,无论把需求分析到哪一层,都可以给出对应的解决方案,最终使用哪一个,就得按照很多其他因素来考虑了,开发实力,投入资源什么的。本文这个喝水的例子,可以说明一个广为流传的断言:所有的需求的背后,都会有一个马斯洛需求。解读用户的需求有一些模型,Y型大约是比较公认的一种,有兴趣可以找找看。

So, what do you want ?

用户调研——先有鸡还是先有蛋?

最近一个项目在方案的制定阶段,由于项目牵扯到的利益相关方(用户)太多,因此想到求助于用户调研来帮助确认一下需求,希望通过用研能够给产品的设计及整个项目的运营方案提供一点支持。联系了一下用研团队,告诉我说需要对整个方案给出一个demo,开始还以为是要将各用户坐到一起来跑一遍流程,后来进一步沟通,原来是要产品的交互原型,并通过这个原型来和用户进行沟通并得到用户反馈。

于是我就绕糊涂了。在我心目中,是希望通过用研来帮助我确定方案,因为很多地方不敢拍脑袋决定,方案确定在用研之后。但从用研团队的来看,是在已有产品方案的前提下,让用户来提出问题和反馈。用研的思路没有错,因为只有让用户真正用上了产品,才能去获得反馈,否则用户根本就不知道你在说什么。这下到底是先有鸡,还是先有蛋呢?

这两天仔细想了下,大概画出下面的图。

一款产品在初始阶段,是需求的提出。产品经理此时需要感知并收集原始需求,分析并确认这个需求,据此进行产品设计,以及相应的商业方案的确定。而我的思路便是在这个阶段,进行一次用户调研。当然在我的想法中,并不是拿着产品去问用户你要不要这个产品,而是通过一些其他的问题来进行一些侧面的了解。相当于是向用户去确认这个需求。

用研团队提出的介入点实在demo-用户反馈这个阶段。这个阶段的用研目标相对明显,得到的用户的反馈更为直接。即这样的产品设计是否能够恰当的满足用户的需求。

两处虽然都是用户调研,但用户在其中的作用并不一样。第一处是需求的产生者,第二处是产品的审查者。那第一种用研是否有用呢?还是应该快速的给出demo,进行第二种用研?