产品设计的环状循环

• 原文地址：The Circle of Product Design
• 原文做者：Francesca Negro
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：Ryden Sun
• 校对者：ryouaki Starriers

产品设计的环状循环

In All Its Freudian Glory

咱们只是简单的从A点走到B点，有时候都会变得混乱不已 —— 会考虑这条路是否是对的，咱们走得是不是正确的方向，若是咱们走捷径又会怎样等等这些问题。 但当A点是一个用户问题并且B点是一个实现的功能，这就像你用一张旧地图和一个坏的指南针在大海里航行。 这就解释了为何按照一个严谨的流程 —— 即使时间很紧张 —— 也会是通往B点的关键因素，并且有着最多的信心和尽量的与解决方案相关的数据 —— 而且 —— 会让之后的相同的工做变得简单一点（也为了之后的迭代创建详尽的文档）。

---

文章中全部的过程都是 Freudian glory(弗洛伊德学说风格)（全部的插画都是我画的）

---

1.理解问题

问题也是须要被理解的。

首先，这个需求是如何被提出的？这是一个顾客的需求，是一个CEO的点子仍是一个实现愿景的蓝图？理解需求从哪里提出的，不管它是在 Jira 上，或是邮件里，或是贴子里，这是最重要的。从用户的附加解释中，辨别出那些真正触发需求的问题一直都是困难的，而且是容易忽略的（让咱们来面对它，减小时间的消耗）。

回溯到最开始的被触发的想法， 意味着须要确保咱们设计的出发点是一个真实的问题，而且不是一个可能的解决方案。

从顾客关爱部门，CEO，首席产品官他们那里获取他们的想法，不管是谁 —— 就像产品设计的 Sigmund Fredu —— 深挖这些想法直到你找到来源，那个激发需求的最初始的事件。

2.调研问题而且收集数据

调研这个问题是解决方案的一部分。

第二步意味着会变得很擅长打扰别人和搜索东西。一旦定位了那个事件（多是童年的心理创伤或是客户的抱怨），那就是时候尽量多获取这个问题的信息了。 其余人是怎么处理这个问题的呢？这是一个广泛的仍是特殊的问题？咱们有办法把这个问题分解成多个小问题吗？而且，最重要的，收集这个问题的数据。

即便咱们在讨论一个全新的功能/或是产品还处于开发状态，仍是会有相关的（某些程度上）度量方法来使用的。若是是对于一个已经存在的功能进行提高，他 应该 是容易从分析中收集数据的或是 应该 有任意的度量方法能够被执行的。

3.从新构想这个问题

Blue steel ™.

根据目前全部的信息，对于问题和其存在于的背景应该比较容易的有一个更清晰的认识。 从新定义这个问题意味着须要从不一样的视野和角度看待它（看一下 J.W. Getzels 在“Problem of the Problem”的工做和其创造性的问题解决），所以在收集过程当中，从任何之前的偏见或者解释来破坏他的行为均可能会被加入。 因此，当最初的需求多是“咱们须要一个功能容许余额太低时转帐给用户”（这就是一个需求包含解决方案的例子），促使产生这个需求的问题多是“转帐给用户太耗时并且须要不断地查看余额”。 这个问题的从新定义打开了通向解决方案的新道路（执行一个调度程序，亦或是余额太低时自动提醒）。

4.设计解决方案

Vitruvian 解决方案。

问题如今已经成功定位，并且数据是能够被投入到更普遍的产品背景中的。如今是时候把解决方案构建为“决定这些方法中哪一个方法更适合解决这个问题”。出于这个目的，它能够适用于一系列问题：解决方案中应该有哪些功能 —— “用户应该可以设置自动提醒吗？” “用户应该可以引入事件吗？” —— 而且创建一个可能的解决方案实现列表。 目的是减小选项，造成一个能够用原型来测试的设想。 既然目的是测试这个设想，原型应该是理想化的以设想为中心，是从全部修饰和不必的细节中剥离开来的，这些修饰和细节可能会在测试中让用户分散注意力。 在这一步，若是能和开发者或是任何将参与到过程当中的人（如，整个设计团队，客户关心部门）进行交流就理想了，这样能够收集他们从自身角度出发关于解决方案的见解了。

5.测试解决方案

“我想知道为何他们让我作一个数学测试”。

依靠现有的可用资源和时间，用户测试一直都是有挑战性和有必要性的。

即便资源不多，时间很紧，测试一个能表明大部分产品用户的用户样本是十分重要的，这更比测试一大群没有表明性的样本重要（参照 1936 年的 Literary Digest 案例）。

进行记录 —— 或者更好的办法是进行录音 —— 这是最详尽的办法来更方便的在一个用户体验研究员的帮助下进行访谈的总结（若是可能的话，或者至少有另一个能够记录的人），为了能同时保证记录的质量和访谈的活跃度。

6.实现解决方案

不适合3岁如下的小孩。

目前为止，设想被验证了没有？若是已被验证，什么是设计方案的痛点和长处？假设全部都进行顺利（设想被验证而且几乎没有痛点），这个原型应该变成真实的屏幕显示出，同时需求须要传递给开发者们。为了给将来迭代铺设道路，一个强制性的任务是定义哪些是功能点的KPI和绩效指标，这可能须要别的团队成员（市场人员，后端和前端开发人员）的帮助。

若是设想没有被测试，那就有必要回到以前的设计解决方案步骤，甚至是从新审视问题自己而且从新开始。

当设计一个复杂的解决方案时 —— 最有可能的是对于一个复杂的问题 —— 一个可能的策略是从实现解决方案的最简单版本开始， 接着不断增长复杂度最后发布。

7.运送这个功能

Arrrrrrrr!（语气词，相似啊啊啊啊啊啊）

好吧，这是很明显的。 赶快把他发布出去让世界知道他发布了。

8.密切关注功能点的成功

它有达到最好的效果吗？

若是全部事情都进行无误，如今应该能够收集度量数据了。 去客户关爱部门，告诉他们目前正在进行的功能的关注点，而且为用户反馈设置一条特权通道，这些反馈包含新功能的全部方面，这也是一个很好的监测进行状况的注意。

9.解决方案有解决问题吗？

解决方案也须要理解。

功能已经发布并且用户已经使用了一段时间（几周或者几个月），根据流程和其余问题，如今是时候问一个问题：大多数用户有发现问题被这个方案解决掉了吗？

在理想的世界里，咱们会举办大型的舞会和聚会来庆祝解决方案那简约而又灿烂的美丽，世界上的饥荒也会仅仅存在于记忆力，由于咱们这个功能的问题解决能力。

现实中，不是每一个人都会满意（用户和/或队友），别的问题也会出现，也多是时候解决商业上的一些问题 —— 忽略整个过程 —— 咱们可能会没法完成咱们的目标。 所以，让咱们在过程当中保持信心，不断地从新开始（带着更多的内省）。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。