众所周知，一般的冲水马桶是有两个冲水按钮的。每当我去完厕所准备冲水的时候，问题就来了：按哪个按钮啊？
一般来说，小按钮冲半水，大按钮冲全水（基于节水？）。那选择的标准是什么呢，小便小按钮，大便大按钮？要是我排泄量比较少（或者比较硬...)呢？
所以说每个用户的情况不一样，更别说各家马桶制造标准不一样。
马桶作为一个产品，可以想象到它的使用场景是这样：上完厕所->准备冲水->见到马桶上有两个按钮->陷入思考，假设马桶的冲水功能是可以满足需求的前提下，用户之后的选择有几种：
1.看按钮上面的提示，然后选择一个按钮冲水 （必然增加学习成本）
2.随便按一个按钮，然后看效果（可能增加学习成本）
3.直接不冲走人（给产品带来了不好影响...）
无论哪一种解决方案，可以说这个马桶的体验是不好的，因为这个本应该很简单易懂的产品，却让用户的陷入了思考，哪怕是几秒。
同样的事情也发生在互联网产品身上，例如你以前百度搜索某一个软件，第一排通常出现的是百度软件中心提供的“高速下载”和“普通下载”（现在已经改回只有一个立即下载），普通下载就是直接下载，高速下载就是先下载百度软件助手再下载你要的软件，实质上速度也没多大提升，用户体验糟糕透了。
再比如，我接手过某个小区服务类App，初版里面有两个功能，一个叫客服投诉，一个叫经理信箱。我第一反应是这两个功能分别是干嘛的呢？有什么分别？哪个能完成我的目的？而这个功能原本设计的初衷是客服没有回应时找经理，因为经理的权限比较高而且能立即处理。那如果我是用户，我直接用经理信箱不就好了吗？客服投诉功能就变得可有可无了。
回到马桶问题上，原设计的本意可能是提供更全面的选择，达到服务各类用户以及节水的目的。但从实际效果来看，未必服务好了用户，反而造成了用户的困扰。
解决方案其实也很简单：只提供一个直观的冲水按钮，单次按下冲水量能适用于大部分情况，并且按下时间越长冲水量越大。
这个看似简单的解决方案其实蕴含了几条产品设计的基本原则：
1.Don’t make me think（只提供一个选择）
2.20%-80% Principle（核心功能先满足80%的主要用户）
3.渐进渐强（想办法在原基础上满足剩下20%用户的需求）
现在看看，这三条原则放在互联网产品身上也是极其适用的。这说明产品设计原理其实都是相通的，无论是Web产品，移动端产品，抑或是很传统的马桶产品。
完。
