UCDIn

本文想说的事情是，那个叫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是最好的方式。

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

原文链接：http://www.ikent.me/blog/3042 ，作者：kent.zhu

在足球场有那么一群人，他们凶狠的拼抢不断的传球、他们思维敏捷视野开阔、因为处于兵家必争之地所以往往血溅当场、他们是球场上的发动机，控制着全场的节奏、他们调配团队的资源，把球精准的传送到最有机会的队友脚下，这群人就是中场核心，西班牙的中场核心，大师级人物—哈维。

在现今的互联网行业中也有这样一群人，他们被称为“产品经理”。

互联网并不像世界杯具有80年的历史，所以团队中的人员分工和定位相对模糊。特别是近几年才在互联网出现的产品经理这个工种，已经有越来越多的人参与到讨论产品经理的核心技能、核心职能、核心价值是什么的问题中来。

在此，仅和大家讨论一下产品经理的核心价值，我想，只要认清了自身的价值所在，其他的迎刃而解，或者根本无需解。不管黑猫白猫只要能抓到老鼠就是好猫，无论你用什么方法、无论你是否有职权。

此文较长，看完估计得15分钟。

用了大量的内容来把产品经理的核心价值一层一层的剥开。

首先，整理一下互联网中的产品生命周期都会经历哪几个阶段。

需求收集、设计规划、开发、上线、运营推广或者市场销售、在市场和运营过程中产生新的需求、新功能的设计规划、开发、上线…… 一直迭代下去。“产品经理往往需要贯穿在产品生命周期的这整个流程中。”这是现在很多产品经理的理想。

好的，我们继续往下剥。将产品的每个阶段逐个分解，看看产品经理在这个过程中所起的作用。这是很重要的一步，所以我会说的尽量详细。

一、需求分析

在这一步，很多的产品经理花大量的精力去承担文案撰写的角色，这是误区！因为还有更重要的事情需要产品经理在这个时候去做。

1、了解公司的战略目的

也许“战略”这个词有点冠冕堂皇，可是产品的未来与这一步息息相关，所以不妨提到这个高度来讲。以我的经验，互联网公司要推出一款产品的动机大致四种

A复制：看到市场上同类的产品比较成功，结合自身的资源觉得可以效仿。对于这类产品公司仅能看到眼前利益，远景不明朗，需要一边做一边调整，结果多数是大起大落。例如最近狂热的团购。

B干扰：商场如战场，很多企业会玩声东击西的策略，用一些无关痛痒的产品吸引竞争对手的注意，以欺骗或者干扰对手的注意力，掩护自己的核心业务平稳的发展。此类产品往往成为炮灰。

C打圆场：对于上市公司而言，为了给资本市场一个好看的答卷，经常会用一些莫名其妙的产品来滥竽充数，虽然对用户和行业没有任何意义，但是可以让股东和股民看到企业的产业链条是圆满的。此类产品多数是企业的纯消耗品，因为没有实际的盈利模式，所以都是其他产品在养着他，其结果是没有地位。

D战略性产品：很多互联网企业从大众市场纷纷开始进入细分市场，这就要求企业敢于创新，在创新的过程中往往伴随着很多改革，企业会从新定义市场、制定新的目标，推出新的产品，希望改变现有的盈利模式和业务框架、市场格局。这便有了所谓的战略性产品，例如腾讯的拍拍、百度的有啊、新浪的博客、阿里的支付宝，其中有的成功、有的还不明朗，这也正是此类产品的特性。创新和改革的路上异常艰难，很可能这个产品与现有的很多业务冲突、与现有的部门利益不协调。而且企业不会像中央政府那样搞十一五计划给你5年时间，也许你只有半年，所以这要求产品经理要具有很强的把控能力和坚强的毅力。

作为产品经理只有去了解这些才能预想到今后的工作中可能遇到的问题、可能争取到在资源、可能投入的精力、可能组建的团队规模、可能遇到的瓶颈和坎坷，未雨绸缪才成为可能。

所以，不建议一开始就埋头设计精美的PPT、华丽的demo，应该去了解公司做这个产品的目的和动机。

2、了解市场需求

这里也有个误区，很多产品经理通过所谓专业的分析方法例如swot和大量的百度搜出来的数据做出来一个东西，就算交差了。而很少去考虑为什么要去做市场分析，如果我们每天把很多时间花在应付那些不知道为什么做而做的事情上，将很容易被淘汰。

我认为的目的有三个

A、试探自己的思路与公司的思路是否有偏差，适当的在公司原有的想法上做扩展，加大公司对产品的兴趣。

B、给相关部门吹风，特别是业务团队和运营团队，他们手上正在卖或者正在推的产品可能有很多，你的产品市场优势在哪里？也许不能让他们马上兴奋起来，但是至少应该让他们关注或者积极的反馈意见。

C、自我梳理，写的过程就是想的过程，想的过程就是辩证的过程，很多思路会在写的过程中迸发出来。

所以，市场分析可以包含以下内容：产品对于行业的价值、在市场发展的环境下产品可能的生存空间、产品在市场价值链中所处的环节、预期的市场回报。

关于用户需求这里就不多说了，有很多这方面的文章。

到这里，需求分析阶段算是尾声了，总的来说，产品经理在这个阶段最大的意义就是给产品建立意识形态，有点类似军队出征前的誓师大会，虽然很虚，但是对将来的工作很有帮助。

二、设计规划阶段

在这个阶段，开始有越来越多实在的交付物出来，例如：产品规划方案、产品demo、需求文档等等。

1、产品规划方案

无论这个方案是不是由产品经理本人来做，产品经理都应该要求这个规划方案中说明白几个问题：

（为什么做）产品背景和需求说明
（做成怎样）功能说明
（如何实施）里程碑和时间计划
（回报）投入和产出比
（如何经营）运营策略
这是产品从虚到实一个很重要的过渡，把之前天花乱坠的产品思路通过这个方案告诉大家如何实现，并且是有计划有里程碑式的实施。

如果把产品经理比喻为一枚陀螺，这个方案BOSS拍板的一刹那将成为陀螺的分水岭，在这之前鞭子缠绕着陀螺在蓄力，拍板声一响鞭子猛的抽开，产品经理就开始疯狂的忙开了。

2、产品demo

有了需求，自然就有了功能，各种功能组合生产了功能模块，功能模块就搭建起一个产品的框架，在这个产品框架下有哪些系统提供支持，最终画出产品大概的样子。于是功能模块、产品框架、系统架构、低保真原形打包起来就生成了一个产品demo。

产品经理可以拿着产品demo去评审验证了。听取交互设计师的意见、听取视觉设计师的意见、听取前端工程师的意见、听取开发工程师的意见、听取业务和市场的意见、听取用户的意见，陀螺陀螺疯狂转吧！

如果你发现这群鸟人，之前鸦雀无声，现在忽然噼里啪啦的开始拍砖，不要觉得奇怪。眼见为实，大家只有看到你产品的样子才能发表各种意见，而且这些意见还多数是在抠细节。听取意见的过程中，产品经理不会忙于辩解，思维像陀螺似的转起来，意见是否采纳，更多的决定权还在于产品经理，所以你要能够识别各种意见的出发点。有的人会从专业角度、有的人会用改变功能实现方法减少自己的工作量、有的人会站的自身利益的角度、有的人会站在伪用户的角度。如果你应付不来，可以把大家的意见记下来，回去好好的考虑。如果一些问题非得会上就定结果，先明确轻重缓急，实在不行就中场休息借机场外求助。陀螺陀螺效率的转起来吧！

关于需求文档，这个就不用说了吧！

在这个阶段，产品经理除了协调各方，还应该想办法建立一种沟通机制，让团队高效的工作。在很多互联网企业，产品是没有独立团队的，都是线条式的贯彻在各部门。

三、开发阶段

这里的开发是广义的，包括UI设计、前端制作、程序编写、运维支持

这阶段提几个建议：

做设计和开发的都不是好惹的鸟，要么极具个性、要么孤傲、要么执拗。其实这和他们的工作性质有关，创意是需要时间和空间的，建议产品经理们能尽量的满足他们，也许时间是公司敲定的，但是一个良好的发挥空间还是可以提供的。在上面说的广义开发过程中，产品经理往往会遇到很多新的需求，要么是BOSS直接发话、要么是市场部门临时兴起、要么是产品经理自己遗漏。怎么办？要不要加进去？衡量一下吧，如果是影响到核心功能的可以加，如果是边缘化的东西建议放在第二版再加，否则有新的需求就加，这个产品很难在原定计划上线，而且干扰了开发人员的发挥空间，好不容易安下心来思考，又忽然来了新的需求要做，谁都不乐意的，何必呢？相互多一点理解，就少很多抱怨的。

人无完人，没有哪个产品经理能把产品的方方面面想到100%的程度，所以开发过程中，开发人员会有很多问题需要确认，这些问题需求文档里面被遗漏了，所以产品经理需要留有足够的时间给开发人员，如果自己很忙也需要安排一个专人负责协调。

此时沟通的事情占用产品经理的时间不多，所以可以开始花时间考虑产品相关的文案了，这部分我在之前的文章《构建完善的互联网产品文案体系》中有讲到。这个体系的内容如下：

产品上线之后再做就耽误了，也许这些文案不用产品经理本人来做，但是需要把你的想法和对产品的理解灌输给做事的人。不是所有产品都需要这些文案，相信大家能区分。

四、测试阶段

相信有很多互联网公司没有专门的测试团队（QA），甚至忽略了测试这个环节，所以更多是要求产品经理在短时间内协调分工来完成。问题就产生了，没有专业的团队所以测试的结果可能会有遗漏、测试的周期很短所以有的问题即使发现了也需要放到产品上线后解决，这些仍然需要产品经理来协调和分工。

不要抱怨了，把精力放在解决问题上。这里有几点建议：

A、让自己专业起来：在没有专业的测试队伍之前，产品经理就是最专业的测试人员，只有这样要求自己，上线的产品才能做到尽量完善。

产品的测试包含三个重要的环节—功能测试、性能测试、用户测试

功能测试的内容有很多，曾经在某集团任职的时候，公司推出一个SNS社区，其中测试用例一共7130个，QA部门至少需要测试7130个功能点。朋友们可能很疑惑，觉得怎么会有怎么多的功能点需要测试呢？这里截个图了解一下专业测试团队是怎样测试的，特别是对每个测试用例的描述。

虽然专业，但是仍然无法避免问题的出现，所以微软的团队也在不断的在给产品打补丁。提这个的用意在于，不要因为测试的问题成为产品发展的牵绊。作为产品经理仅需要在五个方面做功能测试就差不多了：

A功能流程：根据之前定义的功能模块，以模块为单位分担出去，分担给谁？部门总会有些机动的人，如果没有可以找前端或者UI，引导他们在测试样式和界面展现的时候以功能操作为前提。系统的流程就不多说了，一个功能从头到位走一遍。
B前端与数据库响应：在我们的影响中，一定能够找出数据存储量最大最频繁的功能点，例如个人空间的日志、相册、视频、签名、好友动态等等。测试的时候需要做的仅是操作界面发布看看前端页面是否及时响应，如果之前要求的是同步，测试的时候发现延迟5分钟，说明前端提出数据的时候出现问题。
C浏览器兼容：万恶的浏览器，没有更好的办法，一个一个测吧，可以交给前端开发去测，谁希望自己辛苦做出来的页面用户看到是变形的呢？
D系统规则和机制：在产品设计的过程中，会有很多的规则和机制穿插其中，例如排序规则、录入和显示的字段最大长度、用户的积分经验值等等。注册几个账号开始模拟用户的角色测试吧。
E模拟用户角色：这里的用户是虚拟的，我们只需要关注其是否能达到目的，暂不去考虑过程的体验。

性能的测试，需要产品经理预估一个用户的峰值，然后可以让开发人员去做评估，看看在这个可能的峰值下系统是否还能正常稳定的运行。

用户测试不细讲，网上有很多相关文章。

在一个月黑风高的深夜，产品上线了！有的人告一段落、有的人兜里揣着项目奖血拼去了、有的人休假旅游，唯独有一个人，产品上线对他来说仅仅只是开始，他需要从一个战场转移到另一个战场，这个人就是产品经理。

这里出现了第二个分水岭，有的产品经理会在这里停下，回头负责另一个新的产品。而对于另一部分产品经理来说，公司给他制定的KPI不仅仅只是产品上线，还可能是诸如用户量、活跃度、信息量、转化率、购买率、续费率等等被量化的数据。所以这也成为产品经理积极讨论的问题。因为产品经理被细分了

A、规划型产品经理：只负责产品前期的规划，然后把规划交给需求部门梳理，完事！这类产品经理表达能力很强，无论是语言还是文字图表。但是因为无法参与产品核心的设计，所以往往成为BOSS的代言人。

B、需求型产品经理：更多的负责收集和处理各方面的需求，并且从设计和开发角将讲需求转化为需求文档，完事！这类产品经理协调能力很强，往往能成为产品对外沟通的枢纽。但是因为没有深入到产品的业务和市场方面，所以在需求的权重排列上会很踌躇和痛苦，往往成为背黑锅的人。

C、设计型产品经理：更多的负责产品的可视化设计，例如产品demo、交互设计甚至是UI设计等等，完事！这类产品经理善于把握细节，而且思维活跃。但是往往因为太注重细节和完美，导致很多想法被强势的业务和市场团队压制，很多想法无法实现，非常痛苦和挫败。

D、市场型产品经理：主要负责产品在市场环境下的运作，承担了大量的市场指标。这类产品经理拥有很强的市场嗅觉，而且市场资源丰富，产品上线之后交付给他们打理。但是因为此类产品经理在前期很少参与产品的设计和规划，所以其对产品的理念以及卖点与产品初衷会有偏差，而且会出现利益为先的情况，影响到产品长远的发展。如果此类产品经理把控能力不强，很容易出现产品频繁的调整方向，最终被其他业务合并或者被公司搁置。

从产品经理的分类来看，要找到产品经理准确的定位和定义，并赋予其核心价值真的不是容易的事情，何况每个企业都有自身的特点和组织架构。

我们把思路拉回来。产品上线以后就到了第五个阶段

五：运营和市场销售

我经常把运营分为四大块内容：

A、产品包装：产品要面向市场，就需要做包装，例如建一个网上展台（产品专题）阿里的诚信通 263的企业邮箱 腾讯儿童频道。除了这些还有宣传材料（宣传彩页、海报、易拉宝）和公关软文。

B、对外合作：包括推广合作、数据对接、功能整合、利益分配

C、公关推广：媒体互换、寻找G点（市场的兴奋点）

D、策划活动：会议营销、网民线下活动

以上这些工作，也许不需要产品经理本人去实施，但是必须产品经理提出来，并辅助具体实施的人完成。

不是所有产品都有市场销售行为，因为有的产品更多的是支持核心的业务发展，例如论坛、公司内部OA、统计系统、CMS系统等等，但是对于业务要往外出售的产品来说，市场销售这个环节产品经理至关重要，有很多事情值得做。

A、植入业务体系：很多企业的业务体系并非只销售你这一个产品，所以如果利益关系不处理好，很容易出现好产品没人卖的现象。例如：公司给销售员的考核时每月30万，也许你的产品定价5000而且属于年费，而销售员卖一个广告售价10万，那么对于他们来说要完成本月业绩是去强攻3个广告还是卖60个你的产品呢？答案很显然。所以产品经理必须努力的推动产品最终深入到业务体系中去，调整产品的提成也好，捆绑打包也罢，总之好产品是卖出来的，而绝非设计出来的。

B、协同作战：与业务体系一起，找出产品的卖点，包括产品销售过程中的一些话术、容易遇到的问题、客户对产品的兴奋点，都需要产品经理去发现，并且努力做到可复制性。

C、参与制定产品定价：产品的价格能不能根据不同的客户类型进行分档，分档的依据是什么？功能如何区别？

D、建立市场需求反馈通道：市场需求的反馈有通道么？畅通么？如何应对这些需求？是定期和销售员沟通还是参与市场行为？如何识别哪些是客户的需求、哪些是销售员从自身利益出发的需求？

陀螺陀螺转啊转！

对于产品经理的核心价值，在这个层面我们剥了很多内容，朋友们是否隐约感觉到了产品经理核心价值所在？如果还不能确定咱们继续剥。

说完了产品生命周期中的几个阶段，现在提一下产品经理在这个周期中所要沟通的对象，关于这方面我在《产品经理的前世今生》一文中有较详细的说明。这里仅用一个图来说明

蓝色的线条代表了产品经理需要沟通的对象。这也是产品经理核心价值的一部分。

现在咱们回顾一下，产品经理在产品的整个生命周期中其实就做两件事情。

第一件事情是“合”：表现为收集各方面的想法、需求、资源、工作内容和节点

第二件事情是“分”：产品可能涉及到的部门和角落通过产品经理这根导管精准顺畅的传输出去，传输的对象可以是各部门、市场、用户、合作伙伴等等

“价值产生于合，能量释放于分。”这便是通篇所阐述的观点！

不要再纠结下面这张图了

原文链接：http://www.pmday.com/archives/300 ，作者：思域

自从说了“不应该有“用户体验设计”这个说法之后”（链接），又看到不少人在讨论产品经理、交互设计、用户体验这些分工之间的协作问题。刚好，前些天帮某中小型公司提了个“产品中心”的配备方案。晒出来，且作为我对 于产品、设计、体验之间的看法。欢迎讨论，不欢迎挑刺。

HI，all

对于这个“产品中心”，我的这个想法有几个基础前提如下：

0、以下观点仅针对我所看到的“大部分”企业，是否适用尚未可知。
1、不应有专门的“UED”部门，设计和产品要放到一起。
2、我心目中的PM是“产品市场经理”，除了产品还应该考虑产品运营和产品体验。项目经理应该定义成PM在某个阶段的助手。
3、PM的定位和能力，根据企业和产品的模式不同，应该有所偏重。比如，百度是偏体验的、淘宝是偏运营的、阿里B2B是偏销售的，Google是偏协调 的。
4、PM应该决策该产品的所有事宜，因为他要承担产品的所有责任。但不是自己亲手做所有事情。当然，更应该充分尊重其他角色领域的专业意见。
5、交互设计和产品设计根本撤不清，所以就别指望撤清，我们往往说“多沟通”就能解决，其实是在避重就轻的扯蛋。
6、类似文案设计的工作不应该列专门的部门，而是谁做的产品谁负责，谁写的文字谁负责。但，需要有角色去倡导、协调、管理所有文案的统一气质和质量。
7、必须要有一个“架构师”，来负责协调所有产品之间的关系，和统一风格。
…………………………..

岗位和职责

1、产品架构师/首席产品设计师：负责整体产品的架构设计和管理、通用规则管理。
1.1，架构设计和管理是一个很见功底的活，需要有耐心培养，更需要赋予足够大的权利和义务。
1.2，对于偏“体验”的产品，通用的呈现层规则必须文档化管理起来。所谓的“通用规则”，主要指：信息架构、页面结构、交互规则、文案规则、视觉规则。 原则上，并不是要他来整理或者设计这些通用的东西，而是需要归档到他这里来管理，原则性的变更必须经过其同意。（当然，其实也可以把视觉、交互、文案交给 这些角色中的“组长”或者“首席”。）
1.3，另，产品架构师最好只有一个，同时设一个助理。一来事情多，二来需要有后续的架构师储备。当架构师流失的时候，对企业会是灾难性的事情。

2、 用户研究组：协助PM和产品设计师做需求调研、竞争分析、可用性测试、用户行为数据分析，整理相关用户体验反馈并出具报告。
2.1，这应该是一个中立的“第三方”研究组，对于产品体验质量的评判需要靠他们，产品决策和设计的来源也得靠他们。这个组不能参与到具体业务太深，更不 能脱离业务。
2.2，这个组的各种研究，仅提供给具体业务角色作为参考，具体决策甚至更深入的研究还得靠业务角色自己来完成。
2.3，这个角色的产出物最好只是好、不好，同时一定要有“为什么”。可以给具体产品建议，但一定要是来自用户的建议，而不是经过自己“揣测”或者“设 计”的“设计方案”。

3、 产品市场经理：所负责产品的用户和需求分析、产品发展规划、市场和运营规划、架构设计、资源调配、通用规则管理。
3.1，所负责产品的所有责任和决策权都应该是他的，但不是所有事情都他来做，同事他还要充分尊重其他角色的专业意 见。
3.2，什么情况下做了什么决策，为什么这样决策，后续计划是什么，必须要有文档。
3.3，除了必须从用户需求出发，也必须要有成本观念，任何一个计划都需要有对于成本和收益的考虑。

4、产品设计师：所负责产品的功能设计、业务流程设计、使用流程设计、系统(研发)需求分析
4.1，功能设计一定要基于产品经理的需求分析而出，不能无中生有。
4.2，业务流程设计和使用流程设计是两回事，都需要有。需要清楚给用户呈现的是什么，也需要清楚背后的业务逻辑是什么。
4.3，系统需求分析是个体力活，也是保证产品设计被最终实施的必须步骤。

5、界面设计师：界面的视觉设计和互动设计
5.1，界面设计师先考虑的不是“好看”，要是“用什么样的视觉逻辑更清晰的呈现给用户界面内容”，然后才是用视觉来影响用户的情感。如之前在微博上讨论 过的一样：视觉设计是用视觉手段解释界面元素的逻辑关系，并达到情感化的影响。
5.2，单页面的互动问题应该交给视觉设计去做。产品设计应该去做交互，但不应该过多考虑“互动效果”。
…………………………..

人员配备

1、理想状态下，我会按照产品的关系，分成几个产品组。如：xxx、xxx、xxx
2、产品架构师只有“一个”，设计助理一名作为后备。直接向产品中心负责人汇报。
3、用户研究组是独立部门，直接像产品中心负责人汇报。视需求而定人员数量。但不能超过产品设计师的一半。
4、根据需求每个产品组，1个PM，2到5个产品设计师，1到3个界面设计师。
…………………………..

补充说明：

1、要根据项目和产品发展阶段设定人员工作。PM必要的时候可以去做产品设计师，界面设计师必要的时候也可以去做产品设计师，但PM不是谁都能去做的。谁 都能去参与产品市场的讨论，但决策不能随便交出去。
2、在中小型团队中，往往我更喜欢“因人设岗”，我认为这对于互联网产品更实际更管用。
3、必要的时候再增加“产品运营”的职位。BD应该成立独立部门，运营不需要。
4、再次强调：产品和设计不要分开，产品中心的人员角色不要搞太多，职责也不要太清晰。

原文链接：http://uicom.net/blog/?p=878 ，作者：白鸦

今天，我们将分析大名鼎鼎的软件公司的网页设计做法和倾向，看看我们是否可以学到一些东西，以避免在我们自己工作的失误。

同意或不同意我的看法，随时在下面评论建议。作为专业设计师，你的观点是有价值的，我期待着你的想法。

偶尔的数落

如果你讨厌文章充满吹毛求疵般的唠叨，我很抱歉，这个文章偶尔会有点挑剔。我通常喜欢赞扬好的设计而不是批评坏的设计，但是当大卫.阿普尔亚德和我决定 写一个微软设计倾向分析的文章后，好像不得不见识一下什么是杂乱，丑陋，甚至（或者）失败的东西。

为了避免评论沦入口舌之争，我在下面的分析中不会提及苹果或者跟苹果单独对比。这并不是因为PC对MAC是最没争论的，而是因为我们只是想看看那些我们 认为真的缺乏实践的网站设计和开发。微软是一个很成功的公司，这不会因为有些问题而掩盖。实际上，正如后面指出的，微软在某些站点团队中有一些很优秀的设 计师，我们只是提出，应该有一个更高更全面的质量控制。

出于这样的考虑，让我们来分析微软一些缺少设计和开发实践的地方，从中你可以受益于这种知识

#1 谨防某些强制插件

苹果和Adobe之间最近的摩擦让我们认识到，依赖完全封闭的第三方插件创建网站最终会导致一些严重的后果。微软似乎要重蹈这样的错误，网站越来越多的 依赖Silverlight。

我浏览微软的站点准备这篇文章的资料是，是经常受到弹出窗口的骚扰，通知我系统没有安装Silverlight因此不能用原本的方式浏览这些网页。我的 疑问是，“为什么要走这条路呢？” 特别是对于一些简单的幻灯片效果的话，可以用的技术遍地都是。诚然，这是微软自己的Silverlight，所以从良好的商业意识出发要支持它，但这并不 意味着加入他们就是最好的选择。

无论你是否是Silverlight的粉丝，我的建议是如果你网站的功能依赖于任何Silverlight或类似技术，要非常谨慎。有关继续采用 Flash开发网站是否更加合理的争论还在持续升温，像Silverlight这样的二线系统的采用变得更具赌博性。如有可能，请坚持跨浏览器，符合标准 的代码和工具——别要求你的访客额外的操作或者安装。

#2 注意分辨率

这是我对微软最大的抱怨，因为它看起来就像设计得很草率。毫无疑问，尽量减小文件大小而增加实用性和保持图片清晰清楚之间是一条狭窄的路，但我还是不禁 觉得，相比那些专业的站点，微软似乎更倾向于显示丑陋的锯齿状的JPG。

拨号上网用户数量已经逐年减少，可接受的图像尺寸已经越来越大。不过这也不意味着你可以不用再注意尽量把有必要小尺寸的图片尺寸弄小，但现在这里，设计 的分量变得这么重，分辨率过小会大大降低了网站的外观质量，图片变得弄巧成拙！

这会是很讽刺的，本来你希望使用图片让你的网站更 好看，但在这个过程中，最终降低了你的美感。如果可能，在不同的显示器预览你处理的图片，要注意有多少失真，多少人工痕迹你可以接受的。

#3 组织凌乱

有时你按照常规的设计规则，到最后还是有些东西似乎视觉欠佳。浏览微软的网站我就遇到很多这样的页面，例如下面这个，尽管尝试使用了基于排列的组织，看 起来还是那么凌乱。

那么问题在哪里呢？简单地说，在于这里一个相对狭小的空间里要放一大堆东西。即使他们肯定的已经试图对内容排版，还通过图标增强视觉可读性，最终结果仍 然是相当失衡。

如果你仔细看看，你会发现这页面的四个栏目似乎是由四个不同的人来设计的，只是把它们都挤在一起。左边的图片相对于右边看起来真的的沉重，文字颜色有点 断断续续，内容是笨拙交错，各列之间缺乏足够的空白喘息空间，难看出它们的版面独立性。

这里得到的教训是要包装你页面的栏目信息时，小心内容信息过于庞杂。毫无疑问，有很多情况下都会要求增加更多的内容，但应在统一和谐且有吸引力的方式组 织处理，比如下面这个漂亮的例子（来自非微软的网站）。

#4 矛盾

从Microsoft.com开始，打开了庞大的导航下拉菜单，选择站点不同地方访问，你会发现，无论哪个链接，你点击出来的页面相比主页是相当不同， 即使在同一个下拉菜单出来的页面都是如此大差别。

浏览微软的网站就像玩一个旋转的轮盘赌。你已几乎猜不到你要去的地方和所期待的下一个页面。部分页面有swooshy（优美风格的曲线）背景，而其它页 面则是渐变的背景，甚至是发散的圆环。大多数网页似乎倾向于蓝色，但又不是相同的蓝，也有一些网页完全忽略了蓝色倾向。

问题是，不管你网站是2页或者200页，一致性还是必需的。在有限的时间内对一个网站的运作方式和界面变得熟悉时，用户会感到更加舒适。每隔几页就给 一些截然不同的东西会使浏览更加混乱，用户体验也变得很低效。

除此之外，创造一个强有力的统一的品牌就是一个良好的业务，因为它帮助客户以更独立的方式去联想你公司。当然了，微软有许多不同的品牌，这些分站都是 从主页延伸出来的，但即使是Microsoft.com核心的网页中，图片风格和导航方法似乎大大不同。

#5 剪贴画中心的设计

看看剪贴画在微软Office很无可避免的存在，这个建议会显然是有点荒谬。但是，ICON设计自1995年以来已经走了很长的路，是时候放弃图片中你 看到的那种特定风格了。

上面这些从微软网页拿来的例子让我感到鸡皮疙瘩，尤其是那个丑陋的“Beginner Developer” 标志。我搞不懂一个回力标为什么要攻击一个神奇的植物，悬浮着显示器是协助攻击还是逃离现场？我所知道的是，视觉传达在这里是一团糟。

这就是为什么CSS画廊像我们自己一样存在世上的主要原因。不这样的话你就可以窃取别人的设计，但这样你就可以一瞥你正在开发的设计十年来的发展状况。 浏览这些CSS画廊，就像在商场流行服饰店一样去，以显示给你的疯狂姑姑她没必要穿得好像要去参加Sunny和Cher的表演。

记得时刻保持自由无疆界，从自我开始超越于流行设计。世界都在变化，小心过于固执保守。

#6 文本对齐与溢出

微软网站的另一个不容忽视的倾向就是文本总是不断的破坏行列，很明显的溢出边界.

这是一个相当容易解决的问题，仅仅需要一点努力和注意。只是一 定要会利用免费工具像Adobe的浏览器实验室，以确保你的布局在主流浏览器都不会被破坏。

在谈到跨浏览器的一致性时，无可 否认的CSS布局像一个棘手的野兽，不过那样的小错会让你网站的品质下降，所以还是很值得你花时间去解决的。

#7 缺乏对齐

有时，一个给定页面交给我，要我指出设计的毛病来是一个挑战。例如，在下面的网页，原本我想找这个小窗口使用的碴——点击时不会变大，但我看页面越久， 我就对这个页面的布局的用意感到困惑。

如果你熟悉基本的设计理论，你知道，学习贯彻稳固一致的路线是优秀的网页布局的关键。如上图所示网站的左，中，右的视觉对齐奇怪的混合，联结顶部留出的 不尴不尬的空白，为内容信息呈现了一个怪异视觉流。

此外，如果浏览上面这个页面，你会看到整个内容似乎试图在页面居中，但由于中间横穿过一个区带，使得页面似乎中心偏右了。

#8 广告杂乱

如下图，免费设计博客喜欢放大量的广告，这是给我们的收入方式，以支持继续提供内容服务。不过如果你运行的是一个专业商务网站，你想减少内容消息并专业 化广告，你就必须仔细考虑了。

Microsoft.com的页面充满了各种广告，实实在在的降低了网页上的美感。有时，这些广告是直接指向到其他微软的网页，有时是指向其他公司或合 作伙伴。导航你的网站到其他下属站点这种概念是无可厚非的，但如何去实现这就有很大的区别了。

有一个事实就是，现在大多数网民都学会了辨认，忽略甚至可能反感横幅广告。这并不是说，这种类型的广告在适当的目标和设计下也没有效果，更不是说微软用 户根本不去点击，我实在觉得可疑的是，就没有更好的处理办法了么？

如你所见，微软网站如果要导航用户到他们的移动电话和其他项 目，简单的方法就是设置了一个混乱，非标准（智能设计）的广告系统贯穿整个网站。不过，似乎将广告内容整合到网站一体，随着用户的关注，会有一个很不错的 点击率。

另外，这种整合将使设计更加统一和谐。因为他们更宁愿增加一个单元而不是分割一个栏目。对了，这也许是我可以理解的微软“效率成本”做法的方案，但我要 告诫一下别让他们误导你。大部分情况下，你设计的网站不会是像微软一样的兆级网络，因此更适于踏实的统筹的设计，可避免过多广告造成的视觉混乱。

显然，有很多类型的网站这并不适合出现广告。你要考虑清楚你网站是销售产品或服务，还是需要额外的收入和广告的骚扰。

#9 缺少留白的喘息空间

在印刷设计，设计师在每一页都安排“生息区”，通常的做法是在页面边缘加入矩形区域，定义出放置内容的安全范围，避免页面太挤逼或页边拥挤。大多数网页 设计师都会直觉上这样做，很明显的你不希望内容太散，因而挤到了浏览器侧边。

然而，正如上面截图显示，微软的一些网页似乎并没有看重这方面的意见。相反，页面的内容总是不在任何空白或者边缘就开始（至少在我使用的浏览器上是这 样）。

左边的导航版，让人感觉不是内置在这个页面的，感觉好像截断了（是了，这样的情况还可能是由于一个事实：我没有IE）。这个例子的教训就是：永远要留意 浏览器窗口的边缘。除非你是为了某种明显的视觉效果而打破规则。将你的内容，尤其是交互和链接，放在有边缘的安全范围，这样用户使用的时候不会感到很挤。

如果你细看一下上面的截图，你可以看到微软的设计师一些失败例子，他们根本没有考虑到这些页面的文本块在主流浏览器是否浮动正常。这是微软很有趣的倾 向，许多网页设计师，终日挖空心思的为IE浏览器而作特别的适应，但一家微软这样的大公司显然不能这么无所谓的，不去在其他系统情况下检查他们自己的工 作。

#10 未充分利用人才

尽管上述关于微软网页设计的负面评价很多，我还是惊喜地发现，他们其实也有不少网站和网页看起来很漂亮迷人。

网站的很多地方让我相信微软真的用心考虑布局，色彩选择，跨浏览器兼容，上面是其中两个例子。这些可以看到，微软这个大染缸中的某处还有不乏才华的人， 可以帮助微软走出衰退的设计。

这些设计师，无论他们是谁，应该提升到合适的职位，让他们能够建立共同协作，并制定每个微软网页设计师要遵循一致标准。他们可以在一个内容混乱似迷宫一 样的地方，建立很多很明显属于同一企业的漂亮站点，从而建立强大网络品牌。

最后我给的建议是，找到你自己公司这种类型的优秀人才，给他们一个鼓励声音，而不是让他在团队中悲哀的埋没了才华，任命最强设计师和开发人员到合适的职 位，在那里他们可以影响每个角落的视觉沟通关联到特定的品牌。

这样可以有效地通过建立明确的，一贯的，严格的品牌指导策略，并将不同品牌的策略分发给每一个设计人员和开发人员。

思考总结

总之，尽管微软拥有不少极有才华的网页设计师，这些人的工作成果几乎被那些大量的不符合标准的内容所淹没，而这些标准，我们觉得即使只工作一年多设计师 和开发人员新手都可以期望做到的。

幸运的是，我们可以拿微软作为教训，以清楚说明这些工作方式是错误的。在说到工作成品的质量时，绝不要悲观的认为，你仅仅是一个单枪匹马的自由职业者或 小型的设计公司，就不能胜过那些大型企业和设计公司。

我发现，世界各地在家里办公的设计师中，要找到比坐在大公司大桌子前的设计师更优秀的实在很容易。 你要享受这样的事实：你不必去协调和控制数百个设计师的工作质量。尽量运用你拥有的少量资源结合你个人天马行空无边无际的创意和动力，去创造一些优美的功 能强的设计，创造一些网络上最优秀的站点。

来源： designshack               编译：MazingTech

一、用户体验信息收集

在讨论手机的交互设计方法之前，需要先对手机的用户使用习惯有一些基本的了解，需要对手机的用户体验信息做一些收集整理。收集用户体验信息首先需要确定两个问题：一是确定目标用户群体；二是确定信息收集的方法和途径。

在确定目标用户群体的时候，很显然的是，已有产品有过使用和交互经验，具备该产品或系统的交互体验的用户，相比较于那些没有体验的用户，可以为设计提供更多更有效的信息。因此在收集用户体验信息时，应该首先考虑所需设计的产品的用户或是有过类似产品使用经验的用户。在理想的情况下，当用户体验产品的交互时，设计师可以通过某种技术或是研究方法获得用户的全部感官印象，掌握他们的情感体验。然而这些主观的体验信息很难用实验室的方法收集或是客观的科学描述表达出来。因此我们只能寻求贴近实际的近距离接触用户体验的方法，就是深入访谈和现场观察。

• 系统出错、没有提示信息——压力、紧张和茫然
• 缺少误操作的补救机制——挫败感、压力
• 交互步骤的繁复难记——挫败感
• 提示信息的不明确（不符合用户模型）——茫然
• 过程处理时间过长——焦虑

二、用户分类

1.依据用户的需求可将智能手机的用户分为两类：

1.1 过程为主的用户(processoriented end user)

过程为主的用户的典型例子是电玩族，他们追求的终级目标就是视觉听觉的冲击和享受，最终游戏的结果反而变得不是那么重要了。此类设计对视觉和创意的要求是极为挑剔的，绝大多数设计师都有深厚的美术功底。

1.2 结果为主的用户(result oriented end user)

然而，与结果为主的用户设计相比，过程为主的用户的市场和受众都要小的多。结果为主的用户不在乎用什么样的方式完成任务，但是任务必须以最短的时间，以最简洁的方式，最精确的运算结果来完成。对于此类用户的交互设计人员来讲，更重要的是设计更合理的任务逻辑流程(logical task flow),以期最大幅度的符合人脑的思考方式和认知过程(cognitive process)。

2.依据用户的使用经验可将用户可以分类为：

2.1 新手用户

指刚刚开始接触和使用智能手机的用户，对智能手机的操作系统没有过使用经验，对计算机及应用程序的一般用法也没有太多的了解，但有一定的手机使用经验。

2.2 中级用户

使用智能手机有一定的时间，换过至少一个智能手机。对智能手机的部分操作相对熟悉，但经常使用的软件数量较少，并不完全熟悉智能手机系统的所有功能，对界面交互所必需的语法信息了解较少。

2.3 专家用户

有过相当长时间的智能手机使用历史，更换过几次智能手机，对手机的交互和电脑的操作都非常了解，经常主动寻找更简洁和快速的交互方式。

一般来说，中级用户和专家用户在长期使用某部分交互时遇到的问题更具有代表性，而新手用户提出的问题则更有利于设计人员认清用户与智能手机交互时的认知过程。

对应用户体验信息的收集和用户分类，我们可以总结出来智能手机上交互设计的方法和要点。

2.信息交互设计

• 信息项目的排布密度合理，字体排列、图标排列的方式具有可调性，设计合适的方式来突出重点信息；
• 使用用户的语言来传达信息，而非技术的语言。有效地使用“隐喻”。例如windows里面的“记事本”就是一个很好的隐喻例子，因为它和人们熟悉的日常概念联系在一起，所以用户可以很容易的理解这是一个什么工具。好的隐喻可以起到快捷的说明作用；
• 字体大小、颜色、图标设计等，都决定可读性的好与坏；
• 需要保持一致性的不光有每个功能软件或是服务的图标外观，更包括开机动画、细节元素和无形框架的一致，都需要贴合用户行为习惯进行设计；
• 尽量避免同一个元素包含太多的信息，例如，颜色的使用不要包含太多信息暗示，因为用户不一定会注意到或是理解某种颜色所包含的暗示。

3.软件交互设计

• 导航功能。随时转移功能，很容易从一个功能跳到另外一个功能；
• 允许工作中断。例如当用户编辑短信的时候，收到短信或电话，完成后回来仍能够找到刚才正写的短信息；
• 方便退出。例如，提供两种退出方式，按一个键完全退出，或是一层一层的退出。
• 让用户知道自己当前的位置，使其做出下一步行动的决定；
• 提供快速反馈，减少不必要的潜在等待时间。在任务交予系统处理或计算的时候，会有一段潜在的用户等待时间，一般我们会通过合适的等待提示让用户知道现在正处于系统潜在工作状态，而不至于让用户频繁地重复操作，使系统更慢；或者合理通过多任务切换处理避免这样的等待间隔。通过这些方法可以让用户回避这种的无效时间，从而提高交互效率。
• 良好的防错机制。误操作后，系统提供有针对性的清晰提示。即使发生错误操作，也能帮助用户保存好之前的操作记录，避免用户重新再来；
• 提供了解用户操作行为的途径，可以更好的帮助改善系统的操作；
• 通过缩短操作距离和增加目标尺寸来加速目标交互操作。

4.体验交互设计

• 让用户控制交互过程。“下一步”、“完成”，面对不同层次提供多种选择，给不同层次的用户提供多种可能性；
• 预设置的默认状态应该具有一定共通性和智能性，并对用户操作起到协助或提示的作用；此外，还应留给用户修改和设置默认状态的权限；
• 图标、多媒体设计、细节设计和附加功能设计为体验增值，有效提升体验度；
• 视觉设计，例如开关机动画、界面显示效果等；
• 多方面考虑用户信息的私密性，提供有效的保护机制，例如指纹识别密码模式。

四、总结

体验是一个比较虚的概念，很难量化很难评估，所以也导致很多小的无线产品开发团队干脆放弃了对产品用户体验的把握，甚至不需要设置一个专门的呃交互设计师职位来改善产品的交互体验，这对于成长型的公司是可以容忍的，但是对于要想做出精品，长期处于市场不败之地的公司就显得不够严谨了。手机互联网是未来的发展趋势，手机产品也对交互设计提出了更多的要求，简单探析了一下从用户体验出发来进行手机产品交互设计的方法原则，之后还是需要一个比较成型的交互体验评估体系的。

原文链接：http://elya.cc/product/595.html ，作者：elya妞