设计是一种由众多较小活动组成的复杂过程,包括:听、分析、评价、头脑风寨、综合、实验、编写设计、描述、讨论、考察、反馈以及其他数不清的活动。文档化并非其中一项活动,但任何活动都涉及文档化,它的结果是形成各种工件—图表、注解、草稿、清单、详细目录、批注和更大的文档,这些都是文档化的成果。
文档化在设计过程中的价值体现在很多方面,但从根本上讲,有3个理由值得创建文档。
统一认识:随着设计过程逐步深入到用户体验的更细微的方面,整个团队可能很容易忘 记项目的主线。最深层的设计决定——不明显的功能、出现机会不大但确实有可能的用户场景——可能忽略了整体设计目标。不过,好的设计必须具有一致性,因为用户希望得到一致的用户体验。那些体现这种思想的文档、统一的主题都有助于提醒埋头忙于项目的人们正确的方向在哪里。从而使项目团队有机会从这个视角来评估新的设计思想。
深入理解:把你的思想画成一幅图使项目团队能够通过新的方式看待它。无论使用 Adobe Illustrator绘制还是呈现在白板上的草图,画图的作用只不过给人们提供一些予以反应、评估和扩展的内容。
求本溯源和有所交代:即使交付件从不打印出来,这些文档资料也记录了所有历史痕迹。 如果在项目进展中拥有决策形成过程的所有记录,你就能很容易地回顾团队在哪些地方做出过哪些关键决定。临近项目结束时,你可能会发现自己忘记了某些事情的前因后果,该按钮为何放置于此,该页面为何采用了有别常规的布局?文档资料的历史记录使你得以追溯这些决策背后的依据。
此外,即便只是白板上的草图、源自可用性研究的成果清单或有序贴在墙上的内客,也能说明文档化是必不可少的。简而言之,创造性的工作必然会产生工件。作为设计团队,你的选择就是要将这些工件规范到何种程度——也就是说,使其高度结构化、精炼,并在项目管理中扮演正式角色。你应当根据需要来决定规范程度。将你的交付件规范化可能有这样一些理由:
- 分散的项目团队需要使用正式文档,以便不同地区的团队之间在不同的时间进行交流。
- 与业务团队完全分开的创造性团队需要将文档作为契约关系的组成部分,或者确保他们能满足其承诺的内容。
- 长周期的项目规范化的价值在于保证其设计决策的长效性。
术语“交付件”(deliverable)表示一份完全独立的文档。可以将一个交付件文给某个完全不熟悉此项目的人,而它包含了足够的内容给予他或她最新的信息。交付件包含与项目相关的背景信息,提高了其中所传达的思想的来龙去脉,并说明这些思想如何引导下一组设计活动。交付件通过说明在更大项目的背景下其包含的想法来阐述内容。
设计过程中的4种典型交付件
设计纲要 | 设置项目基调、定义问题、目标和方向 |
竞品分析 | 寻找解决设计问题的其他方法 |
可用性计划 | 建立一种执行可用性测试的结构 |
可用性报告 | 报告可用性测试中发现的结果 |
图表可以表达想法和认知,但图表本身无法反映出项目的更大的上下文背景。图表就像是故事中的一种场景或点缀;它本身可能会引起人的注意和兴趣,但是不会具有上下文背景。交付件由工件组成,就像一个好故事通过一种突出特定主题的方式将场景串接起来一样。
人物角色 | 说明目标受众 |
概念模型 | 帮助理解站点的信息领域 |
站点地图 | 建立站点底层概念的结构 |
流程图 | 建立站点底层概念的流程 |
线框图 | 表明网页、模板或页面某部分的结构、行为和内容 |
交付件的内容可能是与工件独立的,用于说明项目的目标,或包含前一个交付件的概要信息,提供了符合设计流程的交付件的上下文背景。其内容可能与交付件中的工件直接相关,详述细节、提供基本原理,或者描述与其他工件的关联关系。
交付件与图表的关系参见下图所示:
图表适合在交付件中使用,但是图表属于它们之间可以共享的锚点用于提供内容、参考出处和连续性。随着图表在每个交付件中的使用而逐步完善(a),或者随着交付件本身的完善而逐步完善(b)
本文只是研究学习用户体验设计中交付件的概述性文章,后面会有更加详细的讨论,敬请期待。
转载请注明:陈童的博客 » 什么是用户体验设计中的交付件?都包括哪些交付件?