My Secret Rainbow

#30 不要解决产品问题，要解决客户问题

篇首语

几年前的一次团队周会上，有位设计师给大家展示了一个新需求的设计方案。这是一个很小的需求，在现有的产品模块里增加一个新的报表页面。但这里面有一个问题，新需求中有些内容和现有的产品有较多的重叠，因此大家对这个需求的合理性产生了一些质疑。

于是这位设计师进一步地解释了这个需求的背景。原来在客户使用产品的时候，总是需要到别的地方找一些其他数据来帮助他们计算一个自己关注的核心业务指标。每次处理这类工作的时候都需要在好几个不同的地方取数据再计算，所以希望产品能提供一张单独的报表汇总这些数据。

于是，客户直接向产品经理提出了增加这张报表的请求，产品经理则将这一请求转化成了设计需求，给交给了设计团队。

这个需求看上去的确不复杂，但总感觉还是存在一些模糊的地方，更关键的是会对我们的产品架构带来一些“冗余”。于是我让这位同学与客户再次聊一聊，搞清楚客户的真实需求再继续。

结果也果然不出意料，客户的确需要这些数据，但最终的目的则是获得另一个指标。我们最终在现有报表上增加了一些逻辑来直接计算并展示出了这个指标数值。

这样的情景大家是不是觉得有些熟悉？相信许多设计师在工作中或多或少都遇到过类似的情况。客户提出了一个表面上的需求 A，但实际上他们真正需要的却是需求 B。这种情况下，客户往往提出的是他们自己认为需要的产品功能。而如果我们仅仅按照用户的表述来进行产品设计，可能最终增加的是一些无关痛痒的问题，未能真正的解决客户问题，同时也给自己未来挖了一堆“坑”。

产品问题背后的本质需求

在产品迭代的过程中，我们的客户会有很多的吐槽、提出很多的问题。这些都是我们产品迭代的重要关注点。大家可能都曾多次听到客户提出类似的需求：“我需要 A 功能，什么时候才能上线？”

当客户表达了他们对某些功能的需求后，这些需求有时会里面成为整个产品团队的工作重点。于是，我们立马开始做方案，设计、开发并上线 A 功能、B 功能、C 功能…

当这些功能上线后，团队开始密切关注与这些功能相关的数据，比如 UV、PV、任务完成率等指标。如果这些数据表现很好，这似乎证明了这些新功能的成功，我们解决了客户问题，甚至为这些“虚假繁荣”进行庆祝。

但是，问题真正的解决了吗？可能未必。就像篇首案例中的那个客户，他们得到我们提供的新字段后，仍然需要手动计算他们真正关心的核心指标。尽管我们满足了他们表面上的需求，但并没有从根本上解决他们的问题，那个核心数据。

这个现象的根源在于，用户往往提出的是他们认为产品缺少的功能，但这些未必是他们最核心最本质的需求。换句话讲，他们表达的是他们在使用产品某个阶段中的“痛点”，而不是最终想要达成的目标。如果我们在产品设计的环节中将它们直接转换成产品设计的目标，这是非常危险的。因为我们所有人在追逐的是表象问题，而不是背后的核心需求。

如果将时间线拉长，我们可能会发现虽然某些指标在提升，但产品的体验满意度并没有太大的提升，产品的营收并没有提升，同时我们可能会花费大量的时间和精力，从某种意义上来说我们的这些工作都是无效的。但从长远来看，客户的核心需求仍未得到有效解决。当有更合适的竞争产品出现时，我们可能会失去这些客户。

背后的核心原因是什么？

为什么会发生这种情况？我觉得这个问题还是有一些复杂的，想要真正的搞清楚这背后的原因，我们需要从客户、产品经理、设计师以及公司文化多个方面来进行分析。

在我们与客户的“互动”过程中，产品和设计团队通过客户的意见反馈和产品调研来不断的打磨产品，通过对产品的迭代提升客户的产品体验和工作效率，而我们则因此来获得更高的指标增长和业绩增长。

获取信息、改善产品、提升指标，这看上去本来是一个很正常的机制，理应获得一个不错的结果。但我们不能忽略了在这整个环节中每个角色的动作是否“到位”，这个过程中任何一个环节的不准确可能都会导致最终结果的“变形”。

客户的“局限性”

在产品设计的过程中，客户的声音是最为重要的一部分，但也正是在这个环节中，我们也会面临不少的问题。

首先，客户在描述他们的需求和痛点时，往往难以准确传达他们的真实意图。他们更多的是在反馈自己在使用过程中遇到的一些表象问题，而并非深层次的核心需求。

就像在篇首案例中，客户表示他们需要另一份报表。然而，当我们进一步深入了解后才知道，他们真正想要的并不是那一份新的报表，而是通过报表中的几个数据来计算一个关键的业务指标。因为需求对焦环节的疏忽，产品团队在初期误解客户的核心需求，进而制造了一个伪需求。

其次，我们也不能期望客户与我们对产品的理解是一致的。他们并不理解产品设计背后的复杂性和限制，因此他们有点时候会提出不合理的需求，或者在表达需求时“绕了个圈”，使得本来可以简单解决的问题变得复杂化。就像前面那个案例，其实现有的功能稍加调整就能满足他们真正的那个核心需求。

产品经理的思维模式

产品设计的流程中，产品经理是整个链路的第一道关，需要对问题进行分析和筛选并制定出合理的功能需求。同时，作为设计环节的上游，他们的交付质量也直接会影响到最终产品设计的质量。

互联网行业里有很多优秀的产品经理，他们非常善于把握用户需求并与公司产品战略做好平衡。但是，也不可否认的是，这个行业还是有很多不那么靠谱的产品经理。作为设计工作的上游，设计师对产品经理有着极强的“依赖”。

如果你的产品经理正好是这一类，在日常工作中会直接响应的客户反馈，缺少对问题的深入分析，那么设计师在进行这些需求设计时，很可能也会被“带偏”，大概率也会最终偏离用户正在的需求，最终的设计无法有效地解决用户的核心问题。

另外，产品经理这个角色通常都会面临着巨大的业务压力。他们不仅要满足用户的需求，还要在竞争激烈的市场中推动产品的快速迭代。为了在短期内实现业绩上的增长，他们可能会倾向于通过小步快跑的方式，快速的推出一些列功能来响应用户的反馈。

这种做法虽然可能在短期内带来一些积极的数字指标，但它们可能并未能为客户和公司的真正核心指标带来影响。同时也使得产品变得越发臃肿复杂，对产品长线的战略规划埋下一堆包袱。

设计师的困境

在整个产品研发流程中，设计师的角色往往被定义为执行者。当我们接到产品经理的需求后，就开始按照PRD 的描述来进行界面的设计工作。

这种工作模式使得设计师缺乏对产品整体的思考，而是更多地关注如何满足特定的设计需求，而不是从全局角度审视产品的目标和方向。这种局限性导致设计师难以看到产品的全貌，如果前面需求输入有偏差，我们再怎么设计也很难获得好的结果。

同时，在产品的决策环节中，设计师的存在很多时候只是为了演示产品 Demo，做解释，很少有机会真正参与到产品方向的讨论和决策中。这种情况使得设计师的声音在产品开发环节中往往被忽视掉。我们的建议和见解，都被业务需求和客户需求所“淹没”，久而久之大家也就习惯了在既定的范围内做设计。

随着时间的推移，设计师可能就会陷入一种自我的困境。大家逐渐接受了“执行者”的角色定位，认为自己的职责只是完成分配的任务，没有必要参与到产品层面的讨论中，反正说了也没人听。这种心态不仅制约了我们的职业发展，也使得我们很难在更高的层面做体验设计。大家也开始默默接受自己“工具人”的定位，进一步加剧了他们在团队中话语权的丧失。

环境的制约

除了前面我们提到的客户、产品经理和设计师三个核心角色，环境的影响在整个产品研发环节中同样不可忽视。商业环境的瞬息万变，尤其是在当前经济环境下，给我们的产品团队带来了巨大的挑战。快速变化的市场使得我们不得不不断调整策略，来快速响应用户的需求，以解决当前面临的迫切问题。这种环境压力下，团队往往不得不优先考虑短期成果，忽略了对产品长远发展的规划。

随着时间的推移，这种“追求短期成果”的工作方式会逐渐渗透进公司的文化，成为团队日常运作的一部分。为了在激烈的市场竞争中保持竞争力，团队不断推出新功能和新产品，满足客户的即时需求。虽然这种做法似乎在短期内带来了一些过程指标的繁荣，但从长远来看，却对我们的核心指标没能带来更大的帮助，难以形成可持续的竞争优势。

以上的这些看似独立的问题，实际上是相互交织的。每个环节的局限性与压力都在无形中加剧了另一个环节的问题，一环套一环彼此影响。

然而，凭借我们设计师自身的力量要改变这一切还是非常有难度的。我们也不期望能在短时间改善这一切，但对于我们设计师而言，重要的是在这种环境下，保持独立思考和解决问题的能力，不要让自己沦为一个纯粹的执行者，而最终逐步被这个行业所淘汰。

我们能做些什么？

在当前的大背景下，我们需要从根本上转变思维方式，特别是在产品需求的定义上。首先，我们应该从客户的实际需求出发，逆向推导出产品需求，而不是单纯地满足表面需求。

电商平台中的店铺装修功能就是一个非常典型的案例。

如今所有的电商平台都会非常关注自身店铺能力的建设。虽然不断增加新的店铺功能看似有助于丰富卖家的选择，但有一点我们需要清楚的认识到，卖家装修店铺的目的并不是为了得到一个看上去很漂亮的店铺，而是为了通过更好的展示来提升销售额和利润。店铺的装修只是方法、手段，而不是最终目的。

因此，当我们接到类似的需求时，应该首先思考这个需求与客户最终目标的关联，考虑它能为客户的最终目的带来什么实际价值。

在产品设计阶段，我们不应该简单地根据客户的要求去制定需求，还是需要从他们的最终目的为最终目标，反向推演出能够实现这些目标的具体路径。也许在这个过程中，你会发现用户真正需要的不是 A 而是 B。

举个例子，当我们接到会员营销功能的需求时，我们可以通过优惠券来吸引买家用户加入会员；加购、收藏返现来提升商品在搜索中的排序位置，这些功能的目的最终都是为了提升卖家商品的曝光、买家的意愿度，最终都还是为了商家能卖出更多的货而服务的。如果我们找不到这个逻辑推导关系，那么我们就需要好好思考一下这些需求是否真的有必要了。

这种逆向推导的方式可以运用在所有的产品需求上。每当我们接到一个新需求时，都应当思考它与客户最终目标的关联是什么，以及我们该如何让这个需求变得更加直接有效。这种方式不仅能帮助我们避免无休止的功能堆砌，还能确保我们开发的每一个功能都能真正为客户创造价值，帮助他们实现业务成功。

同时，在我们具体设计工作中，我们非常有必要提升自己在问题挖掘上的主动性。

设计师不应该完全依赖产品经理的需求，而是需要从用户和产品的角度主动思考。例如，在篇首提到的案例中，如果设计师能够主动与客户多做一次沟通，便能发现需求中的失焦之处，从而提出更有效的设计方案。这种主动性不仅有助于提升设计质量，还能避免设计工作陷入表面需求的陷阱。

对于这些变化，我们很可能会受到来自多方的挑战。但我们不应害怕这些来自产品经理的挑战。挑战意味着问题被我们拿出来深度剖析了。当所有疑问都能够被一一的回答时，往往我们就能够找到在当下最为合适的方案。

这个被挑战的过程，其实也是我们设计师能力成长的机会。为了应对这些挑战，我们需要反复深入了解客户需求、业务现状、技术制约以及竞品的各种状况。通过全面的分析，我们才会心中有底，才能构建出一个符合各方利益的设计方案。用这种方式来思考每一个设计需求，才能让我们在面对挑战时更加自信，也能让我们在未来的产品决策中有更多的话语权。

最后还有一点需要提一下。项目、需求最终都是归结为一段段代码，但它们的背后实际是由一群人“操纵”的。这些人有着各自不同的利益关注点，客户关注自己业务的结果，产品经理、运营关注各项数字指标的增长，而研发等团队则关注着自己的效率、技术先进性。

这些潜在的利益冲突或是协调，都会影响最终的设计方案。因此，在整个设计过程中，设计师不仅要关注技术和用户体验，还要充分考虑团队成员之间的利益关系，并在设计方案中找到平衡点。

写在最后

记得当年在晋升 P9 的 PPT 里我写过一句话，「在产品优化一步，胜过设计修改十步」。关于这句话，当时和评委聊了很久。因为我认为当设计行业发展到一定阶段后，产品与设计越来越密不可分。只有将两者放在一起综合思考，才能用户体验这个词得到进一步提升。这不仅是未来的必然趋势，更是我们设计师在设计领域继续发展的必经之路。

当客户或产品经理要求你设计某个功能时，如果我们完全按照他们的要求执行，最终的结果很可能会出现偏差。客户和产品经理往往缺乏对设计需求的深入理解，他们不知道应该提供什么样的输入，也不清楚在现有条件下会得到什么样的设计产出。

每个人天生都是问题的解决者。在工作和生活中，我们都会不断地遇到问题，不断地解决方案。因此，当我们面临一个问题时，很自然的就会提出一个解决方案并希望尽快推进实施。但在产品设计和开发中，个体的能力都是有短板的，每一个由个体提出的方案都有可能存在偏差。正是为了确保方案的正确性和有效性，我们才需要多个角色、不同工种的共同努力，才能从多角度审视问题，最终找到最优的解决方案。