有感用户体验规划与系统实现

最近一直在“深山老林”中修炼“支付宝新版收银台”,经历了白板设计，视觉设计，前端开发，前后端联调各个阶段。点点滴滴……

重点谈谈对交互设计的感受吧：个人觉得设计师应该好好的思考一下收银台的设计粒度，在我们不能确定用户是否会遇到某类问题时，不妨放开怀抱，将粒度切的大一些，如果一味的把自己当作用户，患得患失，其结果只会把自己的产品绑成个大粽子，这样很可能导致在不明确具体问题的情况下，设计粒度过细。到后期再想优化，就举步为艰了。

个人非常反对，设计师总是以“我觉得用户可能”，“我觉得用户一定”的论调在设计讨论中去说服需求方，“觉得”只是一种推测，既然不能确定用户会遇到你假设的问题，那为什么不能先把设计粒度切大一些，等产品上线，观察分析用户使用的情况后，再对症下药呢？究其原因，是因为设计师太怕用户受挫，关心则乱下失去了一些设计原则。我想，在不影响用户正常操作的情况下，对于一些假设的受挫场景，不妨放手一试，用户不犯错，你又怎么知道自己的产品问题在哪里呢。知错而改之，总比一辈子都活在自己“觉得”的世界里强。更何况未必错！

说了这么多，其实只是想引出一个话题，作为一个优秀的设计师，必须学会“如何均衡用户体验和系统实现”，要知道你设计的是一款产品，你必须对他的未来有一个规划，而这个规划，用户体验和系统实现之间的关系是非常微妙的。常常听到很多设计师再抱怨“我想到个很好的体验改进点子，但是开发告诉我系统实现不了，郁闷！”有没有想过为什么？我想很大一个原因就是因为前期设计粒度过细，到后面瓜就不好切了~~呜呼哀哉！总之一句话：“该有的体验一个也不能少，该有的原则同样不能少！”粒度要怎么切，很有学问，需要在不断的实践中去体会。

说到如何均衡体验和系统实现，不妨拿新老收银台做个比较，个人觉得非常有说服力,我们从老收银台现有问题着手分析一下：

如果按上图(老版)设计方案，当新加入一个资金渠道，并且该资金渠道又支持支付宝账户余额补支付功能，那么你的系统实现成本就略嫌尴尬了，你会发现，在新增的这个支付渠道TAB下和余额TAB补支付的情况下，你都必须重复渲染这个资金渠道的实现代码（譬如：图中codeWidget部分网银支付渠道的实现代码），虽然我们可以把这块抽成一个公用的组件widget统一调用,但是无可避免的要设置一些参数去实现一些个性化的显示。并且页面渲染时,会重复渲染,新增加一个资金渠道就等于X2的代码渲染量,久而久之系统会越来越臃肿,性能也随之下降,so bad,简直就是一个恶性循环……