方案,不是流程

举个栗子:

目的:

银行希望加一项功能,允许客户把他们的存款账号分为可以命名的“存钱罐”(如“节日”,“燃气”,等等)。 这样通过明确存款的目的,可以让客户更加积极踊跃地存储。

最初的解决方案:

开始设计存款流程的时候,事情一下机会变得复杂起来,比如说,客户在账户中存钱时,他得先存上钱,然后再把这笔钱划到某个“罐”里--原来的一步变成两步。如果有人在存款时不知道系统支持“存钱罐”功能,那么存入的钱必须保存到账户中的“日常存钱罐”中。

在从账户中转账的时候,问题就变得复杂了。用户必须要选择从哪个“罐”里提钱。如果客户从某个“罐”中提钱太多,即使其他“罐”里还有钱,也可能会被拒付。

导致一大堆非正常的操作和细节的功能。 这应该是所有产品设计者应该长鸣的警钟。

最终的解决方案:

后来我们认识到,允许客户命名他们的存款账户就能达到命名“存钱罐”的效果。

如果客户想换一个“存钱罐”,只要再开一个新户就行了。甚至从一开始就给他们两到三个账号,并建议他们为这些账号分别起不同的名字。

从实现、解释和支持“存钱罐”的投入来看,还是让客户命名账户更快捷、更节省成本。

关键是客户更容易理解

如果在设计的时候只盯住流程,那么结果很可能会创造更多的功能去处理出现的各种异常情况、问题和细节。想要避免这些复杂性,退一步想,把注意力集中到客户的目的上面,问自己“还有其他解决方式吗?”

如果一个小的变化导致了复杂的流程,就应该退一步去寻找更好的解决方案。

results matching ""

    No results matching ""