存档

标签 ‘需求’ 中的存档

产品设计流程中的关键评审点

2010年08月02日 Ben 2 条评论

产品设计流程中,比较关键的评审点有哪些呢,如下图:

 

iamben@关键评审点

(看不清,请猛击图片看大图)

如上,产品设计流程中,比较关键的评审点有产品介绍会议、需求评审、项目启动、原型设计评审。

产品介绍会议

作为专为老板定制的产品介绍会,其重要性当然不言而喻,相当关键。任何产品,在开工之前,一定需获得老板的支持,因此最好的办法就是做一个漂亮的PPT,然后把老板们召集起来,充分发挥你的口才,给老板们好好的生动的上一课。

在介绍会上,介绍一下为什么需要这个产品,都有哪些商业价值,能给公司带来何种的利益,尽力吹。

提出一个可行的产品规划,短期的、中期的、长期的都可以,让老板们觉得你是在认真的做这个产品。

最重要的一点,PPT中要提出对资源的要求,有多少人参与,都需要什么人。

总的来说,产品介绍会主要的目的就是给老板介绍产品,需获得老板的支持,向老板要人。

需求评审

“很好,就这样执行下去吧”,老板都这样说了,那就什么也别说,甩开膀子干吧。

等等,产品可大可小,我们到底做多少,做到什么程度,满足哪些需求,怎么定?

那就把相关人员聚在一起开一个需求评审会吧,大家讨论一下,本期产品的实现范围,给需求排个优先级。

讨论完毕,一定记得冻结需求,并形成需求文档。后期的详细产品特性以及项目计划,都已这份需求文档为准,对于后续执行过程中的新增需求,一律作为后续需求,补充在后续的版本中,这点很重要。

项目启动会

好了,产品的实现范围确定,相信产品特性也就确定了。

这个时候,可以把产品组相关人员都聚集起来,如策划、运营、开发、测试、美工、市场等相关人员。

给大家说说,这是什么样的产品,要实现哪些功能,完成后,我们能得到什么。

另外,需在会议上提出初略的产品计划,更详细的计划,需进一步与相关部门的负责人沟通后才能得出。

总之,就是要给大家说清楚,接下来我们要做什么事情,大致的范围是怎样的,具体有哪些人参会,项目的大概计划如何。

产品设计评审

需求确定后,即可开始产品的原型设计。在之前,需产品设计师充分理解需求,并将需求转化为产品特性,以原型的形式展现出来,并提供给开发、美工、测试人员。

在原型设计完成后,需对原型进行评审。通常,评审会并不是一次性通过,都会来回好几次。

好的产品是“磨"出来的,没有哪个产品一做出来就是完美的,都需要不断的调整、完善。同样,我们做原型,也应该有这样的态度,原型也是产品,不能因为是原型就马虎对待。

原型设计评审通过后,产品的前期工作已基本完毕,对于产品后期的工作,已基本没有太大的障碍,各条线继续按照产品计划往下走即可。

值得注意的是,如果资源充足,在原型设计评审期间,还可开展一些可用性测试,相信在可用性测试期间,还会发现不少可用性问题。至于如何进行可用性测试,此处不再详述,留在以后的篇幅中吧。

用户需求,我们应该忽视还是接受

2010年05月01日 Ben 0 条评论

昨天下班后,同事请客吃饭,我也不客气,决定一起去。加上我老婆,一共5个人一起等另一位同事,他工作上还有一些事情没处理完。闲来无聊,翻开google reader,老婆发现一篇关于用户的文章,说写的挺好的,里面有一段大致是这样的

中国的互联网,基本上是给30岁以下的年轻人设计的,这跟中国互联网的用户构成有关。在这样的环境中做产 品,其实是一件很幸福的事,因为你的用户都是最具好奇心,最好学,最喜欢尝试,最没成见,最有冒险精神的一群人。困难的不是让他们弄明白,而是让他们产生 兴趣,或者感到需要。他们不笨。
 
确实有笨用户,就是那些意识中根本没有技术,精力、记忆力和学习能力都已经变差,戴上老花镜仍然看不清屏幕 上的文字的老年人。他们确实是笨用户,因为这些光怪陆离的IT玩意儿从一开始就不是为他们设计的。

老婆平时工作与用户接触最多,所有用户的需求都从她这里获取,对于我们的用户,没人比她更了解。看完这篇文章后,向我抱怨道:“有时候我们用户的需求,根本不要去理会他,甚至是不合理的”。

这句话很有道理,听到的另一位同事也在对此进行评论:“如果你去跟google提需求,他们理都不理你”。我似乎还听到过另外一种声音,就是我们产品升级换代的理由之一就是根据用户的需求,我们只做用户需要的东西,尽量去满足大多数用户的需求

如果我们尽力去满足用户的需求,那么我们的产品最终可能会成为一个超级大杂烩,但这不一定是坏事;反过来如果我们把用户的需求直接忽视掉,不免会有些闭门造车的感觉,除非你是google,有庞大的产品创意、设计团队支撑。

的确很难界定我们到底是应该忽视还是接受用户的需求,没有绝对答案。遇到这种问题时,可能需要进一步去琢磨用户的心里。实际上有些用户提出的需求根本就不是需求,而是一种需要、愿望。

而我们要做的就是把值得分析的需要、愿望进一步分析转化为实际需求,再对需求进行评估后进而提升为产品改进。嗯,这样做似乎还是比较靠谱。

文章写到这里,我突然想到一个问题,若是你的大老板给你的产品提出一个建议,或者公司内部以“用户”自居领导们给产品提出意见,你到底是应该忽视,还是接受呢?