土豆妹儿

从正式工作以来算起做了两个大项目，刚开始做产品的时候比较懵逼，到后来看前辈的文章加上自己的领悟，考虑的问题就越加成熟，逻辑也越加清晰。是时候做一套自己的交互文档规范了，以便于日后的工作中更加有效率和规范。（由于公司的项目源文件是保密处理，所以文章中举的例子不是同一APP，也不能完整的成文，只能分享方法，依样画葫芦就好了）

前期，完成了产品的定位，分析，结构，功能等，就开始做产品的原型了。觉得大体的逻辑和结构走的通之后，开始写原型的交互文档。那么产品的交互文档中主要有哪些内容呢，该怎么写，以下就是我自己总结的规范，共同进步，欢迎吐槽。

（1）项目概述

（这些都可做简单介绍，因为在BRD和MRD中有详细体现）

首先，得用一页来介绍产品，让看文档的人（包括自己）更了解项目。

项目的概述包括：

1.1 项目介绍

简单介绍项目和项目的DNA。

1.2 目标人群

项目的目标人群定位。性别？年龄？职业。

1.3 类似项目

1.4 竞争对手

1.5 推广地点和时间

1.6 商业目的

1.7 推广策略

靠什么吸引用户注册？优惠？现金？在哪儿推广？宣传单？还是网上注册？

（2）变更日志

修改原型图，可能是由于开发过程中某些效果实现比较困难，或者是临时需求变更等原因，都是正常的。每变更一次都要记录：例如，

变更内容：添加摄像头设备进行封面设置的功能（比如修改了字段属性、功能样式）

变更区域：【A-摄像头管理】_【A-01添加摄像头】；【A-摄像头管理】_【A-02编辑摄像头】；

【A-摄像头管理】_【A-03视频监控】（因为这个功能的添加或修改影响到的所有页面）

变更原因：方便用户通过图片快速找到内容（可以在这里简单写出原因和提出需求的人、时间）

（3）版本说明

将每个版本的升级的升级内容进行说明。

以下是对版本号升级命名的规范

– 产品版本号 （1.26）

版本号 （ 1.26 ）

– 重大调整升级

– 产品结构功能等有调整

 子版本号（ 1.26 ）

– 在原有基础上面对局部功能进行了升级或调整

修正版本号（ 1.26 ）

– 局部小范围优化与Bug修复

– 一般是不动功能性的东西

（4）信息构架

项目都包含了哪些内容，层次结构怎么样，它们是如何组织起来的。有了信息结构，项目成员可以直观快速的知会这些信息，特别是刚接触时。

（个人习惯用Xmind画，版本在Xmind中表现出来。并导入Axure）

（5）流程图

作用：明晰功能流程，并与研发同时讨论其实现的可能性；避免遗漏界面与后台返回的状态提示。

项目包含业务流程、操作流程、交互流程说明。

业务流程：是业务逻辑。通常会由几个「角色」来组成，他会有一种流水线般的工作线，A搞定了，传给了B，B搞定他的部分，传给了C，C搞定后又要将结果传给A做。简单的理解这种穿梭在各种角色中的操作就是所谓的“业务流程”。

拿外卖点餐产品当栗子，分别说明他们。

画业务流程通常会用到“泳道图”这个是专门来表示多角色配合的一种流程。如下图。

（个人习惯用Axure画，以便直接在Axure中修改。）

角色有三，用户，系统（后台），厨房（第三方商家）。

我们来跑一下这个短短的流程，如果「用户」选好了今天的饭菜，提交订单了，这时就将订单信息推送给了「系统」，「系统」在后台生成订单，用户的订单状态变为「等待付款」。（其实系统这部分用户是看不到的，但是产品经理需要想清楚。）用户会来到支付页面，这时候做一个判断，用户是否为这个订单支付了费用呢？如果是，那么「系统」就会受理这个订单，将信息推送给第三方「厨房」，如果不是，那么用户就是取消了订单，订单状态变为「订单失败」。接受到订单的第三方厨房也会做一次判断，这个订单接还是不接呢？这是个问题~

我眼中的业务流程是个大局的东西，在思考他的时候也是着眼于整个系统的，你不再是一个用户，因为用户是不必知道后台的一些判断细节或是操作过程的，但如果你是产品经理的话是一定要清楚的。流程中总是由一个动作展开，那么思考时，我们要对每一步都带着一个“如果……不……”会怎么样的心态，就会发现很多可以做判断的地方。如果支付不成功呢？如果厨房不接单呢？如果退款不成功呢？这样想下去你的流程细节就会越来越完善。

OK，回顾一下，业务流程的重点是：设定角色，跑通流程、用“如果……不……”穷尽判断，思考产品背后的判断逻辑。

操作流程：顾名思义，就是用户对产品的一个操作流程，这个流程是为了完成某个任务。比如成功下单，比如登陆注册，比如退款等等。如图，这就是“用户下单”的操作流程。

他完全是以一个用户的操作角度来写。在初画操作流程的时候，不要早早的去过分在意细节与逆流程，逆流程便是那些需要判断是否的那个“否”的流程。第一次我往往都会用最理想的状态，将流程跑通，再去思考这里面会不会有那些“如果……不……”的细节。

交互流程说明：则是用户的操作、页面反馈等更具象化的东西。通常会用Axure来绘制，再加上一些文字上的注解。

（6）全局说明

针对于IOS，Android全局设计、交互的统一说明。

6.1 常用手势

6.2 加载

6.3 热区

6.4 文案

6.5 提示

弹出框类

Toast类

（分享成功、评论成功、添加到下载队列、已收藏、已保存到手机、已发送相册等情况下都可以有Toast提示，告诉用户他已经完成了某个操作。Toast的位置可以可以是居中，也可以是下面）

6.6 弹层/模态窗口

6.7 网络状态说明

6.8 格式规范

时间格式：

时间格式为（24小时制）：YYYY/MM/DD  hh/mm/ss, eg：2016/01/26  16:03:45

名字规范：

First name：Jielun      

Last name：Zhou       

Full name显示为Jielun Zhou

价钱规范：

显示货币符号，小数点后面都保留两位小数，eg：￥5.00

6.9 不同状态

（7）交互组件库

当你感觉到某种UI组合，每次都需要重新画一遍的时候，就可以考虑把这种UI组合做成交互组件。既提升了工作效率，又是文档具有统一性。

例如导航类、列表类、弹出框类、Toast类、键盘类、Icon类

（8）界面原型、交互文档

（导航：在导航部分我用字母、数字分别说明了所在模块、页面编号、页面层级等信息。只是一种便于我自己寻找以及内部沟通的形式。）

（界面：界面也有自己一套规范，如上图：先描述字段是否必填，再描述默认值等。当然颜色上也定了规范）

写交互说明时注意的点：

• 角色和权限说明

产品都会涉及到多种角色，不同角色存在不同的权限和不同的使用场景。所以设计过程要重视角色、场景和权限，也要在交互文档中说清关系。

• 排序说明

列表页面的排序，是按时间倒序或正序排列都要在交互文档中有所说明。

• 状态说明

默认状态：

主要是默认（初始化）显示的数据、文字、选项等。任何一个页面、表单、按钮、文本域等都会有默认状态，这是需要我们注明的。

常见状态：

页面上一个模块，它可能会有多种状态，比如APP客户端个人中心一般会有未登录状态、已登录状态，这些是需要我们展示清楚的。

异常状态：

非正常情况下的样式、文案、说明等，比如搜索无结果、加载失败、网络（定位）未开启、空白页面等等。异常状态一般较容易被遗漏，最终导致产品体验较差。毕竟用户不是都在办公室里把所有开关（权限）都打开才使用我们产品的。

• 限制

范围：

数据的取值范围。比如轮播图的个数、文本域的限制长度、文本域只能限制为数字不能为其他特殊字符的限制等等...

极限值：

数据的显示限制。比如最多应该显示多少字数，超出时如何显示、每次请求数据的条数，不足时怎么办超出时怎么办等等...

例如：两行显示产品名称，超过屏幕宽度截取增加...；时间没有年份时，如果在跨年期间，时间如何展示

• 操作

常见操作：

正常操作时得到的反馈状态。比如一个按钮经过不同操作会出现不同状态，鼠标进入、按下、点击后。

误操作：

用户操作错误的情况。这种情况采取的措施一般是提前预防错误、适当提示用户、系统自动纠错。比如库存接近0时，选择数量时就会提醒用户库存5件，如果用户输入超出5，则自动更正为5。

手势操作：

使用移动端产品时的操作方式。比如滑动、放大、摇晃等。

• 反馈

提示：

用户操作后，系统反馈给用户的提示。例如：收藏成功Toast会给予提示“收藏成功”，让用户明白自己已经完成了这步操作。

跳转：

点击某个链接/按钮后，页面跳转到的地方。网页也表明是原页面刷新还是新标签页打开，移动端要表明转场方式（默认为全局）。

动画：

用户操作后，系统通过动画的方式反馈给用户。动画给人的感觉比较友好，趣味性较强，避免过于夸张。比如Clear用炫酷的手势和动画赢得了用户的青睐。

除静态页面外，还需要考虑各种动态情况；除正常情况外，还需要考虑特殊和错误情况。

• 热区

正常点击热区：

要在原型图中表示出点击热区。用户是点击Icon进入下一个页面，还是点击整个条目进入下一个页面。

特殊热区：

对页面内一些特殊操作制作操作示意图，有静态表达，也有动态GIF图表达，主要是传达一些不好用文字描述的内容，以图文或动图形式说明。

• 修改要点

以不同的色彩标注修改或添加功能后的影响区域，以便开发人员更好的浏览。

画原型图时需要注意的点：

• 通过明暗对比来描述模块之间的视觉优先级

哪些内容是需要用户在页面上最先注意到的?他们的视线应该聚焦到什么位置?我们希望用户执行什么操作?这些问题不能简单的丢给视觉设计师来考虑。

具体实施起来其实很简单，将所有的深色“线框”移除掉，使用不同明度的灰色作为背景色来界定页面和模块的边缘，并籍此表达不同元素之间的视觉优先级。相比于纯粹线框风格的设计稿，我们可以在下图中明显的感受到元素与模块之间的优先级关系。

• 使用真实的数据内容

对于线框原型当中的范例内容，包括导航元素的标题、表单标签、介绍文案、图标等等，我们都应该尽量使用最贴近生产环境的真实数据。

将真实数据作为范例内容填充到原型当中后，我们要确保交互流程所涉及的信息的准确性。举个简单的例子，如果购物车的页面原型当中展示了两个单价为50元的商品，那么在结算环节中，总价应该是100元，而不是随便其他什么数字。

• 增加范例图片的自我描述能力
  

图片对于用户体验的提升起着重要的作用，当人们在网站中寻找商品或服务时，图片是引导他们制定决策的关键要素(怎样通过设计帮助用户制定决策)。另外，图片也能帮助用户对网站自身的形象和定位产生认知。例如：卖奶粉的网页中，产品图片显示一个健康的宝宝会比显示一罐实际的奶粉更有亲和力和说服力，这时原型图中就应该画草图说明，也可以文字说明一下，之后再交给视觉设计师优化。

• 以实际像素为单位
  

原型图中按钮、图片、文字的比例最好按实际像素为单位，不要相差太多，不然会影响视觉设计师的判断。

• 根据产品阶段和需求制作不同类型的交互输出

交互输出一般分为图片展示型（就是一张图展示所有页面，用线连接层级关系）和网页文档型（分多页展示，用网页链接来连接层级关系）。其实都没有很大的区别，能说明问题就行，得具体问题具体分析。

在大公司不管是视觉还是交互，普遍都有规范，以便于团队的合作和日后的管理，我也制作自己的一份规范，以便以后更有效率的工作。我一下子也不能够把所有的情况考虑完全，所以规范文档的源文件也会随时的更新的，边积累边更新吧。

（文档也是在公司写了几天，真不容易呀，也是佩服自己，哇哈哈哈，再次感谢众多前辈的文章，赐予我灵感）