[开发-手把手教你写一份交互说明文档.docxVIP

手把手教你写一份交互说明文档Warlial???2012-06-20 14:50???1条评论???【编者按】本文由@heidixie发布于其个人博客—Heidi格物志。以一个交互设计师的角度为大家讲解制作交互说明文档的好处以及方法。与一般的教程不同，作为一名交互设计师，作者通过对交互说明文档以及对互设计过程中可能出现的问题都很有经验，因此对各个细节进行了详细的分析，使读者知其然亦知其所以然。一. 什么是交互说明文档（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里面不可能写太多交互方面的东西。希望UED能够在提交HTML DEMO给RA时，能同时给出一份页面元素描述文档，需要介绍html demo中的文案、链接以及相关的图片尺寸或显示字符个数。现在RA在这方面花费的时间比较多，经常要和UED去确认这些内容。产品经理：前期RA和PD沟通过程中，有很多交互点点不能够明确，比如“默认显示多少属性值”，“标题显示多少字符”等。在以往的需求和项目中，对待这些问题我们都是想到一点补一点的到FRD文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。PD为了可控性的需求，往往会“越俎代庖”，直接在FRD注明这种需求（对于交互设计师来讲，却又导致没有发挥余地）走访了一些交互设计师后，他们也存