交互说明怎么写

一份足够完整和详细的交互说明文档可以减少沟通成本及信息不对称。

image

所谓交互说明，简单的理解就是对交互原型的解释、强调或补充的说明文字。原型页面往往无法展示全部的交互细节，即便完全做到了，团队中的下游也不一定能够全部get到。所以，一份足够完整和详细的交互说明文档可以减少沟通成本及信息不对称。
相信大多数的交互设计师们都有写交互说明的经历。那么大家知道如何完成一份合格的交互说明文档吗?不妨从以下几个角度了解下到底该怎么写交互说明。

1、写给谁看

首先需要明确交互说明的读者和在项目中的作用：

• 视觉设计师：输出视觉稿

• 前后端开发工程师：代码实现产品设计

• 测试工程师：写测试用例

• 产品经理：项目紧张的情况下，可能会需求和原型设计并行，这时候，交互说明可以协助产品经理整理并输出需求文档

• 自己：原型细节自检，优化设计逻辑

2、由谁来写

很明显作为项目的交互设计师是交互说明的主要撰写人和维护者。
在项目进程中，交互说明应由设计师发起，前端开发工程师也会协助修订细节。交互设计师更多的关注点在需求到原型的转化，对于前后端能否实现并不是很确定。前端开发工程师对交互说明的的把关和疑问，能够帮助设计师将设计思想转为工程师能够理解和实现的语言。这样交互说明也能帮助前端开发工程师明确设计实际执行方案。

3、写什么内容

写交互说明文档时，很多人都会疑惑，到底需要写什么呢？我的意见是，站在下游的角度，视觉设计师和开发工程师在需要考虑的与页面相关的逻辑和用户操作相关的内容基本都是需要在说明中体现出来。另外我们应该尽量写得详细些，避免研发同事多次来讨论或者直接按照自己的理解直接实现，这样最终的验收效果也会比较好。那么具体的该写什么不该写什么，这里也做了整理供参考。

image

3.1这些要写

3.1.1页面整体说明模块

1. 页面统一布局：页面整体的排版布局简单说明（比较直观可不写）

2. 相同的交互动作：统一的页面切换方式、手势、弹窗等

3. 相同的处理规则和注意点：比如所有的表格在自适应时的变化规则

image

3.1.2对象

用户身份和系统功能页面紧密相关。比如后台系统常见的会区分管理员身份，普通管理员还是超级管理员。

3.1.3限制

1. 范围值：比如列表超过10项出现滚动条

2. 极限值：比如某个字段文字超过展示极限值才有缺省，hover气泡展示全部

3.1.4表单校验

表单校验逻辑：是实时校验还是触发按钮后做校验，还是两者结合，表达清楚逻辑并将相关的提示和反馈描述清楚。

3.1.5操作与反馈

1. 操作：

• 交互方式：点击、拖动、长按、缩小、放大等

• 文本框等：获取焦点、失去焦点（比如app键盘的呼出和隐藏）

• 热区范围：比如卡片展示形式有时将整个卡片作为可触发操作的区域

2. 反馈：

• 提示内容：系统对用户操作的及时反馈比如报错提示、失败提示、成功提示等

• 提示形式：提示的控件样式，比如弹出框是否可关闭等

• 跳转：跳转形式是当前窗口/新窗口？跳转到哪里？写清楚标号或页面名称

  image

• 过渡动画：转场方式

3.1.5状态变化

1. 默认：

• 默认选项选中

• 默认显示的文案

• 默认排序方式

1. 正常：
   正常场景下的操作带来的变化，比如点击表格的表头排序

2. 特殊：

• 功能特殊，比如两个复选框必须有一个选中

• 场景特殊，比如无数据情况、加载失败、网络错误

3.1.6其他交互细节

根据项目内容特性和业务将逻辑细节和交互细节表达清楚。比如app可能有锁屏推送，项目是否有数据埋点。

3.2这些不写

• 商业逻辑，比如：某个功能的实现有怎样的意义，跟产品实现无关的前期准备，就不要画蛇添足了

• 视觉规范相关，术业有专攻，尊重和相信团队视觉设计师

• 研发代码的逻辑和规则等，PRD需要解决的问题，不要赘述

4、怎么写

4.1 目录

提供一个参考的目录，可以进行适当的调整作为项目交互原型的目录：

image

4.2 格式

相比较word等文本记录工具比较推荐Axure，原因有三：

• 和原型源文件放在一起，方便维护

• 生成html文件后，研发阅读更方便

• 熟悉Axure操作，能够便捷的添加跳转和动作

4.3 排版布局

根据项目类型和情况确定具体合适的排版，基本可以按照从上到下从左到右的顺序去排版。

• web的页面一般比较宽，可以采用先上下，后左右的结构：
  上图加标注，下文字说明（左图右文

  image

• app的页面比较窄，可以放在原型页面中做说明：

  
  image

5、怎么做才是不错的交互说明

以上都能理解和做到，已经可以完成一份合格的交互说明文档了。那么怎样才算是一份不错的交互说明的呢？
这里分享几个注意点：

5.1固定的目录结构

对接的下游有时候是同一部门或同一个同事，目录保持基本的统一，可以降低下游的学习成本，另外也让自己在写说明时不必每次都去思考目录的划分。当然，针对不同的产品类型和产品特性需要去调整制订目录。

5.2简洁文字

拒绝流水账式说明，另外当描述文字过长，可能需要重新考虑是否是设计逻辑存在问题。那么如何让说明文字尽可能的简单呢？

• 流程图代替纯文字说明：流程性强的功能可以尝试这种方式，简单且直接。

  image

• 表格罗列复杂状态变化

  image

• 灵活运用开发语言（if/else/case等）

• 结合动态效果：遇到动画或者效果不太好用语言描述的话，不如直接把动画放在说明页面展示，并结合简单的语言描述。

5.3尽量使用真实、符合逻辑的数据

原型设计的过程中，需要展示数据，对数据的模拟尽可能的真实，撰写交互说明可以将场景还原更加贴近真实可能性。而且，真实符合逻辑的数据，研发也比较能更快理解页面逻辑，所以也可以减少沟通成本。

5.4处理重复内容

原型页面很多内容是复用，那同样的这些重复的内容，按照常见的处理方法，就会重复写很多次的交互说明（相信大家也会复制粘贴），但是这样带来2个问题，一是研发会不会怀疑前后的交互说明是否有区别，二是如果需要修改的话，需要对所有的相关页面修改，维护的工作量就变大了很多。有2钟解决方法：

• 写在一处：引用时加链接

• 写在单独页面，引用时加链接

5.5更新后及时周知

每次更新都是一次改进的过程，添加新内容的同时，保留旧的内容，让其他人也看到走过的弯路，让他们知道每次修改都是深思熟虑后的决定。为什么要周知呢？下图，是不是很直接地解释清楚了：

image

另外，当我们在项目中写交互说明写多了就会发现，组件可以自己设计生成元件库，调用元件库就可以快捷使用，那么组件的交互说明也可以组件化进行归类入库，在需要的时候直接拿出来根据具体情况调整使用。附上，我整理出的交互说明组件库的部分页面供参考，大家可以根据自己的操作习惯和经常接入的项目特点制作一套适合自己的交互说明模板库：

image image image image

6、总结

以上就是我在项目进行过程中发现的问题和个人思考的解决方案。但是，并非所有人都喜欢写说明文档或者看说明文档。有必要的情况下，需要跟团队成员强调交互说明的存在意义，推动大家去阅读和反馈，这样辛辛苦苦写出来的说明才能对项目的发展起到真实的作用。另外在项目合作的过程中，除了做好自己的任务以外，要多站在项目的角度上去思考，要去考虑团队中其他角色尤其是下游伙伴是否能够较好及时地实现或完成相关任务，这样思考后才去决定自己手下急需和应该完成的任务项。

本文系转载
原文链接：https://www.zcool.com.cn/article/ZOTgzMzQ4.html
原文作者：瑶瑜要鱼