抠一抠产品设计的细节（一）

就算大家仅仅是走路，以A点至B点有时也非常复杂 – 要想了解路径是不是正确的，是否是对的方向，是不是走上捷径的道路。 但当A点是客户的问题而B点是实际特征时，这就像在一个旧地图和错误指南针在大海中导航。 为什么说这个过程严格呢 – 就算是时间非常紧迫 – 也需要更多地提供有关解决方案的信心和数据。

研究问题问题也需要研究，第一，问题是怎么成立的？是客户的要求，CEO的思考，是实现问题的路线图？那么理解问题的位置就变得非常重要。

如何分辨诱发用户遇到的实际问题常常很困难，这也容易被忽略。但是最初引发它的问题，意味着确保设计的起点是实际问题，而不是可能的解决方案之一。从首席执行官，产品牵头人，产品设计师等人收集客户关怀的见解 – 进一步挖掘，一直到你找到引发这个问题请求的原始的具体事情。

研究问题收集起数据深入探讨研究问题，是解决问题的一部分。第二步意味着要善于挖掘出人们和搜索谷歌的东西。一旦出现事件（也许是年少的创伤或者投诉），也需要更大地获取信息。 其他人怎样处理这个问题？这是一个基本问题还是原始问题？有无办法将问题分解成为更具象的问题？最重要的是，收集数据。

即便我们正在探讨一个全新的功能或产品有待开发，也有这些类似的指标（某种程度上）是可以使用。假若这是对已有功能的改进，则应该更容易从分析中获取使用数据或应该实施的任何类型的指标。

再次设计问题现在有了所有这些信息，应该很容易就可以更好地了解问题的背景和存在的原因。重新构建问题意味着获得不同的视角并从另一个角度来看待它，从而打破它以前在收集时可能添加的任何偏见或解释。因此，虽然最初的需求也许是“我们想要一个功能，同意在余额不足的情况下向用户转账”（已包含解决方案的需求），但问题可能是“转移给用户的钱花费时间，并且需要经常检查余额”。 这个问题的新框架为解决方案开辟了新的途径（实现调度程序，或者在余额不足时自动发出警报）。

设计的解决问题的方案，解决方案的问题现在定下来，数据上可以是用于广泛的产品背景。如今是框架解决方案的时候了，举个例子“决定哪一条途径诱发解决方案更适合这个问题”。为此，将解决方案的特征放在问题的形式中可能很有用 – “用户能自动设置提醒吗？”“用户能不能够导入事件？” – 并建立一个列表可能的解决方案方法。主要目的是缩小选项的范围，并形成一个用原型进行测试的假设。