编辑指南:交互设计师通常在团队中扮演连接角色。上游对接可视化设计人员和项目经理，下游对接可视化设计人员和开发工程师都是以交互设计人员输出的交互文档作为下一步的参考。交互文档的重要性不言而喻。

基于项目实践，作者分享了移动终端交互输出文档的编写步骤和过程中需要注意的关键问题，供大家参考和学习。

我认为，一套完整而优秀的移动交互文档可以包括以下几个部分:

业务背景、产品目标、用户人群和用户目标业务规则定义用户流程图设计原则交互流程标注

当然也可以添加产品概述和更新日志等。产品概述简单地指出产品版本号和产品相关人员。

更新日志主要用来表示每次更新后更新了什么，更新者是谁，更新时间是什么时候，如下图所示。

01业务背景、产品目标、用户群体和用户目标

作为交互设计师。我们收到需求后，首先需要知道的是产生需求的业务背景是什么。其次，基于商业背景，我们知道产品的目标是什么。最后，搞清楚产品的用户是什么，用户的目标是什么。

交互设计师从产品经理或其他需求发起者那里了解需求生产的业务背景，然后了解为什么要做出这个需求。了解清楚之后，追溯需求最原始的本质。

在我们实际工作的大多数情况下，产品经理不会在需求文档中清楚地写出业务背景。此时，我们的交互设计师可以在交互文档中输出业务背景，并清晰地显示出来。

业务背景是什么？业务背景通常是我们为什么要做这个功能。通过做这个功能，对业务有什么帮助。通过业务背景，我们可以推演出业务诉求，并得到对应的产品目标。产品目标是什么？产品目标是产品能得到什么样的结果，对产品来说可以获得什么样的好处。所以在交互文档的设计中要重点体现出产品目标。通过明确产品目标，可以清晰的指导我们做交互方案。用户人群是哪些？用户人群主要是通过我们对现有产品的用户画像得到，并推算出使用这个需求的用户人群是哪一类人，通过明确的用户人群，这样我们在做设计过程中，可以很清晰知道这个需求为谁而做。用户目标是什么？用户希望通过使用这个功能达到什么样的好处或目的。

接下来，我将用一个虚构的案例来说明如何输出移动交互文档。

案例:浏览器的小测验和新活动。这项活动的需求是通过浏览器的金币问答，让用户与产品产生新的互动，从而提高新老用户的日常活动，增强他们的活跃度。

基于这个需求，我们交互设计师应该如何设计和输出一个交互文档？

根据以上:在设计之前，我们需要考虑业务背景、产品目标、用户群体和用户目标。

经过分析，我们可以得到该需求的业务背景、产品目标、用户群体和用户目的如下:

商业背景:

让用户通过使用浏览器的一些指定任务来赚取金币，并将金币用于消费(问答活动)，从而形成一个完整的良性闭环。

产品目标:

通过活动分享，提升浏览器的下载量；通过用户赚取金币的方式，提升用户使用某浏览器时长；通过活动引导用户分享，从而得到产品活动的更多曝光。

用户群体:

已使用某浏览器并喜欢获利活动的用户；未使用过浏览器的但喜欢获利活动的用户。

用户目标:

简单方便的完成小考，希望中奖。

02商业规则

产品的业务规则可能需要与产品经理、业务部门和运营部门进行沟通和讨论。这涉及到整个产品业务的规则。在实际工作中，我们有两种互动的情况:

产品经理会和业务或运营沟通，然后输出一份业务规则，这时候我们交互可以认真阅读并梳理业务规则，如果觉得不合理的话，可以和产品经理讨论沟通，并修改业务规则使之变得更合理，并输出在交互文档中。产品经理只是简单的有个业务规则想法，这时候需要我们交互设计师帮忙一起沟通并细化其业务规则，并输出在交互文档中。

该要求涉及的业务规则有:活动时间规则、金币生成规则、金币消费规则、资金池消费规则、活动发布规则、提现规则。对于这些，如果产品经理没有制定清楚，或者制定的不够好，就不够详细。然后可以互动整理，公式化。

在制定规则的过程中，我们设计师需要了解活动之前、之中、之后的所有活动流程，并贯穿整个活动流程。并给出合理的规则定义。如果规则制定不合理，整个活动就会因为规则的漏洞而崩溃。

下图显示了我定义的所有规则:

03用户流程图

用户流是指我们的设计师在用户使用过程中，要梳理出各种场景流，通过用户流程图，避免遗漏场景和交互方案。

对于任何功能或活动，第一个问题是入口设置在哪里。所以需要设计活动入口的逻辑。

主动用户主流程是用户正常进行活动的过程。

与主流程不同，对应的是金币不足时的异常流程。

如果用户赢了比赛，对应的问题就是提现。由于浏览器目前没有钱包，所以设计是绑定微信提现。

为了曝光，需要设计共享功能和入口。当用户中奖后，需要提示正在使用该产品的用户中奖。当活动到期时，需要设计相应的到期活动界面。

在对上述简单分析和深入的用户流程图进行总结后，可以得到以下七种用户交互流程图:

竞猜活动的入口设计在哪里金币充足-竞猜活动主流程金币不足时提现流程活动分享流程及所有入口已中奖时场景活动过期时场景

04设计原则

这里的设计原则是一些交互或视觉设计原则非常常见的，但是在设计这个活动交互方案时需要遵守的原则。这里的设计原则与业务紧密相关。

在设计这个活动之前，我们应该明确这个活动的设计过程应该遵循什么原则。这样，在设计整个活动的各种场景时，就可以清晰地让交互过程和页面布局遵循既定的原则，从而拥有更全局的视野。

这个活动的产品目标是通过活动获得产品的曝光和下载，所以需要满足的原则是引导用户快速找到活动入口，并提供活动的简要描述，吸引用户参与，顺利参与。

本次活动的目标是简单方便地完成小考，并希望获奖。在设计过程中，要通俗易懂，用户没有意识和运营成本。为了给用户一个中奖的机会，让用户觉得公平，需要及时将中奖用户反馈给用户。

因为活动只是暂时的，所以需要减少活动对大多数非目标用户的干扰或不喜欢。

基于以上分析，总结后制定了以下设计原则:

引导用户快速找到活动入口，并顺利参与提供活动简介说明，吸引用户参加竞猜活动页面，简单易懂，用户没有认知和操作成本尽量减少该活动对绝大部分用户产生打扰或反感保证公平公正，及时向用户反馈中奖人数

以上设计原则是为后续交互过程确定思路和设计指导。

05交互式过程注释

基于上面的用户流程图，我们可以得到7个用户操作流程，即7个交互流程标注。

目前，我认为显示交互式流程注释的一个更好的方法是按照一个主流程以站点地图/画板的形式显示。当一个主流程中有多个分支操作流程时，可以在站点地图/画板中显示。同时，分支进程的操作名通过标题来区分。

如下图所示:

当涉及异常场景且可以全局重用时，只需要全局组件描述，每个流程不需要显示其异常场景组件或页面。

全局组件是指整个产品共有的组件，如全局断开、成功操作、失败操作、加载、空数据接口、404等。

全局断网：一般是在首页使用tips提示。用户在其他界面点击操作时，也会出现toast反馈提示用户。也有一些app在用户进入出现对话框提示用户网络异常。相对于对话框，使用tips对用户的干扰更小。操作成功：一般操作成功都是根据具体的使用场景对出对应的提示。操作失败：异常情况导致操作失败，这时需要统一的提示，通常使用toast，也有一些使用对话框强提示用户。

加载：涉及到全局加载和局部加载，全局加载在设计中要统一说明，例如上一个界面点击进入下一个界面，使用的全局加载就需要说明。如果是一些小场景的加载，那么需要特殊说明。例如上拉加载，下拉加载，局部小区域加载等。

空有三种数据类型:

初始状态的定义：初始化状态，没有任何内容，需要用户进行某种操作才能产生内容的界面。清空状态的定义：通过删除或其他用户操作，清空当前的页面内容，产生了空界面，这时候需要有明确的提示，且告知用户该如何处理。出错状态的定义：由于网络、服务器或者没有找他其他结果等原因导致无法加载内容，产生了空界面，这时候需要有明确的提示，且告知用户该如何处理。用户操作反馈的无结果界面也可以用这样的思路来设计。

下图是H5小测验与新活动互动过程标记示意图:

在列举过程的过程中，尽量一行一行的走到最后，避免行与行的交叉。界面之间各种线条穿插造成的后果就是阅读凌乱，体验特别差，逻辑容易出错。同时在每个界面下写下相应的标注说明。

标签

以上是如何输出移动交互文档的说明，仅供参考。可以根据自己公司的实际情况进行合理的添加、删除或修改，使文档更符合自己公司/项目团队。