iamsujie的产品设计：人人都是产品经理

2009年夏天，“e网打进”的产品portal做了一个改版项目，叫“变脸”，回想一下，我们正是按照：“战略、范围、结构、框架、表现”的顺序做的，设计师也从头到尾很充分的参与其中。很快半年过去了，产品、公司、团队里很多事情都发生了变化，不过对于这个项目来说，还是有些可以分享一下的东西……

这个项目的缘起是为了统一公司几个产品的portal风格，但我们希望能在老板给出的这个目标下找到“变脸”的更多价值。于是项目开始后我查看了portal页面的访问情况，分析了用户场景，画了下图。

产品portal的用户场景

在“e网打进”刚上市之时，portal页面只是付费用户的登录入口，有一个简单的填写账号密码的输入框，并没有额外的商业价值，但随着产品的成长，渐渐有了点名气，当时每个月有几万UV（Unique Visitor，独立访客），其中：

非付费用户的访客占大多数，超过80%，短期内相当稳定；付费用户约20%弱，目的其实很明确——登录，很少会东张西望看其他内容；极少数的经销商，有个入口登录后台也就行了。

非付费用户的访客访问portal的行为逐渐增多，他们通过各种途径知道了“e网打进”，可能是通过搜索引擎，可能是听到朋友说起，有了点兴趣，但是到了这个页面以后，看不到产品介绍、不知道如何购买，虽然portal本身使用了“e网打进”，服务部门的同学可以及时与访客交流，但页面内容的缺失导致流失率依然很高。

有了上述分析，很直接的想法就是portal要转型，重点满足普通访客，促进他们转化为e的付费用户，所以我们加重了营销相关内容，力求创造更多的销售机会，也就是所谓的“潜在用户”。进一步思考：

潜在用户 = 访客数 × 转化率

我们可以一方面通过增加页面的营销内容提高转化率，另一方面也可以通过SEO、公关、推广等方式增加访客数，下面只说前者，但两者的目的都是希望能加粗上图中访客到“潜在用户”的线。

之后，我们和销售、服务一起讨论，确认了目的，总结出portal需要哪些页面，以及导航菜单的结构，因为整个站点的复杂度相对较低，所以我们压缩在一级菜单里解决了，如下表。

产品portal菜单结构示意

接着是确定每个页面上都需要哪些元素，以首页为例，我们列出了下表。

首页的元素

上面的工作可以看作“结构化思维”，“战略、范围”的设计基本完成，接下来就是“形象化表达”了，“结构、框架、表现”，UE的同学就成了主角。下面几张图是用哪些工具做的就不说了，这里聊一下PD和UE谁做什么事情，怎么配合。

一开始，PD和UE一起讨论，手绘出首页的大概样子。PD要表达清楚每一个模块的商业目标，可以给出自己对页面的布局建议，但最终的页面结构，UE可以主导确定。

纸面Demo

然后是线框图，PD有时候也会直接给出这个，“变脸”项目中，是UE的同学做的。大家仍然是讨论确定，UE这时候会在设计的过程中融入很多自己的想法，PD要做到的就是防止走偏，保证大家对商业目标理解的一致。

比如在下图中，大家讨论后确定页面为“左侧大右侧小”的双列结构，并且左侧的内容主攻访客，右侧的内容主攻付费用户。

线框图Demo

接着，UE出页面效果图，会安排销售、服务等相关方来做一次评审，告诉他们这就是将来看到的页面，征求意见，他们一定会有各种疑问，这时候PD和UE需要确保每一个细节设计都是有理有据，包括每块区域的位置、长宽；每行文字的字体、字号；每个小图的颜色等等，都不只是为了好看，而一定是与商业目标符合的。

比如下图中，“立即购买”的区域用了页面上最跳的橙色，在充满商业气息的蓝色氛围下很醒目；且位置在“e网打进”访客的电脑最常见的分辨率，即1024×768的首屏右下角，这归功于数据分析；又有个亲切的美女在向你招手，进一步吸引眼球。以上三点设计非常强势的突出了目的，至于是否太过，需要后续的效果分析来验证。

视觉效果图

2009年12月在线上的这个页面，整体和上图看起来还是很像的。今后一定会有变化，不知道你在看的时候是什么样子。

新首页上线以后，事情还没有完，持续的监控和改进是必须的，所以在上线后的半个月、一个月、三个月这几个时间点，我们都做了一些数据分析，从结果看，有一定的效果，比如访客粘度、网站停留时间均有提升，填写表单留下联系方式的潜在用户明显增多，具体就不仔细讲述了。

翻出来一份同事写的培训记录，应该是去年的需求管理方面的课程，该人长相彪悍，被大家一致认为家里是开夜总会的，他倒也欣然接受，于是有了同样文风彪悍的短文一篇，当作介绍产品经理（PD）日常工作的文章看吧，正式开始：

• HI ALL：听了董老师的课，看了苏老师的笔记，收获良多，收益非浅，对自己的工作有极大的指导意义。

• 鄙人一直以来都认为PD的工作就是和找小姐的过程一样，都是要解决两个问题：一个是X谁的问题，另一个怎么X的问题；

• X谁的问题，在公司一般不由PD费心选择，上面的老板自然早就运筹帷幄且成竹在胸，就象是老板把哥几个带到了一个夜总会说到：“哥几个今天晚上就在这里消费，大家好好干，整高兴！”那我们也绝对不会跑出去换个其他的夜总会玩，你说是不是？这个步骤我们的专业术语叫做“立项”；

• 接下来，我们会叫来几十个MM 来看看，看看哪些个MM长得好看，笑得甜美，声音好听，性格温柔，再叫她们做几个仰卧起坐给哥几个看看，这个步骤我们的专业术语叫做“调研”；

• 调研的结果是，我们把符合我们标准的MM留下来了，赶走了那些长得不好看的MM，叫她们回去反省、学习、进步，等进步好了再出来接客。我们要‘有所为，有所不为’，自己的体力有限，也不能全部都留下来，这个过程，我们就叫做“规划”；

• 规划结束，老板给每个兄弟都分一个MM，让哥几个练习演讲口才和忽悠技术，分配的原则就要看各位擅长应付哪种类型的MM了，这个过程我们的专业术语叫做“模块划分”；这个过程结束，好戏就要开场了；

• 好戏开场，哥几个一人抱一个MM，海阔天空，天马行空，前世今生。。。一边胡吹乱砍，一边拉MM的手，一边还碰MM的长发，各人心怀鬼胎，想着后面的好事，这个过程，我们的专业叫做“设计”；海阔天空，胡吹乱砍，我们叫“头脑风暴”，为在MM面前博得好感，哥几个相互吹捧，我们叫做“团队协作”；

• 要想换地方娱乐的，需要和MM达成一致，在离开大厅跳双人舞之前，出于礼貌和安全，哥们还是应该给我们大家打个招呼是不是？这个过程我们就叫做“评审”；如果其中有个兄弟说：“小心点哦！最近扫黄，风声紧。。。 ，”那明显就是“评审”没通过哈；

• 如果评审通过，当然就是该干什么干什么了，XXXXXXXXX.（此处省去108字），这个过程我们叫“开发”；

• 有鉴于哥们的体力有限，这次开发，你一般不太可能展现完72招108势，您的大部分技术还没展示出来，不过你不要着急，也不用感觉委屈，你有本事就有的是机会给你，对于本次展示剩下的部分，我们会安排您过一段时间再进行展示，这个过程我们就叫做“迭代”；

• 开发结束出来，老板问大家：“哥几个今天玩得HAPPY不？”你肯定要说“HAPPY！HAPPY！”但是如果有MM说：“XXX那个家伙让我感觉不爽！有X、Y、Z这个几个地方不到位”那你就惨了，测试给你报了BUG。再如果老板对你说：“你娃不适合玩这个”你就更惨了，这个我们就叫“考核”；

• 本次培训，老师对以上整个过程的实际操作方法给我们做了理论性指导，我们的苏老师也做了总结和归纳，结合自己平时工作中的实际操作，感觉很好，很 HAPPY！以后工作也好，泡MM也好，大家有了理论知识做基础，完全有理由相信自己可以做到游刃有余，百发百中。

最后，我们再对比着看一篇比较悲观的文章——《PD就是出来卖的》，希望同学们能对PD的工作有更深刻的认识……

今年在参与阿里软件的内训师计划，负责PD（Product Designer，也可算是产品经理的半成品吧）入门培训课程的开发，所以一直在找各种机会和同行聊相关的话题，这也是作为课程需求采集工作的一部分，这块我自己分了4期：

 1.  阿里软件，管理软件事业部各产品PD代表（做完后，开始整理课程大纲）；

 2.  阿里软件各产品PD代表（做完后，尽快发布课程的beta版，可用于阿里软件内训）；

 3.  阿里集团各子公司PD代表（完善，仍然用于内训）；

 4.  业界产品经理代表（这部分，聊天对象还在积累中）；

采用深度访谈的原因很简单：无明确问题，先开放式聊天，每个人1到2小时，围绕几条线索“一个需求从采集到实现；一个项目从立项到结束；以PD为中心的组织与流程；零散话题”，大家来谈各自的产品是怎么做的。

相对而言，等到有明确的事情需要验证的时候，问卷就比较合适了，到时候可能会利用自己的网站做数据的收集，提前和同学们说一声也希望大家能帮帮我，：）

4月底，开始了第一期的访谈，参与者是管理软件事业部3大产品“钱掌柜、外贸版、e网打进”的PD代表；5月上旬，进行了第二期访谈，参与者是“阿里旺旺、alisoft.com”的两位PD代表，根据聊天的内容，上个图，是我根据PD @ alisoft做什么、怎么做整理出的，这只是最高层的一张图（点击看大图），也是内训主干的框架，里面的各个部分还有细化的图，后续准备仔细写出来。

最后放出一些可以公开的聊天内容：

需求相关

 Ø  产品早期多为老板驱动，PD驱动，特别是市场不成熟的时候，我将之不成熟的比作“主动进攻”；后期会逐步转变为用户驱动、销售驱动、服务驱动，更像“被动防守”。

 Ø  管理需求，特别是日常的小需求，包括收集、状态跟踪，两个团队用excel，两个团队用mantis+excel，一个团队用QC，都ok。用mantis的团队说，mantis适合收集，跟踪，方便记录存档与反馈，但管理还是由各个产品的PD自己做，多用excel。大家都会按需要开产品会，召集产品相关方共同确定接下来一段时间做哪些需求。

 Ø  需求的优先级谁定，安全的做法是谁获益谁负责（俗称老板拍脑袋），但PD是专家，应提供专家意见给老板，当然高层授权的专家负责制也许更好。

 Ø  部分团队的需求文档直接在wiki上写作，管理。

 Ø  部分团队需求评审与UC评审分开，需求评审偏商业，UC评审偏技术。

项目相关

 Ø  典型项目周期：web based，2周到1个月（不算产品1.0这种大项目）；旺旺，3、4个月。

 Ø  项目沟通方式各有不同，主要是4个方面：周期分“日”、“周”为单位；形式可以是会议、邮件；发起者不同；参与者不同。但目的相同，都是为了项目成功，所以可以按需选用最合适的方法。

 Ø  一般5开发工作日以下的小需求不参加产品会争夺资源，采用搭车的方式做。

 Ø  一个团队的产品文档实践很高级，拥有整个产品的UC，直接在网页上编写，采用SVN做版本管理，和代码类似，项目启动开UC分支，完成后要合并UC。另4个团队仍然是项目文档的模式，产品文档只在产品1.0的时候出现一次。

 Ø  一个团队的敏捷实践很值得推广，用白板做看板，把晨会、日报整合，已经写了一篇相关分析。

团队相关

 Ø  PD团队人员构成，偏商业+偏技术背景各半比较合理，有团队大部分技术出身，深感对偏互联网的产品“感觉”上不到位，比如对用户体验有心无力。新人过多也是大问题，这也是高速成长团队必然存在的问题，老中青的结构还是必要的，个人感觉1年内的同学不要超过一半，且需要有3年以上的同学，这样才稳定。

 Ø  PD不要侵占交互设计师的工作，不要侵占系统分析师的工作，现状是存在很多侵占现象的，这也许和很多历史原因有关，有同学感到不停的在被迫做不专业的事情，犯各种错误……

 Ø  讨论了阿里巴巴B2B区分PD和RA（Requirement Analyzer，需求分析师）的做法，PD尽量往前走，偏市场/用户，产品规划；RA往后走，偏实现，写UC，做系统设计。

 Ø  开始出现专职DM（开发经理）的角色，配合项目经理管理开发过程，比如协调人员、制定开发计划，自己并不是项目的开发人员，而且可以同时担任多个项目的TM。

最后提一下这门内训课程，已经开发出5、6个小时的版本，希望以后有机会与同学们分享。

产品设计师能力不足的时候，不妨先做用户想要的，而不要自己去胡乱分析用户需要的，因为……这样做错了就没法把责任推到“用户”身上了……

很坏吧，当然对一个团队来说，要尽量避免“只有能力不足的设计师” 的情况出现。

豆瓣认领用的 doubanclaim5160c54702b3c65f

2008年春，接受了CSDN的专访plus博文视点的闲聊，发现说的东西都差不多，自己整个精编版如下，完整版猛击此处。

记者：2007年7月，您开始在自己的 MSNSpace 上面写“产品设计体会”这个系列文章的，最初您开始写这个系列目的是什么呢？在这之后，又是哪些原因一直让您保持住了持续更新的热情呢？

答：就像我在第一篇里提到的一样，一开始只是个很朴素的原因：那段时间老板要求我们产品设计师的周报要写作文，不少于500字。当然之前也确实在工作中有些零散的体会，但一直懒得整理，正好在老大们的“产品设计师要有想法”这个观点的指引下，就开始写了。

……我写得也不多，基本就是每周一篇。年初我给自己的08目标中有写满52篇，正好满一年，现在很有信心要写满99篇，相信到时候会有一些小小的奇迹出现。

记者：系列文章发表这么久以来，您最大的收获是什么？写这个系列文章得出的体会，对您的工作有怎样的提高？

答：写系列文章是一个不断思考、整理的过程，在写作过程中，我越来越感觉到需要学的东西很多，不管是工作中还是自学的时候都能得到新的知识，所以需要一个提炼、融入自己知识体系的过程。举个不合适的例子，就好像做产品一样，不断的加功能，加到太乱了就重构一次，再加功能，越来越强大。

写了这些文章后，确实感觉工作更有目的性了，经常一个礼拜是这样的过程：这几天要做什么工作，缺哪些知识，就去看点文章看些书；然后再到工作中实践；最后总结写成体会，就这样循环。

记者：对于自己的工作，您是抱着怎样的态度去关注的呢？

答：态度？能骗到自己把工作当爱好就OK了。我发现自己真是干一行爱一行，我研究生是学生物医学工程的，在医院实习过半年，穿着白大褂在检验科给人做检查。后来又用很多临床收集来的数据做分析，整天对着电脑研究数据挖掘和信号处理。之后找工作误打误撞进了阿里，做起产品设计，从开始什么都不懂，到现在越做越觉得这就是我想做的事情。阿里能提供的平台和自由度真的很好，三五年内我觉得完全可以继续边做边学到很多东西。

记者：做产品设计需求雄厚的技术功底吗？对于以后想走向产品设计的开发者，您有什么建议呢？

答：我本来不是技术出生，所以我回答：不是必要条件。团队里也有从开发转向产品设计师的，很有特点。背景这个概念绝对是有利有弊，看各人怎么用自己的“技术背景”了。用好了，可以在设计的时候思考全面，进入实施阶段与工程师更顺畅的沟通；用不好就会让技术压倒商业，在业务模型没定的时候就考虑过细的实现难度问题。团队中的产品设计师原来还有做运营的、做项目设计师的，所以说之前做什么不重要，产品设计师必须是一个通才而不是专才，另外加上不断的学习。对于要做产品设计师所需要的综合素质，各位可以看我的体会哈。

记者：最后，您希望您的读者在看了这个系列文章后有什么体会？

答：之前只是周报，然后贴出来的最初目的是找到同行，抛砖引玉，大家一起交流一起进步，因为自己是个新人加菜鸟，入行到现在也才两年不到，所以一直很希望得到大牛的指引。但是，我感觉写原创的产品设计师、产品设计师太少，可能大家都太忙了吧。这方面交互设计师、用户体验师做的就好很多。我去年开始就订阅了好几位牛人的blog来关注阅读，都很有意思而且收获也很大。在他们眼中经常感觉PM和UE是“对立”的，所以我要立志做一个“爱好用户体验的产品设计师”，：）