交互设计方法论 2.0探讨

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

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

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

　　用户参与

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

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

　　需求管理

　　这里包括两层意思，首先，对需求

　　制定计划

　　对大多数的项目而言，项目团队总是对进度想象得很乐观，对进度保持乐观很重要的一个原因是有很充分理解当前进行的工作。但作为公司的产品现状而言，我们可以看到行业的用户界面技术创新，其速度是高于开发实现技术的。设计师想要做到的许多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.建立风险列表，提供可用性评估指标，例如XXXXXXXXXXX(请原谅我隐去的一些信息)。

　　2.设计初期引入用户研究资源，保证客观公正的建立典型用户模型，对设计概念的接受程度进行测试，对设计方案的用户操作问题进行观察，在设计投给开发实现之前，尽量将界面可用性问题加以曝光，避免用户界面和可用性出现大的缺陷和隐藏的缺陷。

　　3.确立内部专家评审机制，从设计的方向开始，到设计细节实现，内部专家(黄金圣斗士级别为主，也包括神斗士)会先进行一轮预审，然后才会到产品层面的评审，这样也有助于设计团队内部资源的合理利用。

　　4.将开发阶段和测试阶段的工作明确化，例如在开发之前需要确认设计方案的执行程度，在测试阶段要提供界面实现评估报告等，一直到项目结束都有工作要做。这也成为了CDC交互设计师的日常工作之一，而不是提交完设计方案后就意味着任务结束。

　　经验法则：有正确可执行的计划只是第一步，引入check机制，强化执行和跟踪水平，项目会更容易获得成功。

　　复制成功

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

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