原型中，这些应该有的说明

前面有说到《原型应该包含哪些内容》包括：

1. 变更日志；

2. 版本说明；

3. 信息结构；

4. 流程图；

5. 交互说明；

其中“交互说明”部分是最直观和细节的，也是研发会仔细琢磨的部分（也是大部分会跳过前面步骤直接进行画图（&交互）的部分），所有需要我们考虑清楚，表达清楚。因为按钮不止一个状态、文本域是有限制的、用户操作不是完全可控的...

1. 状态

默认状态：主要是默认（初始化）显示的数据、文字、选项等。任何一个页面、表单、按钮、文本域等都会有默认状态，这是需要我们注明的，否则研发人员难以准确单纯的从原型上判断出元素背后的逻辑。

常见状态：页面上一个模块，它可能会有多种状态，比如APP客户端个人中心一般会有未登录状态、已登录状态，这些是需要我们展示清楚的，如果我们少写了状态，研发人员就会纳闷xxx(登录)之后(前)是什么样的呢？

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

2. 限制

范围：数据的取值范围。比如轮播图的个数、滑块的范围&刻度、文本域的长度等等...

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

3. 操作

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

特殊操作：一些极端情况下的操作，出现概率较小，还是要想好应对措施。比如我们在买保险时会有常用被保险人，选中某个其详细信息会出现在申请表单中，如果在这时候修改了被选中人的信息，修改后的人，算被选中人还是新的被保险人呢？提交表单后是覆盖愿被选中人信息还是新增一个被保险人呢？

面对可能出现复杂的情况，要和研发人员一起探讨解决办法，并把交互说明写清楚。有时候研发人员想到的办法可能更简单实用。

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

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

4. 反馈

提示：用户操作后，系统反馈给用户的提示。

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

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

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