Group items tagged

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

这种方法不错,但也带来新的问题：增加了每一个页面的http链接数。对于大流量和中等流量的网站，每个页面增加5个以上HTTP连接数，系统管理员可能就麻烦大了。两个可能解决办法： 把所有样式都放到一个文件里，而不是分成多个模块。这里的问题是，失去了框架只包含特定文件的灵活性，而且维护也变得麻烦。 有一个服务器端程序,动态把多个单个文件处理成一个响应。我还没看到这种做法，但如果做好了应该是很有效率的。以我上面框架为例，当请求（Request）base.css时候，而不是请求（Request）type.css , grids.css 等的时候，这一动态处理过程触发。这样一来,单个文件仍然可用，而在平台版本上整个框架也有效的。 总之，我们目标不是尽可能的抽象，这点非常重要。相反,其目标是提供了一个快速启动和更有效率的设计过程，这是绝对有可能去做过的。如果你过于的抽象，事情会变得混乱，太多的HTTP链接数会影响你网站的性能。记住：一个好的框架不是把事情搞更难更复杂，而是一个简单的从零的开始。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

常见的一些帮助形式 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. 搜索 通过输入关键字查找帮助的内容。这类帮助形式可以以最快的速度帮助用户找到他们需要的内容。但它对用户的要求也比较高，需要用户能够找到概括他们遇到问题的关键字。所以建立搜索帮助最关键的问题是建立的“帮助知识库”能够涵盖大部分用户所需帮助的关键字。

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

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

心流通道的概念。

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

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

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

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

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

「关系」！B2C 购物网站的购物者之间存在什么关系？有必要建立关系吗？会因为什么而开始第一次搭讪？建立起来的是甚么关系？能够长久维持吗？ 「关系」，是Web 2.0 唯一需要思考的关键

并不是所有的Web 2.0 服务都会走向交友服务。但是关系的建立与维持却是Web 2.0 赖以生存的基础。而其实，多想想人与人之间的关系是如何产生的，以及背后的人性心理是甚么，是很有帮助的。

Openworkbench（http://www.openworkbench.org ）也是一个开源的项目管理软件，其功能跟Project 2003相似，是一个值得大家去使用的一个工具，但对于中国很多软件公司，都是使用特别版的Project 2003。假如你很尊重版权，又不想使用Project 2003，那Openworkbench是一个非常好的选择。

第二、需求分析工具     需求分析工具用得比较多可能就是Rational Rose、MicroSoft Visio或MindManager，一般我们使用Rational Rose来进行用例分析，画用例图，画状态图；使用MicroSoft Visio来画出应用系统的结构图、流程图等。当然，对于MicroSoft Visio能画出来的东西，其实Rose也一样可以实现，只是，大家都是这么干，我们也没有必要专门去做一些特例的东西，特别是对于一些比较特殊的公司及行业。

二、系统设计阶段： 第一、系统设计工具     主流的系统设计工具有大家非常熟悉的Rose2003，不过，现在已经不叫Rose了，现在IBM最新的设计工具是RSA（Ration Software Architect），Borland Together，SyBase PowerDesinger，MicroSoft Visio，对于开源的系统设计工具也有很多，比如ArgoUML、DBDesigner等等。

第二、开发的技术框架     技术框架的选择是非常关键，一个好的技术框架，可以让我们的开发更加快速、团队的分工更加合理、系统能够支持多种数据库平台、我们的维护更加方便。     Web前端MVC框架是Struts 2。Struts 2可以说是Struts穿上了WebWork的外衣，其内核大部分都是采用了WebWork的技术，并且基于AOP的设计思想，让我们在软件设计上的能够更加多地体现“高内聚，低耦合”的设计思想。

第三、开发规范的定制     文件命名规范、数据库设计规范、编码规范、团队协作规定等等一些规范性的东西，需要在系统开发前就规定好，并且做相应的培训。QA也要做好监督的作用，定期做评审工作，对已发生的问题及可能出现的问题，及早发现，及早处理。

第四、开发工具的选择     团队一定要选择同样的开发工具，开发工具相同，软件版本相同。为什么要这样子做，其实假如你作为一个Team Leader，你会在管理你的团队的时候发现很多问题，而解决这个问题，那在项目编码前，就把什么东西都规定好，以免其中发生问题，影响整个团队的开发速 度。开发工具的选择也是非常重要的，目前企业用得比较多的开发工具有：Eclipse、Jbuilder、NetBeans、IDEA。

三、开发阶段 第一、配置管理工具 代码管理工具有很多，现在公司用得比较多的代码管理工具有CVS、VSS、SVN。 对于一个开发团队只有2-5个人，并且这两三个人是同一间办公室里，那使用VSS是一个非常不错的选择，个人觉得他小团队的管理方面非常好用。个人觉得 VSS唯一的缺点就是一个文件当被一个人锁定，那其他人就没有办法进行修改了，当一个文件为多个人所共用且开发团队人数较多时，这种问题将会显示非常严 重。VSS客户端跟服务器你都可以从Visio Studio里面找到。

对于一个开发团队有超过5个人，那此如选择CVS或SVN将是一个更好的选择，并且，假如你的团队是分散的，可能不在一间办公室或者根本不在同一个城市，那使用CVS或SVN是一个非常更想的选择。CVS的服务器一般是使用CVSNT或CVSServer。

四、软件测试阶段  第一、缺陷管理工具     软件你不能保证它永远不会错，只是，有些错误你暂时还没有发现而已；有些错误需要在某些特定的环境下它才会发生。就像Windows，时不时会有一些系统 更新文件要求更新。可能这些更新不是错误，只是一些系统安全方面的隐患。这些都可以算是软件系统的缺陷。那这些缺陷我们应该怎么进行管理？怎么进行跟踪 呢？现在缺陷管理用得比较多的有两个：第一个是开源的bugzilla，另一个是商业的JIRA。

六、软件维护阶段 第一、客户CASE跟踪管理工具     客户CASE跟踪系统相信很多做CISCO公司金牌代理的人都会用过。我们必须在公司内部建立相应的CASE跟踪制度。当用户使用系统的时候，发现一些问 题，那我们需要对这些问题进行录入并进行跟踪。像客户呼叫服务系统等等一些商业化的软件外面还是很多的，这些系统其实公司自己开发一个也是很快的。但必须 要有。这个也是提高整个公司整体服务形象的一种态度。

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的角色转变，包括如何更好地平衡你现有的技能以及怎样避免潜在的不足等。

Avatar服务的成功关键，在于其展示机会要多。用户花钱买头像，就是为了展示自己。如果曝光度不足，购买的意愿就会降低。这就是「有钱，要让大家知道」的心理，经营者首先必须制造曝光机会。

你写的Blog与上传的相片都是有形财产，无形财产则可带入「信用」的概念，亦即在一个社会中被认可的程度。例如，社区网站实行多年的积分及等级制度，就是一种被社区成员公认的个人信用。 一个用户在Web 2.0 网站中的活动必须要累积成财产，最后，除了在此地形成的关系链以外，用户还会因为这些虚拟财产的累积而再也无法离开。简单来说，「搬家」变得困难。 然而，这些制度大部分没有被好好运用，积分与等级仅是无关重要的数字罢了。经营者其实没有注意到，适当制造「穷人」以及「阶级不平等」才是一个社区网站进步的关键；而实体社会其实也是如此。

而经营者该做的事情是，定义出你的社区中，哪些是用户的虚拟财产，包含了有形与无形的。是所谓的活跃程度？关系链的多寡？还是被其他人推荐的次数？积分如何累积，如何变成等级？ 其次，等级与积分该如何被展示，被消耗，以创造真正的被拥有的价值，让用户自然的感觉阶级不平等的存在，适当的呈现这种不平等以促进整个社会（社区）向上的动力，进入正面循环？