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

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

　　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