章节 38

你解决了错误的问题

问题框定如何决定什么会被解决

需求简报落在你桌上。有人已经给问题下了定义。你读完，点头，打开工具，开始设计。错误常常发生在线框图或文案初稿存在之前。它发生在那几秒里：你没有检查，就接受了别人对问题的定义。

设计师受的训练是解决问题。学校、作品集和求职面试，通常奖励答案，多于奖励重新框定问题。答案是否对应实际问题，得到的关注少得多。于是你越来越擅长解决，却不知不觉停止追问：自己究竟在解决什么。

框架塑造答案

1983 年，Donald Schön写下了一些本该改变设计教育方式的话，但实际上并没有带来多少改变。他区分了解决问题与他所说的问题设定。问题设定，是首先决定把哪些事情视为问题：给情境命名，建立框架，决定什么算相关事实。

问题如何被框定，会塑造你最终设计的东西。把问题框定为“用户找不到结账按钮”，你就会看按钮。框定为“用户还不够信任这家店，不愿完成购买”，你就会看完全不同的一组东西。行为一样，工作却变了。一根线都还没画，框架就已经开始缩窄答案。

Kees Dorst花了多年研究专家设计师实际如何思考，发现框定在工作中起着核心作用。有经验的设计师不会急着找答案。他们会在问题上多待一会儿。他们不会轻易接受别人交来的第一个框架。在决定路径之前，他们会尝试其他看法。

有些问题会在解决过程中改变

Horst Rittel 和 Melvin Webber在 1973 年为一类问题命名，大多数设计师每天都在面对，却没有一个词来称呼它。与那些有明确终点、存在正确解法的问题不同，这类问题一碰就变。解决一个方面，会改变其他所有方面的条件。

社会问题永远不会被彻底解决。充其量，只能一遍又一遍地重新解决。
— Rittel & Webber · 译自英语

很多设计问题就是这样。你设计新手引导流程，想减少中途流失。流失减少，意味着更多用户进入核心产品，于是客服压力增大。解决流失，又暴露了一个此前没看见的留存问题。你一推，系统就动。

Rittel 和 Webber 的意思，不是这些问题无解。而是它们会惩罚那些想找一个干净利落答案的人。你脚下的系统一直在移动。

这对设计师之所以重要，是因为狭窄框定才是默认状态。拿到简报，接受里面的框架，然后开工。简报说“简化设置页”，你就简化设置页。但真正的问题，也许是用户在主流程里找不到需要的东西，才跑去设置。或者，客服要求一个更好看的筛选面板，真正的问题却是搜索结果烂透了。设置页是症状，不是病因。你只是让症状更容易忍受了。

Segway 解决了错误的问题

Dean Kamen 的团队造出了 Segway。自平衡系统确实是工程上的壮举。他们的问题陈述很清楚：城市个人出行效率不高，我们可以造出一种东西，让人在建筑之间短距离移动时，比步行更好。

设备按设计正常工作。它能载人，自行保持平衡，几乎不需要训练。Kamen 预测城市会围绕它重新设计。整个产品生命周期，却只卖出 14 万台。生产在 2020 年结束。

团队把问题框定为设备问题：造一种在建筑之间移动的更好方式。但真实问题比设备更大。

城市的人行道并不是为车辆设计的。多数地方的法规禁止 Segway 使用自行车道和道路。5000 美元的价格，让很多本来可能拿它实际通勤的人买不起。它能否融入社会环境，同样成疑。

这些都没出现在最初的问题框架里。框架问的是：我们能造出一种更好的短途交通工具吗？它没有问：城市、监管者、雇主和社会规范，会容纳它吗？团队造出了机器，却误读了它必须生存的环境。

在问题上多停留一会儿

经验较少的设计师与更强的设计师之间，常有一个区别：开始制作之前，他们愿意在问题上待多久。

经验较少的设计师更可能听完简报，觉得够清楚了，就开始工作。更强的设计师会先慢下来。他们问自己究竟在解决什么，为什么重要，以及这是否从一开始就是正确的问题。在别人眼里，这可能像拖延。通常，却是最重要的部分。我见过团队只因足够早地问了那个直白的问题，就省下几周。我也见过团队跳过这次停顿，花一个月打磨错误的东西。

很多糟糕工作，始于一份听起来合理、却指向错误对象，或只指向问题一部分的简报。一旦团队开始设计，质疑这个起点就更难。所以，更强的设计师在花时间做方案之前，会先花更多时间看问题。

他们问那些简单、却很容易被跳过的问题。我们为什么做这个？为什么现在做？这里到底哪里出了错？我们是在解决真正的问题，还是只是在把某个人建议的方案做出来？这些问题不耀眼，却能省下大量白做的工作。

再强的设计，对准错误的问题，也仍然会失败。