Group items tagged

2. 富UI 现代 Web 中的 UI 变得越来越漂亮，越来越好用。过去的一年，Web 中的 UI 有了显著提高，有了一种接近桌面的感觉。Ajax 和 Flash 被广泛使用。 特别是我们比去年看到了更多留白区域，还看到很多现代的 UI 技术会显示用户同系统之间交流的视觉状态，比如，按钮在正常和被按下时显示不同的样子，用户同系统交互时能及时得到反馈，另外，越来越多的服务可以被用户定制。

1. 凸版印刷风格 这种风格有些出人意料，可能因为之前很少有人使用。该风格在在各种主题的网站中都有，但主要用于产品设计或在线服务类网站。

3. 透明 PNG 使用 PNG 实现透明虽然不被 IE6 支持，却在过去的一年大行其道。设计师们似乎正在尝试将背景图片和内容融合并实现一些印刷媒体的风格。比如，将 PNG 半透明图片放到整体背景的某个区域上，用来加亮显示这个区域，如标题或声明。一些 PNG 同名技术还用来实现灯箱框效果。 Smashing Magazine 去年曾有篇使用透明效果实现创意设计的文章，很多设计师在他们的作品中开始尝试这些技巧。有趣的是，透明效果常被用于页首和页尾部分，不过也有些例外。

4. 巨大字体 以前的文章中我们曾介绍过巨型字体设计，2009年，巨型字体设计还会风行，尤其是那些设计社，以及展示型，产品介绍型，或在线服务型网站，他们会使用巨型字体显示重要信息。 巨型字体设计中使用的字号往往超过36px，设计师们对字体编排注入了更多关注，以实现更漂亮，更连贯，更值得信赖的站点。

6. 灯箱效果 灯箱框是第二代弹窗，它们比第一代基于 JavaScript 的弹窗更友好，可以让用户将注意力集中到最重要的部分。这些窗口一般由用户的某个行为激发，并显示在其它内容的上层，他们有时候是半透明的，并包含一个关闭按钮。

5. 代用字体 设计师们还把更多注意力放到字体上，虽然经典的 Web 字体，Helvetica, Arial, Georgia 以及 Verdana 等仍占主流，一些代用字体正浮出水面（如 sIFR）。 有趣的是，这些字体会和设计无缝地衔接，设计师们似乎并非为字体而字体，而是要将字体同他们的设计结合在一起实现更漂亮的效果。

7. 媒体块 随着宽带接入的普及，用户现在可以承担更丰富的内容，设计师们也借机提出更有吸引力的内容。越来越多产品网站使用媒体块显示视频，让用户更容易理解这些内容。用户只需靠在椅子上看视频，不需要一步一步往下点，这些食品通常比较短，直奔主题，虽然很正规，但也包含一些娱乐性。 不过请注意，视频应当是你内容展示方式的次要选项，并不是所有人都有宽带接入，也不是所有人都喜欢有视频播放（他们可能正在后台听网络收音机或播放音乐），另外，也不是所有人都启用了 Flash 和 Javascript。

8. 杂志外观 传统印刷媒体设计中使用的编排技术也出现在 Blog 设计中，文章的编排，文字排版，图片甚至对其方式。基于网格的设计也很流行，但主要用于展示与产品页以及大型博客，极少用于公司网站或网店。

9. 滚动幻灯导航 幻灯片水平和垂直滚动，可以向不同方向滚动，当前项加大加亮。这种导航技术可以让用户快速直观地浏览站点中的内容。一般常用语娱乐性网站，另外，设计者还可以使用该技术展示他们的作品。

10. 在重点位置做形象展示 网站的左上方一般是一个站点最重要的区域，因为那是用户注意力最集中的地方。因此，在那个部位放上网站中最重要的信息是明智之举。 事实上很多设计师正是这样做的，不管是 Web 程序，公司网站，在线服务还是作品展示，设计师们将口号或简介性内容放在那里，并使用醒目的排版给用户以良好的第一印象。这些内容长短不一，不管哪种方式，但它们都占据可观的空间，一般横跨整个幅面，高度在250到400之间。不过这些形象展示性区域一般并不用于博客或在线商店。

3．帮助设施： 系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

4．合理性： 屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。

9．安全性考虑： 在 界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。 如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有 存盘而全部丢失。

6．菜单位置： 菜单是界面上最重要的元素，菜单位置按照按功能来组织。

7．独特性： 如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。

8．快捷方式的组合 在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些 在西文Windows及其应用软件中快捷键的使用大多是一致的。

5．美观与协调性： 界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。

10．多窗口的应用与系统资源： 设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。

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

第一步，由产品管理者总结产品应该传达给用户的”形象和气质”，作为关于文字工作的基本准则。（比如，Robin提出百度的产品气质是”简单，可依赖”）。“负责人”根据这个准则，再去翻翻书或者看一些关于界面文字表达基础原则的文章，总结出自己产品一些大原则的”行文风格”。（因为是’行文风格’，所以无需太具体，一般在WORD上不超过二页即可，尽量简洁以免耽误应用的效率和质量）比如：（以下是某项目中的部分段落摘抄，切勿照搬）“说明性和提示性的语言不得超过两行，不超过50字”“界面上不得体现大片的专业术语作为帮助信息”“保持文字的一致性，本产品界面中所有和ID相关的信息都叫’帐户’，..”；“使用通用语言，不搞一些特殊化的文字，让用户一眼就能看懂”“保持语言的简洁，既定事实不做重复。如，’你的好友列表中没有好友，请立即添加’改为’立即添加好友’，….”；“如果系统出错，则明白准确表述错误，同时以积极的语调给出建议。如，’抱歉xxx，您可以xx再试一下’，….”；……..

第四步，经过一段时间的”审核”和”规范总结”基本上产品的文字就可以有完善的统一指南了。一般情况下，不超过一个月一个创业产品的系统性的文字风格和规范就可以形成了。这之后”文字工作负责人”的工作除了简单过一眼要展示出去的界面，基本山已经不需要做什么类似工作了。这个时候，其实规范不规范已经不是最关键的了，可贵的是”所有在界面上写字的人都有了统一的行文风格和习惯”，我们的界面文字越来越专业友好。。

最后，按照我上面的方法算一下成本：（创业团队里面，很多事情都牵连在一起的，这里未算管理成本）一个文笔好的女孩”负责”：假设她的薪水是4000，这个工作需要占据他20%的工作时间，那么是800；会直接在界面上写字的假设有4个（20人产品团队）：假设他们的薪水是5000，这个工作平均需要占据他们5%的工作时间，那么总共是1000。一个月的总共成本：1800。 6、文字是产品情感传达的一个重要因素，特别是互联网产品，需要保证用户在不同情景中的角色感，需要迅速高效的转达准确信息。中文的世界上一些糟糕的文字表达屡见不鲜，啰啰嗦嗦的风格尤为突出。

三、Web2.0创新应用服务发展概况   Web2.0时代最容易被识别的特征之一就是博客的崛起。不论是个人日记或个人观点评论，在网络上都已经有相当多的网页供人阅览。以下介绍几个成功的Web2.0代表案例。   1.   Wikipedia   维基百科提供开放的平台环境供使用者编写百科全书。截至2007年6月止已有200多种语言的版本，合计超过350万个词条，其中规模最大的英文版已拥有100多万个词条。相较于大英百科全书等以专家为主体的传统编辑方式，维基百科将编写百科全书的权利开放给所有的志愿者。借着鼓励使用者参与以及使用者贡献内容，维基百科集合了众人的力量，成为善用集体智慧的典范。也是第一个C—内容产生方式上的标准范例。   2. Linkedin   Linkedin.com是一个基于6度分离(Six Degrees of Separation)理论的社交人脉网站。它提供了一个平台让使用者输入自己的人脉信息，之后Linkedin.com便能基于这些人脉信息提供一个介绍人机制（Referral System）。当使用者需要接触某个本身不认识的人时，介绍人机制便能协助使用者通过类似「朋友的同学的朋友」这样的人际连结路径去接触对方。截至2006年底，Linkedin已经拥有遍布全球420万名用户。通过这样更为精致的社会网络连结机制，Linkedin为中高阶商务人士提供了有价值的人脉介绍服务，成为Web2.0第2个C—社群上的成功典范。   3. Flickr   Flickr是Ludicorp公司在2004年2月推出的相片分享服务。当时外界普遍认为线上相薄服务已经定型，且市场已然饱和。然而推出之后靠着使用者的互相流传，以25％～50％的用户增长率跌破众人的眼镜，迅速成为Web2.0世界中的经典服务之一。Flickr在4个C上都具有相当的代表性：在第一个C—内容这部分Flickr通过使用者上传照片并填写标示信息，建成了庞大的图片资料库。在第2个C—社群这一块则是通过诸多社会网络功能，将使用者彼此相连，增强Flickr对用户的黏性。而在第3个C—用户体验部分则是将AJAX技术发挥的淋漓尽致，提供了用户简洁、直觉化、且操作性良好的界面。最后，由于Flickr开放了服务平台的API，因此产生了大量的跨服务整合应用，譬如结合Flickr与Google Map的GmiF(Google Map in Flickr)服务，见图下。这便是第4个C－跨服务整合的体现。     4. Salesforce.com   Salesforce.com是Web2.0在企业市场发挥的经典案例。它是一家提供线上CRM服务的SaaS(Software as a Service)厂商，该公司开放了程序界面给开发者，让软件开发商能开发出与Salesforce.com平台紧密结合的服务软件，也就是第4个C：跨服务整合表现。并提供了AppExchange线上软件平台，让软件开发商将软件上传，借此形成一个基于品牌策略的生态体系，见图下。通过这样的机制，该公司的CRM企业用户可以在AppExchange网站上直接寻找自己需要的企业应用软件，并进行即时的线上安装，迅速扩充自己使用的线上CRM服务的功能。

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

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

心流通道的概念。

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

2. 单页布局 单页布局是使用一个单一的页面展示站点的全部内容，这并不意味着站点内容少，这个页可能很复杂，包含了大量图形和动画效果，加载的时间也会有些长。比如，用户点击导航菜单后，该栏目下的新内容会在旧内容处通过渐入渐出，滑入滑出等动画效果显示出来，而页面其它部分始终保持不变。（白宫的最新网站的首页就有这个意思 - 译者）

3. 多栏布局 多栏布局（大于3栏）通常比较复杂，但通过适当设计，会对访问者带来更好的访问体验。最近几年，Web 内容爆炸，用户停留在一个网站的时间越来越少，就要求  Web 设计者尽可能有效地展示数据，既要让访问者多停留，又要让他们更容易发现他们希望看到的内容。

多栏设计一般用于杂志布局或展示型布局站点，一般使用网格布局技术实现。多栏布局一般使用概述/细节式结构，首先用多栏展示概述式内容，然后进入详细内容的展示。Mozilla Labs 就是一个很好的例子。

4. 巨型插图式与多变背景设计 象巨型字体主导当前 Web 设计一样，巨型插图风格设计似乎也正流行起来，巨型插图可以和巨型字体的结合使用，带来更吸引人，更生动的效果。 另外，设计师们越来越喜欢使用那些色彩鲜艳的图形提供背景，包含各种风格，抽象画，剪贴画，剪贴簿，装饰画，怀旧，水彩，有机纹理以及照片背景等。

5. 更多留白 这是近年来最值得期待，也是最有意义的 Web 设计风潮，设计师们在页面留白方面越来越慷慨。（这也是我非常欣赏的一种风格，只可惜在我们国内，仍有大量的客户认为满当当的页面说明你的公司实力雄厚 - 译者。）

6. "社会"网络元素 任何人都喜欢流量与认可，在 Web 设计中加入社会网络元素，可以鼓励你的访问者参与进来。（不过在 Web 2.0 日渐式微的今天，也许满页花里胡哨的社会网络元素正逐渐变得让人厌烦 - 译者）

7. 解释风格的导航 传统的水平导航条，一般是一些标题连接或图标链接，用户很难从这些短短的信息中真正知道这些导航所代表的内容，解释性导航会在栏目导航菜单上提供进一步解释内容，让用户更好地理解这些栏目代表的内容。

这类导航一般使用更容易表达内容的大图标，加解释性文字，鼠标 Hover 效果也必不可少。

8. 动态 Tabs 这类设计一般在页面加载时，将多个 Tab 中的内容一次性加载，通过 Javascript 或 CSS 效果，实现鼠标指向某个 Tab 时，该 Tab 中的内容立即显现。（微软官方站近一年来一直是这个设计风格的代表。- 译者）

树图 树图（Treemaps）可以将多列数据以方块组的形式展现出来，这些方块还可以加以不同颜色、以不同大小组织起来，从而以图形的方式来揭示数据内在的模式。这种用户界面可以用来表现复杂的数据关系（比如层次关系等）。 在网站Smartmoney website上，便有一个这样的例子。通过这种用户界面，浏览者可以一目了然的看到数百种库存的信息。下面的图例中，库存货物信息根据不同行业被分组，进而按照其市场资本的大小以不同大小的矩形 表示出来。而颜色则用来表示价格的升（绿色）降（红色）。 要了解一个公司的详细情况，则可将鼠标移至该公司所在矩形的上面（下图展现的是通用电气公司的情况）。

拖放 拖放（Drag-and-drop）这种用户界面设计采用了使用者所熟知的移动元素的操控方法（使用者可能有过使用微软视窗应用的经验）。在恐怖小屋的在线商店（Panic Room’s online store）的网页上，要将物品放入购物车中，浏览者可以点击带有加号图标按钮，亦可通过拖放动作来完成。 拖放动作比较简单，先点击你要加入购物车的物品：

50. 你们的程序员能看到测试用例么？MVM：要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。 51. 你们是否随便抓一些人来做易用性测试？MVM：要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。 52. 你对自动测试的期望正确么？MVM：别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。 53. 你们的性能测试是等所有功能都开发完才做的么？MVM：不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。 54. 你注意到测试中的杀虫剂效应了么？MVM：虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。 55. 你们项目组中有人能说出产品的当前整体质量情况么？MVM：要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。 56. 你们有单元测试么？MVM：单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。 57. 你们的程序员是写完代码就扔过墙的么 ？MVM：大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。 58. 你们的程序中所有的函数都有输入检查么？MVM：不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。 59. 产品有统一的错误处理机制和报错界面么？MVM： 要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。 60. 你们有统一的代码书写规范么？MVM：要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。 61. 你们的每个人都了解项目的商业意义么？MVM： 要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。 62. 产品各部分的界面和操作习惯一致么？MVM：要这样。要让用户觉得整个程序好像是一个人写出来的那样。 63. 有可以作为宣传亮点的Cool Feature么？MVM：要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。 64. 尽可能缩短产品的启动时间MVM：要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。

65. 不要过于注重内在品质而忽视了第一眼的外在印象MVM：程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。 66. 你们根据详细产品功能说明书做开发么？MVM：要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。 67. 开始开发和测试之前每个人都仔细审阅功能设计么？MVM：要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧” 68. 所有人都始终想着The Whole Image么？MVM：要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。 69. Dev工作的划分是单纯纵向或横向的么？MVM：不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。 70. 你们的程序员写程序设计说明文档么？MVM：要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。 71. 你在招人面试时让他写一段程序么？MVM：要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。 72. 你们有没有技术交流讲座？MVM：要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。 73. 你们的程序员都能专注于一件事情么？MVM： 要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5 个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的 资源了。

74. 你们的程序员会夸大完成某项工作所需要的时间么？MVM：会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。 75. 尽量不要用Virtual HeadsMVM： 最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对 Resource Manager的。

5，文字的视觉设计应该完整的融入整个产品视觉中。很多视觉设计师喜欢把文字融入到界面的造型中去，得到非常棒的视觉效果，这个很值得学习。从最基础来说，我们的文字在界面上和图形一样应该有主次有深浅，关于这个部分潇潇同学已经有了很好的表述，我只补充一个例子： 图片网站本身应该表现的是“图”，文字只是其辅助信息。flickr在个人首页里每个图片下面都有四行的文字，但我从未感觉到他碍眼或者多余，因为flickr用的是很柔和的粉红和几乎可以让我第一视觉点忽视掉的灰色；而yupoo在个人首页里每个图片下面只有三行文字，可每一个我都觉得他们扎眼，因为yupoo用了重灰色粗体、绿色粗体、重灰色、绿色四种表现方式，而且字体都还不一样。

6，尽量让文字自身可以起到“推销”产品的作用，而且”推销”的不只是产品气质。文字其实可以像图形设计一样在情感上给用户以触动，从而积极的达到对于产品的“推销”。比如，很多人已经把“注册”改成了“立即注册”、“马上注册”；比如，baidu.com的“更多”页面最上面以前是“推荐使用”后来改成了“试试看”，虽然只是少了一个字，但给用户的感受和尝试欲望马上就很不一样；比如，某电子商务网站会在注册要完成那里说：“太好了，你还需一步就能成为我们的注册会员”比如，… .

4，界面上的文字应该具备该产品需要传达给用户的气质。 这里往往遇到的是怎么做的问题：怎么确定产品要表达什么样的气质？怎么确定什么样的语言风格才算是表达了这样的气质？在稍微大型的企业我们一般有很多种方法可以做到，比如找很多用户让他们说出他们需要的、比如通过情绪板、比如通过颜色分析等等。但在创业公司我一般建议大家实用一点：1>N个很了解产品定位的人坐到一起，每人一个贴纸写下来一个你认为可以描述该产品的句子或者事物；2>把所有人的描述拿出来大家讨论，把每一个用二维分析的方式摆出来，最终得到一个大家都认可的结果就是这个产品应该表达的气质；3>每人N个贴纸，根据刚才得到的结果，结合自己产品的环境写下来你认为要表达这种气质需要什么样风格的语言；4>用第2点中同样的方法得到一个统一的结果，（比如：严肃、简练、..）5>安排一个专门的人写一份简单的指南，描述这个结果具体执行时一些需要注意的常见问题和原则。（比如：既定事实不再重复、不用反问语句提问用户、即时说明文字不得超过20字、…）

交互设计

对中文而言，至少 font-size 和 line-height 之间使用黄金分割率是不适合的，假如中文字体使用 12px 的话，最佳行高是 22px，如果字体使用 14px 的话，行高应该使用 24px 。另一个例子，在表单中，输入框的宽度应该是标签文字的宽度乘以 1.62。而对于显示在 Web 上矩形来说，它的宽度应该是高度乘以 1.62。

Web 设计师同时需要很好的计算能力，至少要在旁边放一台计算器，为了节省时间，作者建议在设计中随时记住一个 62/38 原则，在任何需要分割的地方，都使用 62% 和 38% 作比例。对于需要分割成三份的场合，可以先按 62%，38%原则分成两份，再将那份大的按 62% 和 38% 的比例分割