如何做出及格的交互设计稿？至少达到这5点！

一、事情起因

工作特殊性，我所在的组做的事情是在另外一个组产出的设计稿基础上去和客户对接，基于客户的要求提供定制化服务。所以一旦有新的设计改版升级，我们都需要让另外组的设计师们提供交互文档，然后我们基于这份文档来继续后面和客户对接的工作。

然而当我们接收到了新文档打开后，懵了！礼貌的询问对方：“请问这个是过程稿，还是最终稿”？因为简直「太乱了」，导致我看文档看的非常费劲，即时花了大力气因为文档乱以及信息确实，最终也没能了解功能具体如何运作。在一个大家熟悉产品的设计团队下，产出这样的交互稿着实让我吃惊~

这里面的乱主要有以下几点：

1. 文档无主体结构，标题不统一
2. 内容未分模块讲述，相互穿插，无集中讲述
3. 内容呈现逻辑弱，无从大-小讲述
4. 页面信息多且杂乱，包含：更新信息、待确认信息、分析信息、会议纪要...和设计界面无关的信息
5. 规则描述不完整且板式混乱

更多干货：

二、交互稿最基础要达成什么程度

交互稿绝对不是必须要做的非常漂亮，但绝对要「清楚」

因为交互稿承载的是功能、产品界面以及如何运转的（包含页面流转、规则、样式、反馈...)。需面向 PM、UI、RD、QA 全流程工作人员进行查阅的。正常一份可读性好的交互稿，其他人一看大概就知道你产品、功能具体是啥样的。

至于说交互稿到底要做到什么程度，我们可以拆分来看看看

1. 删除不必要信息

对外交付的设计稿需删除和具体页面之外的信息，诸如：分析、沟通结论、会议纪要、竞品分析、用户分析等等。因为你交付出去的是最终确认的，比如开发同学只需要看最终明确的设计及规则即可，这些分析过程可以放在画板外面供自己或团队查看即可。对于一些设计目的或者目标什么同样内部汇报可以放，当时交付出去的时候可以移走。

2. 页面模块划分及标题

根据实际产品，对功能模块进行划分，分别针对单一模块进行详细的呈现。并且对于不同的界面需要有对应的标题。

3. 交互说明要尽可能完整和统一

页面的交互说明可以遵循从大-小的方式。如大的框架的说明，再到细节的说明。

如：卡片整体的结构，包含标题、副标题、评分、评价...信息，哪些是必选，哪些不是必选，基线状态是怎样的。说完这些可以继续拆分描述，标题是一行还是两行、超出怎么显示等。

对于界面的说明要完整，即：页面上有的内容需进行规则描述。规则描述上也尽可能可以遵循一个规则来，如：常规规则、特殊规则、限制说明、文案、操作反馈、手势、提示、动效等，需要尽可能的覆盖不同的场景将规则尽可能的描述完整。

如 1：一行文字，最多显示多少个字符，超出后是...溢出、跑马灯、折行、字体缩小展示等；

如 2：搜索结果 feed，默认展示几个结果、没有结果什么样式、后续多余的答案是滑动加载还是需要分页、加载过程成功、失败样式、无网络样式等

如 3：按钮切换会有 toast 提示，toast 规则是怎样？误操作多长消失、有操作是否会消失、若同时快速点击其他按钮 toast 提示是已最后点击的为准反馈还是按照顺序依次反馈...

这些规则会有很多，交互设计师初稿肯定无法能够做到 100%的覆盖，但是基础场景至少需要阐述清晰~

总之，之前前辈说的一句话：凡是界面上有的信息及元素都应该有自己的规则说明，但同样的不做重复说明，有一次就行。

4. 页面功能流转要清楚

有些功能涉及到的页面流转很多，这时需要页面之间进行连线，方便读者在更加直观的看到页面间如何出入，及对应的分支流程。

5. 更新记录及版本说明

因为交互稿面对多伦的评审肯定会进行多轮的迭代修改，对于每轮具体的修改项都需要完整记录，这个可以单独开一个模块为版本记录，所有页面的修改都可以在这里进行记录。只不过记录的时候需要分点。

如：

首页模块：

1. 修改XXXXXXX,详见页面「1.2.2 首页说明」
2. 修改XXXXXXX，详见页面「「1.2.6 滑动说明」 ...

总结

以上初略的可以作为交互稿的基础，至于说细节板式，字号，颜色这些当然统一更好，但是我想说的是，更重要的是内容，交互设计师需要组织好内容信息及结构，引导读者根据你所呈现的信息来一点点了解产品的全貌。

欢迎关注作者微信公众号：「小发的设计笔记」