设计-手把手教你写交互设计文档.pdfVIP

离开交互圈已经有段时间了。但由于博客还在，还是能够偶尔收到一些邮件，上周有位同 学问我：我在求职，我看到很多招聘说明上需要交互设计师编写界面交互设计文档，请问界面 交互设计文档是什么文档？怎么编写呢 这让我想起来2009 年自己在项目里也大力推行过交互说明文档（在下文中，简称为DRD）， 格式倒没什么限制，交互设计师自己写到界面上也行，单独文档成文也行，总之就是让交互设计 师能够将界面承载不了的信息通过文档沉淀下来，降低项目里的沟通成本和风险。今天整理电脑， 翻出以前的PPT，分享之。这将涉及到几个问题： 一. 什么是交互说明文档（DRD）？ 所谓DRD 即是用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。 在项目中，交互设计师的主要产出物可能依次是：site map，page flow，wireframes。有 的大型项目前期，交互设计师有可能还会产出用户需求分析文档（与PD 产出的市场需求文档不 一样的是，URD 更多侧重于对目标用户的需求分析）。 DRD 则很少有人专门撰写。如果需要对交互设计进行说明，聪明的交互设计师往往会直接 标注在线框图里，或者在项目中不断和前端工程师和开发工程师口口相传，反复验收，不断迭代 修改来确保所有的交互设计意图最终得以呈现。 二. 为什么要写？ DRD 非项目必需环节，一般情况下也不会为交互设计师专门留出相应的时间预估。没有这 份文档，项目也会继续，但是可能项目会为此承担不必要的沟通成本和时间成本。严重的话，项 目的质量也会受到影响。所以写与不写，交互设计师需要做把握，时间被统一包含在“线框图” 环节内——如果你要写，请在评估时预留1-2 天的时间。 那么，结合我过去的经历，谈一下此文档的必要性。 下图是一个产品开发项目基本的流程。 敏捷开发意味着很多不同角色的流程需要并行操作。如果等到产品经理的FRD 已经全部敲 定，交互设计师再开始去画线框图，固然会减少沟通成本和返工风险，但是同时意味着交互设计 师的很多想法不被采纳。如果产品经理再强一些，他甚至会在FRD 里连原始的DEMO 也一并绘制 出来了，功能性的需求和界面交互的需求有时无法区分太清楚——比如他会在FRD 里直接要求每 页条目40 条，超过40 条即分页。而交互设计师可能会认为像蘑菇街那样不断装载出足够长的页 面会更亲和„„所以，我们希望是和产品经理同时开始工作，在术业有专攻的时候相互补充。 同样，开发工程师也希望及早介入需求，在FRD 并未确认的时候就了解需求，进而将商业 需求和功能需求转化为开发工程师看得明白的开发需求清单（这个清单，大部分叫做UC，即USE CASE）,当这份清单由工程师需求分析师——在过去，这个角色被叫简称为RA，但是目前已经取 消此专门的职位，而是由开发工程师代表担纲此环节工作，为了便于描述，在此文里，我仍然将 做这件事情的人称为RA——交付给具体的执行工程师后，执行工程师基本上可以当作一条条的 checklist 开始高效工作，而不必再思考商业逻辑和需求。同样，测试工程师也需要编写具体的 文档去指导很多测试人员在开发后高效测试，这也是基于UC 和FRD 去撰写的。 所以，开发需求分析是个很重要的环节。那RA 是如何来完成需求分析工作的呢？ ● 前期介入，对PD 进行开发需求评估支持； ● 如何写一份交互说明文档参与每次的FRD 评审会； ● 详细审阅FRD 文档并不断与PD 确认。 对于做这件事情的人来说，足够详尽的FRD 是非常重要的。所以一份FRD 虽然是PD 产出， 但是很多实施细节则是由开发工程师不断沟通评估并确认下来的。而设计需求的传递，却存在很 多问题。除了线框图，没有“详尽的说明性的文档”告诉他们。比如： 一方面，交互设计师对产品经理说：这块由我们来考虑，你的文档不必包含设计上的说明， 这随时会调整的。 另一方面，线框图的评审有时会让RA 参与，有时却没有叫他们。即使叫上了他们，他们也 会发现交互设计的需求变化要比FRD 变化快。另外，他们会认为UC 不必写太多关于交互设计的 需求。 在某个大型项目结束后，作为交互设计师，我进行了一些调研，听听这相关人员是怎么表 述问题的： 开发部门的需求分析师： ● 每次变动都很痛苦，设计变了之后，我就要跟着改UC，改截图，有时候UED 改了还忘 了通知我们，导致UC 有问题„„ ● 页面交互的需求容易漏掉，因为UC 里面不可能写太多交互