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

嗯,我是文艺青年。