云之家 CRM 自 2015 年底快速发展，从原来的一个模块，发展到了九大模块。到 2016 年底，基本上覆盖了客户关系管理的全流程。而原来的 CRM 首页已经无法满足九个模块的展示，同时原来的首页的功能体验也不够友好。基于此，产品团队也开始着手考虑优化首页的设计。随着业务越来越复杂，各个子模块页面越来越冗余，所以 1.0 的改版，除了需要重新设计首页之外，还需要对各子模块的界面进行优化。
接着我们使用 KANO 模型去分析目标用户和产品决策的需求。我们将实现难度低用户满意度提高不明显的定义为基本型需求。实现难度较高，但能让用户觉得特别有用的定义为兴奋型需求。而这两者并不是我们重点关注的核心问题(因为不是产品的差异点所在)，但是在我们设计的过程中，依然投入了资源去实现此类需求，因为用户最基本的需求还是需要满足的。经整理我们将穷举出来的需求归纳到 Kano 模型中:
最后，我们根据上图，将需求进行了进一步的精简提炼，找到了产品的终极目标:使用大数据服务提升销售效率从而提高企业收入。产品终极目标的存在就在于防止我们的产品在最终呈现上偏离了既定的方向，但是产品目标归产品目标，而设计目标则不太一样。设计的本质还是为我们的用户提供有效的行为解决方案。所以经过对产品终极目标的分析，以及考虑到 CRM 1.0 首页的定位，我们进一步提取了 CRM 1.0 首页改版的设计目标:效率与激活。
从上图可以看到，两方案的差异点就在「有无快捷新增操作」上。我在后台查看了个模块的用户行为数据，发现其实某些新增功能常高频的，所以我提取了一些高频的操作，将其放到了首页那里。但是这个方案的问题就在于，这种新增功能对于销售员来说的确很方便，但是对于中层人员以及老板来说就不是很重要了。
因为一般这类人已经不跟单了。于是我就想「有没有一个不同角色的用户都共有的高频需求呢?」，回过头来看之前整理的思维导图、 Kano 模型，以及设计目标。发现 to B 应用跟 to C 应用最大的不同就在于，to B 用户存在阶级。特别是业务比较重的场景中，阶级之间存在种种矛盾。很难通过单一的设计去满足多阶级的需求。
MVP Testing 验证了我的思考。制作好了低保真原型后，我拿着这两个版本去到我们公司的销售员、销售总监那里做了个简单的 MVP Testing。大家对快捷新增操作的意见的确是很不一样。销售员的确认为这样可以更方便地开展工作，但是也有一部分人觉得不实用，原因就是没有提供 TA 想要的快捷操作入口。(因为销售员的工作也是存在分工的，有些销售员可能就关注线索的挖掘，比如地推人员。对于这类用户他们的高频操作就应该为「新增线索」。同时，销售模式的不同，也会导致高频操作的不同，如果企业的产品是以投标的形式售卖的话，这种项目型销售则是以「商机跟进」为主。)而销售总监则认为快捷入口比较鸡肋。
大家可以看到，其实我是取消了整个快捷入口模块，原因就是它不灵活，而且通用性并不强，如果需要提高其通用性的话，还要为它提供自定义功能。用户需要为此，去学习如何设置，同时其它模块也有设置功能，过多的设置只会让用户觉得软件过分地复杂。同时增加了自定义功能，会延长整个开发周期，就当时的情况来看，留给我们开发的时间并不多。(我认为在平衡设计方案的时候，还需要考虑实现的问题。如果开发周期很长，但是对体验的边际提升并不是很大的话，我宁愿采取开发资源较少的设计。因为互联网产品的精髓就是「迭代」，设计也是可以「迭代」的)
总结整个设计过程，其实大家不难看出，我的整个设计流程几乎按照 Lean UX Cycle 的方式进行:
从需求分析到设计，再到完成设计原型展开原型级的检验。检验过后，继续思考并且调整设计，接着再进行检验。可能每一个新设计只是在旧设计的基础上进行了一点点的改进，但不积跬步无以至千里，微小的提升积累得多了，量变形成质变，产品就会慢慢变得越来越好。
云之家 CRM 1.0 发版后，得到了许多用户的好评，但这不只是一个人的力量，而是一个团队的力量，感谢每一位参与的同学。回过头来看当年，团队所有人为着 1.0 发版而加班，也是很快乐的~ 大家朝着同一个目标前进，为用户不懈地打磨优化产品。
作者:王梓铭，云之家用户体验部交互设计师。前产品汪， 还能偷偷撸几行代码。时常做梦,想改变世界。怀揣着这个梦想，跌跌撞撞尝试了各种各样的东西。录过视频，开过 Podcast，玩过博客。 最后发现，其实改变世界并不难。从小事做起，帮助能帮助的人，改变能改变的人就已经足够了。
推荐：