把产品做到极致的文案(由一个文案引发的系统改造)

把产品做到极致的文案?作者以一个错误提示问题为例,介绍了他认为比较核心的三类产品思维工具及其在项目中的应用,分别是本质思维、结构思维、系统思维具体是如何进行的?欢迎感兴趣的伙伴们阅读~,我来为大家讲解一下关于把产品做到极致的文案?跟着小编一起来看一看吧!

把产品做到极致的文案

作者以一个错误提示问题为例,介绍了他认为比较核心的三类产品思维工具及其在项目中的应用,分别是本质思维、结构思维、系统思维。具体是如何进行的?欢迎感兴趣的伙伴们阅读~

01 前言:关于产品思维的迷思

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

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

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

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

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

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

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

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

但随后我追问了自己几个问题,发现并没有这么简单:

为什么这个错误定义会遗漏?

为什么之前统一文案的规则没有生效?

还有没有其他也会在发送场景触发的错误没有定义?

要修改错误码,只能通过发版本的方式吗?

为什么没有做成实时配置实时生效?

于是我拉着技术又进行了一轮沟通,我们发现,之前的错误梳理是分散且单一维度的,即:登录模块的产品梳理登录模块的错误,发送模块的产品梳理发送模块的错误,而实际邮件登录、收取、发送等诸多过程中,都需要验证帐号的有效性,所以部分登录时的错误,在发送验证时也会发生,而两个场景下的提示在文案与操作上有所差异,无法单纯的复用。由此,原先的问题被重新定义为:

    如何完整定义所有的错误场景?

    如何实现错误提示配置的实效性?

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

与人体系统相似,产品也是由一系列系统组成运行的。那么当我们发现表现层出现问题的时候,就需要提醒自己进一步思考下问题的影响范围有多广?是不是系统底层逻辑出现了问题?比起解决表征的问题,我们更需要去优化引发问题的系统。

问题本质探究的思考方式:

    问题溯源:不断追问why,从根源解决问题,避免复现。追问的方法很简单,但很多时候是我们忘记问或问的不够深。

    审视目标:重新审视产品目标,明确现状与目标的差距在哪里,为什么?

    回到系统:把问题放回到它所处的系统中去重新思考,找到系统中起决定性作用的核心因素。

03 结构思维:复杂问题构建

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

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

结构化思维方法可以帮助我们:

1. 拆解要素 分类重组

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

第一层:协议,如IMAP、SMTP等;不同协议之间的错误码相互独立;

第二层:产品端与场景,不同端、不同场景下的提示样式、内容规则会有差异;

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

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

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

每个Tab是一个协议;

纵向是需要梳理的每个错误码;

横向是错误信息组成与不同场景下的需要定义的内容;

而他们组成的每个单元格就是我们需要完善的内容。

借助此工具,每一个错误码,都有了一个梳理的框架,可以明确需要定义哪些内容,避免场景与内容的遗漏。

2. 提炼共性 建立标准

在拆解梳理的过程中,会发现内容之间会存在一定的相似性与复用性,通过找到这些共性内容,又可以逐步形成一些标准化规则:

相似场景的提示形式是否可以统一?

好几个错误码都在描述帐号风险问题,他们的文案提示是否可以复用?

一些常用文案,如:确定按钮是用「确定」还是「好的」,是否可以统一?

常用关键词的翻译是否可以统一,避免后续翻译混乱?

通过这一步,可以总结和输出:错误提示组件规范、文案规范等标准化工具,一方面是保障用户体验的统一性,另一方面也是为后续设计提供参考降低成本。

结构性思考是产品设计中很重要的工具,可以帮助我们将复杂的问题转化为简单的行动,将混沌的问题转化为清晰的描述。

常用的结构化方法:

    图表化:展现复杂问题的结构,帮助更全面的完善细节,也是我在整理信息是特别常用的一种方法。但其难点是在于要将问题拆解充分,最终每个单元格只有单一的「是与否」信息为最佳;

    模型化:将问题思考的过程提炼,帮助我们进行更全面的分析与思考,设计常用的分析模型如:用户体验地图、用户增长模型…

    公式化:找到核心变量及其影响关系,明确工作与结果的关系,对于数据结果导向的工作特别常用。

04 系统思维:让设计动起来

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

1. 动态适应

“系统能运行多久?”

系统的设计需要满足动态的需求变化,单以错误提示为例,发生变化的情况有很多:

虽然希望能够完整定义所有错误,但事实上是比较难做到的,未来的内容新增不可避免;

相关方对于服务的调整,有可能会造成错误提示的修改要求;

提示上线后,发现文案效果不佳,会带来优化需求;

随着产品能力与技术的迭代,一些过去的内容与操作可能不再适用,需要调整;一些过去的未知错误有了新的解决办法,需要补充…

之前的错误提示,是伴随着每次功能迭代,在设计时定义好,在研发时写在客户端,因此造成每次修改都需要发版处理的情况。在优化方案中,替代原先在客户端管理的方式,将错误内容配置放到服务端,客户端获取服务端错误码与配置内容进行匹配,展示相应内容:

2. 自动执行

“一定需要提示吗?”

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

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

这个提示真的有必要展示吗?—— 是否可以通过自动重试或其他策略优化,避免错误的发生?

这个操作真的有必要让用户处理吗?—— 是否可以提供一键检测、一键修复的方案,帮助用户完成一系列的复杂操作?

3. 主动反馈

“你能发现未知的问题吗?”

前面提到,提示系统的作用之一就是便于后期将未知错误转化为已知错误?但是如果是未知错误,我们要怎样发现它们?如何决定哪些未知错误需要优先处理?

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

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

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

05 结语

有同学会问,如果要搭建这么一套系统的话,投入大时间久,那这个之前的问题就一直放着吗?

当然不是。在实际工作中,处理问题需要同时考虑解决效率与投入价值。

从处理问题的效率上考虑,最开始的错误提示当时也是先及时做了补充的。但是此时,这个文案的补充并非孤立无序的,我们能够清楚,它将是错误信息管理表中的一项重要信息,也是配置系统的一项重要配置,是未来错误提示系统的重要一部分。我们并非在零碎的做事情,而是在逐步完善一个产品系统。

作者:徐恺

来源公众号:网易UEDC,网易用户体验设计中心

本文来源于人人都是产品经理合作媒体@网易UEDC,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

© 版权声明
THE END
喜欢就支持一下吧
分享