设计思想 - UCD大社区

设计师谈敏捷

fifisama — 2010-08-31 23:15:43

腾讯一直推广敏捷开发，也在强调敏捷开发，但你会发现，即便如此，还是会陷入以下情景

又臭又长的讨论会
好像人手永远不够
不切实际的想法
悬而不决的功能点
无穷尽的偏好设置
越来越多纠缠不清的细节
项目依然延期

我们如何构建一个更轻巧的开发流程，让我们更快更好的交付结果？作为一个设计师，如何成为敏捷的一分子？以下是一些心得方法，希望和大家分享

1 界面先行

作为设计师，最简单能让大家明白你的想法就是先把它画出来，不要用晦涩的语言和结构图，毕竟不是所有人都能把你的语言转化为图像。而且界面（视觉，交互）设计是相对轻量级的，修改起来也简单，成本也低。但修改程序就远不是那么回事了。保持界面先行可以让你非常灵活，至少在开始开发之前可以随意修改。

界面先行另一个最重要的原因就是，对于用户来讲，界面就是你的产品，界面可以帮助你从用户角度看待自己的产品，如何展现，如何操作，给人感觉怎么样，是不是易用。只有当你面对真正界面的时候才能回答这些问题，文档概要并不能帮你解决实际用户体验问题。

2 初期不需要太关注细节

虽然大家总说，成功来源于细节，当然，这非常对。但前期过分关注细节的同时也会令你止步不前。先把大框架确定下来，而不是一直纠结于

这条提示怎么写更合适？
文字字号用16还是14？
要不再往左挪1像素？
这里加个高光把
把2像素的描边变成1像素

你需要关注细节，但不是现在。所有事情都要从大到小的去做。先把他做出来，把该放的东西放上去，然后实际去用一下。

细节是你在使用的过程中才会慢慢显露出来，只有在使用中你才会发现哪些更值得关注。如果你有足够的时间，当然可以面面俱到，如果没有，请先把精力放在最重要的事情上。

3 不要纠结那些还没有成为问题的问题

“当我们的用户用了这个功能以后还想跟另一个功能配合使用怎么办？”

如果想快速推出版本，就先解决当下。不要花太多时间去考虑还没有成为麻烦的问题。别担心，你还有后续版本。

而且你就真那么确定用户想跟另一个功能配合使用么？如果不是，就先放一边，等问题真正浮出水面的时候再去快速解决。

4 帮助产品经理精简功能

好像大家都在弩着一股劲，比谁做的多。竞争对手的产品如果做了**，我们就要做***，他们有4个功能，我们就要做5个。如果不做，拿什么跟他们竞争？

这种方式是行不通的，因为你会发现，永远是赶超，永远没有自己领跑的那一天。怎么办？

做少

通过做少来打败他们

做的功能越多，功能间的交互就会越复杂，用户的学习成本就会越高。而我们的用户真的用的上那些高深的功能么？他们会不会已经被那些多如牛毛，但我们自以为高明的设置搞得疲惫不堪？试着少做一点，让自己的产品更加轻巧而更具备亲和力——没有人会喜欢使用显得自己很笨的软件。

5 功能间更少的牵扯

把一个功能点做的尽量独立，能保证需求改变时更为快速，更为灵活。

如果功能间的牵扯太多，就如同你身上沾满了蜘蛛丝，每做一点改变，其他的都要进行改变，从设计，到开发，到测试。当你发现改变的代价太大时，你就会放弃，然后依旧背负着带有缺陷的功能一路走下去。

为什么不开始就尽量少牵扯呢，这样更加来去自如

6 要有自己的主张

虽然交互设计通常都会处在不黑不白的阶段，因为没有绝对的对与错。但我们还是需要坚定自己的主张。也许果断的观点看起来目中无人，但总比那些“嗯……其实这样也成……”模棱两可要好的多。敏捷开发中需要的就是快速做决定，而不是唯唯诺诺和稀泥。

————————————————————————————————

也许并不是所有的项目都适合，毕竟初期不考虑细节必然要考虑后期更改的成本。但对于一个新产品，快速触达用户，让用户来使用，验证，反馈，得到的数据更加真实有效。根据这些反馈作出的调整总是比自己拍脑袋来的简单，更加符合用户需求。

敏捷，并不只是站立晨会，迭代总结，理论，文档，更需要的做的是，把它做出来。

产品人员怎么向技术人员描述需求

312950@qq.com(seraph) — 2010-08-27 09:12:11

近日参加一个子产品的新版本需求讨论，过程中负责该子产品的产品人员（某聪明帅小伙，哈哈）在前期需求讨论时不管是综合听取他人意见还是表达自已观点时，都很顺利，但总是在最后进行需求要点的总结陈词时犯卡壳，抓不着重点，说不清楚，思路打结，自已说到一到都挠头，更不要说听者犯晕了。

数次下来不得法，之后我自已总结了下，如何才能做好向技术人员简洁准确的描述需求：
在这儿（in Here）
做了事（Do something）
发生了什么，得到了什么（Happen something, get something）
HDH描述法能够让技术人员更精准无偏差的明白：要做什么。

举个简例：
文档名称：某管理模块V4需求详述.xlsx
需求分类：列表页面增补需求
需求详述：
1、信息列表页面--在这儿（in Here），初始显示状态--做了事（Do something），每行的信息标题后增加显示四种状态图标，每种图标显示与否规则是。。。--发生了什么，得到了什么（Happen something, get something）；
2、（当前页面）每行的新留言状态图标（小页面状）上--在这儿（in Here）点击--做了事（Do something），浮出留言显示层并显示内容（最大显示字数50，超过切字并补...）、时间信息--发生了什么，得到了什么（Happen something, get something）

另外，如果某种功能流程的复杂性较强分支较多--例如工作流引擎的实际应用，可以考虑用mind类思维脑图工具来快速画出树图，用更直观的视觉效果来帮助整理和说明各种情况的分支流程处理及相互关系，今天时间不多就不专门再实例说明了。相信各位在日常工作一定会碰到，不妨一试。

源地址：http://312950.qzone.qq.com/blog/1282808174

姐姐，Google Wave，乐风和Bambook

碗曰 — 2010-08-25 16:21:49

Google Wave自称要关闭了，于是，就有分析师、高级分析师、资深分析师、媒体人、资深媒体人、资深投资人、董事投资人等跳出来，恨其不幸，怒其不争的说，我其实早就知道....，Waver（儿化以示亲昵和关切）有七个缺点，八种错误

问题是iPhoner也有七个缺点、八种错误，你老人家怎么没早早预言它完蛋呢？

上大学的时候，有个姐姐，每次跟大家聊天的时候，谈到感情，总是毫不疲倦的重复说，我理想中的男人，有内涵、上进、宅心仁厚、乐观幽默，别的都不重要。3个月以后，这个姐姐就拜倒在一个很英俊很英俊的没内涵不上进气量狭小苦闷忧郁排球运动员之大裤衩下。

我的结论是，产品设计的关键，是你的长处有多长，能不能碰触到G点；而不是你的短板有多短。举个小小极端的例子，一个没有摄影功能的单反照相机，要比有摄影、有拍照、有WIFI摄像头功能还能当桌面电子相框的相机要好的多。

这个G点，就是需求，当下用户迫切的1、2个需求。反观那些成功的产品，Gmail就是一个超大，Skype就是语音清晰、WinRAR就是高压缩比、360就是免费。在你接触到需求点的时候，什么gmail界面不中国啊、Skype不如MSN有用户基础啊、WinZip垄断市场啊、360不专业啊都不再是问题了。我有时候经常还会感慨，在Winzip一统天下的垄断局面下，WinRAR居然能破土而出，真是奇迹，也佐证了自然垄断不可怕的观点。

那么，Google wave的关闭，不是因为它的慢、不是因为它的复杂，而是因为它没有找准需求的锚点，要满足的需求太泛。

按照这个逻辑，乐风恐怕不成，Bambook希望大大地。

注：从产品设计的角度考虑的这个问题，不讨论质量原因造成的问题。

源地址：http://yuancd.blogspot.com/2010/08/google-wavebambook.html

浅谈UGC的信息组织方式

纯银 — 2010-08-25 09:20:23

醒目！本文颇枯燥，很难耐心看完，提前预警一下。

1、
关于信息的组织方式，在1.0时代无非是人工分类，网站下面设频道，频道下面设栏目，栏目下面再设内容列表页。到了2.0时代，信息爆炸，很显然没法全部进行人工整理。通常所见，主要有八种组织方式在起作用。

第一种还是人工整理，由人工编辑出1.0风格的内容首页。哪怕2.0的口号已经响彻了五年，普通用户最适应的还是传统布局的内容首页，看上去整洁丰富，分类清晰，有良好的品质保障。如果一定要靠算法来生成首页，也不是不可以，但摸索尝试与配套建设的成本太高。不如安排一两个运营人员每天更新，还能实现更多的运营意图。

第二种是按时间维度排序，常见于海量信息的列表页，分作纯粹的Timeline（比如Twitter与feed流），或回复置顶的排序方式（比如论坛与Google Buzz）。前者能保证公正的曝光机会，后者适用于回复价值较高的场所——回复本身变成了内容阅读的一部分，并且有效地证明了内容的品质与热度。

第三种是时间维度的变种，在时间坐标之外加入了新的过滤项，如点击数高于xxx次的最新发布内容，以维持其品质；或是用回复之外的互动方式来干涉时间轴，如最新被推荐过的内容（虾米音乐频道）。

第四种是互动排行，包括浏览数/评论数/推荐数/收藏数排行等等。不仅细分出各种时间单位的排行榜（今日/本周/本月/历史排行），也分作总量排行与增量排行两类。其中增量排行的可靠性较佳，加入时间衰竭机制后，更能避免大者恒大的不合理现象。

第五种是用户自定义分类，分作在国内水土不服的tag，或是高端用户喜闻乐见的自定义文件夹（比如豆瓣豆列与Flickr博览馆）。

第六种是相关推荐，可能根据用户行为或关键字匹配，由系统推荐相关内容，也可能是用户自己的分类推荐（比如Flickr的相片集与群组）。

第七种是关键字搜索。

第八种情况就洒脱了，压根不组织信息，主要靠follow进行人与人之间的订阅。

2、
这篇日志写了很长的时间，可能拖了一个多月吧，大改两次，写废了起码2000字，总是不满意。最终决定不再绕来绕去卖弄文笔，而是简单明了地阐明看法：怎样处理UGC信息列表。

这可是个大麻烦，因为成功的信息列表总是伴随着两个要素：类别筛选与品质控制。

论坛采用了最简单，最低效的产品设计方式来搞定难题。首先由高级管理员进行版面分类，指引用户去不同版面发表不同类型的帖子；随后再依靠普通管理员（版主）删除不合规范的帖子，奖励（置顶或加精）优秀的帖子。于是内容管理压力完全下放到了运营端，产品设计者不伤一文脑筋。

这么搞当然也是有背景的。密密麻麻的文字标题列表，使少数劣质主贴对整个版面的冲击不大；而用户习惯于快速拖动浏览回帖，也降低了劣质回帖对浏览的干扰。只要勤于管理，当类别与品质不合要求的内容在一定比例以下时，完全不影响整个论坛的正常运行。换成图片和视频产品，一屏掺进去一两张劣质图片就觉得惨不忍睹……

比视觉污染更重要得多的优势，则是论坛容易激发平等、积极的讨论。由于互动活跃，话题性强，论坛可能是天底下最容易形成公共社区的产品，从而保障义务管理员的成就感与投入度，把高端用户驱动起来，靠他们消化掉巨大的运营管理成本。

换成其他类型产品，由于在公共社区的构建上先天不足，找不到肯卖力的好义工，在信息组织上只得寄希望于标签的使用，并依靠各种社会化推荐数据来鉴别品质。但除了tag在国内的不流行之外，这里还有个要命的悖论。当浏览者进入最新信息页，很容易被未经过滤的劣质内容气跑——真是个垃圾堆。既然没人愿意浏览最新信息页，谁又来帮你过滤和筛选最新内容呢？

他妈的，看上去进入了一个死循环。

解决思路之一，先对用户进行甄别，将靠谱的用户加入白名单，有免审特权。其他用户的内容先审再发，审核前仅在最新信息页显示，不进入精选信息页。
效果：不佳。在我这边，昆虫拍得好的用户，未必人像拍得好；风景拍得好的用户，未必lomo也拍得好。虽然采用了复杂的主题聚类白名单算法，还是没解决问题。关于用户的不确定因素太多，白名单内的用户未必放心，白名单外的用户又带来很大的审核压力。

解决思路之二，采用一些运营和算法手段提高最新信息页的品质，吸引用户浏览。
效果：不佳。虽然品质确有提高，但仍不足以作为用户进入的默认页，若不是默认页，新内容吸引到的用户只有10%左右，达不到社会化推荐有效的流量要求。

解决思路之三，学习Digg的内容推荐功能。
效果：极烂。脱离了Digg起家时极客社区的文化氛围，只有最无聊和最臭美的用户才乐意干这事儿。问问各大博客运营团队便知。

解决思路之四，让热心用户代替管理员来审核内容，多人投票决定结果。
效果：仅在糗事类网站有过成功应用，背景特殊，很难复制。

解决思路之五，通过站内动态与站外传播，实现一定的浏览量，在此基础上再通过社会化推荐行为来鉴别较好的内容，形成自己的精选信息页。
效果：几乎是目前唯一有效的UGC信息组织方式。当产品有比较强的个人中心，你的用户愿意通过个人动态（或其他订阅方式）获取信息；或者像优酷土豆那样，容易通过站外方式传播信息；就能收获足够的评价、推荐、浏览数，帮助你下定判断。但这里有个前提：通常用户重视其个人空间时才会频繁访问个人中心。换句话说，个人中心首先是个人空间的附属，其次是好友关系的沉淀，非得先做强空间，做强关系不可。脱离了这二者，动态如无根之花。两年前我曾经在这里吃过大亏。

那么，当你从空间到关系，建立起来一整套产品生态系统后，是否就可以通过信息的自然流通，进一步激活社会化推荐，生成有价值的精选信息列表页呢？没这么快，还取决于社会化推荐的形式与算法。简单的做法是浏览数筛选，为了更客观一点，也可能是推荐、分享数筛选，或者评分、评价数筛选。无论怎么设计，当你的筛选算法不公开，用户（尤其中低端用户）会骂你玩黑箱，规则不透明。但只要一公开算法，或是被人猜到算法，作弊立刻疯狂地流行起来。

我曾经遇到这么一批用户，他们每发一组摄影作品，不管多平庸，都把链接甩到几百人的QQ群里说，“兄弟们，帮个忙”，然后几十上百人跑去猛顶一把，哪怕是高级用户也席卷其中。这些QQ群几乎变成了公开的作弊群，互捧臭脚，当运营人员进行质疑时，对方理直气壮地回答：“这么多人投我票，你凭什么说我拍得不好？”毫无惭愧之意。同类用户在摄影爱好者中数量不少，很难彻底封杀，只能采用Digg的算法之一，降低Followers的投票权重（Digg还有更多巧妙的算法可借鉴）——但这样规则又变得不透明了，你又要挨骂了……

挨骂倒不算什么大的问题。虽然规则公开确实是社区用户的需求，不睬他们也罢。反复尝试，总能找到合适的筛选算法。真正的麻烦是，当一个新用户初来乍到时，即便是个优质用户，这时他没有任何好友关系，无法得到足够数量的社会化推荐，作品自然进不了精选信息页，孤零零一个好不可怜。怎样将新用户纳入信息流通网络？有以下几种对策。

方法一，在公共页设置新人推广位，简单介绍新加入的用户。
效果：烂。谁他妈的没事干去点新人头像，又不是大波美少女。

方法二，将新人作品聚合在一起，引导新人互相交流，抱团取暖。
效果：较差。谁这么肯定新人就喜欢和新人交流？恰恰相反，大部分新人更乐意于与资深用户建立关系，更快融入社区。此外这个新人作品区必定良莠不齐，浏览价值很小，停留时间很短，不值得重视。

方法三，通过一些信息匹配手段，既向新人推荐他可能感兴趣的老用户，也向老用户推荐可能感兴趣的新人（二者的形式不同）。帮助他们快速建立关系。
效果：较好。前提是这款产品有足够多“用户在意”的信息坐标（城市/性别/兴趣/主题偏好/用户等级/相似背景/相邻IP等），实现有效的用户匹配与推荐。

方法四，在产品内部开放群组服务，相当于建立无数个性化的小论坛。新人可以加入自己感兴趣的群组，在微型公共社区展示自己，结交朋友。
效果：较差。在国内，大量中低端用户毫无节制的卖弄、耍宝和自我推销，强悍地击溃了群组管理员的耐心。和成功论坛相比，群组在推广手段上极为匮乏，很难精准地导入目标用户，大部分又缺乏高明的运营管理手段。要不寂寞无趣至死，要不就是低端用户赶跑中高端用户，导致整个群组的衰亡。低端用户本身无法产出优质内容，很难形成内容社群，如非洲军蚁般过境而去。只有用户群整体素质较高，话题性强的产品才能建立有效的群组，比如豆瓣和时光，终究是少数个案。

方法五，对新用户发表的内容进行运营审核，一方面过滤垃圾，另一方面也可以将其中的优质作品直接加入精选信息页，帮助优质的新用户更快得到认同。
效果：较好。前提是支付得起这份运营成本，通常适用于发表成本比较高，品质判断比较容易的产品。我就这么干，当然会有一些算法在起作用，对“新用户”与“垃圾用户”作一个定义。

对UGC信息列表页的介绍到这里为止。

3、
信息列表页并不是UGC的唯一信息组织方式。到目前为止，列表、动态、推荐，这三者在不同性质的2.0产品内各有其地位。比如论坛以列表为主，社交网站以动态为主，我特别想讲一下Flickr——“推荐”是它主要的信息组织方式。从一张好图通向一个摄影世界！

故事从每一张好图开始。好图在哪里？你点开“发掘”这个页面，通过算法（浏览数/最爱数/作者等级/发表时间混合）提取了一系列优质相片，无序地摆放着，漂亮得惊心动魄。点击进去，由于页面上只有一张640px的大图，你很容易注意到它右侧的推荐位，包括：
-作者的所有相片
-作者存放在同一专辑内的其他相片
-这张相片加入的群组列表

在这里出现了三个关键设计。首先是页面主要内容与推荐内容处于左右水平排列的位置，而主要内容只有一屏高度，左右栏宽度比大约为2比1，导致推荐内容很容易出现在视野范围内。为达到这个效果，Flickr甚至愿意牺牲大图体验，主打640px的浏览尺寸，以保证右栏的视觉权重。虽有所失，获益良多。

其次是推荐内容的数量众多，因为它可能属于不止一个专辑，不止一个群组。在相片右侧常出现十多个推荐列表，每个列表都可以快速展开，左右滚动，用75px缩略图的形式直接查看作者、专辑、群组的全部内容。推荐效果极其强大。

最后，右侧推荐内容和左侧主要内容存在密切的关联。我有这么一个观点，当用户的主观控制力越强，他的行为就越流畅，越容易持续下去。因此，我们应尽可能进行关联性的内容推荐，并且让用户理解其间的关联所在，而不是放置无关联的“精华推荐”。后者可能会增加第一次点击的概率，但很难形成对推广位的连续点击。作为优秀案例，Flickr的作者、专辑、群组三个维度构成了可靠的关联，并提供最爱、博览馆两种次要关联形式。

在无休无止延伸开来的关联链条中，始终遵循着两个逻辑：A、能拍出一张顶呱呱好图的作者必定能拍出更多好图。B、愿意收录一张顶呱呱好图的群组也会收录更多的好图。因此，右侧的内容推广必定是有效的，同时它的位置是醒目的，交互是友好的（快速预览+本页刷新），内容是多变的（通过关联群组不断切换用户，通过不同用户不断切换群组）。只要你找到第一张顶呱呱的好图，就能沿着它，通过右栏推荐位一路狂点，轻而易举找到无数张好图，无数个好摄影师，一整个摄影世界的大门敞开。

这是多么简洁优美，多么令人赞叹的产品设计。写到这里，只有“给力”两个字才能恰如其分地形容我的心情。而疲惫的作者则打算停笔睡觉去了。张无双同学催我写这篇文章，催了三次，跨度一个月。如果没他催我，多半又要刨个坑可耻地溜了，好歹迟迟成文。

源地址：http://firecacada.blog.163.com/blog/static/7074376201072411591622

理想结构与无奈结局

纯银 — 2010-08-23 13:14:00

若干年前，曾见《霸王别姬》的一名主创人员接受采访说，这片子的编剧、美术、造型、化妆、摄影、剪接、音乐、演员、导演等等，整个主创班底都是当时业内最牛逼的人物，又能全情投入，不成功没有天理。即便换一个导演，电影也能同样放在殿堂里受后世供奉。

作为这句话的注脚，陈凯歌后来拍了《无极》。

在互联网上最重要的资源是什么呢？当然是人才。什么资源背景，市场先机，都扯鸡巴蛋。最重要的资源只有一项：人才。在项目需要的每个位置上，都有足够数量的，合适的，甚至是优秀的成员去履行好自己的职责。

拿产品项目举例，在中型以上的公司，中型以上的项目，通常需要哪些岗位配置呢？

首先是产品经理，或产品总监，他的主要工作有四项：
1、目标规划（研究市场，保证项目向着正确的方向前进，并有着合理的阶段性目标）
2、搞定资源（从人员到推广，向公司争取合理的资源供给）
3、协调配合（促使同部门、跨部门之间不同的职能单位紧密配合起来）
4、抓住重点（确定每个阶段每个模块的重点所在，调动力量，亲自督促集中突破）

其次是策划经理、运营经理、技术经理，他们的主要工作也是四项：
1、团队组织（进行合理的人员分工与任务分派）
2、需求管理（从多方面收集并整理需求，划分优先级）
3、计划进度（根据需求制定详细的分解计划，时间节点，监督进度完成情况）
4、品质保障（控制好每一项计划任务的完成质量）

在经理之下是执行层，执行层分为两级：高级与普通。高级策划/高级运营/高级程序员完成最重要的模块任务，经验不足的普通执行人员完成相对次要的部分。

按照以上的人员梯队配置，毫无疑问能保证良好的战斗力，但现实多半不这么完美。由于人才缺口，产品经理常常要兼任策划经理的工作，哪怕过多投入琐碎事务会挡住视野，降低市场嗅觉，干扰他对方向与重点的判断。在理想结构下，产品经理更应该多做全局性的观察和思考，而不是沉溺于每一个细节——当然，前提是有合适的人来管理好每一个细节。

与此同时，策划经理可能也有苦衷。由于属下缺乏高级策划，自己常常要兼任高级策划的工作，亲自攻克难关。这样的事情做多了，谁来牢牢抓住需求与进度？谁来承担复杂任务的组织管理？他同样也疲劳不堪。

再说到执行层，即便是优秀的策划人员也分很多类别。有人适合做需求明确的功能应用类产品，有人适合做需求模糊感性的社区类产品，有人适合做营销意识强的电子商务产品，有人适合做轻巧而灵活的移动产品。而运营工作更有着内容管理、活动组织、社区关系、资源协作等明显的偏向。你有一些很好的执行成员，并不意味着有一些很适合的执行成员，这个世界上没有万能侠，没有最好，只有最般配与最契合。

这样的一个产品项目，方向未必正确，重点未必清晰，组织计划未必严密，成员特长未必匹配，肯定走得一瘸一拐。如果在策划、运营、技术等层面上压根没有执行主管，那就更加糟糕，产品经理被无休无止的琐事困住，顾大局则失细节，顾细节则失大局，疲于奔命。

麻烦还没完呢，做好一款产品可不仅仅是产品部门内部的事情。如果策划人员的交互设计能力较弱，有没有一个专业的交互设计师专注、及时地配合？有没有适合这款产品美术风格的一到两个视觉设计师专注、及时地配合？有没有专门研究过这个产品市场的推广同事，商务同事专注、及时地配合？这些第三方支援对产品的进度、质量、成败也有决定性影响，但常常是产品经理无力把控的，只能对天哀嚎。

反过来看，如果在任何一个产品项目所需的全部岗位上，都有足够数量的，合适的，甚至是优秀的成员去履行好自己的职责，如果这个项目本身的定位又不算盲目，那么你已经有了70%的成功把握。

所谓成功，其实就这么简单。

当然，其实也最不简单。

最近听说毗邻的某公司，一下子又要招500人，深感我们这个行业处于高速扩张之中。这听上去让大多数人振奋，却使我苦恼。高速扩张意味着人才短缺，进一步引发各个项目内部的人才稀释。稍微培养起来一个高级职员，很快就跑去做执行主管了（不管适合不适合）；稍微培养起来一个执行主管，很快就跑去做产品经理了（不管适合不适合）。对人才的培养和发掘远远跟不上项目发展需求，更加跟不上跳槽转岗的速度。只要你真是个人才，工作机会无穷无尽，任挑任选；但对于我这样的部门主管，则很难攒到一支齐备而强大的团队。

此时只有三字真言可用：“抢”！去公司内部拼命争抢人才。“填”！自己分心去做其他岗位的工作，填上职能缺口。“拖”！无能为力的时候也只好放慢速度，无奈地拖过去，希望拖到转机出现。

之前我写过一篇日志叫《绑架》，其实，都是一个系列的故事。我在那篇日志里讲了一个“先人后事”的道理。如果一开始就缺乏某些核心岗位的人才，项目必定举步维艰。如果指望着项目启动后再招聘补充这些人才，残酷的现实多半要告诉你：这是一个妄想。最后自己被越走越累的项目拖住，前进乏力，又放不下来。瓶颈在哪里？就在“人才”这里。

我为此设想了一些解决方法。

首先，从现实的人力资源出发，包括现有团队的才能与偏好，个人的人脉资源，公司的招聘实力，数清楚手上的人才筹码后，再去考量自己有能力做什么样的项目。当然，你可能数了半天，发现自己只能做点小事，琐事，杂事，非常沮丧，又按捺不住野心。于是一急就要冒险，一冒险多半踩雷……

其次，在选择工作的时候不要被公司大小，职位高低，待遇好坏所迷惑。最重要的考量因素是，我将去的地方是否适宜自己发展？包括管理文化，项目定位，尤其是招聘实力与团队配置，是否能支持自己做一番响当当的事业？搞清楚，兄弟，你个人的才华在项目成败中影响甚小。不要以为自己了不起，没有人以一顶十。即便你在所处的位置上真是才华横溢，冠绝宇内，其他岗位如果缺乏必备的人才，任何一项重要职能的残疾都足以拖得整个项目歪歪斜斜。这时你能做什么？徒劳无功的 “抢”？三头六臂的“填”？唉声叹气的“拖”？还是望穿秋水，眼巴巴，可怜兮兮地等着一封闪光简历飞进邮箱。

招聘可不是一个靠时间流逝就可以解决的问题。

最近跟朋友聊天，扳着指头数，如果按照“较好的规模、品牌、受众影响力”为标准，在我们这个行业里，每年新进入成功队列的项目有没有5个？数了半天，似乎连5个都没有。天啦，每年新发起的项目起码有500个之多！如此高的失败率，只能证明合适的人走到一起齐心协力，这得有多难啊……真是三生修来同船渡。

我曾在微博上讲，最近6年来，我近距离所见大大小小的项目近百，而成功者仅四五例，究其根本原因，竟然全都是“人才缺口”四个字。不论你是VP、总监、经理，不论你有多么卓越的头脑与资历，在多么了不起的公司领多么丰厚的薪水，最终决定成就的，也只能是“人才配置”四个字。别指望靠一人之力组建一个彪悍团队，脱离了整个组织背景的人脉资源与HR支持，得不到均衡的人才供给，强龙也只是条志大才疏的虫子罢了。聪明人大都有舍我其谁，独领风骚的壮志，然而，同伴比职位薪水更重要10倍！

那么，聪明的你，接下来想拍《无极》还是《霸王别姬》？

这与你是不是陈凯歌全然没有关系。

社区是运营出来的

tony — 2010-08-23 13:06:44

大约一年前就读过周鸿祎写的《好的互联网产品是运营出来的》这篇文章，但是，真正悟到类似的道理，还是有些后知后觉。

这其实可以是前一篇文章的续篇，话题没有那么大，说产品是运营出来的，我觉得有点过，因为任何一个产品，都有一个生命周期，运营不过是其中一个阶段，我觉得不太适合夸大，但确实很重要。都说有些企业在一个正确的时间做了一件正确的事情，就算“成功”了，但持续做正确事情的企业，却不多。

扯得有点远，其实本文并不想谈太多的社区运营，我只是意识到这个问题。想说的是，设计师不应该任务接着任务地做新产品，埋头苦干。而是应该清晰知道产品的愿景以及目前的阶段。严格来说，做互联网设计和传统设计，生命周期不一样，设计一个别墅（建筑），也许前期投入很大，真正交付使用之后，设计师后续基本不需要关注。做互联网产品设计，更像是做城市规划。

再拉回到社区，我有点不太清楚怎么定义互联网上的社区，但在我理解范围里面，目前中文网络里面用户和用户在线交往的场所，多数不是被精心设计过的，起码不是预先预计到的，我经常幻觉一个场景：

如果现实生活中有瞬息移动的特意功能，人可以突然飞似地到达另外一个空间，眼前看到的有可能是一个人头簇拥的菜市场、也有可能是一个情侣相拥的公园，抑或是一个热闹的商场…

这个场景，如果要映射到互联网上，只需要给这次瞬息移动加上一个理由就好了。

而就目前来看，国内很多的运营人员，还仅仅是关注在，怎么让更多的人飞到自己的空间里面，做法有很多，比如请几个跳舞女郎露露大腿，找些皮条客像中关村鼎好门口吆喝拉拽…

长尾的头部确实是如此，但真实的生活告诉我们，三里屯、中关村这样的场所我们一年也许也就去那么几次，而更多的长尾聚集，是小区楼下几个老头扎堆下棋、咖啡馆里几个人围桌聊天、去朋友的家里吃饭叙旧…

目前的中文社区网络里，似乎并不缺乏长尾头部的地标。因为这更容易被设计和规划出来，长尾末端却更难。而一个稳定的社区形成，需要太多的因素。观察几个不同社区的形成，也许能从这些偶然里面看到一些必然：

1 给什么样的理由让人们飞进来；
2 他能看到什么东西，如何融入进去；
3 交流的质量，以及防止干扰的能力；
…
还是有很多地方还需要想得更清楚，如果你有兴趣一起思考这些问题，关注这里。

源地址：http://uitony.com/?p=120

为什么是微创新？

周鸿祎 — 2010-08-21 09:47:42

时代在变化，认识不到这一点，做什么事儿都做不成。

就互联网来说，有两个方面发生了显著变化：第一，互联网的用户群变化了，如果你还按照十年前对用户的理解去做市场、做产品，肯定是缘木求鱼，肯定是南辕北辙。第二，技术语境变化了，互联网发展不再是技术作主导，而是用户体验作主导。

你觉得苹果的iPod、iPhone还有iPad有什么高、精、尖的技术突破吗？其实没有，但苹果把现有的技术以一种新的方式整合在一起，呈现在用户面前，提供了一种完全不同于Wintel的全新体验。靠这个占领市场后，苹果就快速推新版本，每一个新版都有新的用户体验。所以说，苹果是利用了做互联网软件的方式来做硬件。

互联网产品，不管是客户端还是Web应用，要赢得用户，首先要找到典型用户群，提供好的用户体验。要提供好的用户体验，就得找到能打动用户心扉的那一点。这并不是说打动就打动的，有一下子蒙对的，那是运气；有试错试出来的，那就变成了经验。

有两点很关键：第一从小处着眼，贴近用户需求心理，第二快速出击，不断试错。我把这两点我称为是互联网上的“微创新”规律。

我做奇虎社区搜索，有时候我们千辛万苦，花了牛劲做了很大一个东西，但打动不了用户，结果就靠广告、靠推销、靠渠道生拉硬推。一旦不推广了，用户访问量曲线掉头就冲下去了。但是，我们很不经意做出来360，正好打动了用户心里的那一个点，一下子就普及起来了。所以，我在公司经常讲，做产品，一定要找到那个点。

很多人说，腾讯QQ是靠社会关系把用户黏在那里的，但手机号码具有社会关系的黏性，手机用户不是一狠心就转网了吗？其实，QQ本身就有很多微创新，比如QQ文件传输速度比MSN快，这就打动了用户的心。这一点小小的创新，让QQ不再只是一个聊天娱乐工具，也变成了一个高效的办公工具，一下子就把很多坐办公室的人变成了QQ的用户。

360安全卫士从查杀流氓软件开始，也是一直在做微创新工作。查杀流氓软件就是微创新，传统安全厂商怕得罪人，不敢干，没有钱赚，不愿意干，袖手旁观看360的笑话，结果360受到广大用户的欢迎；后来，360开始给用户电脑打补丁，这也是一个微创新，别人嘲笑我们，觉得打补丁真是不一般的傻冒，一点技术含量都没有，人家都不屑于干。我们不管别人笑话，觉得打补丁、补漏洞能让用户的电脑更安全，那360就去干，不管有没有钱赚，有没有利可图。

那个时候，360的团队也有想不通的。我跟他们说：“一件小事，你把它做到世界第一，做到极致，就是一件大事。相反，你觉得自己牛，能写一百万行代码，做出来一个大产品，技术含量高，但用户用不了，用户不愿意用，这种产品又有什么价值？”

360免费杀毒刚出来的时候，传统安全厂商还是嘲笑我们：看看360杀毒，只有三个按钮，太简单，不专业。现在你再看，打补丁补漏洞成了安全软件的标配，杀毒软件也纷纷效仿360杀毒的三个按钮。

包括体检、开机加速，你要是打开360安全卫士，每一个功能都是微创新。360就是靠这样一个一个的微创新发展起来的。要做出微创新，就要像钻进用户的心里，把自己当成一个老大妈、大婶那样的普通用户去体验产品。模仿可以照猫画虎，但肯定抓不住用户体验的精髓。

其实，只要真的是全心全意为人民服务，创新就会源源不断，像泉水一样奔涌出来。

所以，我正在考虑要在360的办公楼上挂上一个大幅的标牌，上面就写“全心全意为人民服务”。要天天讲，月月讲，年年讲。对360来说，这才真正是发展的基石，立业的根本。

源地址：http://zhouhongyi.blog.sohu.com/158210476.html

从用户中来，到用户中去

周鸿祎 — 2010-08-21 09:47:06

《毛泽东选集》第一卷开篇第一句话：“谁是我们的朋友，谁是我们的敌人，这个问题是革命的首要问题。”

我想换一种说法，对于做互联网产品的人来说，“谁是我们的用户，谁是我们的竞争对手，这个问题是从事互联网的首要问题。”

现在一说互联网，就先提到商业模式，一说商业模式，就要问怎么挣钱，何时盈利。其实，商业模式是一个系统，分为几个方面。第一是用户模式，就是要回答谁是自己的用户，给他们提供什么样价值的东西。第二是产品模式，简单地说，就是你要做什么，不做什么。第三是市场模式。就是你要如何定位，用什么样的手段去推广。第四是收入模式，怎么把用户价值转换成商业价值。

所以，谁是我们的用户，做互联网产品的，首先要回答这个问题。

因为我们每个人都生活在自己的圈子里，都会不由自主地认为，全世界的人都跟自己一样。如果按照这种思路做产品，那就会把自己当作典型用户。当年大革命时期，陈独秀认为产业工人是革命的典型代表，所以他只能发动少数人干革命。毛泽东出身农村，认为湖南的农民才是革命的典型代表，结果他成功了。陈独秀不成功，因为他把书本上的马列当行动指南，典型用户是空想出来的。毛泽东成功了，因为他到“用户”那里进行了调查，了解到了实际情况。

现在的互联网用户，跟15年前不一样了。那个时候，互联网的典型用户就像我一样，学计算机出身，会编程，喜欢互联网上出现的各种新玩意儿，还喜欢看谁的东西做得好，做得酷。今天，像我这样的用户只占互联网人口中的一小部分。越来越多的中年人、老年人加入进来，网民的学历越来越低，低收入的网民占很大比例。这些用户一般是沉默的大多数，不习惯在互联网上表达自己的看法，也不愿意向厂商反映产品意见。还有很多方面跟我们做产品的很不一样。

像这些用户，他们对产品的使用需求和心理需求，我们一定不能坐在房子里空想，应该像毛泽东写《湖南农民运动考察报告》一样，放下身段，放低姿态，主动地去了解他们。比如，在路边上看到农民工用手机上网，在网吧里看到有人边吃盒饭边玩游戏的，或者有小女生在玩劲舞团，你都可以凑过去，打个招呼，问问他们上啥网站，喜欢玩啥游戏，喜欢看什么新闻。

做技术的人觉得有一种天生的优越感，有的人用居高临下的眼光来看普通的用户。这种心态是绝对做不出好产品的。其实，心态这东西就是一层窗户纸，一旦你这样捅破了，你就放下了自我，真正融入到用户中去了。毛泽东还有一句话：从群众中来，到群众中去。我把它改一下，做互联网产品，就要“从用户中来，到用户中去。”

从用户中来，放下架子，真正从用户角度去看产品，把一切花哨的玩意儿去掉，把复杂的技术做到后台，让用户看到的是简单，简洁，让用户用起来是顺手，顺心。这样做出来的东西，才会受到用户的欢迎，才会让产品到用户中去，从而汇聚起大规模的用户基础。

源地址：http://zhouhongyi.blog.sohu.com/157847625.html

往前迈一步，往后撤一步

tony — 2010-08-18 09:24:45

在很多场合，都有人问我，怎么从一个做平面设计，最后做到产品设计。翻译过来就是：视觉->交互->产品。
其实很遗憾，这三个领域，我都是半调子。

但问得多了，还是写篇博客综合一下我的想法和建议，给一些初入门的设计师们，归纳起来是三个字：好奇心。

我做事情有个两个毛病：
想起一出是一出，但好的一面是，喜欢瞎想和思考。
懒，好的一面是，总能捡重要的事情做，愿意找问题的关键出路。

回到正题，互联网产品流程，都讲究迭代，这个已经被说烂了，但是真正在执行过程中，却并非如此。
一个是内部迭代，一个是外部迭代。设计师脑子里面尤其需要这个思想。

常见的情况是，需求提到设计师面前，设计师开始执行出方案，到上线，甚至方案提交出去，设计师就基本不管了。这个显然不是迭代的思想。产品的效果，往往在流程中和目标初衷，有所损耗。

设计需要讲究节奏，最近和专业的设计师配合做事情，才真正意识到，阅读需求是多么的重要。好的流程是，设计应该在一个想法产品之初，就开始参与进去。而不是一个需求已经形成文档了，重要的是让设计师了解需求产生的过程。这就是往前迈一步。

历尽千辛万苦，产品上线之后，这时不是万事大吉。设计师要关注的，也不仅仅是关注口碑，而是要去看，用户是如何使用的，数据怎样，和当初设计的初衷是否吻合。这是往后撤一步。

道理其实蛮简单的，尤其是后者，如果没有后续，对设计师自身的能力，以及设计的感觉，几乎没有提升。因为好坏的标准，是在被评价。

中国的设计环境，被美术这个词侵蚀太久了，互联网设计，背负了太多广告公司做项目的工作习惯。而其实据我了解，国外的广告公司做设计，其实并非如此。接触过欧洲的一些小的工作室，看过其中的设计方案，非常严谨和理性。

源地址：http://uitony.com/?p=119

如何正确的看待：产品需求文档和产品需求

费杰 — 2010-08-17 11:42:16

其实那会还在北京的时候，就曾经写了篇文章叫《正确的写产品需求文档（PRD）》后来被转载无数，现在想想那会还仅仅是停留在技能的熟练度一样，或者说通过这篇文章可以让大家掌握一种快速文档的套路。

因为最近还是有很多新人问我要产品需求文档，他们很想看看一个典型的产品需求文档应该是什么样的，我直接拒绝了，我一般会说：“请多想想”。我是这么的理解：看文档本身其实是没有意义的，特别是产品需求文档，其实是需求的产物。作为产物就好比是你今天用一个手机，看手机的说明书一样，你已经知道了这个产品是什么样子，但是为什么这么做，如何做？先做什么，后做什么，你还是不知道！

所以从产品需求而言，文档本身没有个推导的过程。这也就回到一个问题上，很多产品经理新人本身是意识不到，如何做需求，如何写需求文档的差别的。在他们的潜意识里，反正公司是需要有产品需求文档这么一种载体来表达他们的想法，所以很自然而然的认为，学会了写需求文档，就掌握了如何做需求，处理需求一样。

这样听起来有点绕口，但我表达的观点是：想与做的过程是分开的。一个是过程，一个是因为有这个过程的产物，很可能很多时候产物本身可能没有太多的意义。但从表象上来看，文档写的有没有逻辑感，有没有层次感，表述的文字是否清晰、清楚也是一种境界。

很多时候我们写方案做PPT，很多人写出来的东西是完全不一样的。那PPT的宗旨是：简单、标题化、有视图、也不乏空洞。之所以举这个例子，其实是所以一样的情况。写产品需求文档本身其实更多的是：产品需求推导的过程。因为先有了推导的过程，然后再有了推导的结果。很顺利成章的，各位产品经理新入门的朋友，你是否也具有：“产品推导”的过程呢？

产品推导的过程是：做什么，为什么要这么做，谁来做，怎么做，一步步怎么做，最后做成什么样，最什么要做成这样，不做成那样。写需求文档的过程其实就是处理需求的过程，所以以上这几点有没有写想明白？很多公司要做一个产品，可能高层是想要一个东西，但在执行的过程中因为上下级之间认识、理解的不一样，所以在执行的过程中或多或少有所偏差。所以在这个过程中，回答上面几个本质的问题，是会纠正你做需求的思路，不会做弯路。

产品经理这个群体是个很奇怪的群体，他们的主观性非常的强，喜欢把产品按自己的兴趣和喜好去做，所以得出一个结果本身不难。因为这个结果很可能是出于产品经理主观喜欢的结果，但如果从过程出发得到一个结果，这个时候大家相比一下过程和结果本身而言，对于结果的认识想必也会不太一样。

结合今天说的主题：《如何媒体正确的看待：产品需求文档和产品需求》，产品需求文档可以是没有固定格式的，大家不要把产品需求文档想象的怎么样怎么样。写产品需求文档，是做产品经理的一个基本能力，写的逻辑感怎么、层次感怎么样，写的是否清晰和明白，是有一定差别的。但本质上不管是excel、word、rose、还是txt，其实都是次要的。

宗旨：让给你需求拍板的人，知道你的逻辑是什么，让和你一起做的程序员很清晰的知道需求是什么，让给你一起测试的人员知道你的细节就可以了。以后也方便于版本升级，知道你一个版本、一个版本都加了哪些需求，改了哪些需求，删了哪些知道需求就可。所以文档本身起到的东西就是这个，一个是告知，一个是存档。

但产品需求是本质核心的东西，只有你想明白要做什么，怎么做，谁来做，一步步推导的过程是否合理、是否让自己信服，让别人信服，这才是最根本的。有了这个做保障产品需求在文档化的过程中，才会层次分明，结构清晰。所以当很多朋友一直在问我文档怎么写的时候，请大家好好的想一想：我应该在哪几个方面处理这个需求，需求的维度怎么切割？需求的优先级怎么切分？哪些是核心的，对整个产品起到重大关键的？哪些是锦上添花的？哪些是可有可无的？需求的主线是什么？……等等

只有想明白了这些，才会轮到如何把产品需求，进行文档化的阶段。这个时间，我们再回顾头看看《正确的写产品需求文档（PRD）》，通过一些小的思维方式把写文档的技能组织起来，发现所有的一切都是那么顺利成章。最后也忠诚的建议大家：要想学会写需求文档，请先学会怎么样分析需求开始。生活也一样，从本质看起，这样我们感受到的会不一样。

相关话题：产品需求文档源地址：http://www.kuliqiang.com/?p=3209

浮躁的设计，你我他

2010-08-17 10:43:07

弥漫在中国各行业的心浮气躁，在互联网设计领域也不能幸免。

视觉设计在做交互设计的事，交互设计在做产品经理的事，产品经理在做老板的事，就是没人做自己专业领域的事，并且是沉下心来踏踏实实去追求做到极致。

大家都太浮躁。

比如，一个公司的网站，请了一堆设计师，都很忙。但是网站上一个输入框都丑了好多年，还继续在那丑着。问起来，原来有的在忙乎用户调研，有的关注产品发展战略去了，眼光还真是够长远的，有的在和产品经理扯信息架构内容运营，有的……

但，就没一个去把一个显而易见的网站最基本的功能小组件做好来，看看输入框上别人玩的的创意，我知道你看得懂的：

这么批评人是不对的，但是这是现状。再看下拉区块，别人能干什么？

Google Wave的滚动条，虽然还有些小毛病，但是人家的态度，我很欣赏：

听到很多设计师朋友的抱怨：

别人不尊重我这个专业。

我说的没人肯听。

我的专业度，公司其他人/部门不认可。

……

我说，都是自己造成的。

你该做什么？

老老实实把最基本的做好来，再去和别人要求尊重吧。

别尽整些“高端”的。

老实不吃亏。

源地址：http://z.ctripued.com/?p=28

有的放矢地满足用户需求

Blueui — 2010-08-15 21:41:01

苹果粉丝都知道，当iPhone 1.0上市的时候，人们对于iPhone不支持多任务感到惋惜。苹果在HIG中的解释是：移动状态下，屏幕很小，内存有限，并且人们只能在一个时间与一个应用程序发生交互。

最近在做有关iPhone APP的项目，对这种多任务处理有了些自己的感受。

首先我们分析下，人们对多任务的需求是什么？

• 快速切换几个应用程序。

作为iPhone用户，安装大量的app简直就是小儿科，一不留神，九个屏幕全满了。虽然iPhone运行应用程序的速度还是很优秀的，但是需要关注的是，在移动状态下时间更加宝贵，如果切换一个程序花费太多时间，人们会产生焦急感。在早期，HIG中规定应用程序响应时间不要超过20秒——请不要轻易挑战人们的心理极限。

• 同时运行两个或者更多的应用程序。

这里说的“同时运行”主要是说——边****边****。例如，边听歌，边玩游戏。边听歌，边看下说。请不要过于挑战人们的能力——边看电影边看小说。人们在移动端可以使用不同的感官享受不同的服务。

在iPhone iOS4.0出来之前，即便没有多任务，苹果iPhone 3G 3GS 都一样畅销。原因何在？

针对第一个需求：快速切换应用程序。苹果给出的解决方案是：1.程序退出时，应该保留用户此时的界面；系统主动随时为用户备份数据（例如游戏、文档编辑等）2.提升硬件的速度。

可以说，3GS之所以畅销，就在于满足的一代用户对于速度的不断追求。

针对第二个需求：同时运行多个程序。在苹果看来，你可以边听ipod边做其他事情，原则上，你的服务不能含有声音，否则ipod会自动暂停，直到你退出其他程序才会自动继续播放。那么可以说，苹果考虑到硬件特点，暂时没有开放端口而已。

总的来说，用户的需求在一定程度上被满足，符合这个产品在这个阶段受到硬件条件限制。那么iPhone 4.0出现，全面向多任务体验开路，多任务不是一个支持不支持那么简单的事情，他们做了很多细致的工作。

首先，硬件性能指标全面提升——这让多任务变得可能。这就是为什么3G型号不支持的原因。

其次，增加交互行为。双击home键，调出多任务栏。无论你在哪个界面都可以顺畅切换。在这里，调用物理按键，是唯一的选择。试想，如果你用手势，那样应用程序开发者就缺少了一个手势。选用home，也让多任务管理变得非常值得依赖、稳定。

最后，苹果给出了相当详细的指导原则，来让您避免多任务带来的诸多问题：

苹果针对多任务对产品的要求——在多任务环境下与其他应用程序和谐相处——直截了当的引导产品设计者要注意对多任务的正确和节制地使用。

下面的指导原则，可以帮助我们的应用程序更好的出现在多任务环境下：

1. 中断或者音频在切换中要过渡自然。

2. 从背景中启动或者停止，要迅速和顺畅。

3. 在后台运行要足够可靠。

具体做到这三点，需要做好如下准备：

1. 时刻准备程序暂停或者重启。因为多任务功能增加了用户暂停应用程序的可能性。另外广告和程序切换也会让暂停更加频繁。更快和更精确的存储用户的应用程序的状态，是对应用程序的要求。

2. 确保自己的界面能够容下两倍高的状态栏。例如当有电话来的时候，就会出现两倍状态栏的通知区域。也就是说，你的应用程序不能因为通知区域的出现而发生问题。

3. 允许用户随时根据意愿暂停使用应用程序。那游戏为例，暂停退出游戏应用，当我再回来的时候，需要继续刚才的游戏画面。

4. 确保你的音频服务是合适的。多任务允许媒体在后台继续服务。同样也要求你的音频服务能够暂停或者继续播放。想处理好这块的问题，你必须阅读“声音”这块的指导文章——用户想使用您提供的音频服务，但是不需要惊喜与您对声音的特别处理——例如，通知提醒声音，铃音。那样只会造成混乱——苹果也不会通过您的app申请。

5. 使用本地通知推送服务。一个程序需要为随时而来的通知推送做好暂停准备。使用本地推送通知，需要阅读相关的指导文档——别什么都推送都通知——你的用户会因为你推送的没有意义的通知而崩溃。（一般情况应该是：消息到达；事件发生；新数据请求下载；情况发生变化。）

6. 适当的时候，在后台完成用户的任务。当人们开始一个任务，他们希望它完成，即便他们切换到别的应用程序。所以，如果你的程序提供了类似这样的任务，而且这类任务不需要人们持续关注，那么程序应当在后台静默完成，完成后给用户一个提示。

——————

用户需求伴随着产品出现而成长，有的放矢的满足用户需求，就想苹果在多任务上的做法，将需求拆分，即不给自己画牢，也没有打击用户的积极性，这样的做法值得我们学习，一蹴而就的做完美产品，只能带给项目沉重的压力，和过度的成本。

源地址：http://www.blueui.net/blog/?p=189

产品经理如何推进团队执行力

seraph — 2010-08-11 09:43:44

按，前天参与了一次Podcast的录音座谈节目，其中聊到如何推进团队的执行力，略有心得分享，整理以记之：

1、产品经理首要确定的工作原则：战略决策产品，产品驱动开发；

2、结合实际情况，设计可执行的工作流程，明确各职能环节的工作成果输出（原型/界面设计，需求文档/思维导图或流程图）；

P线：产品管理，产品设计，界面设计，交互设计，及其它
T线：项目管理，技术架构，技术Leader，开发人员（前端，页面，后端，服务端，数据端，运维等）

3、尽可能的明确可度量的工作成果标准，由P线经理提供需求要点纲要，表明要做到什么，不用做到什么，T线经理根据需求与相关人员共同设定工作目标和标准；

虚拟示例：某功能模块，进行V2版本优化，2周为一次迭代周期，共2个周期

需求要点是：功能性流程与V1版本相比无增加点，重点是实践前后端分离的开发模式重构该功能模块的实现代码，交付给用户更有惊艳效果的操作流程，强化每个操作环节的引导或提示体验

第一个周期的关键是：需求明确，各职能角色的充分交流

第1周目标是：P线成员完成产品细节需求策划，T线成员相关技术架构的预研
第2周目标是：需求策划完成交付，二个关键展示页面的技术功能性开发完成

第二个周期的关键是：保证质量，在进度内完成既定目标

第1周目标是：所有技术功能性开发完成，关键业务流程可以走通无误

第2周目标是：所有需求策划细节开发完成，重点是用验设计、界面设计无损实现

此产品开发组团队共4人：责任产品经理1人，技术骨干兼项目经理1人，相关技术开发人员2人；周边支撑资源：界面设计、、交互设计、页面制作，约6人/天

4、抓住一切机会点，在团队内告知及说明工作原则和流程标准的重要性，特别关注对老板的告知；

5、对于执行过程中的各职能环节协调问题，保持高度的敏感，最及时的处理此类问题；

6、对不同职能角色的沟通技巧，产品经理本身需要在思考上有相当的弹性来去适应不同的角色思维模式，老板，技术Leader、成员，界面设计、用户体验、前端开发、客户等

在和P线角色沟通时，要适当的讲解技术实现相关原理，能做为什么，不能做更要为什么，并在满足需求本质的前提基础上，提出妥协或更合理的解决方案；

在和T线角色沟通时，尽可能说明该功能需求的来源，用户反馈次数和态度，分析其合理性，以具体案例和模拟用例来推演出合理性；

虚拟实例：项目管理=》项目成员管理与授权功能=》产品提出需要可以增加部门为项目成员

已有功能流程：进入项目成员管理，可选择部门下拉框=》员工下拉框，点加入成员

产品的思路：选定部门后，即可直接将该部门加入项目成员，让项目经理操作减少，当部门员工离职后也无需再取消该员项目成员身份

技术的思路：该需求技术可行，需要涉及到的功能点有，项目成员管理界面可增加部门，部门绑定的权限角色被授权，3个其它功能模块中类似的人员选择区做同样的处理，约2-4人/日工作量。

我的分析：能理解该需求思路，选部门的出发点在于减少项目经理操作次数，这个能认同，但一个项目经理在此项目里选了部门为成员以后，如果该部门有人员增加而又正好不是参与该项目的，岂不是还要再回来把这个项目的成员里去掉这个部门，再加上原有的员工；其二，这个漏洞虽然很小，用户实际操作中碰到的几率很低，但既然我们提供出这个功能，就一定会有用户使用到出现问题，那岂不是违反了我们做这个修改的目的：改善用户操作，获取用户认可。须知，对于用户而言，我们做的更好是应该的，大部分用户未必感知到，感知到的用户也未必会传播；但如果我们做了一个会出某问题的产品，大部分没出现该问题的还是沉默状态，出现问题的就一定会进行传播反馈（抱怨不爽投诉。。。），影响到本来没此问题的用户群体了。

结论：需求决策的原则：产品环节对没有问题的解决方案进行判断或优先级选择时，可以按关注用户几率的多少来进行，但如果有问题的方案，就不能按用户关注几率来判断，哪怕只有百分之1的用户有可能出现问题，就是致命。该需求应该寻求其它解决方案。

我的方案：项目经理选择部门后，人员下拉框里第一项是“加入该部门所有员工”，产品认为可以满足需求的出发点，技术认为需要投入的工作量约0.5人/日，达成共识；

7、以合理的方式展现团队的各阶段工作成果，一则收集需求反馈，二则收获公司及客户的认可提升团队士气；

综上，主体的思路是：确定原则，明确战略，设定标准，统一思想，持续沟通，修炼技巧，展现成果。此次主要是对设定标准和沟通技巧分享两个例子，其它的环节有机会再谈谈。

相关话题：产品经理源地址：http://user.qzone.qq.com/312950/blog/1280751839

基于Axure的PRD写作思考

kent.zhu — 2010-08-11 08:56:47

本文想说的事情是，那个叫PRD文档的家伙只是个称呼而已，PRD的问题不在于如何写而在于如何被传递与执行。这里简单介绍一下我基于axure rp的一种新的PRD写法。（友情提醒：从来不用axure，认为他笨重无比的人请路过。）

从半只脚迈入产品经理这个大门的那天起我就被2个文档的名称深深的纠缠着，他们是市场需求文档（MRD）、产品需求文档（PRD）。先不论你是什么方向的PM，这2个玩意一定会一直伴随你的Title跟着你。这2个文档在不同的团队中有不同的叫法和写法，我也见过有团队的MRD其实就是PRD，不沾半点商业市场分析的边的，当然，这些不是本文探讨的内容。

长久以来，有个很有趣的现象：“有没有PRD模板，PRD该咋写”这个问题已经成为新手入门经典必问题目之一；如果1年以后这个家伙还在这行里混，他一定会抱怨，娘滴，我们的QA压根就不看我的文档、我们的交互（如果有这个职位的话）还是会问我一些我写的很明白的问题、我们的测试拿着文档问我该咋测试、….

Web页面之间的关系是网状的，而Word文档只能树状的表述，这无疑是矛盾的；PRD文档无法做到实时更新发布，我回顾了我第一年写的PRD文档，很多下面的修改栏都是空的，惭愧之至….；所谓一图胜千言，万言刚够文档标准，每个PRD都是臭长臭长的，这样的东西别说交互设计师了，很多PM自己写完了都不想看。所以，我武断的认为，撰写某些PRD文档实在是一个既耽误时间又费劲且不敏捷的事情（很多PRD都是一夜情，写完了就不会修改更不会有人乐意看100P以上的文档），是在让产品经理实现慢性自杀！

个人认为，一个PRD文档需要包含以下的内容：

1、概述
1.1、名词说明：文档中涉及到的名词
1.2、产品概述及目标
1.3、产品风险预估
1.4、产品开发进度：产品开发阶段及责任人与时间节点
2、使用者需求
2.1、使用者需求描述：定义用户是谁
2.2、管理员需求描述：后台管理部分（很多人会忽略这个部分）
2.3、任务流程图：从业务逻辑流程到产品逻辑流程转化
3、功能需求
3.1、功能总览
3.2功能需求分解：界面分解及交互说明和用例
4、非功能需求：与该产品相关联的辅助产品等
5、上下线需求：产品的生命周期
6、运营计划：产品的上线后的反馈与改进

整个文档中，最大的部分其实是对功能需求的分解，但是最核心的部分是使用者需求与功能需求部分。使用Axure后，我发现Axure可以很好的承载我平常写的这个产品需求文档的全部内容，最主要的问题是，Axure是可以网状的展示的。下面是举个例子：

在Axure的站点导航中，默认的Home页面承担了PRD文档的第一部分内容；而使用者需求描述及任务流程图也可以由Axure自带的流程图功能完成；任务流页面的分解本来就是Axure中完成的；最后的非产品功能部分也可以由axure完成（文本块组件）

同时，Axure支持多种格式的输出，一般情况下我是发送给团队Html文件包，也可以是.chm格式的文件（团队协作目前还没有尝试）。该文件包打开后，左侧是整个系统的导航菜单，右侧是相应的说明。最主要在于，原型中的页面是可以相互跳转的（得益与axure的强大交互功能），同时页面有注释功能。所以，整个产品需求文档真正实现了基于产品的模拟，网状的传播，而不是Word式的树状阅读。

1）见过不少新手使用Axure生成的原型有页面是空白的，我问为什么，他说这个页面不知道放什么，但是又不能不命名，否则逻辑上有些不通。实际上，这个空白页面就可以用来放这个页面的流程图及整体的说明。

2）不建议做太复杂的Axure动作，比如使用多个层、动态面板等。因为在工程师等的眼里原型图是不可以点击的（基于viso等的惯性思维），所以，为了避免花很长时间去实现一个很炫的axure交互而最后被埋没，建议把任务分解来画。比如一个输入框，需要画：默认状态、获得焦点状态、输入字符判定状态、失去焦点状态等，按照逻辑分步来展示。（在我特别蛋疼的时候我会先分步展示，然后搞个比较炫的交互放在上面自己玩或者用于演示）

3）在每个页面的下方或者侧边（由页面大小来定）要放一个功能详解的文本块来对本页面的功能进行详细说明。也可以直接使用Axure自带的注释功能（组件注释、页面注释）为什么不推荐用Axure的组件注释功能？因为这个功能在生成的原型里是被隐藏的，有被人无视的可能。

4）使用axure的组件库功能（可自制）和模块功能既可以保证设计的统一性（设计规范），又可以提高原型制作的效率。图中我采用了注册模块。

下面，QA时间（这个QA是问答，文中的QA是技术，呃，注意区分）

Q：为什么我看到有的书上说要写N多文档，带RD的有：BRD、MRD、PRD、….
A：是的，有这样的定义。BRD（商业需求文档）、MRD（市场需求文档）、PRD（产品需求文档）。每个公司的风格不一样，我个人倾向于把BRD与MRD整合，PRD单独做。但是MRD与PRD中会有内容重合，就是会同时提到用户是谁？为什么要做？产品目标是什么？等几个问题

Q：Axure有个功能是可以导成Word格式，把做的原型导入后是归类好的，包含了用例文档，为什么不这么玩呢？
A:没人说不可以这么玩。还是那句话，个人习惯。

Q：除了页面原型之外你塞了这么多东西到Axure里，会不会导致源文件以及生成的文件体积巨大？
A：实际上塞进去的东西都是文本，使用axure的文本组件完成的，体积并不会大。同时，请不要在用axure做原型的时候使用过多的图片，尽量是用组件和模块完成。我目前位置做的最大的一个原型是4.7M，这是一个完整的系统原型。

Q：按照你的写法Axure好像是万能的了？
A：没有不好用的工具，只有用的不顺手的人。人是活的，工具是死的，且Axure目前在mac平台下功能并非很强大，也有很多人觉得axure很笨重，更加喜欢轻量级的原型功能。不过，这些都不是核心问题，核心问题是要让你的团队能够以最高的效率进行合作。使用Axure的人不必鄙视Viso，用excel的人也不必羡慕OmniGraffle，拿Word的人也不必留恋firework。

既然提到了MRD也顺便说下我写这个文档的习惯。一般情况下这个文档是给老板看的，主要是对市场的分析、同类产品的竞品分析、我们产品的盈利预测等等。所以，一般由PPT来完成。你的文档越长老板越反感，你的文档文字越多老板越没兴趣，所以，PPT是最好的方式。

文档这个东西跟流程有类似的地方，大公司会相当重视这个事情，因为要规避风险。流程与文档的核心点在于如何高效传递如何快速执行而不是他如何写以什么形式写。相对于小团队而言，流程之殇大可避免。当然，如果大公司能够以小团队的心态去做大产品的话，定会事半功倍！我更相信小团队大产品的力量，而不是大团队大产品的说法。

产品UI设计流程

小威 — 2010-08-10 22:25:03

本篇是为杰妞同学写的产品UI设计流程，其实对于产品UI设计流程特别是对于大型的互联网公司的要求特别高，经过不断的挑“刺”后才得以面世，得到的设计稿件完全与最初版本不同，商业类的产品会让产品和商业气息相兼容，与UI设计师的最初思想完全不同，而UI设计师会将自己的风格带到产品中来，会给产品灌输一种“性格”，该产品特有的“性格”，一般公司只将把UI设计流程分为四个简单的阶段：分析、设计、配合、验证。

1、分析阶段
需求分析、用户场景模拟、竞品分析（聆听用户心声）。
需求分析：对于一个产品来说，必然有对用户需求的分析内容，更多的是从MRD与PRD获得，或者从产品需求评审会议上得到需求分析的内容，当然可以直接与产品经理交流获得相关产品需求。如果说设计原则是所有设计的出发点的话，那么用户需求就是本次设计的出发点。
用户场景模拟：好的设计建立在对用户深刻了解之上。因此用户使用场景分析就很重要，了解产品的现有交互以及用户使用产品习惯等，但是设计人员在分析的时候一定要站在用户角度思考：如果我是用户，这里我会需要什么。
竞品分析（聆听用户心声）：竞争产品能够上市并且被UI设计者知道，必然有其长处。这就是所谓三人行必有我师的意思。每个设计者的思维都有局限性，看到别人的设计会有触类旁通的好处。当市场上存在竞品时，去听听用户的评论，哪怕是骂声都好，别沉迷于自己的设计中，让真正的用户说话。

输入物：MRD、PRD、市场需求文档、市场调查报告、竞品分析文档（或其一或全部）

输出物：设计初稿（或许只是几个简单的界面）

2、设计阶段
设计方法采用面向场景、面向事件驱动和面向对象的设计方法。面向场景是针对该产品使用场所等模拟，模拟用户在多种情况下产品使用的模拟。面向事件驱动则是对产品响应与触发事件的设计，一个提示框，一个提交按钮……这类都是对事件驱动的设计。面向对象，产品面向的用户不同对于产品的设计要求不同，不同年龄层的用户对于产品的要求不同，产品的用户定位将对UI设计师影响因素。

输入物：交互文档（高保真原型）

输出物：设计终稿（所有的设计稿）

3、配合
UI设计师交出产品设计图时，更多的配合开发人员、测试人员进行截图配合。配合开发人员对于PSD格式的图片切图操作，对于不同的开发人员的要求，切图方式也有不同，UI设计师需配合相关的开发人员进行最适合的切图配合。

输入物：设计终稿

输出物：设计修改稿（设计稿切片）

4、验证
产品出来后，UI设计师需对产品的效果进行验证，与当初设计产品时的想法是否一致，是否可用，用户是否接受，以及与需求是否一致。都需要UI设计师验证，UI设计师是将产品需求用图片展现给用户最直接的经手人，对于产品的理解会更加深刻。

输入物：产品

输出物：产品（面向用户最终版本）

产品UI设计中夹杂着许多设计原则要求，统一公司UI设计流程，使UI设计师参与到产品设计整个环节中来，对产品的易用性进行全流程负责，使UI设计的流程规范化，保证UI设计流程的可操作性。UI设计师应该分析公司产品的特点，制定符合产品生命周期的UI设计流程。每个产品的生命周期中，UI设计师应该严格按照流程，完成每个环节的职责，确保流程准确有效的得到执行，从而提高产品的可用性，提升产品质量。

建议：UI设计师有自己的风格，同样有自己的个性，建议在时间充裕时，UI设计师做二套设计稿，一套适合企业的，一套适合自己的，当老板对企业那套设计不满意时，将适合自己的一套展示给用户，或许会有不同的效果哦！

相关话题：网站设计规范分享及探讨源地址：http://www.537520.com/?p=650

我理解的产品经理

kent.zhu — 2010-08-10 22:09:26

本文，我从一个新手的角度去记录我所理解的产品经理是什么。仅代表个人观点，仅从一个没有UED支撑的从业者所思所想出发，肯定会有错误，欢迎批评探讨。

前段时间千鸟写UCD概念在中国系列的时候，我跟他说你可以写个“产品经理在中国”，千鸟说这个事情太复杂没有经历去搞，等有时间的。于是，我一直期待到现在我想表达一下我自己理解的产品经理了……

首先，产品经理是个舶来品，业界普遍同意的是这个东西源自宝洁公司。其英文说法是Product Manager，中文翻译为产品经理，简称PM。我试着从这2个缩写字母来理解一下目前的产品经理流派。

1、产品的经理。P：Professional，专注于做（Design）；M：Management，专注于管理。
2、产品和市场。P：Product，产品设计层面；M：Market，市场运营层面。

第一种流派是目前几个大公司的产品经理流派，每个产品经理最终的发展方向不一样，有专注于设计的有以管理为方向的，然后P1、…、P12，M1、…第二种是我自己杜撰的，基于我自己的理解，个人为人第二种缩写的解释会更适合我理解的产品经理。

产品经理是永远从需求出发的立足于产品的有良好运营思维并擅于团队作战的狼首领。

记得早前在微博上有一条关于产品经理的微博流传甚广，被转发很多次，我是这样回复的：“我们只是：开发里面最懂UI的；运营里更注重用户的；战略中比老板更知道从细微着眼的；销售中比运营更了解产品的；比谁的权利都低但比谁都会运用权利的；产品做好了最容易被遗忘的那个小人物”。这是我对我理解的产品经理的第一次概括。下面详细说下

1、产品经理首先必须要对所从事行业充分了解，先是行业专家。深度了解这个行业的用户行为、行业规则、行业特点，或者至少是资深用户，才能培养自己的同理心，才能把握住整个产品的发展方向，最终去做产品。

2、产品经理是个立足与产品有运营思维的人。之前我说，产品设计师都是自负的，他们思考问题的方式在于这个事情应该是什么样子而不是他现在是什么样子；工程师同学永远都会先考虑功能实现然后考虑是什么样子；而市场运营同学考虑问题在于老板给我的预算额度是一定，我怎么分配这些市场费用能够达到收益最大化。所以，产品经理同学就必须兼备以上的思维，在做某个决定的时候同时“人格分裂”的从这三个方面考虑一遍。

在产品团队中，产品经理必须时刻记得问自己这样几个问题：我的核心用户是谁？他们在什么情况下有这个需求？这个产品的目标与期望值是多少？并且，要让整个团队的人都有问这几个问题的意识。需求，永远都是最根本的，如果产品经理搞不清楚这个事情，那么交互设计、视觉设计、工程师都会跟着错！产品经理草率的告诉交互设计师说我们需要上一个某某功能，交互设计师有责任有义务询问产品经理，为什么要做这个，给谁做？然后才是开始去做设计！否则就只是个工具。

3、产品经理要在团队中扮演寻找满意解的角色，而不是最优解的角色。如上图所示，产品设计、市场运营、工程技术3个部门关注的产品的点是存在重叠的，而产品经理就是去发现这个重叠的部分并很好的利用这个重叠的人。

满意解的意思在于，产品经理是基于“权益”的标准来进行团队沟通的，而不是基于权利或者权力，这个解需要平衡团队所有成员的权益。所以，我一直认为，“马化腾、史玉柱等是中国最好的产品经理”的说法是有问题的，他们应该被叫做“拜用户教”教徒以及“UCD型Boss”，他们算不上产品经理。

4、产品经理的核心技能在于沟通与控制。团队以及合作的观念必须时刻具备，当团队里每个人都受到鼓励、赋予了权利并且被尊重与信任的时候，团队就会有最理想的表现。从另一个层面上看，以团队意识为核心的结果往往会是没有核心，平衡了各方的利益之后，往往把本来最有利的部分完全抹杀了，敢于拍板和为自己的决定负责对产品经理来讲很重要，也就是要讲究控制，或者按照百度的话说叫做“和多数人商量，听少数人意见，自己做决定”。记得之前有位前辈给我推荐过一本书《只有偏执狂才能生存》，受益颇多。

你可以有某个领域不会，但是，你要有能力指使会的人去做。当然，也有必须什么都去做的产品经理。我把国内目前的产品经理分为两个类别：有UED支撑的产品经理（雌雄异体）、全能型产品经理（雌雄同体）。在有UED支撑的情况下，产品经理不太需要去关注产品具体的设计细节，产品经理更加偏重于如何去沟通，去解决问题；而没有UED支撑的产品经理更多的在于学会如何最大限度的利用资源，由于从设想到实现几乎都是一个人来做，所以，偏颇在所难免，寂寞是产品经理最要命的敌人。

5、产品经理一定是最爱自己产品的那个人，并且，我觉得只有自己一个人爱是不够的，同时还需要让整个团队的成员都植入这个观念。这种爱不是溺爱，我觉得有2个方面：擅于且敢于主动的自我阉割，开放的心态接受一切批评意见；不断的向大家介绍你的产品，并推荐之。为了爱产品需要有狼性，如我在微博上所说，产品经理应该明白，资源是靠“打砸抢”得到的，别指望别人施舍；社区的运营与产品设计者也应该明白，要做好社区就必须要有铁血政策，特别是在一个充满刁民的社区，当然，对部分意见领袖的怀柔也是必须的！

6、产品经理需要关注细节，但是不能纠结与细节。这点其实不用上纲上线，写出来只是警醒一下我自己。

没开始写之前我觉得我想的挺明白的，可是写着写着发现这些话好像是直接对我微博上说的过的话进行总结与摘抄，然后再读一遍发现好像都是废话…..不过，好吧，也许最难做到的就是那些正确的废话了，我还是记录下来了，我会不时回头看看我走过的路我思考过的痕迹的

相关话题：产品经理源地址：http://www.ikent.me/blog/3019

精确到像素的Web设计

zhouwenqi — 2010-08-09 12:39:55

　　这句话不知道是不是我的原创（文字，不是理念），我以前经常讲，同时立即得到很多人的反对，认为这个观点不仅拖长设计周期，而且严重浪费成本，由于反对声太多太激烈，在加上有“导师”说：“很多人都反对你的观点就表示你错了”！而且我掌握的都是小规模团队和公司，他们注重的是效率尤其是股东放不开项目进度，我开始有点置疑这个观点，而且困扰了我好长一段时间，后来专门分析了一下，让我重新或更加坚决的坚持这个观点。

先看看是什么人在反对（非Web设计不纳入此列）：

1.没有UED团队（不包括曾经呆过UED团队的）的；
2.自己总是对的（包括在和队友合作中）；
3.广告、VI、产品或其它设计领域转过来做Web设计的；
4.不重视交互和视觉；
5.无法脱离“临慕”或“拿来主义”者。

排除自身能力之外，在主观上想做到精确到像素而受到外界约束占很大一部分，主要有下面几种：

1.受设计周期限制；
2.非团队主管（或上级）插足；
3.设计者情绪因素；
4.没有规划好；

上面这个列表我不是想说一定要做到精确到像素，因为这个确实和“环境”有关系，国内拥有专业UED团队的企业几呼个个都是先壮大企业本身实力之后才开始慢慢重视UCD（尽管他们一在强调：我们一直重视产品质量、用户体验...）具体不展开来说了...以上这些不是本文论述的主要部分。

随着众多成功的互联网企业、产品的崛起，UCD将被提高到一个新的台阶，UED团队工种将被分的更细化，同时将催生“更精致的Web产品”，精确到像素的Web产品将是一个趋势乃至必然。现在的团队中由于分工进一步细化，团队面临的问题也进一步体现出来，如交互设计师（或视觉设计师）在做出高保真原形后，再到前端开发那里，在UI细节上和布局上都和原型有所差距，比喻鼠标悬停效果没有设计、文字行高不匀称、图片有毛边、区块间距参差不齐等，这些都是细节问题，往往只差几个像素甚至1个像素，但足以影响整个UI的品质感，更重要的是工作效率也会受到影响，前端开发人员会停下来找交互和视觉师进行纠正，会发觉这个问题其实很快速的解决了，前面为什么没有顾及到呢？另外一个问题如果前端开发将这个细节问题向下遗留，后果不敢想象，这样做的大有人在，为什么前端那边要将问题遗留呢？

从几个方面来看这个问题（这里不谈技术原因）：

1.等待中的沟通。这个和上面下达的指令的强硬度有关，命令太死会分散团队协作能力让设计师处于完全属于“受指挥”状态，随着时间推移就会变成直接待命令，应付命令，这些细节往往就顾不上了，问题丢在前端这边时他们也不会主动和交互师去沟通了，而是往下遗留，所以无论规划的产物多完美，总会在传递过程中清耗一部分的，后端角色无法完整理解你的初衷。这里可以增加会议沟通来弥补一下，但一个会议怎样也不能够让所有人能够理解并且提出建议。所以必须主动沟通，而且要更开放鼓励这么做，沟通是互动的，不要等。

2.统一产品思想。成功有多种途径，漂亮的UI风格也是多样化的，没有哪一种色彩是最美的，因为色彩都美，在产品开始设计前，产品架构会给它一个定位，所以必须围绕这个产品定位去构思、设计、开发，不要参杂个人偏好。

3.规划不够详尽。架构师在规划时往往会露掉一些细节没有描述，例如：评论和是否采用Ajax实现？商品评分以矢量图还是图表还是数字等形式呈现？还有Banner的以何种方式切换？是局部还是整体切换？是采用FLASH还是脚本？等..这是无法避免的，这种漏洞应该只能遗留到交互师和视觉师这里就应该解决掉，传到前端开发或再往下就严重影响效率了，任何一个环节碰到类似问题都应该主动找上游沟通，一起商讨才能快速找到新的解决方案。

4.细节验证成熟。细节决定成败可能有点夸张，但细节体现一个产品是否成熟，细节可以验证一个UED团队的实力。

最后我想说的是：“我们都不希望在这些基础领域绕来绕去，但要提升必须得把细节做好，才有精力去创新去体验，在团队中好好做角色，好好做产品”。

源地址：http://www.zhouwenqi.com/blog/board_40.html

互联网产品的灰度发布

chuanliang — 2010-08-09 10:31:12

在传统软件产品发布过程中（例如微软的Windows 7的发布过程中），一般都会经历Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等几个阶段（参考Software release life cycle）。可以看出传统软件的发布阶段是从公司内部->外部小范围测试>外部大范围测试->正式发布，涉及的用户数也是逐步放量的过程。

在互联网产品的发布过程中也较多采用此种发布方式：产品的发布过程不是一蹴而就，而是逐步扩大使用用户的范围，从公司内部用户->忠诚度较高的种子用户->更大范围的活跃用户->所有用户。在此过程中，产品团队根据用户的反馈及时完善产品相关功能。此种发布方式，按照中国特色的叫法被冠以”灰度发布“、”灰度放量“、”分流发布“。

关于“灰度发布”叫法的来源无从考察。只不过按照中国传统哲学的说法来看，很符合中国人中庸的思维模式：自然界所有的事物总是以对称、互补、和谐的形式存在，例如黑与白、阴与阳、正与负、福与祸。在二元对立的元素间存在相互过渡的阶段，所谓”祸兮福所倚，福兮祸所伏“。具体到黑与白，在非黑即白中间还有中间色——灰色。于是出现了很多关于灰色的说法：灰盒测试，灰色管理（极力推荐任正非：管理的灰度），灰色收入，灰色地带等等。因此对于灰度发布实际上就是从不发布，然后逐渐过渡到正式发布的一个过程。

1、灰度发布的作用

及早获得用户的意见反馈，完善产品功能，提升产品质量
让用户参与产品测试，加强与用户互动
降低产品升级所影响的用户范围
。。。

2、灰度发布的步骤

1）、定义目标

2）、选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等

3）、筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等

4）、部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调

5）、发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

6）、产品完善

7）、新一轮灰度发布或完整发布

3、常见问题

3.1）、以偏概全

1)、问题特征：

a、选择的样本不具有代表性；

b、样本具有代表性，但选择样本用户使用习惯并没有涵盖所有核心功能
2）、解决方案：

样本选择要多样化，样本的组合涵盖大部分核心功能

3.2）、知识的诅咒

”知识的诅咒“的说法来自《粘住》中实验，具体可以自己搜索一下。我们自己对于自己开发的产品极为熟悉，于是乎想当然认为用户也应当能够理解产品的设计思路、产品的功能使用。

1）、问题特征：

a、结果没有量化手段；

b、只依赖于用户问卷调查；

c、没有web analytics系统；

d、运营数据不全面，只有核心业务指标（例如交易量），没有用户体验指标

               e、对结果分析，只选择对发布有利的信息，对其他视而不见
          2）、解决方案：
               a、产品设计考虑产品量化指标
               b、结果分析依据量化指标而不是感觉

3.3）、发布没有回头路可走

1）、问题特征：

a、新旧系统用户使用习惯差异太大，没有兼容原有功能

b、新旧系统由于功能差异太大，无法并行运行，只能强制升级

c、新系统只是实现了旧系统部分功能，用户要完整使用所有功能，要在在新旧系统切换

d、新旧系统数据库数据结构差异太大，无法并行运行

2）、解决方案：

前期产品策划重点考虑这些问题，包括：

回滚方案、新旧系统兼容方案、用户体验的一致性、用户使用习惯的延续性、新旧系统数据模型兼容性

3.4）、用户参与度不够

1）、问题特征：

                 a、指望用户自己去挖掘所有功能。对于一个产品，大部分用户经常只使用部分功能，用户大部分也很懒惰，不会主动去挖掘产品功能
                 b、互动渠道单一
                 c、陷入“知识的诅咒”，不尊重参与用户意见
        2）、解决方案：
                a、善待吃螃蟹的样本用户，包括给予参与测试的用户小奖励（例如MS给参与Win7测试用户正版License）、给用户冠以title
                b、通过邮件、论坛、社区、Blog、Twitter等新媒体与用户形成互动
                c、提供产品功能向导。在hotmail最近的升级后的功能tip，gmail的tip都有类似的产品功能导向。在产品中会提示类似于：你知道吗，xx还提供xx功能，通过它你可以xx 。

4、灰度发布 VS. A/B测试

灰度发布于互联网公司常用A/B测试似乎比较类似，老外似乎并没有所谓的灰度发布的概念。按照wikipedia中对A/B测试的定义，A/B测试又叫：A/B/N Testing、Multivariate Testing，因此本质上灰度测试可以算作A/B测试的一种特例。只不过为了术语上不至于等同搞混淆，谈谈自己理解的两者的差异。

灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量

A/B测试重点是在几种方案中选择最优方案

关于A/B测试可以参考这篇文章：A/B测试终极指南

5、灰度发布引擎

对于一般的小系统并不需要单独的灰度发布引擎，可以参考A/B测试中做法，在页面javascript或服务器端实现分流的规则即可。但对于大型的互联网应用而言，单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式提到了原来阿里软件所使用的灰度发布引擎，设计思路具有普遍性，可以供参考

6、参考文档

让前端忍不住喊爽的设计元素

陈成 — 2010-08-07 15:28:19

(此文目标对象为：设计师)

现状

视觉效果太复杂，前端一看就傻眼了，实现成本太大；
界面太简陋，仅采用一些简单元素比如直角、实色填充等实现设计。

其实可以尽情地使用这些设计元素

水平或垂直的线性渐变
箭头及各种箭头的变型
单像素圆角
简单阴影
半透明背景

以上这些设计元素对于前端实现来说有个相同的特点：即可以通过添加少量标签或完全利用CSS特性完成，实现成本和后期维护成本低，扩展性高，且不需要任何图片。图片对前端来说就是个难搞的事情，尤其是现在关注性能的同学还需要进行sprites合并。(真的，我宁愿多加几个tag，也不愿多加一张图片)

如果您认可优雅降级，还可针对高级浏览器选择以下设计元素

当然，IE用户是看不到的。

圆角
复杂的阴影
文字阴影

此外，设计师们还可以为Chrome、Safari浏览器设计一些小动画，比如鼠标移上去icon旋转下之类的。

只有让设计师更了解前端，才能实现设计效果和前端开发成本的双赢。

欢迎补充。

源地址：http://www.chencheng.org/blog/2010/08/04/cool-design-elements/

读UCD火花集（二）

deadpoet — 2010-08-07 13:01:22

经历了连续数天接近40度的烘烤后，上帝他老人家大概也实在不忍心，飘过一场雨，再吹起一阵风，突然半夜气温降到30度。这两天醒来突然觉得能一觉睡上6个小时的日子真是久违了，感慨良多不禁潸然泪下（这十个字纯属虚构）。白天去麦当劳叔叔家蹭空调，晚上回来和火辣的笔记本（It is really really hot, physically）一起低效思考，迟钝了两天，终于将这篇文章结束。感谢各位前面的留言，我也将一一回复。

（ps，我是用OpenOffice写完文章粘贴上来，格式上似乎有问题，如果引起阅读不便，我在这里表示歉意，我会想办法解决这个问题）

继续谈UCD火花集这本书吧。

第一章题为“用户体验设计在团队中”，4篇文章组成。在这里小结一下（别担心，这里只谈第一章，虽然依然很长一篇，对不住各位了）：

第一篇：UED——鱼缸里的水（文/Moond）

我对鱼缸、鱼、水的比喻是有保留看法的，不过说实话我也想不出有什么更好的比喻，加上明了作者之意，先认可之，待想到了再来挑战，哈哈:) 好了，收起下巴，接着说，文章开篇提到这样一段引言：

好的设计是让用户体会不到设计的存在。

这句话我在英国读书时也听到过类似的说法，大概是在讨论网站导航时，即真正优秀的导航是存在于用户意识之外的，如果用户意识到自己在思考你所做的导航，那么就是设计上出问题了，当然导航也直接反应了信息架构的合理性，这个以后有适当的例子再讨论了，我还是别把话题岔开到导航设计上去。直白的说，就是那句：Don't make me think。

提到这句引言，是因为作者提到了“潜性”这个我从未听过，但觉得不错的词。我自己所谓的ambient design其实也沿袭同样的思路，而这思路总让我想起一句诗：“随风潜入夜，润物细无声”。设计或许就是一个“润物”的过程，能做到“细无声”是对用户真正的理解和体会。

说到这里想调侃几句“设计”这个词。某天晚上躺在床上时，脑海里把这词拆开了再放到一起，觉得意思怎么变了？诸葛亮、司马懿、曹操还有那谁的一股脑全涌进脑海里了。想想看，诸葛亮最擅长干啥？设-计...年轻时刚就业进入工作岗位就设了火烧博望坡一计，逐渐成名时设了草船借箭一计，职业生涯高峰开始走下坡路时设了空城计，辫子一翘还要设个“诈尸计”。司马懿，曹操这些同志呢，就负责专门吃计，或者叫做“被设计”。而什么才是好计呢？对方意识不到的就是好计，按Moond的话，叫有潜性的计，按我的想法，那是ambient计，对方意识到了，比如蒋干要设周瑜一计，要么你“一计不成再生一计”，要么人家就“将计就计”了。从某种角度来说，如果诸葛亮是设-计-师，那么司马懿、曹操同志就是该是用户了。不过这实在不是什么好对比，我们需要站在用户角度为用户着想，而诸葛亮要是替曹操着想，这三国该好看了。

抱歉，三国意识流刚刚经过，回到正题。

低调的概念传播特性

我记得听过这样一个故事，在法国，为了开一场时装发布会，所有模特、化妆、布景、音响、设计师等等工作人员要在场地一起工作生活上很长一段时间，为的是让每个岗位上的每个人都能理解、沉浸到设计师创作的灵感与氛围当中，在每个细节上都能贯穿设计师的思想。我认为UCD也是如此，它不专属于交互设计师或者用户体验设计师，而是整个团队的每个成员需要秉持的一种理念，这样每个职位上的决策、相互合作甚至博弈的过程中，都有一条基线（baseline）去贯穿始终——用户，所谓以用户为中心的思想才能渗透并表现在产品的每个细节中去。虽然我认为自己在思路上和作者是一致的，但我对作者所用“低调”这个词很挣扎，尽管文章从用户和团队两方面作出了诠释。这可能是我的老毛病：学习使用定性分析里的Grounded Theory后，特别是做过coding（此coding非programming的coding）的人，我估计都极端容易“咬文嚼字”以期发掘用词背后的含义，加上我父亲又是个多年的连标点符号都不放过的老编辑，好听点叫耳濡目染，难听点小学时的咱作文还没交给老师，就得先一个标点一个标点改上几遍...无论如何，我最终还是被这个词困扰而无法释然。

能给我点例子吗？

对于用户——用户体验设计帮助分析和挖掘用户潜意识的需求和习性，力求产品设计给用户带来本质上的满足，以及顺畅自然的使用体验。

这句话太“概念化”，什么叫做“本质上的满足”？什么叫做“顺畅自然的使用体验”？它们是两个方面？是两个阶段？或是两种不同的表现形式？记住这些，依然不能帮助我解决实际可能遇到的情况，既不是guideline也不是use case，理念上咱们一致，其实我需要的是个简单的实例可以举一反三吧。

用户需求会根据外在因素而改变。

这些外在因素有哪些？用户体验设计随之调整会涉及什么？说实话，用“常换水”来比喻可能形象，可实在没有方便理解。依然，一个实际例子或许能让愚钝的我：“哦！“。

用户需求会根据外在因素而改变，商业目标会因为市场需求而转型。

呃...用户需求，市场需求，区别是？还请指点。

第二篇：接过用户的绣球（文/Angela）

这篇文章本身我没有太多想法，但谈到国内外交互体验设计者“出身”的不同时，让我想到这么几点：

设计研究与创新。唐老爷子在今年5月份Design Research大会上做了一篇继续引起争议的presentation（长度大约40分钟，建议观看，虽然是英文，但Don的发音很清晰，语速也较慢），在这篇presentation中，Don将创新划分为incremental（渐进）和radical（激进）两种。技术的革新带来激进创新，而UCD带来的是渐进创新。大家都希望能够激进创新，成为下一个Google，iPhone，Twitter，影响人类，改变世界，然而这是很少能够发生的事情。按照Don的说法，99.9%的创新都是渐进的。虽然看起来没有技术革新带来的改变那么光鲜，但对产品，对人们日常生活依然非常重要的，至于为什么重要？没说，不过想想身边的实例，你最常去的网站在细节上的改进，更新的生活用品，我想还是可以体会到一些。

UCD是万能的吗？Don也再次谈到他的经历：Don当年在低谷中的苹果做用户研究。Jobs一出山，撤掉了用户研究部门，赶走了Don一干人等。结果？自然是讽刺，更好的产品出世了。我在英国时，教授UCD的老师也提到过这件事，同时和我们说，UCD是一种belief，你可以创造很好的产品而完全不遵循UCD思想（苹果为例），你也可能遵循UCD思想却无法得到好的结果。经典的一句话来自亨利福特（Henry Ford）：如果我去问人们他们想要什么？他们会说更快的马（If I had asked people what they wanted, they would have said faster horses）。经常会有文章拿这句话来讽刺用户研究的无效，“用户不知道他们想要什么”，或者“我就是用户”（这个观点想多说两句，留待以后吧）。

我认为福特的例子一方面符合Don对创新的划分，如果是技术革新带来的创新，普通人自然不知道将要面对的是什么，也不知道自己想要什么，97年大家在Yahoo的category里翻信息时，你说我要搜索整个互联网？06年大家写博客时，你说我要microblogging？好吧，你是神人我崇拜；然而，更重要的另一方面，从理解用户来说，亨利福特的这句话其实说明了他对用户深层次需求的理解：Faster! 更快的速度（当然还包括可负担的价格，这里Horse其实就隐含了这点，那时汽车已经有了，只不过一般人根本负担不起）。而对技术的敏感与理解也使他能够通过技术革新带来的机遇满足了人们这一需求。你可能会说这福特又不是交互设计师，可不，他老人家出道时还没这概念，交互设计依然是个在不断摸索的新兴领域，它在不同企业中的位置也会各异，我这里确实可能更多的是在谈“交互设计师”自身的修炼，这种修炼并不一定直接应用于设计工作任务中，但前面的文章我也谈到，交互设计是个多学科综合领域，我们很难精通于所有领域，所以更需要团队其它角色的支持，而这些修炼在我“臆想”中应该能够使我们更好的与其它角色交流，更好地彼此理解，也能更好的发挥各自所长，我们不是福特，不是乔布斯（这一点你还真别不服气），但UCD给予我们思路与系统的方法去理解用户各层次的需求，运用的好，我们依然可以设计出优秀的产品，虽然不一定是划时代，惊天地泣鬼神之作。

中国的一句老话叫师傅引进门，修行在个人，对于UCD，我想各位知道我的意思了。说到这里，还是想强调，我只是根据自身有限的经历谈谈对交互设计、UCD的见解，对我来说还有很长的路在这一领域修炼，特别是进入业界的磨砺。现在的很多想法恐怕还很粗浅，如果能引起你的思考与讨论，我非常期待你的分享与批评。

交互设计与技术。在我这个还未挤进业界的新人的概念里，做交互设计是需要对现行以及新生技术有相当敏感和基本特性的理解的。原谅我，出于对自己的极端偏袒与自恋（此评价纯属虚构，I hope...），举一个我自己参与的，缺乏实际证明的例子：

我在学习UCD时，有这样一个课程设计，因为身处英国的一座旅游小城，主题定位iPhone上的旅游导航服务。需要我们每个小组：1，设计用户调查问题，亲自去市中心随机访问游客；2，对调查进行分析进行“头脑风暴”，创造应用的Metaphor，接着制作两个Persona，和对应的Scenario；3，制作prototype，方法不限，我们使用了两种：low-fidelity（低仿真）的paper prototype（大家一起画...）和high-fidelity（高仿真）的VB程序（模板、图标我来收集并GIMP<也就是Linux上的PS>，程序是同组的巴基斯坦兄弟写的）；4，小组间的presentation和critique。

我们小组由四个人组成，两个来自人机交互（我和另外一个英国人），两个来自IT（一个中国人和一个巴基斯坦人）。具体过程这里略过，主要说说我给这个iPhone应用定的主题：通过调查我们发现传统的“导航服务”其实并不是城里游客需要的（出于景点集中在市中心，小城规模不大，来之前已在网上做了充分的功课等等原因），于是我在小组交流邮件里提议变更应用的主题，思路是这样：

既然assist不能满足用户，那么我们就promote他们。用户进入应用，选择他当天感兴趣的景点，应用生成一条路线（到这里都还相当传统），其后的思路是，以故事情节为主线，让游客沿着线路“探险”，而不是观光。什么意思呢？我们的应用要和沿途的博物馆、酒吧、古玩店、视频点、餐厅等等合作，游客每到达一个指定的地点，我们的应用都给用户讲一个与地点相关的古老的故事（灵感来自英国每个城镇几乎都有的Ghost Walk，这个是伦敦的Ghost Walk。ps，这网站很垃圾），博物馆等地点的负责人员也会给他一个认证码，或者是我们的应用提出的谜语、问题的答案，输入正确后证明到达指定地点，见到关键人物，找到关键“证据”，这样一路下来，如果他进入酒吧，则向老板展示他先前过关斩将的成果，老板认可后，提供独家免费啤酒，他还可以享受特价午餐等等，这样直到终点时，旅游部门颁发给他一枚“勋章”或者证书表彰他的“探险精神”。当然，这个也有级别，完成一条路线那是初出茅庐，等到路线全被某神人走完了，专家级（如果你如我还在看火影，我把这种人叫做九尾级），颁发的勋章自然是一级比一级耀眼（ps，我是热诚的背包文化支持者，徒步、单车旅行支持者，所以思路上也...）。课程设计虽然就此结束，后续还是有很多想法，比如推广到其它城市，用户参与设计路线，跨城市路线等等，当时甚至想到“追寻马可波罗的足迹”，“西游记”，“80天环游世界”等等线路...这属于我间歇性自娱自乐的狂想症，就此打住。

这是在08年末的思路，很明显，如果你关注LBS（Location Based Service）发展，在见识了Foursquare的“chekin”以及badge后，我想你也知道这个思路后来在我的脑海里进行了怎样的调整，指定地点不再需要专人，社会化网络会自动将你的成就与好友，甚至地理位置临近的其它“探险者”分享，这里就不是什么Foursquare里major的问题了（市长一般都很衰，谁愿意当...），你到时基本上就是与徐霞客，Sir Robin Knox-Johnston真正的冒险家为伍了...

抱歉，说过头了，举这个例子，是想说，技术的更新，会改变交互模式，或许非常细微而不会使产品思路完全改变，但需要第一时间意识到它对你的产品的影响。不说领导，至少需要赶上其它竞争或相关产品在细节上带来的用户体验基线的提升。

一个熟悉、简单而且更实际的例子就是Ajax的引入对Form验证的影响了：曾经输入错误后会非常习惯于一个弹出窗口警告你（如果你有把JS禁掉的习惯，那我就无话可说了），如果现在依然经历这样的窗口，而不是悄悄出现在输入框旁边那红色的提示文字，简直会让我咬牙切齿，如同巴里摩尔在Donnie Darko里放声的一吼：F**K！这就是我所谓细节上用户体验基线的提升，如果你不跟上，那么你的交互设计也就从过去的正面滑向负面。交互功能是建立在技术基础上的，技术不仅是开发人员，也是交互设计的粮食，吃饱吃好了，才好帮用户把活干得更好嘛（这比喻太烂，好像咱们一群佃农，用户一群地主）。

（08年的那个课程设计现在回头想来还包括Don在那段Presentation里谈到的：meaning shift，我曾经私下访问过买了iPhone一个英国同学，他的想法是，iPhone对他来说是computer， meaning shift。这个算这篇文章的题外话，有机会再谈到吧。）

后面两篇文章谈到团队组成、管理和PM（Project Manager，项目经理）与用户体验的关系，对我来说虽然学生时代做过大小项目，也担当过不同职责，但都不属于严格意义上的工业级别，更没有机会以交互设计或用户研究的身份参加正式的团队开发；加上这两位作者的文章基本都属于多年项目的经验之谈，逻辑和行文在我看来又相当有条理，基本我在看到他们（再加上千鸟先生）的文章时，只能惭愧自己经历浅薄有限，难以加以评论，剩下我只有拜读和牢记经验之份了。说来PM这个角色也越来越令我“好奇”，读完白鸦先生的文章后遗留的一个主要问题就是，PM的职责究竟是什么？最近千鸟先生也写了两篇文章（这里，和这里）谈到这个，海外也有若干文章谈及（比如这里，这里，和这里）。如果你是一位PM，这些文章或许值得一看。以后有机会与PM共事、交流的话，让我再继续这个话题吧。