举个小例子：
如果我们要去超市买一把鸡毛掸子，我们会去哪个柜台区域？
如果我们在“日用百货”区域找不到它，反而在“肉类生鲜”柜台旁找到了它，当你询问工作人员原因，超市工作人员振振有词地告诉你：“因为鸡毛掸子和鸡肉是从同一个生产厂家进货的，都是鸡的周边产品，所以要摆在一起”时，相信你的表情，一定是抓狂的吧。
上面这个例子如果是发生在生活中，可能会让我们感觉很荒谬，而事实是，这样的事情日复一日地发生在互联网产品的设计过程中。那些互联网产品的制造者们，以产品的“工程实现模型”直接呈现给用户，却对用户的不理解和迷惑熟视无睹，仿佛本应如此。
例如需要为客服人员展示一张用户日程列表，产品经理给出的方案如下：
产品经理因为不了解客服人员需要哪些数据，也没有意愿去了解，所以就简单地把数据库表里的字段一股脑儿地给搬了过来，其大致意思就是“总有一款适合你”，至于哪一个字段适合你，你自己慢慢找吧。
这样做当然不会遗漏信息，但造成了很大的信息噪音，让客服人员无法专注于有用字段，造成了很大的易用性问题。
最后解决的办法就是和客服人员深入讨论，发现降序排列的序号是完全没必要的，流水号是基于单号的扩展和细化，所以可以去掉流水号，最后做出了合理取舍。
以前在OTA公司工作时还曾经遇到过一个欧洲四国通票预订的产品设计，设计需求是这样子的：欧洲铁路公司一般都是商业公司，各铁路公司之间有协议，所以可以购买一种一次可以游览四个毗邻国家的铁路通票，但购买完成后需要选择即将出行的四个毗邻国家。
最初的设计是产品经理根据工程实现模型直接把后台逻辑关系照搬到了前台：
用户在看到这四个下拉菜单时，根本无法直观感受到这个产品的逻辑关系，用户不能理解为什么第一个菜单选中某个国家之后，后面的三个下拉菜单为什么选择范围就变得越来越窄，甚至存在没有选择的情况？所以用户在这个环节的投诉率和出错率很高。
后来从用户的认知模型出发，把所有国家菜单一次性地抽象出来放在一个界面上完成，变成了一个选择菜单的四个选择步骤，因为这种展示和选择方式基本符合了用户的认知模型，所以这次用户的理解完全没有问题了。
如果用户选择了某个国家，可选择范围收窄，用户的直观感受是因为我选择了某个国家，所以只有毗邻国家可选择，用户是可以理解事件发生的原因的，所以用户的可操控感增强了，而非减弱了：
这个设计据后期的调研显示，用户在这个界面上基本没有碰到理解和认知的问题，而且这个界面交互设计方式我们申请了专利。后期本来预备把这个展示方式做进一步的优化，根据真实地理位置把国家做成六边形来以期更加符合用户认知模型，不过后来因为离开了那家公司所以没有实现。
通过以上的几个例子，可以发现，只有从用户的认知模型出发，尽量贴合用户的认知模型去做设计，而不是照搬产品的工程实现模型，才能保证产品的易用性和用户体验。
毕竟，我们设计一款产品的目标对象，是用户而非我们自己。
