如何写一份交互说明文档

发布网友 发布时间：2022-04-24 13:16

我来回答

共3个回答

热心网友 时间：2022-04-13 17:17

交互说明文档，是交互设计师 的输出物中必不可少的一项，它关系着设计方案能否最大程度的被实现。交互新人，大多会烦恼如何写交互文档，今天来聊聊这个话题。 　　交互文档，写给谁看 　　交互文档可以看做交互设计师 输出的”产品”，它面向的”用户”是下游的同事——视觉设计师、测试工程师、开发工程师。他们会根据文档中的线框图、交互细节说明等等，来输出视觉设计稿、写测试用例、用代码实现产品设计方案，并以此为依据完成验收测试等工作。 　　交互文档，写什么内容 　　最初写交互文档时，很多人会有疑惑该写些什么内容。我的看法是，开发同事在写代码时需要考虑的与界面显示逻辑、用户操作相关的内容，几乎都要在交互文档中体现，建议越全面越好。 　　如果有遗漏的内容，开发可能会找你讨论，也可能懒得费时间沟通直接按照自己的理解去实现。最终，验收测试的效果不如意，你也不能全赖开发。所以尽量将交互文档写的全面些，别消费开发同事对你的信赖值。 　　那么，到底交互文档中，需要写哪些内容呢? 　　1、页面流程(界面之间) 　　页面流程图，可以表达产品的整体结构，帮助同事了解界面之间的关系。在撰写交互文档时，也可以以任务、子任务为模块来详细介绍界面如何跳转、何时跳转。 　　2、内容布局(界面内) 　　正在加载状态、加载完成有内容的状态、加载完成无内容的空状态、失败状态(比如网络异常/权限未开启)、不同角色的用户看到的内容是否一样、不同状态的文案图标变化 　　内容的加载方式，何时加载、何时显示、何时刷新 　　其他 … 　　3、交互操作与反馈(界面内) 　　根据用户与界面之间发生的交互操作，提供相应的反馈，可能是提示内容，也可能是界面内或界面之间的跳转。 　　刚入门的交互新人，喜欢把重心放在界面之间的跳转，而遗漏了界面内的内容布局和交互操作。对此，我的小技巧是，先整体看界面全局，再review界面上的每一个元素，思考各种不同场景下这些元素是否变化、如何变化。 　　以登录界面为例，看看怎么写交互细节说明 　　下图，是一个简单的登录界面，我们试着先整体后部分的方式，看看这个界面的交互说明需要考虑哪些方面。 　　1、登录界面的跳转流程 　　什么情况下，从哪些界面可以进入登录界面 　　登录成功后进入哪个界面 　　取消登录后回到哪里 　　界面转场方式，比如从下向上进入界面，从上往下离开界面 　　2、账号输入框 　　字段格式要求，字段长度、字段类别(汉子、字母、数字、手机号) 　　是否有默认提示文案，如果上次登录过是否显示上次的账号 　　光标是否置入此输入框，键盘是否显示，键盘用哪种视图 　　何时检测用户填写的是否正确，填写正确的提示，填写错误的提示，反馈提示何时显示、何时消失 　　输入框中的内容是否支持一键清除 　　3、密码输入框 　　字段格式要求 　　何时检测格式是否符合 　　光标置入后显示键盘的哪种视图 　　输入框中的内容是否支持一键清除 　　是否支持密码可见、如何切换可见状态 　　4、登录按钮 　　按钮是否有可用不可用之分，何时可用状态、何时不可用状态 　　点击按钮之后提示正在登录的方式 　　登录成功如何提示、跳转进入哪个界面 　　有哪几种登录失败的场景(比如账号未注册、网络异常等)，不同失败的情况下如何提示 　　多次登录失败提示方式是否变化 　　5、注册按钮 　　点击进入哪个界面 　　界面的转场方式是怎样的 　　6、关闭按钮 　　点击进入哪个界面 　　界面的转场方式是怎样的 　　以上只是抛砖引玉，给大家打开思路。虽然只是几个输入框，但其细节比大多数界面都要复杂。你可以找一款优秀的APP，去研究它如何设计这些细节，是否还有我没有提到的点，研究透了下次自己设计才能做到更加全面。 　　当然，交互细节说明，只是方案的表述，每一个小点都有好几种设计方案。如何权衡选择体验更优的方案，才最是考验交互设计 师的能力。你可以对比研究几款优秀产品，看它们在细节设计有何不同，分析其中的缘由，想想是否有更好的方案，学无止尽。 　　如何提升交互文档的浏览体验 　　交互设计 师的目标是提升产品的体验，我们输出的文档本身也应该有上佳的浏览体验。为了达到这个目标，我也在不断优化文档的撰写方式和排版。下面聊聊我尝试过的几种方式。 　　方式1：一页纸表示所有的线框图，配上箭头+简单的文字说明 　　网上流传着很多这种风格的图，最初觉得这样的图很有范儿，以为这就是他们输出的全部交互文档，所以按照这种模式产出。等到自己做的多了会发现这类图大多只表达了某个界面的正常状态，并没有详细的交互说明来体现界面的内容布局和交互操作反馈。 　　方式2：一页一个界面，每个界面建一个交互说明文件夹，分功能模块写交互说明(Web产品) 　　工具: Axure 　　Web产品的特点是，层级复杂，每个界面比较大而且内容很丰富。通常会组织好页面层级，再画每个界面的原型，待几轮讨论过后界面布局和内容基本确定之后，再为每个界面撰写各自的交互说明。 　　考虑到每个界面中的内容模块和功能点不少，我没有在确定好的界面上直接标注交互说明，而是将这个界面划分为几个功能模块，并给每个功能模块新建一个页面用来写交互说明。 　　如下图，分别是 Axure的文档目录(左)、某个功能模块的交互说明(右) 　　方式3：一页显示一个大功能点的所有界面和交互说明(App 产品) 　　工具: Axure 　　App相比Web界面内容简洁很多，很多人输出App的交互文档都是一页展示很多个界面，上下左右排满了。设计师大多是大屏电脑，这样设计起来确实比较连贯流畅。 　　但是开发大多用MacBook，没有外接的大屏显示器，一屏看不到几个界面。虽然我会按照横向主流程竖向次要或分支流程的规律排列，但是他们对这些规律并不熟悉，左右拖拽上下滚动几次就容易犯晕，可能一会儿就找不到刚看过的界面了。 　　如下图，界面右侧配上对应的交互说明(通常情况，交互原型应该以黑白灰颜色为主，不过因为我们的APP处于迭代优化的阶段，已经确定了视觉风格，而且某些状态需要用颜色来区分对错，所以会有一些配色。) 　　期间优化过这种方式，将大功能点拆分，按照以往设计Web 产品的方式来组织。对此开发同事仍然觉得不够好，所以有了后面ppt/keynote演示文稿的方式。 　　方式4：一页介绍一个子任务，每页最多4个界面，输出PDF格式(App 产品) 　　工具: Axure 画原型，Keynote 写交互说明 　　为什么采用这种方式呢?源于开发同事看到产品老大介绍需求用的幻灯片，觉得一张图配一个表格的方式很清晰，强烈建议用这种方式来写交互文档。 　　我觉得用幻灯片输出PDF 的方式确实可取，易于浏览。不过一页一个图太零散，界面之间、界面内容的不同状态关键性很强，放在一起介绍更直观。 　　于是，我想到了以前 yoyo 在腾讯CDC 官方博客上分享的交互文档撰写方式：《如何制作实用美观的设计文档》 。以前尝试过用他推荐的indesign写文档，但对这个工具不那么习惯以至于效率并不高，尝试过写完一个产品的交互文档之后就没再用了。不过 yoyo 推荐的将大故事拆分为一个个小故事来写交互说明的方法让我记忆犹新。 　　就这样，尝试了这种新的搭配方式，Axure 画原型，Keynote 写交互说明。 　　Keynote缩略图预览如下图，为每个功能模块建立一个任务/子任务的目录结构，按照划分的结构依次介绍各个子任务。每个页面最多介绍四个界面，页面底部作为固定的区域用来写交互说明。 　　测试、开发同事反馈这种方式不错，一方面是因为每页文档的结构大小一致，滑动浏览的体验也更好;另一方面是因为他们写代码也是按照这样的方式一个小模块一种场景依次往下走，更容易专注看当前写的这个模块的交互说明。 　　虽然有同事的肯定，但这种方式还有优化的空间。因为采用了两个工具，一个画原型一个写文档，如果Axure原型有改动，需要复制到keynote，两处都要更新显然影响效率。所以我还在考虑是否切换到某一个工具搞定这两件事，比如用sketch 。除此之外，文档模板也可以改进优化。 　　就像前面说的，交互说明文档，就像是交互设计师输出的产品，既要根据场景的变化不断调整，又要听取用户的意见，持续优化提升体验。

热心网友 时间：2022-04-13 18:35

1、写给谁看

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

视觉设计师：输出视觉稿

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

测试工程师：写测试用例

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

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

2、由谁来写

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

3、写什么内容

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

3.1这些要写

3.1.1页面整体说明模块

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

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

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

3.1.2对象

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

3.1.3*

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

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

3.1.4表单校验

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

3.1.5操作与反馈

操作：

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

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

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

2. 反馈：

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

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

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



过渡动画：转场方式

3.1.5状态变化

默认：

默认选项选中

默认显示的文案

默认排序方式

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

特殊：

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

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

3.1.6其他交互细节

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

3.2这些不写

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

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

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

4、怎么写

4.1 目录

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

4.2 格式

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

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

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

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

4.3 排版布局

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

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



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

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

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

5.1固定的目录结构

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

5.2简洁文字

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

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



表格罗列复杂状态变化



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

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

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

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

5.4处理重复内容

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

写在一处：引用时加链接

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

5.5更新后及时周知

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

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

6、总结

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

热心网友 时间：2022-04-13 20:10

我用的摹客来写交互说明文档，感觉是为产品团队量身打造的文档工具，支持在线撰写或上传本地文档。

文档可以和Mockplus、Axure的原型图和Sketch、Adobe XD、PS的设计稿互相引用，相互论证。也支持自动生成历史版本，可随时追溯和查看。完成后可以直接生成链接分享给同事，同事可以在上面选中文字评论，审阅很方便，哪里有问题也可以随时查看修改。
文档结合设计稿或原型图，可以更加清晰地阐述交互逻辑、设计思路、功能范围、页面细节等等。团队领导也可以根据产品需求文档清晰了解为什么需要开发这样一款产品。项目的其他相关方也可以随时参阅需求文档，了解项目的基本信息。