从敏捷宣言理解敏捷交互设计.docVIP

从敏捷宣言理解敏捷交互设计 敏捷交互设计是敏捷方法论向交互设计领域的延伸，它提倡让所有相关人参与到设计过程中，迭代演进式地进行交互设计。从2010年开始，已经有越来越的团队在不同程度上使用敏捷交互设计的方法，而放弃了流程化的传统产品设计过程。 事实上，敏捷交互设计方法在很多方面都充分体现了敏捷价值观，因此，理解敏捷交互设计实践的最好方法是从记录在敏捷宣言中的价值观开始。 个体和交互胜过流程和工具 一个传统交互设计的流程一般分成以下几个步骤进行： 任务分析：任务分析基于功能列表（一般来自于客户的功能说明书）──在功能性需求的基础上拆分出人物流程和场景； 页面流程：根据任务分析的结果，为每一个大任务下的子任务中覆盖的功能制作页面流程； 信息建模：根据页面流程的设计出一套完整的信息框架，满足用户所有功能性需求； 原型设计：基于信息建模，设计出低保真原型，交给美工进行页面美化； 视觉设计：基于原型设计，对页面进行美化，最终产出高保真原型，同时编写设计说明； 在传统流程中，我们可以看到非常细致的分工──产品经理负责功能的拆解和分类，以及页面流转；交互设计师设计信息架构和具体交互行为；视觉设计师负责美化页面；前端开发人员负责高保真原型。 你是否体看见了传统瀑布式开发的影子？弊端显而易见： 分工造成的局限性──每个人都用自己的视角进行工作，无法形成统一的产品视角（Vision）； 分工造成的“不可评价性”──你没权利对产品经理的功能拆解有异义，因为你不是这方面的专家； 需求在传递中产生了失真的风险──需要靠大量文档进行记录； 客户没法说不──当客户需要到整个流程的最后看到一个或者两个大而全的设计方案时，他无法提出任何有价值的反馈，这本身就是用一个贵重的半成品绑架客户； 跟软件交付中的敏捷实践一样，敏捷交互设计倡导全功能团队，避免过于明显的分工，和基于分工特有的流程。仅有的流程是基于产品逐步清晰化的过程，而非基于人员的技能，所有人都应该参与到这个过程中来。敏捷交互设计主要分以下几个步骤： 寻找产品方向(Inspire)：抛开需求列表，从目标人群的期待体验出发，寻找可能存在的产品方向； 定位产品需求(Identify)：定位本产品需要提供什么样的消费者体验； 设计产品体验(Ideate)：对决定的目标体验进行设计； 验证产品设计(Implement)：快速制作原型，并频繁进行用户测试，迭代式改进。  图1. 从体验中寻找交付范围，把功能列表放在一边 除了流程简化和分工融合，在工具的选择上，敏捷交互设计也与传统方式有所不同──对于交互的推崇高于对特定工具的选择。 所有在敏捷交互设计中使用的工具，都应该遵循一条原则：它必须推动设计团队成员间的交互，而不是简单提升单个成员的工作效率。 基于此，敏捷交互设计中推崇各种轻量级工具，而不是大型的第三方软件，例如纸质原型Paper Protityping而非Visio或Axure此类原型工具。过于精细的结果往往会增加协作和反馈的门槛，虽然可能提升单个成员工作效率，却达不到鼓励交互的目的。 图2. 使用轻量级的工具进行交互设计 可工作的软件胜过完备的文档 敏捷软件交付过程中，每个迭代的核心产出是不足够完美，但却满足一个完整业务场景的软件──端到端流程的可完成，而不需要面面俱到的完美。 而传统开发方式中在长时间内只是各个功能模块中功能的堆砌，无法在短时间内实现端到端场景，那么文档便成为串联各个功能保证有序开发的必需品。 传统交互设计也存在这个问题。往往一个标准交互设计阶段的文档分三个方面，它们是： 内容方面(Content)：内容的层次和整体信息架构设计； 视觉方面(Visual)：整站风格的视觉设计文档； 交互方面(Interaction)：整站高保真交互设计原型； 仔细分析这些文档的生产过程，我们不难发现以下特点： 它们都是以整站为目标，试图覆盖所有使用场景； 它们的生产过程是线性的，直到三者全部完成才能够指导开发； 正因为每个环节的过程是孤立的，无法形成统一的认识，文档传递经常发生失真； 一个完美的东西很难得到产品方向性的关键反馈； 敏捷交互设计试图在解决以上问题。 敏捷交付的核心在于尽早地交付出可进行端到端测试的代码，而非完备文档，而敏捷交互设计的核心则在于尽早地交付出可以进行端到端可测试的原型，同样亦非完备文档。 而这里说的“端到端可测试的原型”包含以下含义： 端到端：必须设计出符合合理使用场景的端到端流程，这个流程会覆盖一个典型用户最核心的使用场景，所有的交互设计应该第一时间收敛在这个端到端场景周围，而非“整站”功能的分割展示； 可测试原型：不需要完美的原型，只需要所设计端到端场景中涉及到的原型，同时，原型的完备性上必须达到内容、视觉、交互三者细致力度一致，在测试中，三者力度的不一致往往会隐藏问