作者以一个错误提示问题为例，介绍了他认为比较核心的三类产品思维工具及其在项目中的应用，分别是本质思维、结构思维、系统思维。具体是如何进行的？欢迎感兴趣的伙伴们阅读~
在业务工作中，我们经常会讨论到：处理这个问题你需要运用产品思维；我想要提高一下自己的产品思维……我们知道产品思维是帮助设计师更好地推动项目的重要能力，但当想要进一步学习时，又会发现关于产品思维的各种维度的解析。
什么是产品思维？产品思维是如何在我们设计中发挥价值的？怎样体现产品思维？怎样学习产品思维？始终会有些说不清道不明的感觉，缺乏很具体的定义与行动指导。
我自己也在这块苦恼过，各类资讯书籍一看，怎么有这么多类型的产品思维？大家讲的还不一样。但之后我开始反思，也许不存在绝对定义的产品思维，不同的岗位（产品/设计/产品负责人/业务负责人等）、不同的业务、目标、经历、认知……不同的人对如何做产品、做设计其实会有不同深度的理解与运用，进而提炼与总结出可以帮助他们更好的「洞察机会、解决问题、创造价值」的思维工具组合，即为他们的产品思维。
所以相对于学习某种产品思维，我们更应该建立自己的产品思维体系，在学习与实践中不断补充与提升。
今天的分享，以一个「错误提示问题」为例，介绍一下我认为比较核心的三类产品思维工具及其在项目中的应用。
某一天，技术同学过来和我提到：“之前的一个错误码只定义了邮件登录场景下的错误文案，现在发现用户遇到在发送场景下没有定义的问题，你给个文案，这个版本补充一下？”
当下，我也是直觉的反馈说：“好的，稍后给你。”
但随后我追问了自己几个问题，发现并没有这么简单：
于是我拉着技术又进行了一轮沟通，我们发现，之前的错误梳理是分散且单一维度的，即：登录模块的产品梳理登录模块的错误，发送模块的产品梳理发送模块的错误，而实际邮件登录、收取、发送等诸多过程中，都需要验证帐号的有效性，所以部分登录时的错误，在发送验证时也会发生，而两个场景下的提示在文案与操作上有所差异，无法单纯的复用。由此，原先的问题被重新定义为：
就像我们的身体出现了症状，需要去医院检查，请医生明确病因后才能对症下药。体表显现的病症，有时却是内部系统根源出现了问题的反应，如果仅仅是针对表征进行处理，并不能真正解决问题。
与人体系统相似，产品也是由一系列系统组成运行的。那么当我们发现表现层出现问题的时候，就需要提醒自己进一步思考下问题的影响范围有多广？是不是系统底层逻辑出现了问题？比起解决表征的问题，我们更需要去优化引发问题的系统。
问题本质探究的思考方式：
重新定义问题后，第一步，我们希望可以收集、梳理完整的产品错误码，并定义其内容。
但是邮件服务涉及多个不同的邮件协议，加上不同产品端（移动、电脑）、不同场景（登录、发送…）的相互叠加，相关错误有几百个，该如何梳理？
结构化思维方法可以帮助我们：
结构化的过程，首先是拆解的过程，分析问题的对象由哪些部分组成，将这些部分拆解出来。再将子项再进一步进行拆解，不断细分（实现MECE规则中提到的 不遗漏、不重叠的效果）。案例中的错误提示便经过了以下的几层拆分：
第一层：协议，如IMAP、SMTP等；不同协议之间的错误码相互独立；
第二层：产品端与场景，不同端、不同场景下的提示样式、内容规则会有差异；
第三层：内容组成，拆分错误码、错误提示的组成，如：cause、code、形式、标题、操作等；
拆解后，需要再将这些要素重新分类组合，以便于我们梳理和不断补充错误码。
此处，我们利用表格工具建立二维管理表：
借助此工具，每一个错误码，都有了一个梳理的框架，可以明确需要定义哪些内容，避免场景与内容的遗漏。
在拆解梳理的过程中，会发现内容之间会存在一定的相似性与复用性，通过找到这些共性内容，又可以逐步形成一些标准化规则：
通过这一步，可以总结和输出：错误提示组件规范、文案规范等标准化工具，一方面是保障用户体验的统一性，另一方面也是为后续设计提供参考降低成本。
结构性思考是产品设计中很重要的工具，可以帮助我们将复杂的问题转化为简单的行动，将混沌的问题转化为清晰的描述。
常用的结构化方法：
梳理错误提示的同时，我们还需要搭建一套系统，以实现灵活配置与实时生效的目标，即：将我们的设计构想进行产品化落地。而此时，系统思考之一，便是关注系统的动态性。
“系统能运行多久？”
系统的设计需要满足动态的需求变化，单以错误提示为例，发生变化的情况有很多：
之前的错误提示，是伴随着每次功能迭代，在设计时定义好，在研发时写在客户端，因此造成每次修改都需要发版处理的情况。在优化方案中，替代原先在客户端管理的方式，将错误内容配置放到服务端，客户端获取服务端错误码与配置内容进行匹配，展示相应内容：
“一定需要提示吗？”
我们常听到一句话：最好的设计是「没有设计」，转化用在这个项目中却相对合适，最好的错误处理也应该是「没有提示」。
当我们在专注于梳理错误操作内容、设计错误操作配置，不妨可以再问问自己：
“你能发现未知的问题吗？”
前面提到，提示系统的作用之一就是便于后期将未知错误转化为已知错误？但是如果是未知错误，我们要怎样发现它们？如何决定哪些未知错误需要优先处理？
考虑到这个问题，我们在配置系统外，同时还搭建了一套线上报错监控系统（虽然还做不到识别高频未知错误主动预警），定期复查高频错误，补充定义新的未知错误。
至此，错误提示问题的解决方案设计才算告一段落。
邮件系统的错误提示有其复杂性与重要价值，借助产品思维工具，避免了掉入「这个问题很简单」的陷阱，找到问题根源与最佳目标，从复杂繁多的错误中找到规律，进行结构化梳理，建立标准，最后建立错误提示配置系统、自动化策略、监控机制，为产品的错误提示管理建立系统方案，为产品与用户提供长期价值。
有同学会问，如果要搭建这么一套系统的话，投入大时间久，那这个之前的问题就一直放着吗？
当然不是。在实际工作中，处理问题需要同时考虑解决效率与投入价值。
从处理问题的效率上考虑，最开始的错误提示当时也是先及时做了补充的。但是此时，这个文案的补充并非孤立无序的，我们能够清楚，它将是错误信息管理表中的一项重要信息，也是配置系统的一项重要配置，是未来错误提示系统的重要一部分。我们并非在零碎的做事情，而是在逐步完善一个产品系统。
作者：徐恺
来源公众号：网易UEDC，网易用户体验设计中心
本文来源于人人都是产品经理合作媒体@网易UEDC，未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。