新媒易动态
NEWS CENTER
NEWS CENTER
2020-03-30
在关于C端与B端产品的对比中，常提到“B端产品对于交互的设计要求较低”。然而，一方面各大厂都开始在B端领域发力，产品的可替代性逐渐提高；另一方面，尽管B端产品的核心在于业务逻辑和功能设计，好的交互依然是提高产品可用性和业务价值的重要手段。
所以，B端PM在产品设计时，依然需要重视UI，其中反馈机制又是很重要的一环。
从心理学上来说，对交流的需要是人的天性。当我们对外界发出一个信号，都在期待得到及时、明确、肯定的回应。
从产品设计上来说，好的反馈机制能够避免用户与产品交互过程中的“失联“体验，建立用户使用产品过程中的信心。
理想情况下，反馈机制的设计应该由交互设计师主导，但是实务中，尤其是B端领域，由于业务复杂性，很多时候交互设计与功能关联更为紧密，需要以PM的设计为主要依据。
反馈从广义上来说包括两大类：一类是界面的跳转（即进入新页面），一类是停留在当前页面的交互。本文仅讨论后者，即狭义上理解的反馈。
反馈必不可少，但是任何形式的反馈都会增加认知成本，打断心流体验。所以，PM需要在前期多花心思去选择最合适的反馈机制。正所谓PM想多一点，用户就能想少一点。
那么，B端产品的反馈机制与C端有何不同呢？
一方面，顺着“以终为始”的思路，B端产品的最终目的是提高效率。对于用户来说，使用这个产品并没有获得某种“快感”的先天期待，其核心目标是用最少的操作、最快的速度完成工作。
另一方面，B端产品往往与实际业务相关，一旦误操作很容易造成较为严重的后果。如果反馈机制设置过多或方式不恰当，用户很可能因为一些“下意识”的操作（如点击“确认”）而导致不必要的损失。
所以，在B端产品的反馈机制设计上，核心原则一言以蔽之就是“少而精”，即提高信息密度。
笔者在刚开始进入B端领域的时候，为了强调自己对细节的重视，恨不得每一步交互都弹一个提示框。对用户来说，却是增加了很多不必要的点击和“确认”，也造成了注意力的涣散，和对系统可信度的稀释。
所以，在设计反馈时，最基础的检查就是同一个信息是否有重复提示。
如某文档工具，文件上传成功后，进度图标消失，文件已经陈列在刷新的列表中，便无需再弹一个“上传成功”。
但是换一个场景，在IM中转存文件到文档库时，由于界面没有其他提示途径，所以需要在页面弹一个toast。
反馈的形式按照是否需要中断用户操作，分为模态框和非模态框两大类，其包含的反馈方式及特点总结于下图：
*虽然这些空间有Material Design和IOS的区分，但是随着多年的发展和相互借鉴，很多控件都有了类似的设计。所以下面仅从产品的角度进行分析，如有不确之处，希望各位UI同学不吝拍砖：
接下来，我们将需要反馈的场景进行分类，然后将反馈方式进行对应：
（1）如果不需要引发过多的附加操作，但是承载重要提示信息，如“操作有误”“对操作后果的警示”“用户协议”“权限提示”，或者重要运营信息，则采用dialog/alert。