PM札记:产品设计这两年

标签: pm 产品设计 | 发表时间:2011-12-16 11:44 | 作者:鰱鱼儿
出处:http://ucdchina.com/rss/all

做产品差不多也两年左右了,基本上这条路是磕磕绊绊,迷迷糊糊,但好歹大方向是正确的,有空回想总结起来,唏嘘不已,看看以前对产品的看法,再看看今天对产品的认识,不仅感叹自己当初的幼稚,如今,更多的是了解了自己的无知与渺小,怀着一颗谦卑的心,继续学习,在产品这条路上寻找自己的价值。

产品职责包含很多东西,产品设计只是其中的一种职责,只是简单的描述一下我在产品设计上的弯路,回想起我的产品设计生涯,目前走过了三个阶段:

第一阶段:机械翻译

第一个阶段是我刚入行的阶段,当时的title是产品经理,但是现在看来,当时的职位细分下来,更多的是需求分析师的职位,当时的工作职责是收集业务部门的需求,然后设计相应的业务子系统,满足他们的这种需求,当时的工作流程如下:

收集需求–设计功能–项目管理–测试上线–收集反馈,二次改进

在这种工作流程下,几乎很少涉及到用户体验相关的问题,因为做的是后台系统,也就是公司的业务部门人员使用,强调的是功能完备,而非体验最佳,在这个职位开始的时候,我甚至都不太了解公司的业务,但是接到需求就只知道往业务系统上添加各种功能,这些项目上线以后,遭到业务部门的抱怨,做的项目越来越多,直到在这份岗位上的中后期,才悟出了解公司的整个业务系统对产品设计的重要性;

在此后的产品项目中,设计更多的是尽可能的贴近公司的业务流程,而不是过去的那种累加,这种方式,让业务人员的操作不会在业务流程中在不同的页面之间进行跳转,业务操作中不会产生中断,这种体验,现在看来是如此的简单,当时对于空谈用户体验而不会实际操作的我来说,无异于惊天棒喝,让我真正看到了用户体验的那道曙光。

在明白这些以后,我逐步的了解了用户体验的真正含义,当时也经常去参加一些业内的聚会,看众人写的博客,逐步的转入了互联网。

第二阶段:只见树木,不见森林

后来来到新浪,从事客户端的产品工作,算是正式踏入了互联网,与数以万计的用户打交道,在那个时候,我几乎是一头扎进了用户体验和产品设计的大海里,平时的产品设计,更多的是考虑用户体验,每个按钮的位置,每个链接的样式,都会详细的考虑用户体验,怎么样操作更为方便,更符合用户心智模式,那个时候,口头上重视用户访谈,重视用户反馈,但是实际上,更为看重的是产品设计,信奉的一条是出产品,让用户看到,然后再根据用户操作数据进行修正,在新浪的大半时间里,我几乎都是这样设计产品的。

这种在初期的时候,接收的是成熟的产品,因此在这个产品上进行了一些用户体验的改进,通过数据可以看到不错的效果,成就感很大,但是随着工作的深入后,开始接受一些新产品的研发设计,在这个时候,让我困惑的事情发生了:就是对于市场上的同类新产品,明明体验不好,但是在修正了这些体验推出我们自己的新产品时,用户反对的声音反而很大,这些似乎并不是先入的问题;一些新产品,在推出后,体验很好,但是却没人用;而且对于新产品,用户在乎的是功能,体验似乎是第二位的,在这种情况下,决定产品的功能优先级成了最难得事情,当时看到俞军的那句话:决定不做什么,往往比决定做什么更重要。直到那个时候,我才明白了这句话的含义。

在那个阶段,我重视了用户体验,但是对于市场,竞品,用户需求却进行了过度的忽略,产品设计只是在进行产品设计,关注按钮的摆放,链接的样式这些细节,却不能跳出来对看产品,那个时候,看到的是一个树木,却忽略了行业的这篇森林。

第三阶段:看山还是山,看水还是水

新浪的工作结束后,我感觉自己对产品有了更深的了解,产品的真正核心,是满足用户需求,让用户完成自己的目标任务,这才是核心,这对用户来说是雪中送炭,而用户体验,更多的是锦上添花。 
此后在做产品,问自己的第一个问题就是:用户的需求是什么,提供什么样的功能才能满足他们,让他们完成自己的目标,这个是第一位的,在次基础上,再去考虑具体的设计,在设计的时候,去考虑怎么样让用户获得更好的体验。

在这样的工作流程中,用户调研就是一个重中之重的问题,决定了产品的方向,搭起了产品的基础,从这样的角度来看产品,视野有了极大的开阔性,慢慢的理解了一些体验不好的产品为什么能成功,这些产品,满足了用户的核心需求,在此基础上,虽然牺牲了一些用户体验,但是在用户可以接受的范围内,就不会失去用户;并且产品先入的话,可以影响到用户的使用习惯。

在这个基础上,看到腾讯重视用户的调研和反馈,重视寻找用户的核心需求,用户的痛点;百度把产品叫做产品市场,产品文档叫做MRD,对产品事先调研的重视,逐渐理解并认同这样的规定,窃以为这样的安排才是正确的。

在这些弯路后,我回到了追求产品功能满足用户核心需求的阶段,但是已经不是那种总是纯属添加功能而不考虑其他情况的阶段,这点,算是回到看山还是山的阶段吧

以后的工作中,或许对产品设计会有更深层次的看法,期待那个时候的总结

源地址: http://www.wzxiuxian.com/?p=795

相关 [pm 产品设计] 推荐:

PM札记:产品设计这两年

- - 所有文章 - UCD大社区
做产品差不多也两年左右了,基本上这条路是磕磕绊绊,迷迷糊糊,但好歹大方向是正确的,有空回想总结起来,唏嘘不已,看看以前对产品的看法,再看看今天对产品的认识,不仅感叹自己当初的幼稚,如今,更多的是了解了自己的无知与渺小,怀着一颗谦卑的心,继续学习,在产品这条路上寻找自己的价值. 产品职责包含很多东西,产品设计只是其中的一种职责,只是简单的描述一下我在产品设计上的弯路,回想起我的产品设计生涯,目前走过了三个阶段:.

从编辑到PM

- 小鱼 - 所有文章 - UCD大社区
春节前收到一封陌生人的来信,一位网站频道编辑,向我咨询转型PM的可行性. 他问道:“你觉得做媒体和做产品,以前一样么. 话题很有趣,我也乐意就此写点什么. 遗憾的是,编辑转产品的成功概率却是不高的,就我的经验来看,存在四个障碍. 媒体工作需要捕捉阅读的共性,即“大家都爱看的内容”,相对来说比较忽视用户的个性化特征.

如何与PM沟通

- - 曉生
1.要学会听取别人意见,也许PM提出的问题你并没有考虑到,集思广益,可以得出有更好的方案. 值得肯定的是,你设计时已经能学会从产品角度考虑,引导用户操作,而不是单纯的好看. 只要不是单纯审美上的PK,都可以讨论,不是吗. 2.让产品阐述自己的需求点,明确重点. PM们七嘴八舌肯定不对的,要引导他们梳理出统一的意见.

PM培训的答疑课小结

- - 阿里巴巴(中国站)用户体验设计部博客
这期PM培训的最后一次课安排的是答疑,回答了一些同学们普遍关心的问题. 对学员们和讲师的讨论,我做了些小结如下:. 产生这种情况说明项目管理已经存在大的问题了. 要做到的是提前预知,避免这种情况的出现. 万一出现了,首先要深入了解原因. 两个方向,项目内搞定或者项目外搞定. 回答这个问题的关键是找关键路径.

浅析PM工作流引擎

- - CSDN博客推荐文章
1.      JBPM工作流引擎是用来做什么的. 首先要说明的一点是工作流引擎指的并不只是JBPM,JBPM只是工作流引擎的一种. JBPM利用JPDL流程定义语言将现实生活中处理事务的业务流程进行抽象,形成一套业务流程规则,只要处理该项业务就必须按照这个流程规则进行. 举一个很简单的例子,就拿看医生来讲,看医生的整个流程必须是先挂号,再看病,再抓药,只要你进行看医生这个业务就必须按照这套流程进行.

如何防止架构师PM化

- -
和一些做项目主架构或者一号位的同学聊天,经常会听到一种说法:项目主架构做着做着就会做成PM. 这背后什么含义呢,细品下来有几层意思:. 整个集团的架构非常复杂,涉及的域众多,做主架构或者一号位需要大量的协调投入;. 不同域之间的资源错配现象严重,需要投入大量精力在锁定资源和推进排期上;. 项目结构过于复杂,PM催主架构,主架构催域架构,域架构催开发,层层订,各种站会,代码没几行,会议一大堆;.

产品设计流程

- - 互联网分析
新的一年到了,分享个大的东西,这个是之前团队总结的一套「产品设计流程」,里面包含了3大模块,产品前期分析,设计环节,上线总结反馈,基本上涵盖了,从需求到上线的经过的流程,相较于大型UED团队会“轻”一些,适合中小型团队. 如果所在公司内部还未有设计流程,可以参考此流程,也可以拿去在这个基础上进行改进.

您的团队需要什么样的PM?

- - 所有文章 - UCD大社区
     在腾讯,多数部门的实际采用了职能化或弱矩阵的组织结构形式. 中心和小组等组织层级实质属于职能线条,产品、开发、测试、运营、运维等职能角色是产品运营的主要角色,而各部门都会或多或少有一些全职或兼职的PM组织管理着各类跨职能活动.       基于各自情况的不同和各自对PM职位理解的差异,对PM职位的定位也千姿百态.

PM成长日记:从需求到产品

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
   本文作者系大众点评产品经理@ 七手八脚裸奔地小石头.   本篇本来打算写如何跟技术进行沟通,其实跟技术的沟通,是贯穿于整个从需求文档到产品上线、产品跟踪、迭代的过程之中的. 本篇更多的是讲作者工作半年来,从需求文档到产品上线的过程,也希望与同行朋友多交流.   当你辛辛苦苦写出来一堆需求文档,跟UED的同学定好交互、视觉、重构;满以为技术会认真对待,但是你会发现,技术同学基本不会看你准备的一堆东西,基本是按照自己的理解来开发,当开发不下去,第一时间也不是看文档,而是看测试用例,或者直接跟产品沟通;基本文档只是QA同学对着写用例.