平台型产品从「分散用户痛点」推导「统一优化方案」思路总结.pdf

平台型产品从 「分散用户痛点」推导 「统一优化方案」的思路总结 在产品告别初 阶段之后 ，基于业务方、PD 收集的用户痛点反馈 ，思考体验优化方案、推 进迭代优化就成为了用户体验设计师的日常工作。而对于同时有多类目标用户共存的平台型 产品来说 ，用户痛点具备 多、零碎、 （不同用户之间 ）彼此冲突 等特征 ，如果保持 「用户吐 槽一句 – PD 找设计师改一次方案」的项目迭代节奏的话 ，久而久之就会产生一系列问题 ： 陷入细节失察全局、前后矛盾反复修改、被动改进缺少沉淀、信息结构越来越复杂脆弱…… 之前的文章也提到过几次遇到这样的情况和自己的改进想法 ，但没有系统地梳理总结过整体分析推 导思路。今天这篇文章想结合一下个人实践经历 （由于是公司项目 ，只抽象了框架方法论 ，不涉及 具体内容细节 ），总结一下遇到这样的情况时 ，如何将 「多而散」的用户痛点归纳聚焦 ，推导出统 一的体验设计优化方案的方法思路。 和日常快速优化迭代相比 ，这样做有什么好处呢 ？ 产品设计新人最容易犯的错误之一 ，就是过于注重 「抠细节」 ，而无法从更全局、整体的角度来统 一看待和解决问题。针对单一的用户痛点吐槽逐一提出的优化方案 ，割裂开来看似乎都很合理 ，但 却掩盖了痛点之间可能存在的矛盾冲突等关系 ，也容易让设计师陷入细节而不去考虑对产品整体、 长远发展的影响。最终无数个看似合理的单一方案加起来 ，却让产品变得割裂、前后矛盾、结构脆 弱难以扩展。 因为逐一思考解决方案容易忽略用户痛点之间的关联和矛盾 ，所以也容易出现方案之间前后矛盾、 迭代上线后需要反复修改回滚一类的现象 ，给设计和开发都增加了工作量。而如果将用户痛点聚焦 起来分析 ，一次打包成统一解决方案交付 ，这样的状况就能相对减少。 对于设计师自身来说 ，分析推导的过程也是沉淀个人价值和影响力的机会 ，能帮助提升自己的系统 分析洞察能力 ，从更整体的角度来解决问题的能力 ，而不是做一个尴尬的被动执行者。 具体的分析推导流程 1 ）定位用户 B 端产品目标用户群通常很确定 ，直接咨询 PD、业务方获取信息即可。在沟通确认信息的过程中 ， 需要明确以下几个要点 ： 目标用户群可划分哪几类 ？ 这几类用户中 ，哪些是核心主体用户 ？哪些能给平台带来较大业务价值 ？ 用户在平台上的职责是什么 ？落脚页面是哪些 ？有什么潜在诉求 ？ 2 ）归纳痛点 整理各类用户的调研反馈信息 ，描述故事归纳痛点 ，进一步提炼出背后的用户诉求 ，比较建议使用 表格的形式来整理 ，具体框架可参考如下 ： 相关环节 – 问题涉及到的具体相关流程、页面 相关环节 – 问题涉及到的具体相关流程、页面 故事板 – 站在用户角度描述典型使用场景、吐槽反馈 痛点总结 – 从用户故事中总结出具体痛点 诉求提炼 – 推导痛点背后的用户想要的东西 3 ）提炼目标 归类用户诉求 ，提炼出关键用户目标、明确目标之间联系 ，结合业务价值提炼体验目标洞见。用户 目标可以按照用户接触、认知、产生忠诚、自发推广产品的周期来提炼关联 ，的以下是我对一个问 题流转平台产品的用户目标和体验目标抽象 ： 4 ）明确方向 定义清楚产品特征、现状问题、设计目标等后 ，分模块、场景梳理可改进点。 提炼具体的设计方向和改进办法 ，落实到较具体的方案思路上。 排好优先级 （结合业务目标考虑 ），明确好排期时间节点 ，及时和项目组保持信息同步。 5 ）整合设计 分模块、场景整合设计方案 ，平衡多方用户痛点诉求 ，用一套设计稿同时解决多个问题。此处省略 具体交互稿若干…… 6 ）实施跟进 把控产品迭代节奏 ，跟进方案开发落地。 关注上线数据反馈 ，验证方案实际效果。 整理反馈 ，准备下一次迭代优化。 但真正的实践推进过程并不是那么顺利 ，也踩到了几个坑…… 1 ）流于形式 我在实践尝试过程中有些太注重前期的梳理、分析和推导过程表达 ，还写了一份非常完整详细的产 品设计分析报告。但其实很多用户分析的环节内容更多是基于 PD 收集和自己使用的反馈在 YY ，而 没有科学的用户访谈调研流程 ；在出具体方案的过程中思考也不够周全 ，评审具体解决方案时被挑 战到不少细节 ，这些都是今后需要避免的地方。 2 ）节奏 合理 因为自己主动推进项目的意识还不够强 ，疏于设计方案交付后跟进开发的节奏把控 ，设计交付到正 式开发动工间隔了整整一个月之久 ，到写文章的时候相关功能也没有全面开发上线完毕。一个明显 的不良后果就是等开发时我已经遗忘了部分设计细节这么做的原因 ，又花了多余的时间精力来重新 沟通确