除对概念部分的细化、对方法引入层级外，还有如下小调整：

1. 优化图形并分级；
2. 完全以角色为出发点，调整了箭头方向；
3. 不再乱用颜色，调整并减少、统一了关系色彩；
4. 更正并清晰了几个措辞；

很早已意识到理念部分有问题，但是没有明确答案，太多了、之间而且还有重叠。搞清楚一两个容易，每个都有基础认识，并且建立联系很困难。与朋友探讨概念，都是看对方的理解能否促进自己某些方面的认识。如果有分歧不用争论，因为这种东西光说是没用的，一千个人眼中就有一千个哈姆雷特。

以用户为中心的“用户”仅仅是个代名词，代表一种哲学理念。整理前对目标的理解长期停留在“用户友好、开发者友好、搜索引擎友好”之上，无论如何都无法完全对应“实现”指标，后来Realazy这篇07年的观点给了我很大启发。

在理解用户友好、开发者友好的前提下，再次对照大量Search Engine Friendly（以后简称SEF）技术参考，基本可以搞清楚所有小伎俩的来龙去脉。总能看到有人把SEO, SEM等名词与之混淆，目地是做概念的打包营销，然后忽悠土鳖有钱人“效果老好了”。

完全可以清晰看到，网络上流传的所谓“SEO技巧”入门内容基本都属于SEF技术范畴，而且对于专业设计师&工程师来说没什么技术含量。另外，圈内比较有影响力的几位“SEO高手”，我承认他们是有SEM丰富实践经验的营销行家，但对设计&工程的理解并不入流。因此我对利用SEM概念推动设计的说法特别排斥，随着对两年前质疑的深入了解，做出如下补充：

1. 所谓SEM职能是做市场&销售（网络营销）；
2. 准确SEF职能是做设计&工程（搜索引擎友好）；
3. 真正SEO职能是做研究；

对终端用户的体验友好指标，很多朋友受Peter Morville在04年的观点影响较大，但我认为Paul Veugen在Peter观点基础上于本月的总结更简炼。层级部分大体参考JJ Garrett在00年的观点，但我更认同Peter Morville在07年的总结。有兴趣的同行，还可以参考Richard Dalton在JJ Garrett观点基础上于07年的总结。

初学避免追求概念，但随着自我积累在认识方面的提高，多参考同行总结是条捷径。当然，具体能否理解、能理解多少，得看我们各自的实践经验，学习本身就是个分享、提炼的迭代过程。

2009.3.29 细化并调整交付物部分定义。v2.1
2009.3.26 增加图示清晰度。

转自一叶千鸟的博客，原文链接：http://blog.rexsong.com/?p=5359

第一步：做好准备工作

你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。

建立良好的交流也非常重要，它会影响着产品团队。如果你的准备工作做的够好，你也会变得越来越有信心和说服力。

第二步：确定产品的目的

任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求，你的产品如何达到这个需求。

产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起来很简单，但是也只有少数产品才有这样的价值主张。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有工作需要做。也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。这个价值主张可能需要满足公司的产品战略。注意你不需要阐述太多的细节，从某些方面来说，一个有价值的观点应当是越简越好。

产品需求需要确切的指出这个产品发布的目标，同样的这个目标也有优先之分。例如，你的目标可能是：1）易用，2）零售价不足$100，3）和前期产品很好的结合。然后你需要说明如何去测算。对于“易用”这类项目，你需要明确指出产品可用性达到某个水平。这是通常用目标用户来定义。可用性工程师能测算出你的产品对目标用户的可用性，也测算出可用性问题的严重程度，同样你可以说明没有重大的可用性问题。

这里的关键就是让每个人都知道产品成功的时候是什么样，还有给产品团队在设计和实施中遇到问题如何进行取舍的指导。

第三步：确定用户原型、用户目标和用户任务

现在你已经明白你想要解决什么问题，下接下来就要深入了解目标用户和顾客，在这步中，和你的PD（产品设计）紧密联系非常重要。

用户原型

在这个阶段，PM需要和很多用户交流，需要花费大量的时间去直接观察和讨论。现在我们需要对用户和顾客进行分类，然后决定那一类是我们的首要用户。

比如你正在做一个像eBay一样的互联网拍卖服务，你同时拥有买家和卖家，在这之中还有使用频率少的用户和经常使用的用户，不难想象还有个别特殊的用户，比如团体公司采购者。

PM（产品经理）和PD（产品设计）需要首先确定类型是最重要的，然后尽量对这个用户群的特征进行详细的描述，以便使用这个模型去指导产品的设计。这个模型通常称其为“人物角色”。 虽然是想像的，但是应该是典型的、可行的和真实的，让你能够使用。这个想法来自与一个能代表这类用户的本质的原型。

举个例子：

“里昂是一个超级卖家，46岁，男性，居住在Fresno，经营小型摩托车配件。虽然他开着一个小店，但是他的生意大部分来自Ebay,每个月平均有400多次交易。他出售的东西品种非常多，但是他最受欢迎的商品还是哈雷戴维森的负重袋。他自己拥有两个哈雷，还开着1993年的丰田皮卡。里昂已经结婚了还有两个小孩。

里昂买电脑仅仅是因为他需要使用Ebay,除了ebay和电子邮件很少再使用其他东西。里昂已经在Ebay上销售产品已经三年了，他学会了在ebay应该掌握的东西，他非常自豪的拥有超过5000的信用度。如果Ebay更改了网站，特别是销售的过程方面，对于他来说改变习惯、学习这些变更是非常困难的。 里昂已经形成了自己的习惯，星期一列出销售的商品，星期五拍卖结束，设法让在收到货款的几个小时内出货。”

但愿这样的描述能让你了解里昂和知道他是怎么来的。当我们考虑新功能时，我就要问问自己里昂会是什么发应，为了让他能顺利的使用这个功能我们需要做什么。

注意缩小范围，让他仅仅描绘必不可少的。满足所有人是徒劳的，通常最后没人会满意，所以尽量提出几个最重要的和最流行的角色描述是非常重要的。同样，如果你不去精确的定位你的目标用户，你就只会存在模糊的概念，你会发现理解你用户的反应非常困难。你要倾向于设想，让你能更像你的用户。

用户目标（用户意愿）

一旦我们确定并描绘了我们主要的用户类型，我们就需要找出用户在使用产品中的目标(想要干什么).这听起来很简单，但是解开根本问题是非常具有挑战性的，特别当你周围的人告诉你你已经解决了他们想要的。

从CEO、销售代表、工程师到客户，每个人都太兴奋而不能帮助你找到解决根本问题的办法，他们会告诉你在某个地方添加一个快捷按钮，或则添加一个功能仅仅是因为竞争对手有，或则是改变成他们喜欢的颜色。

最好的解决办法取决于清晰的了解到底什么问题需要解决，每个用户模型可能有不同的目的，需要在用户原型涉及的方面中进行寻找。有可能将来某个功能解决的问题并不是主要用户需要达到的目标之一。

用户任务（tasks，用户为达到目标使用产品而需要做的任务）

掌握了用户原型与他们的目标愿望，我们就开始着手设计任务来满足他们的目标意愿，这是产品制作进程中最核心的部分，也是创造力和创新力被激发的地方。

许多优秀的产品仅是用更好更新的办法解决一个已有的问题，有时候这种办法仅仅是应用一个种新技术，但是大部分是来自深刻的见解而使一种新方法的产生。例如TiVo（美国市场占有率第一的数字录像机）在电视节目录制的老问题上面想出一个全新的办法，让顾客更加容易地实现他们的目标并且建立了电子设备一个全新的类别。

注意我们虽然谈到了目标和任务但是还没有谈到具体的功能，这些功能都需要达到用户目标而必须的。你以后会发现许多功能都是低优先级或则是完全多余的。

以“必须功能”这个理由可以排除很多功能。讽刺的是，你用越少的功能，你的产品被发现得越来越强大。这是因为产品的功能越少，你的用户就会发现并使用更多的功能，成功的使用越来越多的功能他们就认为你的产品非常强大。这些理由都是违反我们直觉的，我们大多数人都不能和我们的用户一样，我们在自己的行业中愿意比用户花费更多的时间去探索功能和容忍复杂性。

第四步：定义产品原则

现在你需要开始把你的需求和用户体验定义成详细的要求。同时你仍然会面临着许多的决定和权衡，为你的产品标准作出最佳的决定是非常重要的。

在大多数的产品团队中，每个成员都有做好产品的原则，但很少有两个人有同样的想法，这些差异都会导致不可思议的结果。
尝试和制订一系列指导整个团队的产品原则是非常有价值的，这些原则需要具体到域名和项目。

用TiVo举例，在产品团队工作开始时，以下这些产品规范就被建立，并在团队里传达：

1.它是娱乐的
2.一个傻瓜式的电视
3.一个该死的视频设备
4.平滑柔顺的
5.没有模式和深层次
6.尊重观众的隐私权
7.像电视一样强大

这些规范很大的影响到产品的定义而且在很大程度上加大了难度，但是他们确实是成功产品的来源。比如易趣的口号就是：1、易于使用 2、安全 3、有趣

它将在该项目中，在面对众多问题而作出决定的时候进行指南.

第五步：产品原型和检验

这是一个拿出你想法的阶段，创造力和创新力拿出成就的地方.

很多人都容易犯一个常见的错误，他们对产品设计规范太有信心，结果一旦得到beta的测试他们就必须调整产品。但是肯定beta测试版并不是进行重大改变的时候，所以才会有许多首次发布的产品离目标太远。

对于许多产品来说，这个时候你可以用大量的原型做很多的实验。首先，下面的三个非常重要的测试你可能需要做

可行性测试
一个直接的问题就是产品是否可以开发，你的工程师和设计师应当介入技术的可行性调查和探索可用办法。有些办法是行不通的，但是有其他的办法可行是非常有希望的。
工程师会发现在产品的某个阶段不可能逾越，现在知道比以后知道要好。

可用性测试
产品设计师将要和你紧密工作共同提出产品功能，让它能适应不同的用户。可用性测试常常会找出遗漏的产品要求，同时确认产品最初的要求是否是必须的。在你拿出一个成功的用户体验之前需要多做一些测试工作。可用性的目的是在真正的用户身上测试，从产品目标用户得到质量反馈的测试是非常艺术和科学的。当然产品经理和产品设计将模仿使用，但是实际是没有人能取代真实的目标用户。

概念测试（Product Concept Testing）
光是可用和可行是不足的。真正的问题是你的用户想要购买吗—你的用户有多喜欢-你做的有什么价值。这测试可能与可用性测试联系在一起。

对于一部份小产品，您的想法写在纸就足够了，但是对于多数产品，为了预计产品是否达到目标，复杂用户互作用或新技术的使用、某种形式原型都是非常重要的。

原型也许是一个物理设备，或者它也许是软件产品的一个预览版本。关键是它需要足够现实，您能用原型在实际目标顾客身上测试，并且他们可以给您质量反馈。

以前做原型主要有两个障碍。第一是缺乏良好的原型工具，需要花费很多的时间制作原型；另一个是管理方不知道原型和真实产品的区别，在不可预计的情况下，按照最终产品来要求原型。

今天有优秀的原型设计工具可以让工程师或设计师快速的制作原型，可以有效的模拟未来的产品以达到必要的程度让实际用户进行测试。而且大多数管理者都知道模仿和实际的区别 — 就如同缩小比例的房子模型和真实的家一样。

在实际去做产品之前去检验你的产品是非常重要的。一旦实际的工程开始，作出重要的变动会变得非常困难，花费也会变得很高。

第六步：验证和质疑

当你认为你弄懂了你需要解决的问题，现在是时候开始验证和质疑假设。

假设甚至当作不知道是很容易的，但是切勿把不可知的结论当作指引，那会妨碍你获得成功。天文学最初定义是研究太阳和其他行星如何围绕自己转，本身的定义就是一个臆断，反而阻止人们获得真相。

第七步：写

当然你需要把这些都写下来，大多数的PRD都是word文档，但也有一些是帮助文档，PowerPoint，或则写在白纸上。当然用什么格式不是很重要，重要的是让团队成功能轻松的看懂，不会遗漏，还有就是PRD可以随着项目开发而更新。

记住对话是两个人之间的，但是PRD是要沟通整个小组。你也要记住获得产品的销售才是是重要的，所以不必担心要有什么漂亮的外观、PRD写的有多厚，只要它是可读的、可理解的、是需要的内容。

PRD文档主要有四个部份组成

产品用途
你的工作就是指出目标，团队需要知道他们的目的是什么，目标说明要尽可能的明确，请确保你的内容包括：
*那些问题你要解决，不是解决方案
*谁是目标用户
*细节很多，但是大图片必须清晰
*情景描述
多开展集思广益的会议和临时口头的讨论，从而更好的写出来，更会让团队深入了解。

产品功能特性
产品需求文档最主要的当然是需求。 具体的需求完全地将取决于您的领域，但是不管你是什么行业，您的产品团队将受益于陈述需求的清楚，毫不含糊的要求，而不是模糊的解决方案。
描述每个功能的互动设计和使用案例。您必须非常清楚每个功能和用户体验，还需要给工程团队留下足够多的灵活自主空间。
同样重要的是确定那些要求满足哪个目的。这里就需要提到“需求跟踪”，对于关键的产品这是一个重要的流程。每种产品规范可能受益于清楚确定那些要求满足哪个目的，如果某人决定削减要求，想要深入了解就会非常困难。 从要求到目的明确说明将会是文档更加清晰。

发布标准
发布标准经常是不断变化的，但是好的PRD应该考虑到为每种标准定一个最低要求。典型的如：性能，可测量性，可靠性，可用性，可控性。

时间进度
其中很困难的一个问题就是描述产品需要的时间进度表。随便列出一个时间是没用的，你需要描述环境、动机、预计目标。你需要整个团队都和你一样达到预计目标，最终完成一个成功的产品。

第八步 优先级

除了明确的要求，对每一个您的要求给予优先和排列秩序是很重要的。多数产品经理，如果他们给予优先级，一般都是表明要求是否是“必须有， “重要”或“希望拥有” (或其他一些分类系统)。分类是很重要的，不可掉以轻心。

产品经理对任何一个标记“必须拥有”都需要有高度的标准。如果还没有找到必须拥有的功能意味着产品还不应该产生。所以小心标注“必须拥有”，这些标注“必须拥有”的功能直接反应出产品的核心价值。
“重要”的分类也很重要，在产品销售前只要有机会就要满足这些功能。
“希望拥有”产品团队也应该注意到，即使大多数也都没有实现，在未来版本也适当的慢慢实现。

这些有时候是不够的，从1到n每一个分类优先排序都是很重要的。有几个原因：
首先，上市时间总是被关注，并且日程表经常下降，您说不定被迫使削减有些特点为了尽快进入市场。 你也不想产品团队先开发简单的功能而放松重要的功能，导致最后客户使用的关键功能还没完成。
其次，在产品设计和开发阶段，团队将会发现更多的问题产生并解决这些问题，所以很有可能有更多关键功能出现。优先顺序会可以帮助你如何平衡以容纳更多的功能。
这点就是说产品经理如何不给出优先级和重要等级，其他相关较少的因素也会跟着无法确定。

整个PRD是一个不断完善和思维提高的过程，明朗锐利就是可以成功的产品的，模糊就是失败的产品。在争论最激烈的时候也能容易做决定，并且帮助工程师做出计划。

第九步 测试完整性

现在你有一个PRD草稿，你需要测试它的完整性。工程师是否可以充分了解并达到目标？OA Team（质量管理团队）是否有足够的信息来做出测试计划，是否可以开始做案例？

当投资人或相关人审核了PRD，确定了各个需要说明的方面，所有的问题得到解决，现在你就可以按PRD进行产品开发。

第十步 管理产品

在产品实施期间，就算是最好PRD，也有不计其数的问题被解决。解决所有PRD中存在问题，如果不在PRD中就写进去。你的任务就是迅速解决问题并记录在PRD。

如果你做了你的工作并准备记录在PRD，项目审查就会变得非常简单，因为任何一个部份都历历在目。

记住PRD是一个“活”的文件，在要跟踪记录在产品开发期间的所有功能过程。最后你会发现很多额外的东西，如果你认为是必要的就在PRD中写进。

本文大体已经结束，全面的阐述一个PRD的产生和管理过程，感谢SVPG的分享。接下来有空闲时间我会整理上传一份互联网行业的产品需求文档模板在本页面，供大家下载。

我看”必应”

最近两天总是能看到关于bing的新报道涌现,先是老大发的一篇Bing谷歌雅虎三家搜索性能大比拼的文章.对BING有了个初步的了解,然后是腾讯的西贝同学关注微软Bing的文章.慢慢地我也对微软的”live二代”有了浓厚的兴趣.一开始感觉它的名字很怪,官方给的解释好象是”有求必应”的意思.不过也有些不同的意见,今天同事之间调侃:”名字多难听啊?谁没事找”病”啊?虽然是句玩笑话,也并非空穴来风,大部分评论都直指名字难听.不管外界评论好坏,我想用一种全新的视角,客观的看待微软的新搜索引擎.
背景
微软新搜索Bing上线前，微软已经开始了网上品牌推广攻略。微软专门建设的两个宣传网站已经投入使用。这两个网站分别是“决策引擎”

以及“发现Bing”.

“发现Bing”网站主要介绍新搜索的功能特色，设计理念等。微软甚至提供了专门的桌面客户端工具，以帮助了解Bing的最新技术和动态。该网站还有若干个视频，主要是微软的开发人员和品牌专家介绍一些幕后故事，比如为何要选择新设立一个“Bing品牌”等。
在另外一个“决策引擎”网站中，微软试图通过视频等方式传递“决策引擎”的搜索设计理念。微软称，传统的搜索引擎返回海量的搜索结果，需要用户花费大量时间去排除无用信息以及细化搜索。而微软希望通过对这些信息进行分门别类的“组织工作”，为用户决策提供最直接的帮助。
在旅行、本地、购物和医疗信息三个门类的搜索中，微软提高了搜索结果的有效性。Bing首先返回的是经过分类和组织的信息，更接近用户的搜索需求。
中国B2B研究中心作为生意宝下属负责该搜索榜的B2B研究机构在试用体验后发现，在很多方面，Bing确实胜过了雅虎搜索。在搜索展示中，它采用了微软之前收购的Powerset语义搜索的相关技术，在搜索结果页会给出许多相关的搜索建议来优化搜索过程。另外，当鼠标经过某个搜索结果时，Bing会弹出一段文本提示，不需要逐个点击搜索结果就能知道，这是否自己需要的内容，节约了大量的时间。
新功能
1、Bing的搜索结果：与原来不同的是，Bing的搜索结果页面有三栏，而非两栏。中间一栏与原来的搜索结果没什么不同，右边的一栏是广告。
左边的一栏是新增的，它将包含搜索相关和一个搜索历史。左边栏上的一个有意思的功能是分类搜索，它与你的搜索相关。例如搜索一首歌，分类栏里会出现歌词和演唱会门票，而搜索苹果的“iPhone”时，分类搜索栏将显示相关的应用程序，可以直接导航至下载。
2、显示广告:凭借Bing这个搜索引擎，微软很可能重振显示广告的业务。因为Kumo将可以提供更精准的搜索。
3、内容预览：这是Bing的另一项新功能，有了内容预览这个功能，用户就可以不用点击链接直接看到页面，火狐的一个插件也提供类似功能，而Bing会将其进行集成。
交互与体验
首先打开BING的主界面,带背景图的搜索框,背景图片是随机的,有点花哨区别于GOOGLE的简单.给我印象最深的首先是搜索图片的体验:图片预览与滚轮式图片浏览机制.
图片预览:当用户的鼠标移到图片上会看到放大图,伴随有相关文字信息提示.
滚轮式图片浏览机制:用户可以一直上下滚动浏览图片,因为BING没有翻页机制.
最后是视频搜索:用户把鼠标放在视频上会自动播放预览.这个体验到是瞒有意思的.不过更有趣的是BING搜索到的结果,让用户特别意外,比如输入用户体验设计师查询视频竟然出现”AV”.
除了以上几点我发现还有一个问题当我输入关键词的时候,下拉框推荐的是我曾经输入过的词汇,并不像百度与GOOGLE那样推荐词汇.
其实,BING的问题还很多,从6月2日正式发布,只是短暂的停留了10几个小时就已经被屏蔽了.有人说是微软整和产品,有人说是被”和谐”了.不管怎么样我希望BING可以把交互与用户体验做的更好,最重要的是结果准确更加贴近用户.在中国这样的大市场里,不去研究用户与当时的国情是很难和GOOGLE 与百度抗衡的.

源地址：http://www.aliued.cn/?p=2084

声明：本文版权归作者Alite所有，作者与文章出处:http://alite.aliued.cn

我是典型极简主义（包括沟通），但是对事物相当有耐性的极端完美主义性格，擅长追本溯源。当我真正意识到自己性格缺陷的时候，便开始在工作中有意做取舍。很多事情不是做不了，而是成本太高，性价比又太低，找不到符合价值观的成就感。

产品经理不是唯一选择

个人认为不管软件领域还是互联网领域，产品做不好的根源，主要是缺乏Senior专业技术人员，但更重要的是业余管理人员泛滥。这也许是任何行业、技术高速发展中，不可避免的问题。

曾在产品经理的责任中提到“设计做的再好不一定能胜任产品经理，因为两者的职业素质和职责不同。”在软件领域还有个说法“国内软件做不好，是因为很多人刚在技术、业务上小有积累、小有成就，就忙不迭去做管理、开公司，觉得那才是提升。”

归根结底，前不久鲍鹏山老师点评武松的那个观点也许值得我们认真反思“中国文化中很不好的一面，就是人人都特别看重体制里面的位置，把这些东西看成是自我的最高价值。”

管理与专业是两条路

最早接触这个概念来自外企，当时觉得工程师薪水比VP高，在国内是件挺稀罕的事情。这里有篇由Sun员工创作技术人员的晋升路线，在软件技术领域具体有一定代表性。文中提到：

严格基础训练到MTS4后开始做选择，继续做Engineer？还是换口味做Manager？基本经过之前的考验后，我们对自己都能有清醒认识。两套体系都分别有对应层级，但再往后的进阶几乎已不是技术含量问题，而是我们的天份决定能走多远，说白了就是“性格决定命运。”并且在Senior位置上退休也不是什么丢人的事情。

给雅虎干活时，了解到雇员也有P和M两套晋升体系，P代表Professional，M代表Managment。分别用数字代表level高低，涵盖了做设计和工程的两类技术雇员。相比Sun不够细致，但也许更适合互联网公司的高速发展。结合Sun的经验，个人认为合理的产品团队组织结构如下：

设计“师”不是随便说的，产品设计师里再细分职能的信息架构师、交互设计师、界面设计师、视觉设计师根据团队，以及产品要求制定。也就是个名片上的title问题，通常不建议划入组织体系。因为强大而灵活的团队中，设计师职能可能会变，而且兼多个职能也正常。

现实中最常见的问题是专业人员不服管，有两种可能：一是M的管理手段太弱，喜欢对P发号施令而无法协调，经常被顶撞；二是M的理论基础太菜，与P没有共同语言而无法沟通，经常被鄙视。要知道在团队里，只有英雄之间才可能惺惺相惜，中国传统文化更讲究“士为知己者死。”大家能在一起工作绝不仅仅是为了钱。

比较崇拜的收藏家马未都先生在访谈中提到“我不大善于跟人复杂的交往，我希望单纯，但是人对人之间一定是复杂的，人对物之间就显得简单。”我想真正的设计师听了都会很有感触，因为只有与事和物打交道，拼的才全是我们自己的能量。

挺瞧不起这个“管理是一门艺术”的说法，好像做管理是个很牛的差事似的。这不废话嘛，任何事情做到高处都是艺术，中国古代经典中类似说法多去了。真正的Professional应该懂得如何看无字书，如何弹无弦琴，理论和创新都值得一辈子去实践，积累和沉淀才是王道。

© 一叶千鸟http://blog.rexsong.com/?p=6054

　　CDC交互设计方法论的思考其实是个永恒的话题，在内部管理大会上有人演讲，提到team 2.0概念，让我深有感触，结合我们自身在实践中的设计方法及设计流程，在平台化，多人参与，分享互动，个人贡献的价值体现方面我们又该有什么样的思考？关于设计流程化大家慢慢有了一个共识，就是：除了完整，规范，还要敏捷，有自我完善的能力。形象一点说也是要从1.0往2.0升级，那改革成功的标志应该是什么？随着公司业务的蓬勃发展，CDC承担的设计项目也越来越多，随着项目经验的逐渐丰富，我们发现在今天的研发环境中，存在着许多挑战：人力成本预算限制，多并发设计的进度压力，交付高质量设计方案，提供易学易用型的设计工具，学习和开发新的设计技术和尝试新的量身定做的项目管理工具，这一切都是为了从多角度完善设计方法，敏捷设计流程，进而达到我们期望的理想设计目标，取得源源不断的内部及外部竞争优势。

　　从2006年上半年CDC成立开始，CDC交互设计一个很重要的使命是，将多年的设计经验总结提炼成一套设计方法论，进而变成一个可复用，可持续改进的设计流程并加以执行。但是只有一两条设计流程其实是不够的，正如Web 2.0没有一个明确的界限，而是一个重力核心一样。不妨将交互设计方法论2.0视作一组原则和实践方法的组合，由此来把距离核心或远或近的诸多方法论和管理技巧聚合成为一个类似星系的网络系统。

CDC交互设计方法论的几个维度思考：

　　用户参与

　　一个设计项目从立项启动开始，我们即明确以用户为中心的设计理念，在以满足用户需求为目的的交互设计过程中通过多种手段来理解用户，理解他们的使用环境，限制（包括各种生理，心理限制），特征和任务目标。同时在需求提炼（主要是可用性需求），设计，评估及测试使用过程中，由交互设计师主导，把persona逐步还原演绎为成可供设计参考的use cases。

　　经验法则：请不要“虚拟用户”也不要“将产品需求方当用户”，很简单的概念，但是经常设计师在这一点上常常犯错，当产品需求方讲通过层层筛选提炼确定需求提交过来时，用户的需求常常隐藏较深或者被有意无意遗漏，但是当设计师直接接触用户，并提供一个途径让产品能够被用户测试或使用到时，用户必定能针对产品说出其优势与不足，同时设计师掌握到第一手的用户资料，也拥有了更大的话语权。设计师怎么样掌握到第一手资料？我想这次和大家制定的H1 KPI中有结论，有一位内部的同事总结的很好，借用一下，大家共勉：“像观察自己的BABY成长一样，观察用户的行为、发掘用户需求”。

　　需求管理

　　这里包括两层意思，首先，对需求来源的格式加以定义，保证设计需求的明确化，规范化是很重要的一个前提，根据多年经验，设计变更太多，设计稿通过率低很重要的一点是需求不明确，变更很随意造成的。基于这个教训，我们在流程上也特意强化了需求交接的规范，例如产品应该提供什么产出给设计师，设计师如何收集整理需求并条理化等等。

　　另外，我们也看到，业务需求和功能需求最普通，最容易收集。但用户界面的特色，可用性，可维护性和扩展性等需求缺往往被忽视。如果没有特意制定目标，用户界面，用户体验上的特色要不就被盲目定义，要不就没有定义。而且我们可以看到作为一个互联网公司的产品，通常以内容性设计为主，在用户界面上总是被要求精益求精，相对于IT业界的代码水平，与用户界面相关的代码量通常增长在30%～50%以上，用户对界面特色的理解和掌握总是需要花费更多的时间和精力，但从交互的三层结构模型来看，用户对软件的体验，对交互设计而言的挑战就是“如果想确保产品容易使用，最重要的是什么？”，因此，对于易用性，可维护性和扩展性等可用性需求，必须制定一个明确的，可看得见的定义，在CDC的交互设计流程中，我们把它叫做“可用性需求收集和定义”。这样一来，设计目标遵循项目计划和工作成果评估所能达到的程度将是可量化，并且是可测试的。

　　经验法则：明确需求，一旦确定，就必须对它进行控制和量化管理，交互设计师作为团队成员，必须清楚用户和项目团队不断提出的需求和功能，并打造成为设计方案的基石。

　　制定计划

　　对大多数的项目而言，项目团队总是对进度想象得很乐观，对进度保持乐观很重要的一个原因是有很充分理解当前进行的工作。但作为公司的产品现状而言，我们可以看到行业的用户界面技术创新，其速度是高于开发实现技术的。设计师想要做到的许多UI风格和特色尝试其实涉及到大量的细节，预期行为以及重复性，而这些并不能被项目组其它角色快速领悟到，并被以风险和技术实现限制的理由加以扼杀，这也常常造成一个现象“理想的设计永远是在下一个未开发版本中”，基于这样一种设计体验，CDC交互设计方法论中特别强调了对设计需求的版本化细分，制定计划，有步骤，分阶段的实施，对遗留问题有跟踪。对未实现设计目标有明确时间定义。

　　经验法则：对于设计需要有切合项目现实的实施计划，要宣导团队认可的设计目标并细化成可实现，可跟踪的feature list，并提供尽可能详细的细节说明，一方面也考虑项目现状，可用性需求可以分批实现，must，need，mayb，要心知肚明，形象一点来说，也就是大家俗称的“讨价还价”，一个主设计师很重要的能力就是议价能力，需要把项目当作“生意”来经营。

　　技能储备

　　关于技能对设计目标的转化，开发软件的过程中，需要学习的东西很多，相关的新型操作系统，新的开发语言，新的应用软件结构，对于交互设计师而言其实也是一样，新的用户界面风格，新的界面实现技术和新的设计工具。每样新东西需要时间来学习，也是CDC要打造一流设计师团队建设中很重要的一个环节，技能储备的厚度，设计视野的深度直接影响到CDC的设计水准，一个很重要的问题是“如何将日常的设计积累应用到交互设计实践中？”多数时候我们也认可这种转化迁移其实是自觉自发的，但是为了保证设计质量，我们在交互设计流程中也明确了竞品分析研究的环节，即在概念设计之前，设计师必须做一定的研究分析工作，对相关产品进行专业上的深度分析，对趋势进行有理有据的推导，进而形成自己的创新点，项目的设计目标也得以确立，保证设计一开始就有一个高水准的起点。

　　设计技能的持续优化，主要是对设计工具优化而言，经过这几年的积累，应对各个产品线，我们拥有了自己的设计开发工具，有了可复用的设计模板，有了越来越实用的交互统一规范，正在制定的可灵活调整的流程指南，希望做到的只有一点：成果的传递无障碍，经验的积累可复用。我们也坚信，站在千人的肩上一定可以成长得越来越快。

　　经验法则：技能的培养和使用无法保证项目自动获得成功，但正确的实践能够清除项目中的错误，使用正确的方法和技术，可显著提高设计项目成功的可能性，一定要先进行设计相关技术的储备。

　　创新机制

　　条条道路通罗马，同样地，交互设计问题的解决方案也不止一种。我们总是在追求最好的解决方案，但考虑选择的时候，通常可供选择的方式总是被时间，技术，资源，竞争等以上因素，甚至更多因素羁绊。有时为了“交货”，通常我们总是选择一个最稳妥，最保险的解决方案，只是很可惜通常这个解决方案看上去并不怎么创新。

　　对于交互设计的创新，我们通常愿意采用这样一种形式，在提供切合目前现状的最合适解决方案时，鼓励设计师储备“备选解决方案”，而备选方案的设计通常会有制度性的保障，例如当没有想法的时候，设计师可以在交互设计组，甚至更大的范围发起“头脑风暴”会议，可以申请“设计封闭”，可以组建“工作坊”，当创新点梳理出来后，鼓励自己动手，通过各种工具变成可演示Demo，以直观丰富的形式向项目组展示，这个其实也是一个启示，对设计方案的创新需要有孵化机制，需要包装，需要推销，“唯有震撼，才能影响”。

　　经验法则：任何设计都是可以改进的，这是永恒真理，但只有适合当前项目需求的才是最优方案，不盲目创新很重要。

　　设计实践

　　主要有两个维度， 对于垂直维度，我们关注流程实践，我们如何组合团队搭建，用户参与，设计评审，原型设计，专家评审，迭代设计等设计过程，以保证设计实践的最优路径，并做到快速渐进，在这个维度目前我们还在摸索，但随着交互设计子流程的建立，应该说基石已经打好了。

　　对水平维度而言，我们关注共同成长，对于多数设计师而言，多年的设计实践最终可以形成自己的行事经验和专有技能。从此成为立命之本，对于CDC的设计团队而言，我们还有很重要的工作就是团队建设，如何分享设计师的经验，如何取长补短，如何形成最优的设计实践。其实是一件群策群力的事情，简单而言，B1.0项目的教训如何保证B2.0中不再重复，A项目的经验能不能复用在B项目中。在一个大团队中，很难保证一个设计师会跟一个产品跟n个版本，从生到死，当一个新人加入时，他（她）需要怎样的准备才能快速成长，项目组之间的信息不透明，不对称这些都是问题。目前我们是通过小组的制度来加以保证的，例如所有设计师参与的周例会，月会分享，原创写作，项目组showcase机制，定期项目管理沟通会，邮件周知制度等来保证的。

　　一点题外话，从上可知，设计实践产生了一个重要命题是“各项目线设计实践中的零散经验教训如何转化为群体智慧，从而保持基业常青”，从这个话题延伸，目前广为人知的概念是design patterns，DP在产品设计中怎样才能做到内容自发产生，被设计环节以最小制作代价复用，同时又能有很强的自我修订能力？坦白讲我们还在实践，能够看到的好的范例一个是yahoo的DPL，这个我们以后有时间再探讨。

　　经验法则：越早制订设计流程越早遵循，设计实践效果就越好，关注设计师团队的共同进步，消除各自的能力短板，团队才能互补。

　　风险管理

　　预先示警相当于提早准备，若能认识到软件和用户界面的实现均涉及较高风险，产品开发团队就能够预先管理整个过程。通常我们在业界的专业分享或者在外面能看到的很多case为什么不具有很强的参考性，一个很重要的原因是它们剥离了软件研发环节的影响因素，“看上去很美”而已，规范风险在CDC的交互设计层面通常倡导几个措施：

　　1.建立风险列表，提供可用性评估指标，例如“XXX”“XXXXX”“XXX”（请原谅我隐去的一些信息）。
　　2.设计初期引入用户研究资源，保证客观公正的建立典型用户模型，对设计概念的接受程度进行测试，对设计方案的用户操作问题进行观察，在设计投给开发实现之前，尽量将界面可用性问题加以曝光，避免用户界面和可用性出现大的缺陷和隐藏的缺陷。
　　3.确立内部专家评审机制，从设计的方向开始，到设计细节实现，内部专家（黄金圣斗士级别为主，也包括神斗士）会先进行一轮预审，然后才会到产品层面的评审，这样也有助于设计团队内部资源的合理利用。
　　4.将开发阶段和测试阶段的工作明确化，例如在开发之前需要确认设计方案的执行程度，在测试阶段要提供界面实现评估报告等，一直到项目结束都有工作要做。这也成为了CDC交互设计师的日常工作之一，而不是提交完设计方案后就意味着任务结束。
　　经验法则：有正确可执行的计划只是第一步，引入check机制，强化执行和跟踪水平，项目会更容易获得成功。

　　复制成功

　　06年的时候，碰到的最大瓶颈就是低级错误在不同项目中重复出现，在不同的设计师稿件中重复，事后反思，其实可以看到，成功和失败的经验都没有好的沉淀机制，形成群体智慧才是问题根源所在。仅靠明星设计师的影响力带动和言传身教是不够的，无论是风光成功的项目经验或是收获惨痛失败的教训，此类知识如果集中在几个人手中都是极具风险的。回过头来看，在诞生于Web 1.0时代并且存活了下来，而且要继续领导Web 2.0时代的那些巨人的成功故事（例如yahoo!虽然最近诸多问题，但并不妨碍他在2.0时代的伟大）的背后，有一个核心原则，就是他们借助了网络的力量来汇聚集体智慧，评价一个团队的专业水准首先要看的是他的知识沉淀是否有合理的平台，其次是看在这个平台上诞生同时具有成功气质的知识的数量及频率有多高，最后是看这些成功的知识又能多快体现在其它的项目中，这个本质上来讲是也是评价一个team有多大的复制成功能力及有多大的执行力的标准，和丰田的精益求精，持续改进企业理念非常的类似。

　　经验法则：建立多样化的分享知识渠道，同时要建立快速完善的聚合平台，把项目线的成果及时有效的转化为专业线上的成就，聚合群体智慧，产生最大的利他效应，这是一个创造学习型设计团队的最重要基石。

       在《可用性工程》等以用户为中心的设计书中“使用用户的语言”是被反复提到的一条。“作为以用户为中心的设计的一部分，用户界面中的词汇应当使用用户的语言而不是面向系统的 术语”。对话要尽可能地使用用户的母语而不是外语，当然，对用户“语言”的考虑应当不仅仅局限与界面中的文字，也要包括一些非语言元素如图标等。
       同时，使用用户的语言并不意味着必须将界面中的词汇限于一个小的常用词汇集，恰恰相反，当用户群使用应用领域的专门词汇时，界面中也应该使用这些专门词汇。在一个专业性的行业网站的界面中也应该使用该行业的专门词汇，针对该网站的受众，使用特色词汇要好于使用普通词汇。
       
       tony曾经写过一篇文章并创造了一个词汇“技术性击倒”，讲产品设计如何和其他人抬杠。之前我牢骚过一回：“某个领域的从业人员如果每天拿着专业术语跟一个外行讲话，你直接不用听下去就可以判断，丫其实是个菜瓜！首先用外行的话把内行的事情讲明白才能算上是个合格的内行人”和tony说的大抵是一个道理。
       使用对方领域内的语言驳倒用户，实质就是一个转化的过程，把自己领域内的知识转化成对方领域内的语言，然后去驳倒对方，这才是真正的内行。利用高分贝和拽生词引用专业的概念来抬杠就类似与兽斗之猫狗。“譬如虎之出击，必贴地、俯身，形似奄奄一息。譬如鹰之将猎，必收翅躬身，作瘦弱将死状。唯独狗猫，稍有动作即张牙舞爪，声嘶力竭，作叱咤状。然一喝则溃之。(via)”

       使用用户的语言也涉及到从用户的角度看交互。比如在一个公园的指示图上标注“你在这里”而不应该是“我在这里”；比如提示用户是否激活某系统而不是提示“无效模式”。
       同时，系统不应该强制用户按照系统定义的命名规则给用户取名。应当允许用户使用任意长度的用户名，如果系统因为某种原因无法处理或者不不愿意处理长用户名的时候应该提供友好的错误信息，并允许用户重新编辑用户名等。

       如何得到用户的语言？
       最行而有效的方法莫过于数据说话，询问用户，用户投票等。让用户对一组可能用到的名字清单进行投票，然后让用户选出自己的语言，这样将会使用户在使用系统时的错误降到最低。或者也可以使用某特定领域内的用户词库等。
http://www.ikent.me/blog/1436#ixzz0D82uDH65&A

首先，一个产品是有一定的系统性特征的，从产品定位，功能架构，结构分析，框架设计 。。产品构建的各个环节都渗透着严谨的逻辑思维。

1.产品定位问题
产品定位是一个高度抽象的过程，在纷杂的各种因素中，直取最核心要素；这个要求产品经理深思熟虑，并逐层过滤。最终明确核心一点：满足了谁的何种需求；从战略层面上，分两个眼光：你用户提供了何种价值；为公司提供了何种价值；

2.产品架构的问题
产品架构被提及的并不多；在技术领域中系统技术架构的提法比较多；但个人认为这个“产品架构能力”十分重要； 一个产品，可看作是一个系统，包含多个功能维度（这个维度可以是层状结构，也可以是环状结构），每个功能维度上分布着多个功能点；
这样的思考有利于我们整体性的考虑一个产品的功能建设；需要在各个层面平衡性的延伸；而不是在一条线上走的很深入，但其余的确是短板（类似水桶理论）；有利于我们在核心及基础功能上建设的更扎实(比如VIP运营分核心功能和长尾功能)，而非在一些边缘要素或长尾上纠缠太多；
一个产品经理应当是一个产品架构师，而不只是能提几个点子的思维发散者；

3. 功能结构问题
描述一个功能，是要用严谨的交互流程来分析的；除了一下抓住主流场景以外，还要考虑各种异常分支情况；
这个时候的业务流程图的描述对产品经理来说是很必要的。（这里值得商榷一下，叫业务流程图不如叫用户使用流程图，东西做出来是给用户用的，这里需要站在用户的角度去思考，业务只是我们运营侧的叫法）

4. 框架设计问题
对于一般产品而言，一个界面是一个交互单元； 这个展示页面上的信息布局，或叫做框架结构需要很明确；
拿WAP页面设计而言，产品经理在设计一个页面之前，头脑中就要确定页面的信息框架：
1）需要明确此页面从上到下，从左右到右，分成几个框架模块；
2）每一个模块要有清晰的职能定义（都是要做什么的）；
3）然后在每个模块中去部署一些链接或文字；
4）同时，还要要限定一个页面之中的模块数目，避免信息量太大而造成用户关注点分散；

一个框架清晰的页面，让用户一览过去，就大致明白要传达的信息，而无凌乱，阅读疲劳之感；你的逻辑性，看这个页面的用户是有感知的；这个感知就是：清晰，或者胡乱； 苹果和橘子放在一起，怎么能和鞋刷放在一起？

我们常犯的问题：
仅以一个ＵＲＬ的粒度（或一行文字）来组织布局，导致多个不同类的信息被组织在一起，又或者任意在页面上插链接，而忽视对整体页面的影响；比如在页面上什么位置上开辟广告区用来承载交叉链接，这里也要斟酌，不要干扰用户交互流程，不要有倾向性的让用户区误点击；

这里所包含的归纳，总结的能力，是需要产品经理对信息有逻辑，组织能力，能系统性的看待一个产品，可宏观到战略定位，功能架构，微观到交互流程，UI体验。