交互设计

在交互设计中，首先要明确事件的概念。这里的事件特指用户在网页或应用上的操作，并且这个操作可以被系统识别。常见的事件类型有鼠标事件、手势事件、键盘事件、焦点事件。

字段规则定义了字段的格式要求。一个字段的规则项通常包括类型、长度、默认值和规则。字段规则可以由研发或者产品经理定义。研发人员只需要查阅规定，就可以知道字段要求。

可以由产品经理定义的是密码规则，因为网站对密码强度有要求。更广一点的字段规则包括自动生成字段规则：这些编号中的每一位数字都有特定的含义，也需要制定规则。编号规则的制定涉及一些技术，通常由研发主导，产品经理辅助。

业务规则是基于特定业务特性的限制规则，范围很广泛。业务规则是行业规定，行业不同，规则也不同。

这类规则都带有行业特点，所以制定规则的人必须有行业经验。因此，此类规则也被称为专家规则。

业务应该考虑的方面有 4 个：

主要流程：也就是正常执行操作的流程，没有任何异常发生。
分支流程：和主要流程并列的流程，是用户的选择，而不是异常事件。
异常流程：异常流程对应的是用户的错误或者业务异常判断。
业务规则：业务规则和异常流程有时候是一回事，两者并没有明确界限；但是业务规则更多强调的是一条简单的规则。

无论是字段规则还是业务规则，都要在需求文档里表达出来。

通常来说，业务规则既可以用流程图来表达，也可以在原型图旁边写出。字段规则因为表达的大多是显示内容，所以在原型旁边写出来即可。

字段规则属于全局性要求，是稳定不变的，所以可以只写一份全局规则来统一维护。

交互设计的时候，可以采用如下几个原则来指导设计。

首先是反馈原则。人机交互的基本原则是让用户和系统之间保持良好的沟通和信息传递。系统要告知用户发生了什么、预期是什么。如果系统不能及时向用户反馈合适的信息，用户必然会感到失控和焦虑，不知道下一步要做什么。

系统应该在合理的时间内，以正确的方式向用户提示或反馈目前系统在做什么、发生了什么。用户在界面上的任何操作，不论是单击、滚动还是双击，系统都应该及时给予反馈。反馈包括显示变化和结果反馈。

显示变化是对用户的鼠标事件、手势事件和焦点事件的反馈。在用户触发这些事件之后，系统要有显示上的变化。系统通过显示上的变化可以让用户知道这个操作是有效的。在用户操作之后显示有变化，自然是好的。因此，显示变化可以多多使用。

在用户输入完信息或提交信息之后，系统就要给予用户结果上的反馈。这个结果可以是错误、失败、成功等等。结果反馈要考虑两点，分别是输入完和提交完。结果反馈只是偶尔使用，使用太多反而不好。在用户没操作完之前，系统不应该有太多的结果反馈。

第二个原则是隐喻原则：系统要采用用户熟悉的语句、短语、符号来表达意思，遵循真实世界的认知和习惯，让信息呈现更加自然、易辨识和接受。

所以，在人机交互设计里，程序的沟通和表达、功能的呈现，都要用最自然、用户最容易理解的方式，避免采用计算机程序语言的表达方式。设计时要采用符合真实世界认知的方式，让用户通过联想、类比等方法，轻松理解程序想表达的含义。

第三个原则是回退原则。用户经常会不小心操作错误，需要有一个简单功能，让程序迅速恢复到错误发生之前的状态。

用户误操作的概率极高。对于误操作，软件系统应该尽量提供撤销、重做或者反悔功能，让系统迅速返回错误发生之前的状态。当然，不是所有操作都可以反悔。

具体实现就是在输入框旁边加删除按钮，或在发送消息后加撤回操作。

第四个原则是一致原则。同样的场景和环境下，用户进行相同操作，结果应该是一致的；用户和平台的风格体验也应该保持一致。

软件设计、产品设计里有很多约定俗成的规范，虽然没有明文规定，但用户都在遵守，因为他们已经习惯了这些规范。产品经理在进行设计时，应该遵循惯例，并且保持系统的一致性，不要盲目标新立异。

在一个或多个系统里面，使用统一的设计风格。无论是图标选用，还是布局规划，都保持整体的一致性，让用户容易理解，并且容易习惯和适应。

第五个原则是防错原则：系统避免错误发生，要好过出错后再给提示。这个原则也可以叫防灾原则。

进行设计的时候，首先要考虑如何避免错误发生，其次再考虑如何检查校验。好的设计在错误发生之后，就会避免它出现，而不是在错误发生后告诉用户错了，还要用错。

主要有两种方法：

给用户清晰的提示，从而避免用户产生错误。
禁止用户产生错误。不给错误的只能创造机会。禁止错误的方法是不让用户填错，或者填错后系统自动忽略。

第六个原则是记忆原则，让系统的相关信息在需要的时候显示出来，减轻用户的记忆负担。

第七个原则是灵活应用原则。系统用户中，中级用户往往最多，初级和高级用户相对较少。系统应该为大多数人设计，同时兼顾少数人的需求，做到灵活应用。

灵活应用原则不仅是一个交互设计原则，也代表一种产品设计理念。系统既要做得简单易用，让所有中级用户用起来得心应手；也要提供必要的帮助，让刚入门的初级用户顺利上手；还要支持灵活的个性化定制，让高级用户能够以进阶的方式使用系统，充分发挥其价值。

第八个原则是简约设计原则。对话里不应该包含无关或不必要的信息。增强或强化一些信息，就意味着弱化另一些信息。重点太多，就相当于没有重点。在视觉设计里，要掌握好突出标记的度，以及内容的呈现方式。

第九个原则是容错原则。容错原则强调的是，当用户已做完任务且错误已经产生的时候，系统该如何应对？主要有两种方法。

一种方法是指出错误。当用户操作因规则冲突无法完成的时候，系统要超越简单的失败提示，转而诊断问题根源，并提供明确的错误说明，同时应该给出具体的纠正建议和替代方案。以此引导用户从错误中恢复并继续任务。对于很多运行时错误和异常，计算机程序都会返回某个错误代码。但用户看到这些错误代码时，并不明白发生了什么。所以一定要将错误代码转换成用户能看懂的信息，并告诉用户解决建议。

另一种方法是降低损失。对于可能造成不可逆后果的操作，系统必须预先明确警示其风险；即使用户确认执行，也需通过技术手段提供缓冲与恢复的可能，从而在错误发生后，最大限度地降低用户的实际损失。

最后一个原则是帮助原则。对于一个设计良好的系统，用户往往不需要经过培训就能轻松上手使用，但提供帮助文档依然很有必要。

帮助信息应该易于检索，通过明确的步骤引导用户解决问题，并且不能太复杂。B 端产品的复杂性比 C 端产品高很多，用户进行自助服务、自助操作的难度也高很多，因此 B 端产品的帮助文档依然有存在的必要。

产品设计人员要尽量在前端交互上做好引导提示。对于复杂的规则和逻辑，可以考虑通过帮助文档这种形式来指导用户。

交互设计还有一些外围需求，分为前置条件、后置结果和最小保证。

前置条件是用例能执行的前提。常见的前置条件有是否登录和网络情况。

是否登录是指在浏览某个界面或进行某个操作时，是否需要登录。

网络情况是指如果遇到网络问题，该页面就无法显示，此时系统要提示网络有问题，并告知用户如何处理。网络问题很固定，产品经理只需要在页面设计提示信息即可。

后置结果描述系统在用例完成后要做的事，包括要跳转的页面、创建的数据和进行的操作。大多数情况下，产品经理要明确跳转页面；对于创建的数据和进行的操作，不需要考虑太多。

最小保证定义的是即使用例未完成或发生意外，系统也要做的事。最小保证是一种特殊的后置结果，强调非正常情况下会出现的结果。常见的最小保证有保留信息和记录日志。

用户在执行用例的过程中会不断输入信息，这些信息有时候需要保留下来。保留的信息在下次用户再执行这个用例时显示，从而方便用户操作。通常来说，只有当需要保留信息时，产品经理才要在需求文档里写出，否则系统默认不保留。

日志记录了用户的操作和系统执行的信息。记录日志功能有时候由研发人员开发，有时候由产品经理开发。

做交互设计的时候：

先设计字段规则的交互。明确字段规则，再设计系统的交互响应。这个交互要能帮助用户高效、顺畅地完成输入工作。
再设计业务规则的交互。业务考虑点包括主要流程、分支流程、异常流程和业务规则。
最后完善 UI 需求，包括前置条件、后置结果和最小保障。

交互设计里，业务规则的交互和外围需求比较重要，要将其汇总到一起，形成用例文档。有的公司的需求文档就由该用例文档加原型图组成。

这个用例文档有广泛应用，既可以用在偏向交互的用例里，也可以用在偏向业务的用例里。总之，只要按照用例知识拆解出了用例，就可以用这个用例文档来描述。

用例文档的字段比较全，但不意味着都要写。用例文档是一个需求检查表，也是一个全面的提示，产品经理可根据情况进行删减。最佳平衡点是：即使删除一些描述，研发人员也不会出错。对这个度的把握，需要产品经理跟研发人员不断磨合，找到最佳平衡点。

用例文档是文字形式的，但不意味着必须用文字写。更常见的方式是，产品经理先画出流程图、状态图等，然后再画原型图，并在原型图旁边加上交互说明。交互说明是图文结合的，描述了分支流程、异常流程和业务规则的内容。

对于前置条件、后置结果，这个保证可以做全局说明，也就是写在几个需求的前面，做统一描述即可。