从“应该是什么”到“是什么”

记得以前接入微信支付，确认会上对技术讲解交互设计方案的时候，被问及资金流转的账户对接问题，一时哑口无言，愧疚难当，因为我确实不知道。我只是娴熟地处理了表层的用户流程和界面布局，而对后台交互流程完全无触及，甚至都没有想到过需要处理这样的问题。当然，那次有策划救火，我则被晾在一旁，成了旁观者。我只是做了这个案子的皮毛，没有解决实质，也即没有解决问题。

我仅仅是面向用户端设计，只是认识到它应该是什么，而不解其本是什么。

对上面的案子，后来我知道了代收实收账户，清晰了各分支脉络，才知那个设计方案实在欠缺了太多的信息和考量。当然，事情也开始有意思起来，并为后来重新设计整个交易系统提供了思想上和经验上的准备。

再后来，我又接到多级类目和题库的标签设计的案子，这两个案子本无关联，多级树形结构和标签的设计方式都已经很通用和常规了，但是采用不同的设计思路却可以使技术实现统一，并保持通用和灵活，以应对不同业务的需求扩展和变化：将类目标签化、将标签群组化并配置单选或多选的属性。当然这是最终的设计及实现方案，中间经过了折腾的技术重构和不断的讨论。回头来看，短期虽然带来了一定的项目时间压力，但对产品的发展而言，却是“功在当代，利在千秋”。

这个案子中，设计方案的优劣在用户层面无差异，但在设计思维上却差了一个等级，设计实现的高度灵活性和扩展性可以应对更多的相似业务、更快的需求变化，而这需要设计师不仅仅停留于“应该是什么”的具象用户思维，而是深入“是什么”的结构化抽象思维，也就是要更多关注业务需求的扩展和技术实现，多和产品经理、工程师讨论沟通了。

以上两个案例的解决，都需要交互设计师跳出“应该是什么”的用户思维，向后延伸至“是什么”的产品全局思维：关心用户情境、关心产品发展、关心业务实现，否则给出的设计解决方案就可能是不完整或低效的。而这样的转变也需要交互设计师模糊职能的界限，在低头深耕“本职”专业之余不妨多抬头远望，与团队相顾相持。

如同对需求的挖掘过程是由“表像”到“动机”一样，设计解决方案也有由表及里的深度等级，“应该是什么”是外在显现，而“是什么”是本元，只有悉知本元，表像才会更自然、更丰富。从外显到本元的跨越，是一个无限接近的过程，需要首先从思想认识上准备起来。想起近来看到一篇谈麻将和扑克哲学的文章，单个麻将之间并无大小和价值差异，而是通过不同的组合补位实现整体的同存共赢。在设计思维和心态上，不妨做一颗麻将，在确定中发现更大的价值，在不确定中创造更多的可能。