聚沙成塔：平台型产品从「分散用户痛点」推导「统一优化方案」的思路总结

在产品告别初创阶段之后，基于业务方、PD 收集的用户痛点反馈，思考体验优化方案、推进迭代优化就成为了用户体验设计师的日常工作。而对于同时有多类目标用户共存的平台型产品来说，用户痛点具备多、零碎、（不同用户之间）彼此冲突等特征，如果保持「用户吐槽一句 - PD 找设计师改一次方案」的项目迭代节奏的话，久而久之就会产生一系列问题：陷入细节失察全局、前后矛盾反复修改、被动改进缺少沉淀、信息结构越来越复杂脆弱……

之前的文章也提到过几次遇到这样的情况和自己的改进想法，但没有系统地梳理总结过整体分析推导思路。今天这篇文章想结合一下个人实践经历（由于是公司项目，只抽象了框架方法论，不涉及具体内容细节），总结一下遇到这样的情况时，如何将「多而散」的用户痛点归纳聚焦，推导出统一的体验设计优化方案的方法思路。

和日常快速优化迭代相比，这样做有什么好处呢？

产品设计新人最容易犯的错误之一，就是过于注重「抠细节」，而无法从更全局、整体的角度来统一看待和解决问题。针对单一的用户痛点吐槽逐一提出的优化方案，割裂开来看似乎都很合理，但却掩盖了痛点之间可能存在的矛盾冲突等关系，也容易让设计师陷入细节而不去考虑对产品整体、长远发展的影响。最终无数个看似合理的单一方案加起来，却让产品变得割裂、前后矛盾、结构脆弱难以扩展。

因为逐一思考解决方案容易忽略用户痛点之间的关联和矛盾，所以也容易出现方案之间前后矛盾、迭代上线后需要反复修改回滚一类的现象，给设计和开发都增加了工作量。而如果将用户痛点聚焦起来分析，一次打包成统一解决方案交付，这样的状况就能相对减少（当然，不能完全避免）。

对于设计师自身来说，分析推导的过程也是沉淀个人价值和影响力的机会，能帮助提升自己的系统分析洞察能力，从更整体的角度来解决问题的能力，而不是做一个尴尬的被动执行者。

具体的分析推导流程

1）定位用户

B 端产品目标用户群通常很确定，直接咨询 PD、业务方获取信息即可。在沟通确认信息的过程中，需要明确以下几个要点：

目标用户群可划分哪几类？

这几类用户中，哪些是核心主体用户？哪些能给平台带来较大业务价值？

用户在平台上的职责是什么？落脚页面是哪些？有什么潜在诉求？

2）归纳痛点

整理各类用户的调研反馈信息，描述故事归纳痛点，进一步提炼出背后的用户诉求，比较建议使用表格的形式来整理，具体框架可参考如下：

相关环节- 问题涉及到的具体相关流程、页面

故事板- 站在用户角度描述典型使用场景、吐槽反馈

痛点总结- 从用户故事中总结出具体痛点

诉求提炼- 推导痛点背后的用户想要的东西

3）提炼目标

归类用户诉求，提炼出关键用户目标、明确目标之间联系，结合业务价值提炼体验目标洞见。用户目标可以按照用户接触、认知、产生忠诚、自发推广产品的周期来提炼关联。

4）明确方向

定义清楚产品特征、现状问题、设计目标等后，分模块、场景梳理可改进点。

提炼具体的设计方向和改进办法，落实到较具体的方案思路上。

排好优先级（结合业务目标考虑），明确好排期时间节点，及时和项目组保持信息同步。

5）整合设计

分模块、场景整合设计方案，平衡多方用户痛点诉求，用一套设计稿同时解决多个问题。此处省略具体交互稿若干……

6）实施跟进

把控产品迭代节奏，跟进方案开发落地。

关注上线数据反馈，验证方案实际效果。

整理反馈，准备下一次迭代优化。

但真正的实践推进过程并不是那么顺利，也踩到了几个坑……

1）流于形式

我在实践尝试过程中有些太注重前期的梳理、分析和推导过程表达，还写了一份非常完整详细的产品设计分析报告。但其实很多用户分析的环节内容更多是基于 PD 收集和自己使用的反馈在 YY，而没有科学的用户访谈调研流程；在出具体方案的过程中思考也不够周全，评审具体解决方案时被挑战到不少细节，这些都是今后需要避免的地方。

2）节奏不合理

因为自己主动推进项目的意识还不够强，疏于设计方案交付后跟进开发的节奏把控，设计交付到正式开发动工间隔了整整一个月之久，到写文章的时候相关功能也没有全面开发上线完毕。一个明显的不良后果就是等开发时我已经遗忘了部分设计细节这么做的原因，又花了多余的时间精力来重新沟通确认，今后要更注意和 PD 一起把控好推进节奏，而不是完成设计方案交付掉就事不关己了。