每个人都有自己的优点和缺点，我的优点大家都知道，善于发现总结和传播。对我来说最大的缺点是做决策，小到决定按钮的位置、当下用什么设计方法、大到决定需求是不是砍掉，对我来说都能纠结和踌躇好久。
初学设计时我也像很多人一样，对设计流程和设计方法抱有过高的幻想，以为按照流程执行采取固定的设计方法就能产出优秀的设计方案。
然而工作完全不是这样，总会有突发的事情、中途介入的需求、需要敏捷处理的任务。根本不可能让你真正从头到尾执行一次标准的用户体验设计流程。
设计方法就更别说了，大家看看尼尔森可用性原则、各种法则定理，除了当作评审和汇报时让自己显得很专业，有谁会真的一板一眼的去落地使用？而且稍微琢磨一下，就发现很多法则定理互相矛盾，如果没有因地制宜的去改造和确定优先级，直接去用结果就是邯郸学步贻笑大方。
到底怎么样才能作出下一步的决策，让设计往正确方向发展下去呢？
我相信不仅仅设计有这个问题，其他岗位和其他行业应该也会遇到类似的问题。本质上来说这都是——如何采取正确的策略达到目标的问题。
项目管理铁三角
一次偶然的机会读了几章项目管理的书籍，提到：有明确目的，需要一定时间处理的一系列任务和活动，都可以称之为项目。很显然，互联网产品设计也符合该定义，也是一种项目。
在项目管理著名的铁三角概念中：时间 + 成本 + 范围 = 质量。项目管理的目标就是平衡这四个元素。
之所以说平衡是因为任何一个改动，必然对另外的元素产生影响。例如增加需求让项目的范围增加，必然导致时间和成本的增加。如果为了提前发版本缩减时间，又不愿意投入更多开发资源，必然导致 BUG 增加，质量变差。
这四个元素始终处在动态平衡之中，我们不可能让项目范围大时间少成本低还质量好。
如果把我们接到的设计需求当作项目来看，那我们也要处理好四个元素。
例如刚开始参加工作的新人常犯的一个错误是把需求当作不可修改的圣旨，经常因为一个紧急需求自己硬扛加班加点做，结果还因为质量不达标而被责罚。这种时候就应该和需求方讨论，要么让需求方决策增加时间要么降低质量标准，或者缩减需求的范围。
工作越久，接到的需求也越抽象模糊，从“设计一个体验好的页面”变成了“如何保证整个产品的体验质量”。面对抽象的需求要明确好范围，制定质量标准，规划好时间并且申请相应的资源来做。
有经验的团队在项目管理上通过制定不同的项目设计流程来利于更快决策。例如大众点评设计团队将需求分为 4 个级别，不同的级别采取不同的设计流程和评审方，设计师也有对应的职责。
项目管理知识帮助我们从整体来看待设计需求，过程中随时决策调整范围、时间和成本，来把控最终设计产出的质量。
决策思维
整体视角不能解决所有问题，设计过程中有很多具体细节的问题需要讨论。
同事推荐我阅读前 IBM 高级副总裁王嘉陵所著《决策思维》，用一个完整的思路来面对所有需要决策的具体问题。
《决策思维》道出了决策的本质：有目标有选择才有决策可做。如果资源是无限的，我们就可以用任何方式做任何想做的事情，而不需要做选择。所以决策的本质是分配有限的资源达到目标。
作者依据 30 年来在 IBM 的成功事业为基础，提出决策内容高质量三个重点 （GPA）：
- G：目标（Goal）
- P：优先级（Priority）
- A：可选方案（Alternatives）
和决策过程的三个重点（ IPO）：
- I：信息（Information）
- P：人员（People）
- O：客观推理（Objective Reasoning）
并将决策过程总结为 10 个步骤：
- 随时观察时势，评估商业形势
- 确定长远目标
- 厘清目前的优先级
- 提出多项可选方案
- 客观推理可选方案带来的结果
- 选择带来最佳结果的方案
- 制定实施、沟通、评估的计划
- 沟通、实施
- 评估进展，并主动调整
- 庆贺进步，再优化
我将书中提到的决策重点内容和步骤绘制成如下图示。
如果把提出多个可选方案当作发散，决策最佳的方案当作聚焦。我们就发现这个图示和设计思维、双钻模型很像。
可能成功的方法底层原理都是相通的吧。
这套方法看起来简明，但实际操作起来却很难。我认为最难的步骤在于收集信息。如果没有收集到足够多的信息，我们不知道现状、目标，更无法提出多个可供使用的解决方案。而客观推理就更难了，要以当前的现状推测执行方案之后可能带来的结果，我们又不是哆啦 A 梦能乘坐时光机穿越未来，怎么能提前推断未知的结果呢。
最小可行产品
只要我们有足够的时间，进行各种调研，请教各种专家，我们当然能更好地推断方案带来的结果。然而时间不等人，等你推断出方案的结果时，市场早已变化。过去的方案已经不适用了。
既然市场瞬息万变，漫长调研不如先推出半成品到市场上看看用户反馈再改进，就是互联网公司普通采用的快速迭代方法。该方法来自于埃里克·莱斯于 2012年所著的《精益创业》中提到的「最小可行性产品」（MVP，Minimum Viable Product）。
我们根据当前收集到的信息提出假设，并依据假设快速开发出最小可行性产品投入市场，接下来我们根据数据和用户反馈验证当初的假设是否成立。
如果成立那说明自己推断是正确的，继续按计划执行。如果错误，则反思提出新的假设再继续开发验证。简而言之就是投石问路、摸着石头过河。
为什么要依据收集的信息提出假设？因为我们不知道收集的信息是事实还是观点。用户有出行的需求这是事实，事实是已经发生或已知存在的信息。用户希望有更快的马满足出行速度的需求就是观点，而观点是个人主观的判断，可能是对的也可能是错的。直接使用未经证实的观点来设计产品，可能导致最终结果出错。
为了验证观点是否正确，我们才采用最小可行性产品来快速验证。但使用该方法又会进入另外一个误区——提出假设后马上一拍脑袋开发产品进行验证。
之所以开发最小可行产品是因为这样耗费的时间和资源最少，用最少的资源拿到结论才是目的。很多时候开发并不是成本最小的方式，我们可以用其他更快更实惠的方式拿到结论。
例如要验证用户是否更喜欢深色模式界面，我们确实得开发出深色模式的版本再观察用户的使用率。但如果只是验证用户是否晚上经常使用 App，通过后台数据查询晚上的活跃用户比例或者给用户发放问卷，验证假设的速度比开发产品快得多。
设计方法的四要素
既然最小可行性产品不一定是最有效率和最实惠的方法，那现在决策的重点就是如何采取成本最低效率最高的方法来达到目的。为此我们必须梳理所有设计方法，整理归类，遇到问题时，才能快速决策使用最佳方法。
我将方法用 4 个维度来梳理：
- 输入：使用某方法的前提。比如可用性测试，必须有至少 5 个用户和产品的高保真原型或已开发成行的程序。
- 输出：使用方法得到的结果。例如可用性测试做完能得到用户使用产品的行为，以及可用性问题。
- 成本：使用方法消耗的资源。例如可用性测试短从用户邀约到测试，得消耗 2-3 天，成本高。而调研问卷发放到结论一个下午不到，成本低。
- 类型：分为表达、结论、发散这 3 种属性。比如用户体验地图能向大家展示当前用户痛点。有些方法是为了梳理得出明确的结论，例如流程设计。还有方法是为了发散找到更多的可选方案，比如头脑风暴。一个方法可以有多个属性。
就像看到钉子拿起锤子，看到螺丝找螺丝刀。为了达成目标而决策使用哪个方法前，可以先看看现状符合哪个方法的输入条件。再想想哪个方法的输出和类型与自己希望达成的目标相同。思考一下现阶段能付出的成本，最后作出决策。
考虑设计之外的方法
设计并不是解决问题的唯一方式，有时候设计之外的方式有奇效。例如为了禁止用户做某事，与其把警告文案做得再大，不如通过运营制定策略，给予用户惩罚来得有效。
总结
通过以上阅读和思考，我目前梳理的设计决策思路如下：
- 把设计当作项目，动态地调节范围、时间、成本和质量。
- 收集信息，确定现状和目标。
- 区分信息中的事实和观点，决策最佳方法（包括设计方法和非设计方法）验证观点对错，获得新的事实。
- 根据当前事实评估与目标的距离，再提出新的观点进行验证。
以上思路还比较粗浅，之后有更系统的思路再和大家写文分享。
