本文作者将以签到为例,讲一讲在对签到进行优化的时候,其基于不同的场景做了哪些设计。
在 To C 产品中经常可以看到基于场景进行的设计,比如旅游类 APP 在获取你的定位后,给你推送当前城市相关的旅游信息;支付软件在你支付后推送周围餐厅的优惠券;当你买完机票后,会给你推送目的地的酒店信息等等。
在 To B 产品中,存在的场景会更加复杂。因为 To B 产品更多的是提供一个针对某个特定问题场景的完整解决方案,在这个问题场景中会存在特别多的角色。只要把握住「角色」这个问题,就可以在不同「角色」组成的小场景中,进行有针对性的设计。
在从 C 端转向 B 端时,非常容易忽视的一个就是角色的区分。不同的角色在面对同一个功能的时候,需求会不一样。如果说能根据这个区分出不同的场景的话,将会更好的引导用户对产品进行使用。
面对一个功能,不同角色的主要工作内容肯定是有区别的。比如云之家的签到轻应用,主要分为3个角色,签到管理员、经理(以经理为代表的管理角色)、员工。他们在面对签到的主要功能分别为:管理签到规则、根据出勤计算工资;查看员工出勤情况并进行管理;签到打卡。那么这三个角色在进入签到的时候则会有不同的需求,且我们需要根据不同的情况进行引导。
下面将以签到为例,讲一讲在对签到进行优化的时候,我们基于不同的场景做了哪些设计。
「签到」的背景
签到是云之家的一个轻应用,周活在轻应用中排名靠前,但是转化率一直稳定在比较中庸的位置。
分析了一下问题的原因,主要有两点:一是客观上功能性方面与竞品存在差距;二是设计上的缺陷,用户引导上并没有做的很好。所以,我们以提高转化率为目的,对签到应用进行了分析和调研,并重新进行了设计。
那么如何根据角色进行设计呢?主要分为这几个步骤:
需求的目的:在设计之前的大前提,是明确需求目的,以目的为准绳,防止自己在之后的思考走歪路。其实这一点是非常重要的一点,对于比较复杂的功能,涉及的角色较多的时候,设计师在经过长时间的深入思考可能会出现思维跑偏的情况,时不时地回头看一看自己是否脱离了需求目的是非常有必要的。明确了功能需求的目的,才能够以此为准绳进行设计。
包含的角色:明确涉及到此功能使用的角色一共有多少个
主要角色是什么:找出主要角色
角色的场景:正确理解不同的角色在此功能下的使用场景
分角色进行设计:针对主要角色和次要角色分别进行设计
1、需求的目的
其实目的已经非常明确了,就是需要提高签到应用的转化率。但是,在此之前仍然需要进行调研。经过用户电话回访得出,用户在放弃使用签到的原因总结起来有两个方面:
功能性缺失:这个主要是在竞品的比较下,云之家的签到功能覆盖面相对而言会比较窄一些,相对复杂的场景没有覆盖到,导致用户在对比之下选择了竞品。
设计上的问题:这个主要体现在不知道怎么用、界面太复杂、找不到我想要的功能(但其实功能已经存在)这三个方面
针对第一个方面,在功能性的扩充上是一个持久战,需要花费很大的精力和人力去解决这个问题。但是第二个方面,却是设计可以比较方便解决的。所以,我们从第二个方面入手,去解决由于设计带来的转化率低的问题。
2、包含的角色
这也是一个非常容易回答的问题,只要设计人员对于产品的情况充分的熟悉,就能够很容易的回答出这个问题。
签到应用中包含的角色有:
管理员(团队)
签到管理员
老板
经理
员工
当角色过多时,我们需要分析角色的权限功能,看能否「合并同类项」。以上的 5 个角色,合并后变成了 3 种:
管理员:在这个场景之下,签到管理员和管理员的权限功能都是一致的,就是「能否对签到规则进行管理」,我们通过这一个功能来定义用户是否为「管理员」。当用户拥有权限的时候,会对其进行针对性的设计。
经理:以经理为代表的管理层人员,在这种场景下,除了基本的签到功能外,老板和经理都是对员工的签到情况进行查看和管理的角色,区别仅仅是查看范围大小的不同。
员工:被签到规则约束的角色,主要操作就是签到。
3、主要角色是什么
管理员、经理、员工,三中角色哪一种是主要角色呢?如果按照人数来的话,员工无疑是最多的,占据 9 成以上的比例。但是事实就是这样的么?
在进行调研以前会单纯地认为,同所有 toC 产品一样,签到应用也可能通过普通用户进行传播,并没有去思考更深层次的问题。但是,在接触用户才发现,toB 的产品传播模式跟 toC 的很不一样。
(1)由上至下的决策模式导致管理员才是重点
对于签到应用来说,能不能提高用户的转化率、甚至进一步带来新用户的注册,很大程度上依赖于决策人,他们的身份可能是 CEO、HR、信息部主管。即使身份不同,但是进入云之家的目的却是一直的:寻找能够满足自己公司的移动考勤方式。
当他们选定了软件工具后,背后带来的可能是成百上千的高质量用户。并且,由于企业软件的迁移成本的问题,这一批用户很有可能在接下来的很多年都会持续使用你的产品。拿下一个决策者,带来的是一个团队的利益。
(2)由上至下的使用模式导致管理员的操作才是重点
这一点则非常容易理解,如果没有管理员建立签到规则的操作,则不会有经理查看签到记录的操作、也不会有员工签到的操作。
综合这两点也就不难得出,管理员才是我们的主要角色。
4、角色的场景
在此需求的基础上进行了调研,在对数据进行处理和分析后:
使用云之家的流程
在外访过几家云之家签到的用户后,发现他们在使用云之家之前差不多都经历了同一个套路:
(1)公司有移动签到的需求
(2)大型公司:信息部负责任/人事行政负责人接到需求进行调研和试用;小型公司:CEO 自己进行试用
(3)进入应用商店/搜索网站寻找并下载几款签到产品
(4)管理员自己进行试用
(5)试用过后选择其中一款在公司进行小范围试用
(6)小范围试用通过后,全公司推广
所以,管理员作为公司当中第一个接触云之家的人,打动他就变得无比重要。从以上的信息,我们可以得出一点比较重要的信息,那就是:管理员进入云之家签到时,目的一般都比较明确。这个结论将会在后面的设计上用到。
第一次进入云之家的场景
在进行了用户调研以后发现,当用户面对一个陌生的软件的时候,第一次进入签到设置页面时,看到复杂的操作界面的时候会比较无措。
分析一下当前从签到切入进行使用的团队,流程大概如下:
产品决策人:老板(小型公司)、HR、IT。决策人带着需求进入软件,想要一个软件让他们能够打卡。
下载云之家
打开云之家
进入签到应用:看到一个大大的签到按钮,明白可以签到,进入设置页面,不知道如何进行操作,不知道如何让团队人员能够参与到签到中
选择放弃使用云之家
这是一个从下载到放弃的典型过程。
所以是哪里出了问题呢?不难看出,是签到设置的页面出了问题。旧的界面是很单纯的步骤的罗列,界面看上去非常复杂,主要是提供给用户的选择太多。我们将对这个页面进行重新设计。
5、分角色进行设计
抓住关键词
通过上面管理员的流程可以发现,管理员在进入云之家时,多数是带着目的进来的。我们准备采用引导的形式让用户尽快明白云之家的价值。
B 端的产品引导比 C 端产品引导重要的多,因为 B 端产品的用户在进行试用的时候,相对会更挑剔、严肃、目的明确。他们带着目的使用你的产品,希望能尽快地找到对应的方案,尽快看到产品的价值。在这种情况下如果还不能很快地让用户找到自己想要的功能、解决他的需求的话,用户极大可能就会放弃此产品了。
得出结论后,解决办法就比我们想象的容易了。新注册并新建立团队的用户,在进入签到的应用的时候,一定要充分展现产品的价值,拿下他。
各个公司的目的可能会不太一样,比如:朝九晚五的公司需要的是固定班制的考勤、门店型的公司可能需要的是多个签到点能够统一管理的考勤制度、工厂类型的公司或者服务型行业的公司轮岗的岗位特别多非常需要排班类的考勤方式。
每个公司对于签到的要求都不一样,当用户第一次进入签到的时候需要做到这一点:让用户找到想要的关键词,促进用户进一步试用的决心。
所以我们做了这样的引导页面:
只有管理员角色才可见(为了防止其他角色被打扰);
只在第一次进入签到应用的时候出现(用户在体验云之家的时候可能会进行重复性操作,引导页面表现完价值后目的已达到,不能够再阻碍用户的体验活动,需要保证之后操作的顺畅性);
信息尽可能简洁,一屏只展示一个信息。
第一次 or 第 N 次
在分析数据的时候还发现了另一个问题,当签到组建成以后,用户使用起签到的可能性大大增加。所以,体现了价值并不够,还需要让用户能够顺利地完成新建签到规则的操作。
旧的设计是一个步骤罗列的设计,这个是只考虑到了用户在完全适应了签到规则设置,第N次进入的场景。对于用户第一次进入设置页面的场景是不够重视的,而这个场景才是提高转化的重要场景。
新的设计是,当用户一个签到规则都没有建立的时候,做了这样几个改变:
(1)空白页展示签到组能够支持的功能,带入「弹性考勤」、「按部门考勤」、「新员工自动加入签到组」等关键词/短句
(2)空白页直接按钮引导用户新建签到组
(3)操作流程化,将扁平形式的信息转化为流程式的信息,让新建签到组更加顺畅
这个改变让签到的留存率提高了十几个百分点。
最后
总结一下,toB 产品基于场景的设计一定要在充分理解了每个角色后,进行设计。当发现需求目的与角色有强相关性时,区分角色设计就是势在必行的事情了。
*请认真填写需求信息,我们会在24小时内与您取得联系。