最近做了一个项目，遇到一个经典的用户体验案例，所以决定拿出来和大家分享一下。当然，因为涉及到项目保密的问题，所有素材都是我临时重新制作的。由于只是用来说明问题，所以制作的比较随意，难看了点，希望各位见谅。

这是一个h5套壳的手机APP设计，我所负责的部分是设计——我属于设计外包，程序是客户方自己实现的。当然，这个项目比较曲折，因为种种原因，到后期我并没有继续参与下去，然而，问题就是这么发生的。

关于那个引发惨案的切换按钮，是一个极小的功能，小到我们平时都不会关注到，但是却在主流程里的一个按钮。这个按钮只有两种状态，所以在设计上其实并不复杂。但是恰恰就是这么一个小小的按钮，结果闹出了大乱子。让我们先来看看第一稿的样子：

这个设计很土，但是功能性上，至少并没有产生什么歧义。点击按钮，切换当前状态，逻辑上非常容易理解。唯一的问题：丑！于是，调整了一个版本，提交了过去：

滑槽设计，设计中比较常见的方式，现实生活中也有原型，相对而言，比较容易理解。只是程序实现上，为了图效率，图方便，效果打了很大的折扣。

这个版本提交完成以后，感觉这个项目太累，客户对于用户体验这块的干涉过多，却又有很多问题。所以提交完了这个完整版本以后，果断结单。后续的设计修改，移交给了客户方的设计师——当然，费用上，也适当做了一些让步，毕竟，这是由于我个人原因终止合作了——虽然提交了完整版本。

客户设计师改的版本，我并没太在意，想来是客户希望这个按钮能够“高端大气上档次”，所以让自己的设计改了个看起来复合时代潮流的扁平版本，但毕竟是个小功能，我也并没有觉得问题有多大。但是，没想到的事情发生了。

上线后没几天，当时对接我的pm突然找到我。坚称我设计的这个界面结构有问题，要我找到问题改掉。我也纳闷了，中规中矩的设计，怎么可能有问题。pm说是进入后的用户完成主流程的概率太低，流失率很高。根据以前的经验，我判断了下，应该是主流程里某几个环节发生了问题。

于是，我说服了pm，让程序在主流程的每个节点、每个功能按钮里埋了采样点，持续观察了两天，终于确定了问题——问题就出在了上面那个按钮上。

拿着数据，找到了pm，告诉他，让他们的设计师重新修改这个按钮的设计，就能改善这个问题，看到了数据，pm将信将疑，让设计又改了一稿。本以为事情到此告一段落了，但是没过几天，pm又来找我了，说问题没改善，反而更严重了！于是我看了下他们修改的界面......

这个调整，简直就是灾难......pm表示无法和自己的老大交代了——毕竟，这个按钮的设计是他们老大定的。于是拉着我去找了他们的老大。一翻解释和交涉后，最后在客户老大的深思熟虑下，又用回了第一稿（对于设计师而言，这个场景是不是很熟悉？）——当然，这次终于happy ending了，用户的数据在新版本上线后，终于快速回升了——我不确定是否真的是因为这个按钮方案的调整，但是我相信，应该是有很大关系的。

为什么这么一个很小的切换按钮会出现这么大的问题？之前说了，这是一个很小的功能，但却是主流程上的功能。但凡是功能按钮，无一例外的是需要谨慎对待的——更何况是在主流程上的。

在任何功能性的页面上，设计的核心是满足功能的需求，美观只能排第二位。功能的需求分几方面：1、必须要为功能设计合适的UI；2、必须要让用户看到图标后，对于图标能够无障碍理解，并正常使用。

第一个版本的设计虽然土鳖，但是至少不会出错，用户一看就知道，理解成本相对比较低。

第二个版本的设计似乎好看了一些，但是实用性上来说相对不高，并且实现成本上比较高。好在现实生活中，类似的滑槽设计比较多，所以理解成本相对也是比较低的。但是由于实现成本提升以后，为了妥协进度，去掉了滑动的动效，在某种程度上，其实是降低了用户体验的。

第三个版本，其实是第二个版本的一个简化——应该说是所谓的“扁平化”，但是问题也由此出现了，“扁平化”之后，图表意性被降低了，用户看到这个按钮的第一反应，是需要理解“这是个什么”？一旦理解成本提升了，那么歧义就会产生，就会干扰用户的正常行为。所以，数据不好看，和这样的调整脱不开关系。

至于第四个版本，原本是希望通过增加提示文字的方式提升“扁平化”以后带来的图表意性的缺失。但是事与愿违，问题反而扩大了：在这样一个按钮上，你无法分辨什么是当前状态，什么是可切换的状态。用户理解成本再次提升，歧义变得更严重了。

所以，最终回到了第一稿，虽然丑，但是至少能够说明问题。

总结了这次项目遇到的问题，以下几点是值得思考的：

1、任何视觉设计方面的东西，都必须把实用与信息传达放在第一位，美观是其次考虑的问题；当然这不是说美观不重要，而是在取舍的时候，这是一个衡量标准。

2、扁平化的确能够去除不必要的视觉干扰，但是需要防止过度扁平后带来的图表意性的缺失；

3、设计的再好看，程序无法实现，依然是白搭。甚至由于不恰当的妥协，会产生用户体验上的干扰。所以设计师的工作，并不是psd提交了就结束了。

4、没有数据，就无法验证设计的好坏。甚至出了问题，你也只能干瞪眼白挨锅。所以，不重视数据的设计师，不是好运营；

5、这个项目并没有做小规模的abtext，也正因为没做abtext，所有调整，只能用正式版本做小白鼠，这种行为相当危险；

6、接外包的时候，最好有自己合作熟悉的程序员一起合作接整包。尽量避免接单包设计的单子，以免后续扯皮；

7、永远准备好第一稿，万一哪天第一稿复活了呢？