如何写出一份会说话的交互文档
前言
交互文档是交互设计师或者用户体验设计师与其他伙伴沟通的方式，交互文档往往能表现设计师的专业度。那交互文档如何有更好的表达呢？那接下来会将我们之前的文档架构进行过分享，如果有错误指数请指正。
什么是交互文档
交互文档是一份用来与其他伙伴解释功能优化时候的交互方式，内容优化，交互规则的文档，日常也叫做DRD( Design Requirement Document )。
一般场景是分为大型项目和小型项目，如果是遇到大型的项目的的话需要详细的从商业需求到最后的数据埋点验证都要做好并且和伙伴们都要做好沟通。遇到简单小型的项或者小迭代，基本只要连线图就足以表达交互的设计方案，写太多的注释会影响到观看者的理解成本。
交互文档的价值
对于设计师来讲能体现自己的交互的专业性，能够体现交互工作的承上启下的重要性。
对于上游交接的产品和项目经历来说，会查看交互设计师方案是否符合产品的规划和商业需求，以及方案是否有实施的可行性。
对于下游对接的UI设计师来讲，要根据交互文档里面的面的内容来绘制高保真还原图，等绘制完高保真页面之后并依次为根据落地。
与PRD的差异
PRD（产品需求文档）与DRD是团队项目中常见的文档，而PRD出自产品经理DRD出自交互设计师。这两个文档是极其相似的，因为里面的内容及其相似，而且会有交叉的部分。所以新入职的团队伙伴的理解成本比较高。
两者本质的差异来自于两个不同的职能岗位对一个功能优化的不同理解，产品经理主要是对一个功能的逻辑，原型图主要是为了解释新增或者是优化功能本身。而交互设计师主要是根据用户场景与商业利益之间寻求一个平衡点进行合理的交互设计， 这里有个有很神奇的比喻“带着脚链跳舞”。
PRD一般会顺带在原先的稿子或者是在标注中会带有交互的元素，这种“顺带”会带来一种错觉就是交互应该是由产品经理来做。但是在一份有效的PRD上，交互设计一定不是核心，核心知识将新增/优化的功能进行说明，这些往往是产品经理不会涉及到的范围。这些往往是交给UE/UI/UX设计师来完善交互方案。
查看的伙伴
业务
这里一般指的是产品或者是运营，大部分指的是产品。针对产品的部分主要是展示业务逻辑，DRD需要展示业务逻辑与用户需求结合，从中找出设计方案。
UI设计师
这里一般指的是UI设计师，UI更注重的是要做哪些页面？页面之间的跳转逻辑？报错场景怎么处理？特殊情况怎么处理？
开发人员
这里主要分为实现工程师的和测试工程师
实现工程师：前端以及后端伙伴更关注多少个页面/如何实现页面？以及页面之间如何跳转？异常情况下什么条件下跳转到什么页面？
测试工程师（QA）：测试同学会根据DRD梳理测试用例，基本要覆盖所有的交互场景和异常场景处理。
判断好坏的标准
价值场景明确
设计本质就是了解决问题，所以在DRD中要标注出商业价值和每个页面的用户场景和用户需求，降低每个协同同学的理解成本和沟通成本。
RCBC原则
穷尽原则，DRD要细致的展现出所有场景下的细节都要全部展现出来。
结构清晰
DRD常见的机构是：是什么，为什么，怎么做，结果如何。4个部分逐步进行推进减少团队中下一步接手伙伴的理解成本，同时也让每个同伴了解到能带来什么商业利益（在之后的面试中也可以讲这些）。
图文并茂
DRD如果写得像文章或者纯图片展示的话理解成本会比较高，而且在后续的查看中同学的立即的成本比较高，会增加后续要询问的沟通陈本（虽然说后续开发人员一般看不懂不看会直接来问，但是还要减少）。
修改记录留存
每个版本以及每次优化交互设计的记录，都要记录在文档里面方便之后迭代时候方便查询以及比对，放置重复迭代带来的资源浪费。
唯一
DRD必须保证文档是独一份的，否则在后期会出现2分以及多份不同的文档，对后期的沟通会造成比较大的分歧。
文档架构
交互说明
封面
通常是产品的通常包括产品的名称、Logo、所属部门、参与人员。
文档说明（版本说明）
一般标记当前版本和和当前版本的优化的重点
更新记录（修订记录）
更新记录是文档中必要的部分，找那个更新记录包含了从项目立项到现有版本的所有的改版记录，用于团队人员查询和比较功能模块的增/删/优化在哪个时间以及优化了什么的。常见的部分有：时间，类型，内容，页面。
时间：一般指的是上传到协同平台的时间，比如：蓝湖，mastergo
类型：常见分为3类：新增、删除、优化。项目中优化的场景占大多数，新增和删除的删除的场景很少，一般在一个阶段确定之后就打上不同的标签，之后在查看的时候就可以更直观的看到当前版本的类型。
内容：将更新的内容（优化的功能点）全部列举出来，分别以图片和文件简述形式进行描述，方便之后回溯版本的时候方便做管理。
页面：一般是讲更新的页面对应不同的交互页面，很少有开发同学会有耐心看完大量的文档，直接告诉版本号即可。
阅前通知
一般指的使用DRD文档的之前的注意事项，一些文件中包含了特殊的指导方式和关键词
通用标识
泛指整个DRD文档中常见的元素进行说明，帮助阅读者能够快速了解到项目的专业术语。
通用组件
一般指的是常用的交互设计师常用的控件库，这里的理解可以参考UI的控件库。
业务说明
产品介绍
产品介绍一般一份有效的DRD只要一个产品介绍，而且长期不用更新。产品同学提供铲平介绍的文案。
用户角色
这个要涉及到每个优化的部分使用的B端的角色，通常分为管理者或者是执行，往下按照只为细分可以分为：高层主管，中层主管，底层执行（具体的要看公司和行业怎么称呼）。主要是需要让协同伙伴了解到这个功能涉及到的那些用户角色。
用户场景
主要描述用户的使用场景，方便设计师与产品同学讨论时候确认这个优化的唯一性以及后续做设计的时候能够更加符合用户的利益。
业务需求
这一块主要是产品对于这一次功能优化的原因，方便协同伙伴了解到背后的商业原因，从而有个更好的配合。
交互设计
设计思路
需要设计师提前跟其他伙伴讲述一下业务需求以及用户，从而引导出自己的设计理念。否则只是评审页面的合适度，并没有什么意义。
通用规则
展现交互设计中的共性元素进行整理，方便阅读者整体理解。
非功能性需求文档
为了满足用户需求而必备的属性，为了其他协同伙伴了解所以要做这个部分
交互稿件
通过拖拽交互组件来展现产出物的设计方案，设计师可以根据自己的想法进行增删。
连线的注意点：
连接的页面不要舍近求远
不要忘记把交互方式与交互说明忘记
连线2头要保持不一致：触发页面用圆头，到达页面用箭头表示，不用的话可能会逻辑混乱
尽量减少连线的交叉
交互说明导航
在进行大的优化中会有比较多页的改变，为了方便协同伙伴查看，会将所有的说明整理出一个导航方便阅读者点击进行查看。
回收站
回收站是一个非常必要的部分，设计稿是一个不断优化的过程，废弃的稿子先别急着删。可以把没有用的稿子放到回收站这里，急找稿子的时候会有惊喜。
设计验证
回收站交互走查表
针对需求和设计原则进行统一的规范，在设计完成之后要逐一进行检查防止有疏漏。
数据埋点表
设计的数据埋点和产品的数据埋点不同，产品埋点一般针对功能使用的频率，设计埋点针对的是用户体验方向（例如：操作时长，操作效率是否提高）。通常要要向开发提供针对埋点
字段和表格，并给开发讲述为什么要埋这些点，以及要多长时间的数据。
文档规范
字体
在实际工作中每个人电脑上的字体不同，导致了同样的文件在书写和打开的时候会有字体的差异，在后期的查看的时候一些字体甚至于识别不出来会造成乱码从而造成阅读困难。
在表格内的字体首行要注意加粗，不要让表格排序过于杂乱。
编号
常见的在工作中针对编号是直接往下写编号，但是有的时候格式刷会造成失误，导致级别错误甚至于重新复制之后编号没有更新。
文档目录
文档目录需要及时更新，有的时候着急做手里的任务会导致忘记更新，导致后面查看的时候逻辑会乱掉。
错别字
这个是常会犯的错误，在输入法拼写的时候那面会出现错别字，一旦出现出错别字就会给设计师的其他伙伴一个粗心和非常不认真的印象，极大地影响到了印象分。
书面表达
在内容用词时候，尽可能的书面化，要表达简洁易懂还有避免歧义用词即可。
未完成时
在未完成的时候习惯性给个标注，最好是能给的能快速定位到的标签，方便后续完成时候快速找到。
较长文档场景
如果遇到较长的文档建议做一下页码。
一点点总结
交互文档是交互设计师的工作产物之一，要根据项目的规模和团队的规模进行选择。有没有发现我通篇没有讲设计工具？设计工具其实是并不是很重要，核心还是交互设计师自己的理念。这一篇将是我短时间内设计偏向文章的最后一个，后面会出一个设计的要懂得代码系列，来补充大部分设计师针对前端到底是干嘛进行补一些知识，降低沟通成本和提升线上还原度。
转载请在文章开头和结尾显眼处标注：作者、出处和链接。不按规范转载侵权必究。
未经授权严禁转载，授权事宜请联系作者本人，侵权必究。
本文禁止转载，侵权必究。
授权事宜请至数英微信公众号(ID: digitaling) 后台授权，侵权必究。
评论
评论
推荐评论
暂无评论哦，快来评论一下吧！
全部评论（0条）