应急控制系统大屏策划及UI设计

看一些优秀的交互文档，看看别人对各个状态的标注和说明，以及流程的设计思考。看看别人原型中包含那些结构，是否值得借鉴并学习。找到优秀的交互输出模板，并根据自身设计团队情况，优化交互文档结构，提升交互文档质量

一套完整且比较优秀的移动端交互文档，我认为可以包含：业务背景、设计目标、业务规则定义、用户流程图、设计原则、交互流程标注以及交互各种状态异常场景。

1、业务背景

业务背景通常是我们为什么要做这个功能。通过做这个功能，对业务有什么帮助。通过业务背景，我们可以推演出业务诉求，并得到对应的产品目标。

2、设计目标

设计目标是通过设计得到什么样的结果，对产品来说可以获得什么样的好处。所以在交互文档的设计中要重点体现出设计目标。通过明确设计目标，可以清晰的指导我们做交互方案。

3、业务规则定义

关于产品的业务规则，可能需要同产品经理、业务方和运营一起沟通讨论。这个里面涉及到整个产品业务的规则。在实际工作中，我们交互会碰到两种情况：

情况1：产品经理会和业务或运营沟通，然后输出一份业务规则，这时候我们交互可以认真阅读并梳理业务规则，如果觉得不合理的话，可以和产品经理讨论沟通，并修改业务规则使之变得更合理，并输出在交互文档中。

情况2：产品经理只是简单的有个业务规则想法，这时候需要我们交互设计师帮忙一起沟通并细化其业务规则，并输出在交互文档中。

4、用户流程图

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

5、设计原则

这里的设计原则非平时看到的一些交互或者视觉设计原则，而是在设计这个需求交互方案中需要遵守的原则。这里的设计原则和业务强挂钩。

6、交互流程标注

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

目前我觉得交互流程标注比较好的展示方式，是按照一个主流程在一个站点地图/画板的形式展示。当一个主流程中存在几个支线操作流程时，可以分别在一个站点地图/画板中，展示出来。同时用标题区分说明分支流程的操作名字。如下图所示：

在涉及到异常场景，且可以全局性复用的情况，则只需要全局性组件说明即可，不用每个流程都展示其异常场景组件或者页面。

全局组件指的是整个产品通用的组件，例如全局断网，操作成功、操作失败、加载、空数据界面，404等

全局断网：一般是在首页使用tips提示。用户在其他界面点击操作时，也会出现toast反馈提示用户。也有一些app在用户进入出现对话框提示用户网络异常。相对于对话框，使用tips对用户的干扰更小。

操作成功：一般操作成功都是根据具体的使用场景对出对应的提示。

操作失败：异常情况导致操作失败，这时需要统一的提示，通常使用toast，也有一些使用对话框强提示用户。

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

空数据类型一共有三类：

1.初始状态的定义：初始化状态，没有任何内容，需要用户进行某种操作才能产生内容的界面。

2.清空状态的定义：通过删除或其他用户操作，清空当前的页面内容，产生了空界面，这时候需要有明确的提示，且告知用户该如何处理。

3.出错状态的定义：由于网络、服务器或者没有找他其他结果等原因导致无法加载内容，产生了空界面，这时候需要有明确的提示，且告知用户该如何处理。用户操作反馈的无结果界面也可以用这样的思路来设计。