如何写出清晰易懂的交互文档

读了一篇文章——《如何撰写开发哥哥喜爱的交互文档》,结合平时自己的工作方式进行思考,发现有些方法的确在践行,但有些是遗漏的,因此, 根据文章中提到的一些方法,对平时的工作方式进行了总结,整理出适合自己的书写交互文档的思路。

一、给谁看

就跟做产品需要关心用户是谁一样,写文档要关注读者是谁,他们关心的内容是什么。

产品:关注核心流程是否充分满足产品需求

UI:控件样式及页面展示

开发:控件交互、页面展示、页面跳转、页面加载方式、异常情况处理等页面实现逻辑

测试:场景是否考虑周全、异常情况是否全部覆盖、是否受设备限制等

除此之外,有些情况下,交互设计师会直接对接业务人员,他们关注的内容与产品基本一致,即——核心流程是否满足业务需求,按照『问题-解决方案-流程』的步骤推进即可。

二、意义:为什么我们要输出清晰易懂的交互文档

Why:让团队成员了解项目背景,为什么做          How:让大家明白如何做

既然是一个团队,有一个共同的目标可以增强凝聚力。针对项目背景的解释,让大家了解到项目要解决的问题,让大家从同一个出发点去思考问题。详细讲解设计方案,能够让大家带着前面提出的问题去评估解决方案的合理性,如果在阅读过程中发现解决方案有误,尽早提出就可以及时修改,使方案更加完善。这样子,最终的方案就不仅仅是一个产品和交互设计师认可的东西,而是得到了项目组全体成员的共同评估认可,出错几率更小。

在介绍项目背景时,最好结合数据进行说明,通过这种方式,能够让项目动机更具说服力。比如,对比两种方式的提交率和成交率,无论从提交还是成交来说,方式A都比方式B更优,因此在产品迭代时,要考虑到更多的引导和推荐A方案。

三、设计方案及交互说明

以页面为基准从整体上考虑:原型稿上呈现出来的,只是交互设计师否定再否定的思考结果,有很多取舍是在最终的设计方案之外的

例如在拿到需求时,从整体上考虑共有几个页面,页面关系如何,完成任务的访问深度是否合适?访问深度过深,如何避免用户迷失?设部分思考很少以文档形式留存下来,但却对于设计方案来说必不可少。

从流程上思考:如何可以让流程更加简洁,开发和测试都更容易读懂

能够达成目的的路径有多种,但一定有简单和复杂的差异。尽量多想想能否以更简单的流程来达成目标,避免被既定思维限制。

极端情境考虑

1、网络因素——弱网情况 & 检测不到网络:提示用户网络问题导致的数据加载失败,并引导重试

2、数据因素——数据加载失败 & 数据为空:数据加载失败时,提示用户失败原因且引导重试;数据为空时,建议用户更换请求数据关键词,给出解决方案

3、权限因素——需要授权才能展示的数据或内容 & 页面加载环境变化:如在微信环境下,拒绝授权账户信息

4、设备因素:是否响应屏幕旋转的情况 & 不同尺寸设备的适配情况

交互元素的状态变化

在原型图上标记出可交互的元素,并逐一进行交互描述,描述格式为——触发事件+界面变化(元素变化)+关闭/返回方法。描述之后,需要写清楚元素状态变化的几种情况:

1、状态变化:包括Normal、pressed、disable。对于一些通用组件,以交互规范的形式事先定义好状态,能够有效提高效率

2、数据变化:包括长度变化时如何处理,数据类型变化时如何处理、出现特殊字符时如何处理等

3、动效要求:是否对元素变化有动效要求,动效表现为如何,包括动效示例及缓动曲线参数说明等,使开发能够很直观的了解你所说的效果

4、跳转关系说明:元素之间的链接关系,如何从A到B,又如何从B回到A

为了避免遗漏,可以建立交互设计自查表,引导帮助自己查漏补缺,特别是遇到大型项目,一般周期较长,交互设计自查表,不仅能够起到查漏补缺的作用,还可以提高自己思考效率。

四、不同类型需求的展示形式不同

a.页面优化,尽量放线上对比图,明确更改点

b.新增功能,需要清晰的流程图

c.大型功能,注意拆分细节任务流,方便协作

工作时已养成一种固定的撰写习惯,读到这条建议后,深以为然。根据需求类型灵活处理文档形式,以『易读性』为目标,才是一种好的习惯。

五、文档管理

看过一些文章,一般会在原型图内做版本记录,但我的习惯,为了避免单个文件过大,更倾向于以项目为维度,建立独立的文件夹,以清楚的文件名进行管理。项目完成后,进行复盘时,可以将项目按照页面拆出来,建立以页面为基准的管理文件夹,便于工作交接。

推荐阅读更多精彩内容