专栏名称: 人人都是产品经理
产品经理不再是一个单纯的职位,而是一种思维方式,这种思维是所有互联网人必备的,做互联网的人不能不懂产品,关注产品,改变生活。
目录
相关文章推荐
人人都是产品经理  ·  效率与流量竞争,美团、抖音本地生活下沉市场策略 ·  9 小时前  
产品犬舍  ·  水一帖,聊 10 条有的没的 ·  2 天前  
人人都是产品经理  ·  客户总是“听不懂”?产品经理汇报中的致命误区 ·  2 天前  
三节课  ·  自从用上DeepSeek,我现在强的可怕! ·  4 天前  
三节课  ·  月入3万+!第一批用DeepSeek赚钱的人 ... ·  4 天前  
51好读  ›  专栏  ›  人人都是产品经理

体验优化类需求,如何推进落地?

人人都是产品经理  · 公众号  · 产品  · 2025-02-23 10:00

正文

在产品设计与开发过程中,体验优化类需求常常因为缺乏紧迫性而被忽视,尤其是在B端和G端产品中。本文为设计师们提供了一套实用的方法论,帮助他们推动体验优化需求的落地,供大家参考。


———— / BEGIN / ————

相比起功能性迭代,体验优化类的需求往往更难以被重视,在B端或G端产品尤甚。这种现象也让很多设计师觉得工作价值感不高,容易沦为纯执行类角色,逐渐被项目边缘化。

那如何推进体验优化类的需求落地,让体验优化类的需求得到更多重视呢?

第一步:先确保必要性

什么是必要性?

必要性,是指这个体验优化需求要解决的问题是真实存在的。

也就是说,在第一步,我们要回答2个问题:你要解决的问题是什么?这个问题是不是真实存在?

我们每提出一条需求,都会对应一个预期结果,也就是这条需求落地后的收益,体验优化的需求也不例外。

而之所以有预期收益,是因为现有的产品存在某些可以改进的具体问题。比如某个具体操作的效率不高步骤过长,交互方式过于复杂很难记忆,某个界面的布局太散很难快速查阅信息等。

当有了这个明确要解决的具体问题,接下来,我们就要论证这个问题是不是真实存在,即它有没有必要被解决。

什么叫真实存在?

举个例子。

比如我们说某个表单信息过于冗余,我们希望通过优化表单的字段、排版和颜色来解决信息冗余,对应的优化需求可能是减少2个不必要的字段、某个状态字段的内容使用颜色区分明显的标签来表示。

那么,我们首先要论证“表单信息过于冗余”的问题是否真实存在。

你可能会觉得奇怪,这还要论证、不一眼就能看出吗?

但事实上,“表单信息过于冗余“只是一个主观结论。

许多体验需求很难被重视从而真正的得到落地实现,就是因为它要解决的问题可能只是一个没有达成共识的主观结论。

很多时候,我们以设计师的角度来看,一个产品可能存在非常多的问题,但对于其他人来说却并不是问题,甚至感觉不出来。

如果要让它成为一个有必要去解决的问题,你首先需要让这个问题真实成立,而不仅仅是你主观观点。

基于这个例子,常见的方法是:多搜集几个人的观点,看看是不是别人也认为“表单信息过于冗余”,从而论证这个结论不是你的片面认知。

如果没有精力去做更专业的用户调研,就尽量去搜集关键人的观点。

对比其他竞品,看看其他产品是不是否做到了你认为的“不冗余”,从而论证你这条结论的判断标准是行业通识,而不是依据你的个人喜好。

直接拿出新的解决方案,通过新旧对比论证目前的表单信息比起你的解决方式过于冗余。

值得注意的是,在这个例子中很可能产生的逻辑错误是:论证的不是“表单信息过于冗余”的问题,而是“表单信息可以更加清晰”的主张,需要配合其他信息说明这条需求有必要性的。

当这条体验优化需求被证实是必要的,确实在解决某个实际存在的问题后,要推进落地,还要解决它的优先级问题。

因为有必要去解决,不一定代表它需要被立刻去解决。很多低优先级的需求可能放个1、2年也不一定被解决掉,所以,当我们要推进一条体验需求落地,还要争取尽可能提高它的优先级。

第二步:找准时机

什么是时机?

是指某一条具体需求在某个时候可能被设定为更高优先级的概率。

优先级是需求重要和紧急程度的分级,优先级高的需求必然会被优先落地实现。但即使是同一套产品,优先级的判断标准和权重也是在变化中的,尤其是在如今的社会环境里。

一般来说,体验需求的优先级可以从三个维度来考虑:

1)产品价值维度

与产品当前迭代的核心方向越契合,优先级越高。比如某个功能是产品的核心竞争力,那么与这个功能有关的体验优化需求,就会得到更多重视。

2)体验提升维度

体验提升维度又分深度和广度来判读在深度上,可用性的体验优化>易用性的体验优化>情感性的体验优化。在广度上,要看这个体验优化的受益范围。

比如一个通用页面的体验优化,一定大于某个特殊页面的体验优化,因为只要改一个地方,受益的界面体验更多;又比如一个更多用户受益的体验需求,一定比只有少量用户会受益的体验需求更重要。

3)技术实现维度

技术实现维度也分两个方面,本身实现难度和稳定性风险。本身的实现难度是这个需求本身的实现难度。

这个实现难度应该基于实际资源配置来确认,例如有的公司在某块技术上实力较弱甚至缺失,那么即使对业界来说实现难度低,评估下来也不一定实现难度低。

稳定性风险是对现有系统的影响程度。

如果一个功能迭代需要修改现有系统的底层代码,可能会导致整个系统的不稳定,甚至影响其他功能的正常运行,那么这种迭代的优先级需要谨慎确定;若迭代是在现有系统基础上进行的独立功能模块开发,对现有系统影响较小,可根据其他维度综合评估优先级。

在不同的公司、不同的时间段里,这些评估维度的权重是不同的。

例如同样易用性提升的需求,在一个产品已经满足了基本的可用性要求时会更容易去推进落地;再例如,当前很多公司在做产品智能化,那么与智能交互相关的优化,以及优化了后会显得更智能的体验需求就更容易在这种大方向下去推进落地。

···

随着AI化的进程,纯执行类工作的门槛必然会越来越低,设计师能否从专业的角度帮助产品进行优化显得更为重要。

在确认必要性时,需要通过多方论证问题的真实存在性,避免陷入主观臆断。

在把握时机方面,则需从产品价值、体验提升和技术实现三个维度来评估优先级。

只有在合适的时机推进合理的需求,才能真正实现体验优化的价值。

———— / E N D / ————

本文来自微信公众号:林间有影落,作者:林影落







请到「今天看啥」查看全文