2019年12月23日
B端产品如何梳理需求

在做B端产品设计时,前期的需求收集和调研其实非常重要,如果需求方向错了,那后续的所有工作都会面临着被全盘推翻返工的危险。

 

有可能大家辛辛苦苦了一个月,到项目交付的时候被客户否决打回去重头开始,或是重复性的不停返工,互相消耗着彼此的信任感和耐心。

 

所以,在做B端产品设计时,就要求设计师或产品经理必须要了解客户的真实需求。但是实际操作时,B端产品因为它自己本身的属性,往往前期的需求会数量繁多或需求不明晰。

 

大多数情况是:

1.新接手的项目,对接人发来了一张密密麻麻的需求点文档,里面详细列了所有的功能点,但是对于整体产品背景,产品目的,以及这些功能的设计出发点,设计师并不清楚。

 

2.需求讨论会议上,与客户你来我往沟通讨论了半天,但是结束后往往也觉得面对着这么多的需求一团乱麻不知如何下手。

这时候,如果设计师不对已有的需求进行正确的调研和梳理,而是根据客户提供的功能点埋头开始做设计,就会发现这样出来的设计,可能设计师自己都对自己设计的产品没有信心,更不要说客户的满意度了。

 

怎样才能避免这样的情况,更好的进行需求调研和梳理呢?

 

首先,设计师需要去了解B端产品的特点和其底层运作逻辑。

 

B端产品的特点:

1.为B端产品买单的人是企业,企业是以盈利为目的,企业的关注点是如何增收,或者如何降低成本,获取直接收益。所以在设计B端产品时,需要去考虑这个产品为产品受众提供的价值是什么,帮助企业解决了哪些问题。

 

2.B端产品受众与C端产品不同,B端的受众是企业,是一个群体组织,解决的是组织效率问题,核心关注点和聚焦点在于组织的需求,需要满足组织内不同层级之间的使用需求。

 

了解了这些信息后,对于设计一款B端产品的战略方向就有了,之后就是对产品需求分类和用户分层。

 

B端产品的需求来源点不是单一的,而是由多方提出的,有时即使产品使用者只有三个人,但是三个人身份如果各不相同,那需求点也会各有侧重各有不同。

 

这时候就需要设计师对需求和用户进行分类分层。

 

首先,要对需求进行收集。

在需求收集阶段,需要从三个维度去定位和收集需求:

一个产品中,肯定包含不止一个目标用户,设计师需要对目标用户进行用户分层,并从目标用户去推导每个目标用户的信息关注点和核心目的。

 

例如,客户想要做一个运营大数据监控系统,通过系统可以更好的获取公司整体的运营情况,辅助人员进行运营决策管理。

 

这样一个系统,设计师一开始接触的信息一定很庞杂,你能够听到很多人的声音,有人说要有效率,有人要酷炫的效果,有人说要能预测预警。

 

这时候就要通过需求沟通对用户分层进行了解并确定需求方向和范围,你需要了解的是客户语句里包含的潜在信息。

 

用户访谈1:

从这段话里,你需要提取出哪些信息呢?

是马上开始想要做哪些功能,要怎么去设计功能板块吗?

 

不是的,你要先看到他的核心目的到底是什么,而不是陷入到细节里,需要站到更高的角度去了解他真正想要的是什么关心的是什么。

这些才是这段话的重点,老板对这个产品的态度是止损降低成本,那么产品就要注意风险把控,他想要快速上线。理清楚了这一点,才好定义整个产品的设计和发展方向,理解了老板的目的,才好去判断他的预期,从而完成符合他预期的产品,不然就会出现设计完成之后,被客户怼觉得这完全就不是我想要的,设计不能去引导客户,反而是被客户拉着走让他去指导你的设计,然后你就会被客户拉入他的细节功能描述里,并且让他降低了对你的信任度。

用户访谈2:

这些话里,运营经理是想表达哪些信息呢?

从这些信息里,可以推导出运营经理属于产品的执行层,他是真实每天使用这个产品的人,所以需要考虑怎么提高他的效率提升使用体验。这里还有一个敏感点,这个产品需要大屏展示,公司领导也能看到,那设计时,就需要去顾及运营经理的利益,设计时需要注意不要把负面数据放在首页或者太明显的位置,不然就会损伤运营经理的利益,会让他在领导面前下不来台,那这样的设计运营经理在评审时是一定会要求打回重新设计的。

 

当用户分层理清楚后,就可以从这里入手再去进行需求功能模块的划分,梳理出整体产品架构,了解熟悉公司产品业务,把骨架确定好后,再进一步的去填充整个产品的细节内容。

 

做B端产品,很多时候其实更重要的就是前期的需求梳理和用户分层。

设计师需要花精力去理解业务,去补充更多的业务信息以便减少与客户的信息不对称,去找到核心用户,核心关注点和核心目的。

 

从这些维度去设计,才能在最终呈现出较为符合客户心里预期的效果,才能更匹配客户真实预期想要的产品。不然就只能陷入被客户牵着走,不停的沦为单纯的画图执行者,不能体现出设计师真正的价值。

 

最新文章