易用性悖论

张哈哈 2023-08-01 23:15:13

最近在和团队一块设计产品的时候，由于目前的方向定位是给各个业务方提供底层的一些场景工具，经常会被一些其他团队的小伙伴问到：你们这个方案太复杂了，根本没有人会用。上手成本太高了，我觉得方案不行。

于是乎，和团队的同学思考和讨论了很久，想着怎么能否简化一下方案，让大家都会用，却发现不管是从哪个角度简化方案，总有些之前想到的场景不能覆盖，整体方案的拓展性也会大打折扣。

目前我们整体业务发展存在很大的不确定性，所以系统后期的拓展性必须要高。在思考了一圈后，发现其实我们陷入了一个很奇怪的思维：好的产品，一定是大家觉得上手快，理解和使用成本都不高的产品。

《Don’t make me think》一书中提大量提到了如何把一个产品做的简单，上手即用。但是仔细思考一下，这类产品，是否适用于业务介入程度特别深，业务逻辑特别复杂的产品呢？

拓宽一下思路，我们把互联网产品的概念拓宽至系统软件，会发现基本上一些专业软件，都是上手成本很高，甚至有专业的培训课程来辅助学习。市面上肯定没有人说Photoshop可以一上手就会用，专业或者长期使用的人也不会说Photoshop产品逻辑太复杂了，不用会。

这里其实感觉大家容易陷入一个悖论。易用 = 简单，上手快速。这个结论我理解本身就是有问题的，尤其是在一些大型项目中，如果涉及到的内容本身比较复杂，即便是一个简单的逻辑，前后需要考虑的因素也很多。所以一句简单的“你这个逻辑太复杂了，我不会用”并不能成为一个评价产品好用的标准。

那么思考一下，在SaaS产品，复杂大型项目中，易用性指的什么？我想到了三点。

一、流程是要串起来的

流程需要串起来，指的是一个逻辑，即便再复杂，整个流程必须是从前到后完整的链路。不管产品实现上通过什么样的方式来进行。最终的落脚点一定是基于你业务流程的规则或者逻辑的起点开始，终点结束。这个流程必须得在一个完整流程中。

简单来说，就是你一个流程里面，假如有ABCD四个依次衔接环节，这些环节可以分散在各个不同的菜单，模块。但是从A开始，到B的环节，用户一定不能是先操作完A，然后再一个和这个流程完全不相干的流程或模块中去操作B，即便这样的逻辑是通的或者本身A和B就是一个完全不相干的业务流程，但是整体的上手成本就比较高，至少需要用户通过手册或者培训去了解。

其实有时候，这些流程很简单的就可以解决，比如在一个表单页面，填写完成后，在完成页加一个简单的跳转链接用户很清晰的就知道下一步应该干什么。

二、系统流程要尽量贴合业务实际的流程

还是假如一个系统的操作流程中有ABCD四个环节，顺次安排对于系统模块的安排或者系统交互来说会更友好。但实际用户在线下进行操作的时候，可能真实的业务场景是BCDA这样。那系统的操作逻辑中，最真实或者合理的操作路径就是BCDA这样。即便你发现系统中这样设计可能会导致前后的一些菜单层级不够清晰，逻辑交互貌似不是很合理。但是实际在业务场景中的应用，这样的杂乱，其实际效率一定要比看似有序但却不符合业务流程更高效。

三、业务逻辑完善是第一要素

在做一些复杂项目的时候，很容易就会发现一些业务流程真的很复杂，分支流程特别多，也的确特别不好理解。这个时候前期在设计时很容易把自己绕进去，一些逻辑梳理着就容易走进死胡同。这时我们经常会用MVP的概念来设计产品，先把主流程设计好，后面的一些流程可能自然而然就可以了。这个时候，大家也经常会用“你现在设计的这么复杂，后面会用到吗？”这样的问题来给一个貌似合理的解释。

但实际上，我们很多场景下都会因为前期的一些逻辑想得不够完善，导致后面的大量返工。所以即便有时候，某些场景下可能在这个阶段通过一步就可以完成的工作，假如你预见性的觉得这个流程后面这么设计坑要大改，那我先给它改成两步，其中第二步在目前看起来完全没有什么用。但是长期来看无疑是夯实了整个产品的地基。

这样的好处后，可能前期有一些冗余的流程，但后面在产品的设计中，不需要通过补丁打补丁的方式，使系统变的极其复杂或者难以理解。长期来看，系统反而更简单了。

对标一下传统认为上的上手快速，简单易用。上述的流程中有些环节可能似乎都有些背离了某些原则。比如Don’t make me think中提到的“搞懂用户真正的需求，简化流程，减少步骤”。比如大家在设计中经常用到的同一类信息菜单汇总的设计习惯。

但是正如何一个用了10年PS的用户来说，你会因为PS的按钮太多了，90%的功能我用不到，那我就吐槽PS为啥要搞这么多功能，这么多我都用不到吗？专业的修图师会因为PS的上手成本高于美图秀秀，高于轻颜相机就使用后两者修图吗？

所以作为一个SaaS软件，尤其是可能某些用户群体一天的工作就是在你这个软件中完成的。你提供一个专业，全面的软件，要远比一句“哇，你这个软件的流程好简单”更靠谱。