交互设计文档写什么.docx

界面交互设计文档是什么文档 该怎么编写？在某个大型项目结束后，作为交互设计师，我进行了一些调研，听听这相关人员是怎么表述问题的：　开发部门的需求分析师：　1、每次变动都很痛苦，设计变了之后，我就要跟着改UC，改截图，有时候UED改了还忘了通知我们，导致UC有问题……　2、页面交互的需求容易漏掉，因为UC里面不可能写太多交互方面的东西。　3、希望UED能够在提交HTML DEMO给RA时，能同时给出一份页面元素描述文档，需要介绍html demo中的文案、链接以及相关的图片尺寸或显示字符个数。现在RA在这方面花费的时间比较多，经常要和UED去确认这些内容。　产品经理：　前期RA和PD沟通过程中，有很多交互点点不能够明确，比如“默认显示多少属性值”，“标题显示多少字符”等。在以往的需求和项目中，对待这些问题我们都是想到一点补一点的到FRD文档或者邮件中去。既增加了沟通成本又会存在遗漏细节的风险。PD为了可控性的需求，往往会“越俎代庖”，直接在FRD 注明这种需求(对于交互设计师来讲，却又导致没有发挥余地)　走访了一些交互设计师后，他们也存在如何清晰无遗漏将交互设计需求传递下去的困惑：　交互认为很平常的设计需求，如果不表达出来，还是容易被前端和开发忽略掉。我经历的一个项目，前端从头到尾更换了三个人，每次我都要重复去讲解下设计需求，讲得口干舌燥。而且做好后，还需要去验收。　DRD做为参考手册，一定程度上避免不吻合的问题发生。　即使有问题发生，也可以作为界面验收时的Checklist。将“我对A说，我对B说，A对B说”，转变为“A和B共同参考同一份文档”，减少沟通成本及信息不对称。　全程影响用户体验(一直到测试，都需要参照设计文档)。　可是以下问题都可以通过一份DRD来解决吗?　三、 写什么不写什么?　要明确文档的定位，从写什么与不写什么开始，划清DRD以及FRD的边界。　1. 不写视觉规范规格标注　这些说明与功能实现没有太大关系，主要是为前端做HTML的时候参考的。一般视觉设计师会在PSD里标注清楚。如图：　2. 不写功能实现逻辑。　如下图所示，作为DRD，你有必要传达清楚Browse by category区域的设计：链接的可点击性，链接的指向，字符与条目的数量限制等，但是具体二级类目排列是按产品数目排还是按字母排，还是人工运营，是FRD要解决的任务。　那么文档写什么呢?　举例子说明下：　1. 字符限制　提高空间利用率，有时网页上的动态文字需要从数据库里提取部分然后截断处理。比如下图中的标题和描述。你的DRD需要传达清楚：1，是否要做限制?2，如果做限制的话，多少字出现截断?截断后是显示为省略号还是不显示?这个汉语设计相对简单，如果英文单词的话，因为是按字符，每个字符的宽度不一致，需要预估，另外还需要注明是整词截断还是词间截断。　2. 链接具体化　很多网站都有对搜索结果的筛选设计(refine search)，比如aliexpress搜索结果页左侧。这块区域的交互事件是非常复杂的。　类目和属性的不同如何处理　属性以及每条属性显示的属性值的条目是否有显示上的限制?　选中后，被选中的属性值是停留在原地，方便用户记忆，还是放到统一的位置，方便用户统一查看?其他未被选中的属性值是否消失?　要确保这些你设想中的复杂的交互逻辑能够被理解被呈现，除了一页页的线框图，你有必要再三让前端工程师和开发工程师了解并达成认知一致。所以你需要将页面上的关键链接事件标识清楚。它们有的指向无需刷新页面的交互，有的指向你安排的并非PD安排的某个中间页面(page flow是交互设计师的职责)　3. 交互细节说明　相信我，我很不愿意写这些东西。我喜欢在会议室向各位涉众演示我的线框图，我会研究用axure制作各种动态效果，达到它足够逼真呈现各种联动—— 比如当你选择了下拉菜单中的某项时，页面上其他区域也发生相应的变化。可是，Axure不是全能的。即使能够表达出来，线框图交付出去，也不能确保其他人都能够一一进行点击尝试。所以只能在会议室反复讲解，在事后再三检查并敦促修改。　但是当我尝试用下图对这块小小且复杂的区域进行详细说明后，事情变得简单多了。所以我用节省的时间去写了这份PPT.　又如，你可以在这里说明任何你想要的效果。你的受众也只需要用10分钟时间阅读完毕，标注出与他工作相关的重点，存档并在遇到问题，找不到你人时随时参考。　4. 表单的校验　这也是一项不怎么有创意的事情，但是你若不事先想清楚，在项目过程中有点麻烦。写文档看似枯燥乏味，反过来想也是让你自己再好好思量审核设计本身的关键步骤。我曾经自以为完善的交互设计方案就是在写DRD的时候发现存在重大的纰漏，然后及时优化的。　5. 浏览器的兼容性要求　你们的产品兼容所有浏览器简直是梦想，但是有时出于效率的要求，我们必须