龙空技术网

从0到1,构建金融APP体验度量指标体系

人人都是产品经理 198

前言:

目前朋友们对“功能点计算公式”大体比较关心,咱们都想要学习一些“功能点计算公式”的相关文章。那么小编也在网摘上网罗了一些关于“功能点计算公式””的相关文章,希望兄弟们能喜欢,咱们一起来学习一下吧!

金融APP体验度量指标体系的构建对于用户和金融机构来说至关重要。准确的指标能够提供全面的数据分析,帮助金融企业更好地了解用户需求和行为,优化用户体验。那么金融APP要怎么构建体验度量指标体系?一起来看看作者的分析和总结。

用户体验,一直以来都是老生常谈的话题,它是互联网安身立命的生死线。没有用户会马上“死”,没有用户体验会未来“死”。单单针对这一点,大家没有任何分歧,可以很快达成一致。

不过,在企业实践中,相信大家一定会遇到:运营为了ROI,在新产品上线之初就会增加各种营销位,以获取收益。甚至有的运营,会非常粗暴借助话术精简,要说的模糊说,能不说就不说,以诱导用户点击。那为什么会这样子?是因为大家不考虑用户体验吗?

当然不是。作为产品经理在上线的时候,既要用户体验,还要考虑商业或者业务转化。那对于用户体验究竟考虑多少?这里面的“度”如何掌握?一直以来都是一个玄学问题,貌似仁者见仁智者见智,实则完全以“老板”的意志为转移。

所以,为什么要针对用户体验来建立度量呢?可大概总结如下:

一、 建立在统一度量衡的对话体系。这里面的关键词就是:度量衡、对话。让所有的人都在完全量化的标尺下对话,客观的说话。通过这样的方式,也可以大幅度减少无效的沟通,往复的沟通。正如现代管理学之父:Peter F. Drucker 的名言: “If you can’t measure it, you can’t manage it”。

二、 精准保障用户体验。因为有了度量,才有高低和好坏。通过核心的数据,才快速找到短板,借助优化手段,精准解决核心问题点。

三、产品和设计的收益可视化。在实践的产品落地中,因为有了体验的度量指标,大家可以更为放心大胆的去做体验优化的迭代工作,同时也可以直接同晒自己的优化带来的体验侧的收益。从意识层面,让用户体验和商业转化真正放在天平的两侧。

也正因如此,体验度量在实际落地的过程中,应当明确以下原则:

一、完整性。一套APP的体验度量,应当符合MECE原则。同时,也需要满足统计视角的信度和效度的检验。

二、可衡量。量化是体验度量的根本。

三、可扩展。体验度量与APP所处的阶段、企业的战略目标深度绑定的,度量指标需要阶段性的review、迭代。

根据实际操作的经验,完整的体验度量体系的构建流程如下图:

这块重点需要阐述的是:

没有任何一个体验度量指标体系,是可以一蹴而就的。正如互联网的发展一样,需要遵循小步快跑。因此,在构建之初要抓大放小。没有任何一个度量指标体系可以放之四海而皆准。我们在构建指标的时候,要裁剪成为适用自己的。没有任何一个人可以完全清楚具体落地的细节,所以构建体系的过程是一个螺旋化上升的状态。在呈现数据确定优化动作后,需要进一步回到起点,去完善整个指标体系。目标感,每个公司、每个团队在构建体验指标体系的时候,都会带着自己独特的使命。所以在这个生长的缝隙中,需要紧紧围绕自己的目标。正如:不忘初心,方得始终。

在整个流程中,模型构建至为关键。一个好的模型,可以非常好的支持目标的落地。作为整体的纲要,模型的构建阶段,是一个非常好的系统性梳理及思考的阶段。

首先,既要站在非常高的位置俯视框架的完整性,是否满足目标。同时,也在腰部位置进行了系统切分,把一个整体切成了自适应于业务的区块。最后,可以在底部位置进行了信号-指标-度量的动作细化。

目前,业内的体验度量指标模型,可总结如下:

对于C端产品来说,更多的会侧重在谷歌公司提出的HEART模型、1688的五度模型、优酷提出的DES模型,具体的分类见下图。

不过,从金融APP的体验来讲,还无法直接将上述的模型及指标直接拿来使用。需要针对金融APP从实际的用户体验设计、心智建设的角度出发,将上述模型进行裁剪使用。

作为一个金融APP来讲,不仅带有特定的金融属性,同时它的身上也带有TO C的工具的属性。因此,需要站在不同属性的角度去考虑。

首先,从金融属性来讲,用户对于钱这件事情是非常敏感的,安全感的心智是非常重要的。

此外,从TO C的工具属性来讲,用户是否能够在APP里面完成自己的任务、APP是否使用容易上手、符合用户的审美,具有同等重要的地位。

因此,基于已有模型及金融APP的特征,构建金融APP的体验度量模型——SPEED体验度量模型。

其中,将体验度量模型分为五大维度:

情感体验(Satisfied+Safety),将关注用户的满意度、净推荐值(NPS)和金融APP特有的安全感。性能体验(Performance),将关注技术底层,如:系统崩溃次数、启动耗时、卡顿率、页面异常次数效率体验(Efficiency),将关注APP内常见的任务完成情况,用户带有明确期望来到APP,一定会有明确的任务要去做。所以针对特定的任务,需要关注用户完成的效率。参与体验(Engagement),主要是关注用户对产品形成一定的行为粘性、愿意继续使用产品或功能。如:访问频次、访问时长、活跃用户数等设计体验(Design),主要在产品表现层来做考量,因此更关注易用性(易操作性、易学性、清晰性)、一致性。

简而言之,性能体验是万物的基础,是关键输入。情感体验是万物的升华,是远期输出。而内核由设计体验、参与体验、效率体验三者共同支撑。设计体验是因,参与和效率是果。用户会因为页面的美观、设计的合理性,想要尝试使用该功能。也因为越来越多的用户使用该功能,反向又会push更多的资源投入,进一步规范和约束设计的体验。

在拆分完成5个具体的维度后,接下来需要借助GSM方法论来进行进一步的拆解。

接下来,以效率体验为例,接下来阐述具体的子指标拆解、指标评分、权重设计。

效率体验的目标(GOAL):用户能够高效、准确的完成任务效率体验的信号(SIGNAL):完成率高、路径短效率体验的测量指标(MEASURE):定量视角(任务完成率、任务完成时长)、主观视角(费力度评分)

对于任务完成率和任务完成时间来说,需要再拆分具体的子指标。

这里还是要重点说下,在实践中,很多人会把任务和功能混到一起。这点我实在难以理解,不过还是再强调下。

对于金融APP来讲,一旦用户抱着明确的期望,如:还款、查账、借款等目的打开APP,她的操作路径往往非常明确,且有着明确的起点和重点。在这个路径上才会存在进入-停留-点击等漏斗转换。也只有这种路径才是一种任务。对于任务来讲,我们的核心目标就是在缩短操作路径,给用户非常快捷操作,飞一样的体验。其中,出现的任何卡点、交叉转化、营销等,其实都是干扰。

除了定量的指标外,还可以从费力度的角度来去衡量具体的任务完成的体验。费力度属于用户研究视角的范畴,大家自行搜索了解,在此无需过多赘述。

评分方面,任务完成时间、任务完成率的实践的假设在于正态分布。基于大量用户的任务完成的定量数据,我们可以把每项任务的完成率、任务完成时间可以得出下面的两个数值:

登录的每日任务完成率为E1、每日任务完成时间T1上一个统计周期内,登录日任务完成率均值E1mean、标准差Si

因此,E1min= E1mean-2Si、E1max= E1mean+2Si

基于这两个数值,可以根据下述的规则:

若E1<=E1min,则E1=0;若E1>=E1max,则E1=100,若E1min<E1<E1max,则E1= (E1-E1min)/(E1max-E1min)*100

进一步得出每次、每天的该任务的评分。同理,可得到其他任务的得分。

费力度的实践假设是李克特量表(这块也是市场调研领域的统计范畴,在此也不赘述),基于李克特量表的赋分转换方法可以得出登录这个任务的费力度评分。同理也可以得出其他任务的费力度评分。

最后,权重设计板块,权重设计在实践过程中,同样也有很多方法,比如:优序图法、层次分析法等等。接下来重点阐述下层次分析法的应用。

层次分析法,简称AHP,是匹茨堡大学教授萨蒂于20世纪70年代初提出的一种方法,该方法是指将与决策总是有关的元素分解成目标、准则、方案等层次,在此基础之上进行定性和定量分析的决策方法。

针对效率体验的话,基于AHP可以构建对应的分析模型如下:

基于该模型后,可以邀请一些专家进行重要性的评分。

通过需要进行一致性检验,需将CI和随机一致性指标RI进行比较,得出检验系数CR,公式如下:

一般,如果CR<0.1 ,则认为该判断矩阵通过一致性检验。

然后就可以得出:任务完成率、任务完成时间、费力度的权重=(0.387,0.327,0.286)

同时,也可以得到具体的子指标的权重。涉及数据敏感,在此不再赘述。

到这一步,我们基本上就把指标设计-分值-权重的框架确定结束。

最后的最后,再啰嗦几句关键点:

权重不可以直接套用。俗话说,家家有本难念的经,每个公司的发展阶段不一样,每个业务单元的目标都不太一样,所以权重自然会有所侧重点。不建议直接奉承“拿来主义”;指标和权重设计需要“渐近明细”。随着体验指标体系的设计、反馈、优化的循环落地,整体框架会越来越清晰。所以前期的看不清楚并没有大碍,坚持住先推推看。

本文由@铠泽 原创发布于人人都是产品经理,未经作者许可,禁止转载。

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

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

标签: #功能点计算公式