2023年产品思维实践｜由一个文案引发的系统改造

产品思维实践｜由一个文案引发的系统改造01前言：关于产品思维的迷思

在业务工作中，我们常常会争论到：处理这个问题你需要运用产品思维；我想要提高一下自己的产品思维……我们知道产品思维是关心设计师更好地推动项目的重要力量，但当想要进一步学习时，又会发觉关于产品思维的各种维度的解析。

什么是产品思维？产品思维是如何在我们设计中发挥价值的？怎样体现产品思维？怎样学习产品思维？始终会有些说不清道不明的感觉，缺乏很详细的定义与行动指导。

我自己也在这块苦恼过，各类资讯书籍一看，怎么有这么多类型的产品思维？大家讲的还不一样。但之后我开头反思，或许不存在肯定定义的产品思维，不同的岗位（产品/设计/产品负责人/业务负责人等）、不同的业务、目标、经受、认知……不同的人对如何做产品、做设计其实会有不同深度的理解与运用，进而提炼与总结出可以关心他们更好的「洞察机会、解决问题、制造价值」的思维工具组合，即为他们的产品思维。

所以相对于学习某种产品思维，我们更应当建立自己的产品思维体系，在学习与实践中不断补充与提升。

今日的共享，以一个「错误提示问题」为例，介绍一下我认为比较核心的三类产品思维工具及其在项目中的应用。

02本质思维：从表征看病因

某一天，技术同学过来和我提到：“之前的一个错误码只定义了邮件登录场景下的错误文案，现在发觉用户遇到在发送场景下没有定义的问题，你给个文案，这个版本补充一下？”

当下，我也是直觉的反馈说：“好的，稍后给你。”

但随后我追问了自己几个问题，发觉并没有这么简洁：

为什么这个错误定义会遗漏？为什么之前统一文案的规章没有生效？还有没有其他也会在发送场景触发的错误没有定义？要修改错误码，只能通过发版本的方式吗？为什么没有做成实时配置实时生效？于是我拉着技术又进行了一轮沟通，我们发觉，之前的错误梳理是分散且单一维度的，即：登录模块的产品梳理登录模块的错误，发送模块的产品梳理发送模块的错误，而实际邮件登录、收取、发送等诸多过程中，都需要验证帐号的有效性，所以部分登录时的错误，在发送验证时也会发生，而两个场景下的提示在文案与操作上有所差异，无法单纯的复用。由此，原先的问题被重新定义为：

如何完整定义全部的错误场景？如何实现错误提示配置的实效性？

就像我们的身体消失了症状，需要去医院检查，请医生明确病因后才能对症下药。体表显现的病症，有时却是内部系统根源消失了问题的反应，假如仅仅是针对表征进行处理，并不能真正解决问题。

与人体系统相像，产品也是由一系列系统组成运行的。那么当我们发觉表现层消失问题的时候，就需要提示自己进一步思索下问题的影响范围有多广？是不是系统底层规律消失了问题？比起解决表征的问题，我们更需要去优化引发问题的系统。

问题本质探究的思索方式：

问题溯源：不断追问why，从根源解决问题，避开复现。追问的方法很简洁，但许多时候是我们遗忘问或问的不够深。端详目标：重新端详产品目标，明确现状与目标的差距在哪里，为什么？回到系统：把问题放回到它所处的系统中去重新思索，找到系统中起打算性作用的核心因素。03结构思维：简单问题构建

重新定义问题后，第一步，我们盼望可以收集、梳理完整的产品错误码，并定义其内容。

但是邮件服务涉及多个不同的邮件协议，加上不同产品端（移动、电脑）、不同场景（登录、发送…）的相互叠加，相关错误有几百个，该如何梳理？

结构化思维方法可以关心我们：

1.拆解要素分类重组

结构化的过程，首先是拆解的过程，分析问题的对象由哪些部分组成，将这些部分拆解出来。再将子项再进一步进行拆解，不断细分（实现MECE规章中提到的不遗漏、不重叠的效果）。案例中的错误提示便经过了以下的几层拆分：

第一层：协议，如IMAP、SMTP等；不同协议之间的错误码相互独立；

其次层：产品端与场景，不同端、不同场景下的提示样式、内容规章会有差异；

第三层：内容组成，拆分错误码、错误提示的组成，如：cause、code、形式、标题、操作等；

拆解后，需要再将这些要素重新分类组合，以便于我们梳理和不断补充错误码。

此处，我们利用表格工具建立二维管理表：

每个Tab是一个协议；纵向是需要梳理的每个错误码；横向是错误信息组成与不同场景下的需要定义的内容；而他们组成的每个单元格就是我们需要完善的内容。借助此工具，每一个错误码，都有了一个梳理的框架，可以明确需要定义哪些内容，避开场景与内容的遗漏。

2.提炼共性建立标准

在拆解梳理的过程中，会发觉内容之间会存在肯定的相像性与复用性，通过找到这些共性内容，又可以逐步形成一些标准化规章：

相像场景的提示形式是否可以统一？好几个错误码都在描述帐号风险问题，他们的文案提示是否可以复用？一些常用文案，如：确定按钮是用「确定」还是「好的」，是否可以统一？常用关键词的翻译是否可以统一，避开后续翻译混乱？通过这一步，可以总结和输出：错误提示组件规范、文案规范等标准化工具，一方面是保障用户体验的统一性，另一方面也是为后续设计供应参考降低成本。

结构性思索是产品设计中很重要的工具，可以关心我们将简单的问题转化为简洁的行动，将混沌的问题转化为清楚的描述。

常用的结构化方法：

图表化：呈现简单问题的结构，关心更全面的完善细节，也是我在整理信息是特殊常用的一种方法。但其难点是在于要将问题拆解充分，最终每个单元格只有单一的「是与否」信息为最佳；模型化：将问题思索的过程提炼，关心我们进行更全面的分析与思索，设计常用的分析模型如：用户体验地图、用户增长模型…公式化：找到核心变量及其影响关系，明确工作与结果的关系，对于数据结果导向的工作特殊常用。04系统思维：让设计动起来

梳理错误提示的同时，我们还需要搭建一套系统，以实现敏捷配置与实时生效的目标，即：将我们的设计构想进行产品化落地。而此时，系统思索之一，便是关注系统的动态性。

1.动态适应

“系统能运行多久？”

系统的设计需要满意动态的需求变化，单以错误提示为例，发生变化的状况有许多：

虽然盼望能够完整定义全部错误，但事实上是比较难做到的，将来的内容新增不行避开；相关方对于服务的调整，有可能会造成错误提示的修改要求；提示上线后，发觉文案效果不佳，会带来优化需求；随着产品力量与技术的迭代，一些过去的内容与操作可能不再适用，需要调整；一些过去的未知错误有了新的解决方法，需要补充…之前的错误提示，是伴随着每次功能迭代，在设计时定义好，在研发时写在客户端，因此造成每次修改都需要发版处理的状况。在优化方案中，替代原先在客户端管理的方式，将错误内容配置放到服务端，客户端猎取服务端错误码与配置内容进行匹配，展现相应内容：

2.自动执行

“肯定需要提示吗？”

我们常听到一句话：最好的设计是「没有设计」，转化用在这个项目中却相对合适，最好的错误处理也应当是「没有提示」。

当我们在专注于梳理错误操作内容、设计错误操作配置，不妨可以再问问自己：

这个提示真的有必要展现吗？——是否可以通过自动重试或其他策略优化，避开错误的发生？这个操作真的有必要让用户处理吗？——是否可以供应一键检测、一键修复的方案，关心用户完成一系列的简单操作？3.主动反馈

“你能发觉未知的问题吗？”

前面提到，提示系统的作用之一就是便于后期将未知错误转化为已知错误？但是假如是未知错误，我们要怎样发觉它们？如何打算哪些未知错误需要优先处理？

考虑到这个问题，我们在配置系统外，同时还搭建了一套线上报错监控系统（虽然还做不到识别高频未知错误主动预警），定期复查高频错误，补充定义新的未知错误。

至此，错误提示问题的解决方案设计才算告一段落。

邮件系统的错误提示有其简单性与重要价值，借助产品思维工具，避开了掉入「这个问题很简洁」的陷阱，找到问题根源与最佳目标，从简单繁多的错误中找到规律，进行结构化梳理，建立标准，最终建立错误提示配置系统、自动化策略、监控机制，为产品的错误提示管理建立系统方案，为产品与用户供应长期价值。

05结语

有同学会问，假如要搭建这么一套系统的话，投入大时间久，那这个之前的问题就始终放