我来教你产品设计的流程有哪些。

即使我们只是走路，从A点到B点有时也很麻烦 – 想知道路径是否正确，是否走的方向正确，是否走上了捷径的道路等等。

但是当A点是用户问题而B点是一个实现的特征时，它就像在一个旧地图和一个错误的指南针在大海中进行导航。

这就是为什么经过一个严格的过程 – 即使时间紧迫 – 至关重要的是要尽可能多地提供有关解决方案的信心和数据。

1.了解问题

首先，这个问题是如何实现的？这是客户的要求，CEO的想法，是实现愿景的路线图？了解问题的位置至关重要。辨别触发了用户遇到的实际问题通常很困难，也容易忽视（让我们面对它，减少耗时）。

回到最初引发它的问题，意味着确保设计的起点是实际问题，而不是可能的解决方案之一。

从首席执行官，产品负责人，产品设计等人收集客户关怀的见解 – 深入挖掘，直到你找到引发请求的原始事件。

2.研究问题并收集数据

第二步意味着要善于打扰人们和搜索谷歌的东西。一旦发现事件（可能是童年的创伤或客户投诉），现在是时候尽可能多地获取信息了。

其他人如何处理这个问题？这是一个普遍的问题还是一个基本问题？有没有办法将问题分解为更小的问题？最重要的是，收集数据。

即使我们正在谈论一个全新的功能或产品还有待开发，也有一些与之相关的指标（在某种程度上）可以使用。如果这是对现有功能的改进，则应该更容易从分析中获取使用数据或应该实施的任何类型的指标。

3.重新设计问题

现在有了所有这些信息，应该很容易就可以更好地了解问题的背景和存在的原因。重新构建问题意味着获得不同的视角并从另一个角度来看待它，从而打破它以前在收集时可能添加的任何偏见或解释。

因此，虽然最初的需求可能是“我们需要一个功能，允许在余额不足的情况下向用户转账”（这是一个已包含解决方案的需求），但问题可能是“转移给用户的钱花费时间，并且需要经常检查余额”。

这个问题的新框架为解决方案开辟了新的途径（实现调度程序，或者在余额不足时自动发出警报）。

4.设计解决方案

问题现在已经确定，数据可以用于更广泛的产品背景。现在是框架解决方案的时候了，比如“决定哪一条途径导致解决方案更适合该问题”。为此，将解决方案的特征放在问题的形式中可能很有用 – “用户能够设置自动提醒吗？”“用户是否应该能够导入事件？” – 并建立一个列表可能的解决方案方法。其目的是缩小选项范围，并形成一个将用原型进行测试的假设。

由于目标是测试假设，因此理想情况下，原型应以假设为中心，最好从所有装饰和不必要的细节中剥离，以便在测试时分散用户的注意力。

在这一步，与开发人员以及参与该过程的任何其他人（QA，更广泛的设计团队，客户关怀）进行交流，从他们的角度收集他们对解决方案的见解也非常理想。

5.测试解决方案

根据可用资源和时间的不同，用户测试始终都是具有挑战性和必要的。

即使资源不足且时间紧张，测试代表产品较大用户群的用户样本也非常重要，甚至比拥有不具代表性且因此有偏见的大样本更为重要。

以最详尽的方式收集笔记 – 或者更好地记录音频 – 意味着如果在UX研究员（如果可能的话，或者至少另一个可以人可以记录）的帮助下进行访谈以便保持两者笔记的质量。

6.实施解决方案

那么现在，假设是否被验证？如果是这样，设计的难点和优点是什么？假设这一切都进行得很顺利（假设验证和轻微的痛点），原型将不得不变成实际的屏幕和要求给开发人员。为了铺平未来迭代的路径，定义哪些是关键绩效指标和功能的成功指标是一项强制任务，可能需要其他团队成员（营销人员，开发人员）的帮助。

如果假设没有经过测试，那么就有必要回到设计解决方案的前一步，甚至回顾问题本身，然后重新开始。

在设计一个复杂的解决方案时（很可能是一个复杂的问题），可能的策略之一可能是从实施最简单版本的解决方案开始，随着时间和版本的增加而增加复杂性。

7.发挥功能

那么，这是自我解释。只要把它拿出来，让世界知道它就在那里。

8.关注该功能的成功

如果一切正常完成，则指标现在应可用于收集。

检查客户服务并让他们掌握正在进行的事情，并为客户反馈新功能的各个方面设置优惠渠道也是监控情况的好主意。

9.解决方案是否解决问题？

该功能已发布并可供公众使用一段时间（几周或几个月），并且根据路线图和其他问题，应该提出问题的时间：较大的用户群实际上是否发现通过实施解决了问题解？

事实上，并不是每个人都很高兴（用户和/或队友），其他问题已经出现，可能是时候解决利基问题或者 – 无论整个过程如何 – 我们可能已经错过了商机。

所以，让我们对这个过程保持信心，并重新开始。