章节 33

重新设计救不了你

为什么重新设计通常是错误的答案

改版提案听起来是这样的。产品变乱了。流程像是硬拼在一起的。代码库简直是噩梦。来一次真正的重新设计，就能一口气理清一切，从零开始，一开始就用上正确的架构。听起来很果断。像是情况糟到一定程度时，一个认真的设计师会作出的决定。我听过很多次这样的提案。

这几乎从来不是正确决定。而你仍然想这么做，原因更多在你自己的心理，而不在产品的状态。

产品是怎么变乱的

产品变乱，不是因为团队一开始就想把它做乱。没人会坐下来规划一条令人困惑的结账路径，或一个要点四次才能找到的设置界面。混乱是一层层积累起来的。利益相关者提出要求，于是多了一个按钮。有人需要呈现一个边缘情况，于是冒出一个模态窗口。新功能落到一个本来不该容纳它的界面上。然后，有人说整套东西看起来过时了，开始幻想能一切从零开始。

每个决定都很小。当时看起来也都有道理。而没有人真正退后一步，问问这些小决定加在一起，究竟变成了什么。

C. Northcote Parkinson在 1958 年描述过这种情况：团队花两个小时争论按钮标签，却没人质疑按钮所在的架构。小事会被讨论，因为容易看见，也容易发表意见。大事则在背景里不断生长，因为没有一个人能同时把它的全部装在脑中。

这就是用户体验债务。不是某个你能明确指出的重大失败，而是上千次小捷径累积的成本。Nielsen Norman Group描述过产品团队里的这种模式：拖得越久，处理起来就越难、越贵。大多数团队知道这一点，却仍然希望账单别太大。

从头再来感觉更容易

混乱达到某种程度时，设计师开始想逃离。提案几乎自己就写好了：问题缠得太深，没法一个个修；真正的改版能让团队终于把事情做对一次；留在旧系统里只会越陷越深。提案漏掉的，是计划谬误。

Daniel Kahneman 和 Amos Tversky在 1979 年提出计划谬误，Buehler、Griffin 和 Ross在 1994 年加以证实：即使知道过去的项目超期，人们仍会一再低估自己未来项目需要的时间。改版在规划阶段看起来干净，是因为里面还没有任何东西撞上现实。

当前产品是真实的，有真实限制，也有你已经梳理过的古怪情况。替代方案却只存在于概念里。这个比较从来就不公平。

还有“非我发明”的问题。Ralph Katz 和 Thomas Allen在对工程团队的研究中记录了这一点：群体把内部开发的方案评价为优于外部方案，并不是因为它们真的更好。改版讨论常常就从这里开始。

现有系统是上一支团队做的，而在心底某个地方，有一种本能在说：换成你，不会这么做。我知道这个念头有多诱人。

Digg 打破了人们熟悉的东西

2010 年，Digg 推出了第 4 版。公司处境艰难，增长停滞，团队也确实有架构问题要解决。他们决定，彻底翻新才是答案。新功能、新界面、与内容发布方的新合作，同时推出。

使用 Digg 的人，已经花了多年围绕它建立习惯。他们知道东西在哪里。他们学会了这套系统。第 4 版却把这一切换掉：界面优先展示内容发布方的内容，而不是用户提交的链接，挪走了人们记住的导航，发布时的缺陷又多到让基本功能都不可靠。

用户没有留下来等它会不会改善。他们走了。

发布后一个月，流量下降了 26%。很多用户转去了 Reddit，并留在那里。Digg 在 2012 年以 50 万美元售出。公司巅峰时的估值曾达 2 亿美元。

Digg 没人想毁掉自己的产品。他们想修好它。但他们试图在一次公开发布里，一次修好所有东西，而且无法退回一个用户已经信任的版本。错在改版的规模，不在背后的用意。

先说出五个真实问题

在任何重建讨论形成势头之前，有一件事值得做。写下改版要解决的五个具体问题。不是笼统的不满。是能说清的问题。“用户在结账确认步骤的放弃率是 38%”算一个。“这看起来过时了”不算。如果你能列出五个有证据支撑的实际问题，并证明它们有同一个更深的原因，而且不重建就无法解决，那这个讨论值得进行。如果连五个都说不出来，你很可能面对的不是改版问题，而是挫败感、接手的混乱，或一个看起来丑、却没坏到那个程度的系统。

另一条路，在会议上讲起来没那么激动人心。挑清单里最糟的问题。修好它。衡量是否改善。再挑下一个。这样更慢，总觉得做得不够，也做不成一张漂亮的利益相关者汇报幻灯片。但改版最后几乎总比会议室里大家假装相信的规模更大。

想改版，并不是不理性的冲动。系统已经乱了两年，想真正修好它，这个愿望没有错。出问题的是那个假设：你真的可以干干净净地重新开始。那些把当前产品推向复杂的限制，很多在重来时仍然会在。

利益相关者还会提出同样的要求。古怪情况还会存在。工期还会被压缩。

从头再来，不会消除那些难题。通常，你只是又得从头面对它们一遍。