Group items tagged

设计过程中的副产品1. 角色，角色设计为系统的设计提供了典型的用户目标，它能够把用户研究的开销缩减的最小。2. 原形，这是最终作品的模型，原形可以很简单，简单到用几张图片来表示未来复杂的网站（低拟真度原形），也可以比较复杂，拥有最终产品的一样的交互能力（高 拟真度原型），纸面原形的测试效果其实已经很不错了。通常原型设计会让整个信息架构活起来，所以，请尽量在设计定稿前多做原型的测试！3. 剧情，剧情设计时另一种可以让信息架构设计活起来的技术，它模拟了一个用户执行具体任务时如何体验整个信息架构的过程，也能够让团队的其他成员很好理解设计的意图。

整个过程，信息流动并未因这些举措和功能的推出而阻断，反而很成功地和用户互动起来。豆瓣完成了从工具到社区的转化，同时能够保证其平滑程度，和人与信息之间的协调性，这才是其最出色的地方。 

豆瓣的群组上线，意味着社群化的正式展开。当然，群组的存在也并非由于其具有足够的人际liability，群组的基础也无非是一个组名。群组只是一个在item间信息整合的方式，我们可以随便从一个小组收藏的item中看到这个方式的效果。

再后来，豆瓣终于迈出了很关键的一步：人本的偏移。两个人间有哪些共同爱好，这个很小的应用似乎和以上的应用没有太大差别。真的这样么？如果真是这样，为什么这一个功能会放在我浏览他人profile时的最顶端？答案只有一个：豆瓣终于从信息中心转移到了人本中心。

社区的存在前提是信息的有效性和内涵价值，即一种综合意义上的liability。如果平台能够提供有价值的信息，或者平台能够激励其使用者提供有价值的信息，liability才会产生。社区的建立很大程度上取决于信息的liability。我们能够将社区的交际进行下去，是因为我们将信息的liability置换为其提供者的liability。只有这样，社区的诚信机制才有可能建立起来，人们间的关系才不会仍然松散。信息的价值成为社群性的粘合剂。

很严格的规范来完成，少任何一个element都无法建立起item的profile。同时为了提高其信息的liability，豆瓣也引进了wiki的思想：通过对item的信息投票来规约信息的准确性。又一个UGC的应用。我们需要注意到，这个投票和更改的过程本身就已经是信息在人们间流动的开始了。

观察豆瓣的举措。豆瓣的架构是一个矩阵。他们将高度结构化的items——书目、电影、音乐专辑等等——作为一个坐标，同时将完全去结构化的用户作为另一个坐标。我们可以看到这是两种规范方式，一种是信息至上主义，一种是人本主义。信息的管理需要高度的标准规范，而对用户的管理却必须更加敏捷。豆瓣在这一问题上处理得相当得当。

流动并未因这些举措和功能的推出而阻断，反而很成功地和用户互动起来。豆瓣完成了从工具到社区的转化，同时能够保证其平滑程度，和人与信息之间的协调性，这才是其最出色的地方。

：人本的偏移。两个人间有哪些共同爱好，这个很小的应用似乎和以上的应用没有太大差别。真的这样么？如果真是这样，为什么这一个功能会放在我浏览他人profile时的最顶端？答案只有一个：豆瓣终于从信息中心转移到了人本中心。为什么这么说？在这个应用中，item终于成为了彻头彻尾的工具，并且这个应用产生了一种精确的人际关系的定义。群组的确如此，但是我是否会和群组中的人们有相似的爱好，或者有相似的认知程度，这个无从判断。而共同爱好这一功能可以将这一问题完全解决。这是社群的基础，即信息的liability彻底转化为人际的liability的实际应用。从这一步开始，豆瓣正式从社区化工具转向了工具化社区。之后，广播的引入再次证实了社区化的判断。虽然广播仍然整合了用户与item之间的信息，比如“蟾宫读过《昌耀诗集》”等等；但是这一应用的产生的确促使社群化的瞬间加剧，同时也保证了item并不会被边缘化。相反，item的存在反而成为了人际间的加固栓，利用item定义的相似identity，将本应很松散的人群集合成为黏性极高的社群，并且长期相互加强。 

豆瓣的群组上线，意味着社群化的正式展开。当然，群组的存在也并非由于其具有足够的人际liability，群组的基础也无非是一个组名。群组只是一个在item间信息整合的方式，我们可以随便从一个小组收藏的item中看到这个方式的效果。比如拉康的小组中有很多拉康和关于拉康的著作，这首先是一个信息的重构过程。但是很快，重构的不只是信息，“人”这一坐标也由此产生集聚效应。这个效应的产生是由于人们在某一方面的属性类似甚至相同。豆瓣成功地利用其独特的个性和定位激励用户产生小组并为其添加内容增加收藏。一个社区化的良性循化就这样构成了。个人的社群性和信息的重构在这个循环中彼此加强。此后，九点、“去过哪”这些产品都是作为个人社群化和信息重构的标志。此时的豆瓣处于信息和人两种因素的中间地带。

不要把需求整理的非常详细以后再去内容设计，只要在内容设计该结束的时候完成需求整理；不要在开始信息架构设计的时候完全确定内容设计，只要在信息架构该确定的时候完成内容设计。也就是说“需求整理在信息架构开始的时候完成即可”。

你应该计划好你的项目，让任何一个层面中的工作都不能在其下层面的工作完成之前结束。… 在我们知道基本形状之前，不能为房屋加上屋顶。… 要求每个层面的工作在下一个层面可以开始之前完成，会导致你和你的用户都不满意的结果。… 一个更好的方法是让每一个层面的工作在下一个层面可以结束之前完成”。 拿到这里会有一点小变动，应该这么说：不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段这个阶段的工作。

用户调研应该贯穿于设计的任何一个环节，在整个设计过程中既起到“引导”的作用，又起到“校验”的功效。加入了对用户的研究以后，整个“迭代的设计过程”才会变得完整和丰满。

4. “帮助页面”的设计目的是让用户尽快离开这个页面

7.“帮助”的维护和创建同样重要

6.“帮助”的结构应该是清晰、内容应该简洁，尽量避免用户在使用“帮助”的过程中产生新的疑惑

5. 根据你的用户和你的系统来选择你采用“帮助”的方式

常见的一些帮助形式 1. 帮助目录（按照一定方式将帮助分类） 2. 常见问题（也可以说成“热点问题”） 3. 论坛支持 4. 搜索（通过输入关键字来查找所需的帮助信息） 5. 客户互助（类似百度知道） 6. 名词解释、定义（对专业术语的诠释） 7. 提供下载线下帮助 8. 即时在线客服（通过IM或者基于web的IM的帮助，提供帮助的可以是专门的客服人员或者是机器人） 9. 客服电话 10. 邮件帮助 11. 博客支持 12. 视频演示 13. 交互式的帮助 14. 交互过程中的帮助（可以是显性的也可以是隐性的） （ps：后文有这些帮助形式在主流网站的实例）

帮助的分类 按照得到帮助的速度来分 1. 即时性帮助 这类帮助在用户遇到问题时，可以很快的给出帮助的反馈（并不考虑这个帮助是否真的被解决）。如，用户遇到问题后，进入帮助页面，在FAQ中寻求解决办法；直接拨打24小时客服电话，用IM向在线客服寻求帮助。当用户的帮助需求很紧急时，即时帮助就显得很重要了。 2. 非即时性帮助 这类帮助需要一段时间才能得到帮助的内容。如通过发邮件，提交表单提出帮助诉求。这类帮助往往作为“主要帮助”的补充：当用户在系统提供的帮助中找不到答案的时候可以通过这种方式来寻求帮助。适合高级用户提出复杂的帮助需求，不适合帮助需求很紧急的用户。 按照提供帮助的位置来分 1. 进入系统的帮助页面寻求帮助 用户需要通过进入帮助页面或者通过搜索引擎来主动获取帮助。目前主流的帮助都是建立专门的帮助页面。这样的帮助存在一个问题，当用户在人机交互过程中遇到挫折，便放弃交互时，再好的帮助页面也失去价值。 2. 在交互过程给出相关的帮助 在人机交互过程中系统会提供显性得或者隐性的（如，通过鼠标触发）提示，说明或者进行自我解释来帮助用户完成操作。设计这类帮助的终极目标是让用户忘记所谓的帮助页面，在人机交互过程中对帮助用户学习和纠正用户错误。设计这类帮助的往往是从整个网站的信息构架开始的。这类帮助的设计需要花费更多人力，物力和财力。但这也是体现出信息架构和交互设计的重要性。 按照提供帮助的对象来分 1. 提供帮助的是机器 如传统的帮助页面，视频演示。这类帮助具有局限性，它只能满足大部分用户的需求，但对于有特殊需求的用户就无能为力了。 2. 提供帮助的是专业的客服人员 如客服电话、论坛、借助即时通讯软件的帮助。比起机器提供的帮助，这类帮助更加灵活，基本上能解决所有的问题。除此之外，像客服电话这样的传统服务方式，更适合不熟悉与机器打交道的人使用。 3 提供帮助的是用户本身 如淘宝互助这样的平台就是通过用户本身的沟通来取得帮助。这类帮助更加开放，更容易了解客户真正想知道的，更有利于建立帮助知识库。 按帮助所采用的形式来分 1. 文字说明 最普通的帮助形式。文字帮助往往是单独，枯燥的。用户往往无法完整阅读大篇幅的文字说明。但如果需要解释专业术语或者名词时，文字形式的帮助无可替代。 2. 图文说明 主流的帮助形式，提供比文本说明更加直观和清晰的帮助形式。可以解决大部分用户的帮助需求，但遇到比较复杂和繁琐的交互过程时，图文帮助并不是最有效的。 3. 视频演示 通过演示人员完整的人机交互演示，让用户更直观的学习整个交互过程。这种帮助形式适合较复杂和繁琐的交互过程。当然这类形式的帮助会对网络带宽有一些要求，所以最好能提供用户在线观看和下载两种选择。除此之外视频演示还有结构不清晰，很难快速定位整个交互过程的其中一个过程。 4. 互动式帮助 通过模拟真实的交互环境，提供引导和说明帮助用户完成整个交互过程。对于较复杂的交互过程，互动式的帮助是目前最好的解决办法。它贴合用户更愿意在“实践”（虽然是模拟的，但基本重现实际交互环境）中学习的意愿。它也能解决视频演示中结构不清晰，难以定位整个过程中的其中一环节的问题。 5. 搜索 通过输入关键字查找帮助的内容。这类帮助形式可以以最快的速度帮助用户找到他们需要的内容。但它对用户的要求也比较高，需要用户能够找到概括他们遇到问题的关键字。所以建立搜索帮助最关键的问题是建立的“帮助知识库”能够涵盖大部分用户所需帮助的关键字。

采取多途径获取信息的方式来分散用户对低效率的厌恶。用户的满足感来源此时并不是信息获取，而是“拥有”。

充分利用第三方的力量，转移用户对浏览器乃至刷屏行为本身的依赖。什么意思呢，其实特别简单，就是开发出多种关注途径，比如工具条，大家可以试试在浏览器里安装了Facebook工具条后是不是还那么频繁地登陆；再比如基于Adobe air的桌面客户端等等。当我有了这些方式去获取我因为刷屏而获得的那些实时信息，我的“拥有”感就会得到实时的满足。

，也会对自己的网站信息渗透进工具栏和桌面有更好的扩展。笔者很支持这种多途径的第三方工具。

这个导致我们对网站的满意度或许会提高，但对实际效率的提高没有直接的帮助。

为所有用户行为提供即时反馈能够减少用户的焦虑感。有效地使用布局、信息设计、排版、交互设计和信息架构可以平衡挑战感和用户的技能等级。

心流：当用户在完成交互行为时需要高技能水平，并且通知感知到高挑战，且两者达到某种平衡时就会有心流的体验产生。最生动的例子莫过于玩游戏。任何游戏一定会提供一定的难度给玩家，并常常伴有过关打boss等设计来让玩家感知挑战。 控制：在驾车的时候，是需要高的技能——驾驶的，但是挑战感并不强，这时，能够感觉的就是控制感。当然，提高挑战感，例如赛车，能让某些人着迷，从图上可以看出原因，因为他们进入了心流状态。 放松：放松性的阅读和品美食就属于高技能和低挑战。 无聊：做家务，需要有一定的技能水平，但是却不能让人感觉到挑战，所以做家务事一件很无聊的事情。 冷漠：当交互行为的技巧低而面对的挑战也低的时候，但是这样就无法产生持续上升的心流，也会出现心流体验。这种情况下是一种冷漠。例如看电视，我们沉浸于其中，但事实上整个身体、心理并没有很激动地参与，而表现出了冷漠、无感情。 忧虑：在不参加太多逻辑的争论的过程中(当然不是参加辩论赛)，有一定的挑战却没有要求很高的技能。表现出的就是忧虑的情感。 焦虑：在做一些例如重复性的工作，死记硬背文章的时候，由于技能水平低却完成高挑战的任务，就会出现焦虑。 激励：当工作技能提升或者学习水平提高等，有一定的驾轻就熟之感，这时，工作和学习就有一种激励的感觉。

心流通道的概念。

将心流理论应用到我们的实践中去，我在这里根据心流产生的原因来一一阐述。 清晰的目标 首先，我们要理清我们设计的流程，将我们的逻辑信息构架、导航、搜索路径尽可能清晰地展示给用户。尽量的让每一个页面只完成一个目标，且清晰。减少选择，让用户能够很快地做决策。强大的网站应该是像在一个高档的餐厅，客户用餐，除了体验到美食，也同时体验到了优质的服务。可惜，现在的大多数网站都像是在做自助餐，在你面前摆上无数种选择，认为这是在尊重用户意愿。就像自助餐一年难得吃几次一样(大部分人认为自助餐是性价比高，在利益的驱动下去吃。)，这样的自助餐模式网站开始看起来不错，但他们忽略了用户总是懒惰的这个事实，用户总是期望有人一步步告诉他该做些什么，于是慢慢地用户就会失去兴趣——因为他们总是不知道该干些什么。 提供及时的反馈 Donald博士在《设计心理学》这本书中 在说明执行/评估周期(Excution/Evaluation Action Cycle)时，有对反馈做比较深入的阐述。在这个周期的评估阶段，用户会去比较现实发生的和他们预期发生的事件之间的差别。及时的反馈有助于用户评估之 前所作的操作是否有助于更进一步地接近目标，以便用户重新调整操作或者进入下一个操作步骤。所以在页面上我们会关注页面加载速度，加快反馈时间。另外，我们应当尽量及时且清晰地让用户了解计算当前在做些什么，用户刚才的操作有哪些影响。例如在进行某些操作的时候，用户总能获得刚才的操作成功与否的反馈。 尽量设计相应的挑战以迎合用户的操作技能 在上述关于心流通道的概念中，我们已经解释了在一定的挑战感结合一定的用户的操作技能下，用户才能进入“心流”状态。在《软件观念革命》中 所述的针对新手、中间用户和专家用户设计的观点与这点其实是类似的。这就要求我们在每个流程、每个页面设计之初要理解该页面为谁设计，以便来制定界面的复 杂程度。对新手访问的页面，设计简单、清晰的结构，以便他们迅速学会界面。对于专家用户，除了增加页面的复杂度，同时可以加入页面定制的功能。在白鸦的只把20%拿出来中，白鸦说：“不要试图一下子把什么都抛给用户，他们根本接受不了。需要用你20%的对用户最有吸引力的东西在0.3秒内搞定她的神经，然后勾引她自己去发现另外的80%”。这也是在平衡挑战感和用户操作技能。广泛地，《和谐界面》提出的“5W+H启发式(5W+H heuristic)”中的“谁/为什么(Who/Why)”也如出一辙。

30个最顶尖的基于栅格系统的博客网站设计。

网页栅格系统的原理与应用：

我们把宽度为“W”的页面分割成n个网格单元“a”，每个单元与单元之间的间隙设为“i”,此时我们把“a+i”定义“A”。他们之间的关系如下： W =（a×n）+（n-1）i 由于a+i=A， 可得：(A×n) - i = W 这个公式表述了网页的布局与网页“背后”的栅格系统之间的某种关系

yahoo的网站页面宽度为W=950px，每个区块与区块的间隔为i=10px；如果应用上面的公式，可以推出A=40px，既yahoo首页横向版式设计采用的栅格系统为： （40×n）- 10 = W

下面我们列出当n等于不同数值时W变化的数值表格

yahoo首页的布局完全是按照栅格系统进行设计的，每个区块的宽度对应的n值分别为：4，11，9。在这里我们看到一个很有意思 的事情：只要保证一个横向维度的各个区块的n值相加等于24，则即可保证页面的宽度一定是950px。然而，950px的宽度也恰好就是当n=24的时 候，W的宽度值。由此我们得出以下的应用模式：

在栅格系统中，设计师根据需要制定不同的版式或者划分区块，他们的依据将是上面的那张对应表进行设计。这样，一个栅格系统的应用就从此开始了。

它给整个网站的页面结构定义了一个标准。对于视觉设计师来说，他们不用再为 设计一个网站每个页面都要想一个宽度或高度而烦恼了。对于前端开发工程师来说，页面的布局设计将完全是规范的和可重用的，这将大大节约了开发成本。对于内 容编辑或广告销售来说，所有的广告都是规则的，通用的，他们再也不用做出一套N张不同尺寸的广告图了……

对于内容信息不确定导致高度不确定的页面，在高度层面上就无法做到栅格了。

我们可以衍生出任何一种栅格系统，只要改变A和i的值，这个根据网站的实际情况来制定。那么如何选择合适栅格系统，主要通过“构成 要素与程序、限制与选择、构成要素的比例、组合、虚空间与组合、四边联系与轴的联系、三的法则、圆与构成、水平构成这些设计元素规划，来实现比例和谐的平 面设计”。

PM是什么? 传统意义上PM就是一个产品的主管，为了方便讨论，我们这里将产品定义为软件、网站、网络应用、局域网或技术产品。 作为一名领导者，PM将对整个产品的成功负责，这其中包括用户体验。对技术产品而言，用户体验是产品成功中非常重要的部分，当然还包括其他方面，像产品的销售、技术、法律、商业模式、定位、品牌和营销等。 PM应该扮演一个领导者而非独裁者的形象，才能保证产品的成功，并得到各方的支持。像总统会与负责防务、交通、农业等的官员共事一样，PM团队也包括营销、技术、财务和其他领域的人。与票选民主不同，PM对用户和客户负责，通过收入、利润、用途和其他市场驱动因素来实行决定民主。 产品管理中涉及的各项任务和领域使得PM必须精通业务的方方面面。

产品管理与用户体验的冲突 最常见的UE与PM间的冲突就发生在该产品应该做什么与产品该怎么做的讨论上，双方经常辩论谁应该负责定义产品特性与需求。PM感觉应该由他们负责，因为他们管理产品，但是UE人员感觉应该由他们负责，因为他们花了时间来研究用户需求并直接与客户和用户互动。 最终由于PM对整个产品的成功负责，他们也就成了决定产品做什么的最后仲裁者。好的以市场为重点的PM应能理解市场背景和客户需求，并在第一手经验和已有研究的基础上决定合适的产品特性与功能。 然而UE人员常常对此非常光火，因为他们认为自己更贴近客户和用户，理应负责产品的需求收集和定义。好的PM应该象UE人员那样贴近自己的用户，否则就会脱离用户，只知道坐在办公室里开大会，让UE人员来做此类研究。 好的PM能深知用户体验这个角色并理解其重要性，重视他们的投入并利用他们的研究和建议来创造优秀的产品。正如总统需要从自己的内阁成员那里获得建议一样，PM也应该利用自己的"内阁成员" — 用户体验、市场营销、技术等 — 去做出决策。 从UE人员向PM角色的转换远不止去操作所有的界面设计， PM一项很重要也很有挑战的任务是负责确定产品的目标与策略，树立内在和外在的产品领导能力，创造商业模式及获得资本，从小事出发又能着眼大局，并协调市场、工程技术、财务、销售当然还有UE一起向成功迈进。 在第二章，我们将向你介绍迈向产品管理的方方面面，包括你在UE岗位上不可以做而在PM角色上需要做的事情、成为PM你必须做哪些准备、UE背景的人成为PM后常有的缺陷等，来帮助你作出这中转变。

平衡各方力量 确保你的产品重点是客户和用户需求非常重要，但是其他方面同样值得关注，包括但不限于: • 销售目标 • 市场/品牌目标 • 技术趋势 • 文档管理 • 预算管理 • 市场趋势 • 竞争力 • 商业模式与回报 (可能的人员浮动、变局影响、价格杠杆等) 做好一款产品需要在商业目标、用户需求和市场效应之间进行一系列权衡，作为PM，你就必须在各方之间努力做好平衡。

推广产品 你必须同时在内部(包括销售、市场、管理层、开发者等)和外部(包括客户、用户、业界分析员和媒体)取得支持。仅仅只是开发出一款好的产品还不够，你还必须让人们知道它，推广它的好处。 向组织中的其他产品提供策略投入 如果你是一间中型或大型公司的PM，你在这个位置上同样需要影响其他产品。你也会同其他公司内的其他PM交流，你需要考虑公司的全部产品线，并将你的产品融合其中。 你面临的挑战与压力 PM这个新角色会让你很有荣誉感和责权感，而且新头衔带给你的影响力可能会胜过其他，但它也是”带刺的玫瑰” — 你同样必须应付挑战和压力。

在前一章中，我们勾勒了PM的职责、PM与UE人员的差异以及为什么两种角色之间会产生冲突等。 现在我们来介绍当UE人员成为PM后其思考重点、职责与挑战将会发生哪些改变，离开UE工作岗位后你将有哪些收获与损失以及如何为这种转变做准备等。 在你向PM的角色纵身一跃之时，最好清楚这次跳跃对自身的影响。 作为UE人员不可以做而作为PM必须做的事情 成为PM后，你每天的工作将会发生巨大的变化! 你必须运用你的全部知识投入到整个产品中。作为UE人员你也许能同样做到这一点，但是限于行政授权你未必需要和公司内的全部决策部门打交道，以下就是你的一些"新职责": 关注产品策略以及客户和终端用户的需求(这也是你做出转换决定的原因) 你必须长期地研究客户和用户，找出用户需求与商业目标的切合点。相应地了解这方面的知识并有意识地利用它。 从产品的整体性上协助确定用户的焦点，不只是设计 沟通、政策以及定价都必须整合成为"客户体验"的整体，过去我们常常对这些方面的重要性认识不够，成为PM后你就必须对关乎产品体验的方方面面负责了。

学习并准备成为PM 因此，你想成为PM? 不知道从何做起? 除了上面提到的以外, 你还应该增加你在产品管理方面的知识，从中找到你为这一角色转变所需要的东西。 想想你迈向UE之路时候所做的事吧: 书、博客、会议、小组讨论、各种组织以及导师等，它们都发挥了很大的作用。如果你想成为PM，这些方式依然有效。 成为PM最好的条件是通过培训和会议。差点忘记提了，我们在IA 2007峰会: 你想成为产品经理 上有一个预备会议，这个半天的训练营上将会集中讨论如何从UE向PM的角色转变，包括如何更好地平衡你现有的技能以及怎样避免潜在的不足等。 还有其他组织提供类似的训练营活动，包括: • 实务营销 • 280小组 • Blackbot • ZigZag营销 • 硅谷产品小组 有大量非常好的Blog在讨论产品管理，你也可以从中选择: • Roger Cauvin的博客 • 实务营销的博客 • SVPG博客 • 产品管理观察 • Tyner Blain • Michael的产品管理与营销 • 如何成为优秀的PM (它的联合作者之一便是 Jeff Lash) 还有很多从UE角度来谈产品管理的书籍，这些都应该作为PM的珍藏: • 赢在新产品: 产品从创意到启动的加速实现, 作者Robert Cooper • 软件产品管理精华, 作者Alissa Dver • 产品经理手册, 作者Linda Gorchels 此外，有志成为PM的人还应该阅读一些综合的管理类图书，包括领导力、管理、市场营销、财务、技术、策略学等。 产品管理有两个主流的社团组织: PDMA (产品发展与管理协会)和AIPMM (国际产品营销与产品管理协会)。两者都提供培训、会议、本地讨论小组及其他产品管理资源。 同时，你还可以利用你的一些职业网络，也许能从类似LinkedIn — 帮你寻找能建立联系并回答有关产品管理问题 — 这样的服务中获得帮助。在你的公司里项目管理也能指导你，况且来自其他组织的产品经理也能给予你不同的或许更真诚的帮助。 正因为你学习产品管理并思考如何迈向这一步，可以找你的经理谈谈。优秀的经理会帮助你的职业化成长，即使这也许意味着你将进入公司的其他岗位。

作为PM，你的权力很有限 Guy Kawasaki形容PM是"一个背负全部职责却没有任何权力的人"。大部分为你的产品工作的人会向不同的管理层汇报，很少甚至没有人会直接向你汇报。你必须梳理这些分散的资源，指导他们的工作 — 尽管他们从各自的经理那里获得了不同的工作方向。 你必须做出决定并对此负责，而不仅仅是建议 事实上你必须做出很多的决定并为此负责，不是所有人都会认同(你的这些决定)。当然如果你的工作干的好，你可以向他们证明你的决定是正确的，明确解释你的原则，其他人也就不会显得焦急或轻视 — 但这并不容易! UE出身的PM会发现所创建的体验也许不是对用户"最好"的体验， 因为还需要考虑其他重要的因素(比如管理层的需求、商业策略、商业模式等)，让这些人理解做出这样的决定或许有损用户，但最终有益于产品往往需要时间。 你将经常处在利害分歧的中心 销售人员希望有不同的功能、开发人员将你制定的时间表往回推、财务人员需要新的后端功能、商业开发人员希望能为合作伙伴做一些产品调整、设计师希望更改一些功能的实现、用户希望增加一项你的竞争对手推出的新功能、管理层希望你的产品能与公司新产品进行整合… … PM就处在这样不同的竞争中心，在一些公司中这样的处境是很不妙的。你必须调节好这些冲突的想法，制定相互之间的优先级以推动产品策略并保证皆大欢喜(至少不能让某个人动怒)。 成功的PM总是围绕着整体的目标和策略来平衡各方的要求，决定做哪些可以最大限度地支持这些目标。PM对目标与策略的理解越深，就越能做出权衡考量。有时候一点小的让步能够得到更多的收益，有时候则需要更好地梳理目标。 管理层需要从你这里得到关于产品的信息 PM不只是产品开发团队的一员，你是整个产品的象征。无论你把事情做好了或搞砸了，也无论你是否真的能驾御局面，你都必须为此负责。 作为UE人员可以做而作为PM不可以做的事情 从UE岗位转换到PM岗位的人会对新职责感到兴奋和有挑战性，与此同时，他们也会失去一些UE工作的一些方面: PM不必插手过多细节 这是很多之前习惯过问小事的人面临的最艰难的挑战。作为PM很多具体的工作都应该是委派给其他人(来做)，一个花费太多时间去处理细节问题的PM注定没有做好他们的本职工作 — PM需要关注的是战略层而不是战术层。 PM并不追求尽善尽美和理论上的完美 有一个针对UE的笑话是UE人员经常回答问题的时候说"这个取决于…"。对PM来说，也许它确实取决于某件事情，但这不是紧要的。这并不是什么理论上应该发生的问题，而是在此情况下我们马上要做什么以及为什么做的问题。 你必须习惯够用即可的观念，做出在用户看来未必完美但在有限的资源下很受用的决定即可。 PM对产品的核心问题不只是建议 这一点和上面的有点背道而驰，UE实践者们提出建议，而PM需要决定策略、较高层面的用户体验、功能设置、市场规划、定价及其他方面。之所以又提到这一点，是希望促成你进行反省。如果你只是习惯建议或很难做决策，你也许不适合成为PM。 PM不是艺术家或专家型实践者 PM并不专注与产品的某个部分，而是知晓全局。他们有点类似船长或教练去驾御局面。在这个层面上，PM需要保障一起共事的人能将产品目标反映到方方面面，例如营销策略、界面设计、版权书写等。 由于不是专家，在各个方面进行调节是比较困难的，PM就必须在后面的工作中不断学习如何领导其他专家向一个共同的目标努力。 从现在起更好地配合你的PM 如果知道"幕后"产品管理，你可能已经动心了。有一条捷径能帮助你开始: 从现在开始更紧密和有效地配合你的PM! 这个办法即使对那些并没有这方面特质、技能或只是想成为PM的人来说都是值得一试的。作为一名UE实践者，更好地理解其他角色的同事所面临的责任与挑战可以帮助你调整与他人共事的方式，并且最终使你变得更有价值、更受尊敬、更有影响力。 有UE背景的人在某些领域是能够很好地与PM相处的，有些办法能很好地帮助你探路，而无论你是否迈出了这一步。 领导力 不要只知向PM或其他同事索要具体的研究和设计成果，在很多情况下，其他同事很欢迎你能有主动性和创意，不过同时他们也保留不同的观念，只要把事做起来就能迅速公开和集中地进行具体地讨论，总好过停留在理论和臆测层面。 向PM问清楚他们的产品目标是什么 问清目标非常重要，体现在两个方面：第一，PM自己有可能之前没有仔细想过产品目标，你这一问后，有可能让你成为最受信赖的顾问之一并帮助他们建立目标。 第二，如果PM已经有了目标，那么你也就能清晰地建立一系列的目标和预期。如果他们的目标存在问题，你还可进行澄清和确认，并决定怎样让它回到正确的道路上。 帮助PM评估设计的各方面因素 不要只是提出设计方案然后让PM做决定，要让自己准备好参与讨论特定设计选择的影响，向他人展现你的设计背后的原因已经他们在更广范围内与产品远景和目标的联系，聆听PM怎么说并搞清楚他们拒绝或认可的理由。 提出带有远期规划的强烈建议 你所能提供一些证据和经验将支持着你更紧密地成为产品的一份子，而不只是一个辅助的参考者。你也能从纷繁复杂的因素中做出决定的过程中得到锻炼，如果你立志想做PM的话这些很有帮助。 展现你对工作的远期规划将使你能成为团队中最重要的成员之一，并且能展现你有担负更多职责的潜力 — 不管你现在的角色是什么。 帮助PM走出办公室 PM不应该对客户和用户视而不见，尽管有人是这么干的。你应该通过询问他们最后一次见用户是什么时候来帮助他们，把他们带入到正式或非正式的用户研究中，或者给他们讲在用户访谈中的一些有意义的故事，邀请他们下次同去。如果被拒绝了，下次继续邀请。 如果PM能自愿去拜访用户，让他们带上你。除了了解用户需求之外，这也是一个你有时间向PM求教他们的观点、兴趣与目标的好机会。 如果你真的无法把PM带出办公室，那就把用户们带进来吧。在这种情况下，应该没有哪个PM(包括其他开发成员)能找借口拒绝和用户沟通。

产品管理与用户体验的冲突 最常见的UE与PM间的冲突就发生在该产品应该做什么与产品该怎么做的讨论上，双方常常争论谁应该负责定义产品的特性与需求。PM感觉应该由他们负责，因为他们管理产品，但是UE人员感觉应该由他们负责，因为是他们在花时间直接与客户和用户打交道，研究用户需求。 最终由于PM对整个产品的成功负责，他们也就成了决定产品做什么的最后仲裁者。好的以市场为重点的PM应能理解市场背景和客户需求，并在第一手经验和已有研究的基础上决定合适的产品特性与功能。 然而UE人员常常对此非常光火，因为他们认为自己更贴近客户和用户，理应负责产品的需求收集和定义。 好的PM应该象UE人员那样贴近自己的用户，否则就会脱离用户，只知道坐在办公室里开大会，让UE人员来做此类研究。 好的PM能深知用户体验这个角色并理解其重要性，重视他们的投入并利用他们的研究和建议来创造优秀的产品。正如总统需要从自己的内阁成员那里获得建议一样，PM也应该利用自己的"内阁成员" --- 用户体验、市场营销、技术等 --- 去做出决策。 从UE人员向PM角色的转换远不止去操作所有的界面设计，PM一项很重要也很有挑战的任务是负责确定产品的目标与策略，树立内在和外在的产品领导能力，创造商业模式及获得资本，从小事出发又能着眼大局，并协调市场、工程技术、财务、销售当然还有UE一起向成功迈进。 在第二章，我们将向你介绍迈向产品管理的方方面面，包括你在UE岗位上不可以做而在PM角色上需要做的事情、成为PM你必须做哪些准备、UE背景的人成为PM后常有的缺陷等，来帮助你作出这种转变。

产品管理和用户体验的差异 尽管PM的职责很广也很有战略性，他们还需要负责在战术层面具化他们的战略。在一些细节上，PM可能存在与UE人员重叠的问题。正如Johathan Korman写道: 当我向那些不了解"交互设计"的人们描述我是做什么的时候，首先我说:"我观察用户的需要，确定哪类产品最适合他们，然后制定关于这个产品的行为规范，以此推动开发团队的工作。"人们常常回应说: 在我的组织里，我们管这个叫"PM"。 乍一看，用户体验的角色和产品管理惊人的相似。然而你仔细观察就会发现产品管理和用户体验在职责、重点和依赖度上是有区别的。 职责: PM负责整体成功，而UE人员负责界面设计使之满足用户需求并易于使用。UE人员同样应该像销售、营销、工程人员那样关注整体的成功，尽管并不负责这些方面。 重点: 当UE人员聚焦在界面与产品体验之时，PM会从市场整体反馈、特定市场规划、竞争力、技术、收益与损耗以及可调用的资源等方面来审视这些界面与产品体验。 依赖: 信息架构师(IA)、图形设计师、易用性专员等主要精力集中在界面上，他们需要依赖自身或类似角色的其他人一起来完成工作。PM则坚定地要求他人能执行其产品策略，他们更多地需要融合一些微妙的产品目标、策略、影响力、坚定和公平的决策等因素，这些要求多甚于UE人员。 或许Johathan Korman最好地诠释了PM与其他角色如UE之间的差异: PM负责产品应该做什么(What the product should do)，而其他角色负责产品怎么做(How the product does that)。

PM对产品的核心问题不只是建议 这一点和上面的有点背道而驰，UE实践者们提出建议，而PM需要制定策略、较高层面的用户体验、功能设置、市场规划、定价及其他方面。之所以又提到这一点，是希望促成你进行反省。如果你只是习惯建议或很难做决策，你也许不适合成为PM。 PM不是艺术家或专家型实践者 PM并不专注与产品的某个部分，而是知晓全局。他们有点类似船长或教练去驾御局面。在这个层面上，PM需要保障一起共事的人能将产品目标反映到方方面面，例如营销策略、界面设计、版权书写等。 由于不是专家，在各个方面进行调节是比较困难的，PM就必须在后面的工作中不断学习如何领导其他专家向一个共同的目标努力。

作为UE人员不可以做而作为PM必须做的事情 成为PM后，你每天的工作将会发生巨大的变化! 你必须运用你的全部知识投入到整个产品中。作为UE人员你也许能同样做到这一点，只是限于行政授权你未必需要和公司内的全部决策部门打交道，以下就是你的一些"新职责": 关注产品策略以及客户和终端用户的需求(这也是你做出转换决定的原因) 你必须长期地研究客户和用户，找出用户需求与商业目标的切合点，相应地了解这方面的知识并有意识地利用它。从产品的整体上确定用户的焦点，不光是设计。 沟通、政策以及定价都必须整合成为"客户体验"的整体，过去我们常常对这些方面的重要性认识不够，成为PM后你就必须对关乎产品体验的方方面面负责了。 平衡各方力量 确保你的产品重点是客户和用户需求非常重要，但是其他方面同样值得关注，包括但不限于: • 销售目标 • 市场/品牌目标 • 技术趋势 • 文档管理 • 预算管理 • 市场趋势 • 竞争力 • 商业模式与回报 (可能的人员浮动、变局影响、价格杠杆等) 做好一款产品需要在商业目标、用户需求和市场效应之间进行一系列权衡，作为PM，你就必须在各方之间努力做好平衡。 推广产品 你必须同时在内部(包括销售、市场、管理层、开发者等)和外部(包括客户、用户、业界分析员和媒体)间取得支持。仅仅开发出一款好的产品还不够，你还必须让人们知道它，推广它带来的好处。 向组织中的其他产品提供策略投入 如果你是一间中型或大型公司的PM，在这个位置上你还需要影响其他产品。你也会与其他公司内的其他PM交流，思考公司的全部产品线，并将你的产品融合其中。 你面临的挑战与压力 PM这个新角色会让你很有荣誉感和责权感，而且新头衔带给你的影响力可能会胜过其他，但它也是"带刺的玫瑰" --- 你同样必须应付挑战和压力。 作为PM，你的权力很有限 Guy Kawasaki形容PM是"一个背负全部职责却没有任何权力的人"。大部分为你的产品工作的人会向不同的管理层汇报，很少甚至没有人会直接受命于你。你必须梳理这些分散的资源，指导他们的工作 --- 尽管他们从各自的经理那里获得了不同的工作方向。

你必须做出决定并对此负责，而不仅仅是建议 事实上你必须做出很多的决定并为此负责，不是所有人都会认同(你的这些决定)。当然如果你的工作干的好，你可以向他们证明你的决定是正确的，明确解释你的原则，其他人也就不会显得焦急或轻视 --- 但这并不容易! UE出身的PM会发现所创建的体验也许不是对用户"最好"的体验，因为还需要考虑其他重要的因素(如管理层的需求、商业策略、商业模式等)，让这些人理解作出这种或许有损用户，但最终有益于产品的决定往往需要时间。 你将经常处在利害分歧的中心 销售人员希望有不同的功能、开发人员将你制定的时间表往后推、财务人员需要新的后端功能、商业开发人员希望能为合作伙伴做一些产品调整、设计师希望更改一些功能的实现、用户希望增加一项你的竞争对手推出的新功能、管理层希望你的产品能与公司新产品进行整合... ... PM就处在这样不同的竞争中心，在一些公司中这样的处境是很不妙的。你必须调节好这些冲突的想法，制定相互之间的优先级以推动产品策略并保证皆大欢喜(至少不能让某个人动怒)。 成功的PM总是围绕着整体的目标和策略来平衡各方的要求，决定做哪些可以最大限度地支持这些目标。PM对目标与策略的理解越深，就越能做出权衡考量。有时候一点小的让步能够得到更多的收益，有时候则需要更好地梳理目标。 管理层需要从你这里得到关于产品的信息 PM不只是产品开发团队的一员，你是整个产品的象征。无论你把事情做好了或搞砸了，也无论你是否真的能驾御局面，你都必须为此负责。 作为UE人员可以做而作为PM不可以做的事情 从UE岗位转换到PM岗位的人会对新职责感到兴奋和有挑战性，与此同时，他们也会失去一些UE工作的一些方面: PM不必插手过多细节 这是很多之前习惯过问小事的人面临的最艰难的挑战。作为PM很多具体的工作都可以委派给其他人来做，一个花费太多时间去处理细节问题的PM注定没有做好他们的本职工作 --- PM需要关注的是战略层而不是战术层。 PM并不追求尽善尽美和理论上的完美 有一个针对UE的笑话是UE人员经常回答问题的时候说"这个取决于…"。对PM来说，也许它确实取决于某件事情，但这并不要紧的。这并不是什么理论上应该发生的问题，而是在此情况下我们马上要做什么以及为什么做的问题。 你必须习惯够用即可的观念，作出在用户看来未必完美但在有限的资源下很受用的决定。

第二章 在前一章中，我们勾勒了PM的职责、PM与UE人员的差异以及为什么两种角色之间会产生冲突等。 现在我们来介绍当UE人员成为PM后其思考重点、职责与挑战将会发生哪些改变，离开UE工作岗位后你将有哪些收获与损失以及如何为这种转变做准备等。 在你向PM的角色纵身一跃之时，最好清楚这次跳跃对自身的影响。

从现在起更好地配合你的PM 如果知道"幕后"产品管理，你可能已经动心了。有一条捷径能帮助你开始: 从现在开始更紧密和有效地配合你的PM! 这个办法即使对那些并没有这方面特质、技能或只是想成为PM的人来说都是值得一试的。作为一名UE实践者，更好地理解其他角色的同事所面临的责任与挑战可以帮助你调整与他人共事的方式，并且最终使你变得更有价值、更受尊敬、更有影响力。 有UE背景的人在某些领域是能够很好地与PM相处的，有些办法能很好地帮助你探路，而无论你是否迈出了这一步。 领导力 不要只知向PM或其他同事索要具体的研究和设计成果，在很多情况下，其他同事很欢迎你能有主动性和创意，不过同时他们也保留不同的观念，只要把事做起来就能迅速公开和集中地进行具体地讨论，总好过停留在理论和臆测层面。 向PM问清楚他们的产品目标是什么 问清目标非常重要，体现在两个方面：第一，PM自己有可能之前没有仔细想过产品目标，你这一问后，有可能让你成为最受信赖的顾问之一并帮助他们建立目标。 第二，如果PM已经有了目标，那么你也就能清晰地建立一系列的目标和预期。如果他们的目标存在问题，你还可进行澄清和确认，并决定怎样让它回到正确的道路上。 帮助PM评估设计的各方面因素 不要只是提出设计方案然后让PM做决定，要让自己准备好参与讨论特定设计选择的影响，向他人展现你的设计背后的原因已经他们在更广范围内与产品远景和目标的联系，聆听PM怎么说并搞清楚他们拒绝或认可的理由。 提出带有远期规划的强烈建议 你所能提供的一些证据和经验将支持着你更紧密地成为产品的一份子，而不只是一个辅助的参考者。你也能从纷繁复杂的因素中做出决定的过程中得到锻炼，如果你立志想做PM的话这些很有帮助。 展现你对工作的远期规划将使你能成为团队中最重要的成员之一，并且能展现你有担负更多职责的潜力 --- 不管你现在的角色是什么。 帮助PM走出办公室 PM不应该对客户和用户视而不见，尽管有人是这么干的。你应该通过询问他们最后一次见用户是什么时候来帮助他们，把他们带入到正式或非正式的用户研究中，或者给他们讲在用户访谈中的一些有意义的故事，邀请他们下次同去。如果被拒绝了，下次继续邀请。 如果PM能自愿去拜访用户，让他们带上你。除了了解用户需求之外，这也是一个你有时间向PM求教他们的观点、兴趣与目标的好机会。 如果你真的无法把PM带出办公室，那就把用户们带进来吧。在这种情况下，应该没有哪个PM(包括其他开发成员)能找借口拒绝和用户沟通。

学习并准备成为PM 因此，你想成为PM? 不知道从何做起? 除了上面提到的以外, 你还应该增加你在产品管理方面的知识，从中找到你为这一角色转变所需要的东西。 想想你迈向UE之路时候所做的事吧: 书、博客、会议、小组讨论、各种组织以及导师等，它们都发挥了很大的作用。如果你想成为PM，这些方式依然有效。 成为PM最好的条件是通过培训和会议。差点忘记提了，我们在IA 2007峰会: 你想成为产品经理 上有一个预备会议，这个半天的训练营上将会集中讨论如何从UE向PM的角色转变，包括如何更好地平衡你现有的技能以及怎样避免潜在的不足等。