B端产品经理指南：交互说明的详细解析与实践要点

交互说明是什么？

交互说明，简单来说就是：原型图边上的注释，对原型图的解释说明。

主要用于描述界面元素是什么？有什么限制条件？有几种状态？操作后有何反馈？以及元素的来龙去脉，从哪里来，到哪里去等。一份好的交互说明，可以有效降低沟通成本，提高工作协同效率。

有的交互设计师喜欢用动态效果来代替交互说明，这样的方式会给开发同学照成一定的困扰。浏览原型的人需要逐一操作才能看见效果。在时间允许的情况下，建议采用交互说明与动态效果相配合的方式，这样也会相得益彰，更容易开发同学理解。

要注意：产品阶段不同，交互说明的规范也不同。如果产品所处阶段为成熟期，那往往产品的交互文档已经沉淀了很多通用法则，可以被复用，那么现在的交互说明文档少写点，问题也不大；但产品处于探索期或成长期，通常来说可复用性的交互资产是不存在的，那交互说明文档就需要准备的相对完善。

交互说明包含的内容

我们先整体看下交互说明包含哪些内容：

备注：对于数据字段还应包括数据来源，数据来源主要指列表内数据来源的说明。告诉开发同学根据什么条件从数据库里取数据。

限制条件

限制条件包括【范围值】和【极限值】，是对元素基本属性的描述。

1. 范围值数据的取值范围，即有哪些可选项。

   举例：在发布文章时，可选择的类型有哪些；在选择职位时，默认可选职位有哪些。

2. 极限值即该元素最大限和最小限时如何展示，以及不满足限制时如何解决。在设计原型时，我们需要特别注意这点（因为真的真的是特别容易遗忘的一点），而且元素的最大限和最小限，对界面排版有一定影响，很可能因最大限信息显示不全，而更改排版方式。

   举例1：列表中文章的标题，最大限制2行，超出后显示省略号。

   举例2：文本框输入的极限值（大家在设计文本框时，需尤其注意，因为它的限制条件比较多）。

状态

1. 默认状态即默认内容，包括文案、选项、键盘、排序等。

   举例1：文本框的默认状态（一般包括：文本框提示文案和默认键盘（c端））

   举例2：列表默认排序方式。涉及到列表，就要想起这句话：按什么排序？几种常见的排序：按发布时间倒序/正序、按更新时间倒序/正序、按热度正序等，需具体情况具体分析哦。

2. 正常状态用户正常使用时，会遇到的状态。

   比较常见的如登录/未登录状态，认证审核状态，订单状态等。举例：用户申请身份认证涉及的状态。

3. 

   特殊状态一些特殊场景才会出现的状态

   包括无数据状态、网络加载状态、网络未连接、系统报错等。虽然这些状态不会经常出现，但是同样会影响用户的体验。所以我们在做设计时，也要考虑全面。

操作和反馈

当用户执行某项操作后，需给予用户及时的反馈。不管用户是常见操作、错误操作还是一些极端特殊操作，都要做到“防呆“，防止用户不知所措。

我想你肯定遇到过这样的情况：当你在浏览器中点击【下载按钮】后，如果网络状况不太好，浏览器就没有任何反馈，这时候是不是有些抓狂？会不断尝试再次点击，结果下载了n多份。所以，想要给予用户好的体验，就要重视用户操作后的反馈。几种常见的操作和反馈如下：

1. 正常操作：在正常状态下，用户的操作流程（即来龙去脉，从哪儿来到哪儿去）。在用户的操作过程中，需要及时给予用户反馈，告知用户发生了什么。

2. 错误操作：当用户进行了一些错误操作时，需要给出一些纠正反馈。错误提示内容需包括：当前错误和纠正信息，即告知用户当前发生了什么，接下来可以做什么。

   举例：一个评论框的操作和反馈（包括正常操作和错误操作）

其他

用户身份

当某些功能并非开放给全局用户时，需明确告知开发人员，哪些用户有此权限。如果文档中不注明，开发人员会默认认为该功能开放给所有用户。所以当涉及用户权限问题时，需明确的在交互文档中标注清楚，哪部分用户有权限使用。

举例1：某些功能仅针对会员开放，如：视频产品的去广告功能、微博的首页置顶、微博来源自定义、Bear的多设备同步等。

举例2：某些功能仅针对某类身份的用户开放，如：知乎中，开通专栏的用户，才有权限使用专栏管理&发布文章等功能。

站内信&推送

当完成某步操作后，是否需要触发消息（站内信&推送）通知用户。以及通知用户的文案写些什么。

举例1：用户申请身份认证，当他提交审核后，会自动触发站内信，告知用户：信息已提交审核，审核时间多久。

举例2：当用户身份审核通过后，后台触发站内信和推送，告知用户：审核已通过，点击查看详情。

数据埋点

很多刚入行的朋友，不太注意数据埋点，这样就会导致产品上线后，才发现想看的一些数据没有做统计，由此导致部分初始数据的丢失，最终数据分析不够准确。所以在功能开发时，便要进行数据埋点，为上线后数据分析提供基础。常见的数据埋点，如：追踪用户的行为轨迹，查看关键路径转化率，分析某个活动对日活注册量的影响等。

注意事项

尽量使用真实数据

使用真实数据，更有带入感，更能还原真实场景。而且在真实场景中去设计，不会遗漏一些特殊状态的处理。

2. 避免过长的文字说明

可以用图片表格讲清楚的内容，尽量不要使用很长的文字，因为大家没有耐心看完。

3. 注意交互说明的排版

整体排版清晰，更有助于开发人员的阅读。

4. 不遗漏特殊状态的描述

再次强调，特殊状态不要忘。很多需求的改动和增加，都是因为特殊状态忘记了，导致最终增加开发的工作量。

5. 偶有遗漏是正常的

有同学看到这条，可能会觉得我写的自相矛盾。一边在强调要写完整不要遗漏，一边又在说偶有遗漏是正常的。其实这条是想告诉大家，**保持一个好心态！**毕竟谁也不可能把所有情况都考虑到，总会有一些特殊情况，就如同程序员不可能没有bug一样啦。所以大家在写交互说明时，遗漏了也不要过于纠结，及时完善，解决问题是第一位。踩过坑，我们认真记录下来，总结分析原因，下次就会注意了。

总结

以上，给大家讲述了交互说明中一些零碎但很重要的点，以及注意事项，希望对大家有所帮助。

本文中提到的内容仅供大家参考，还是需要活学活用，具体问题具体分析哦。至此，相信大家已经清楚的知道交互说明需要写些什么了，希望每个人都可以建立属于自己的交互checklist。在每次写完文档后，对照检查一遍，有效防止遗漏的同时减少撕逼次数。