Warning: Cannot modify header information - headers already sent by (output started at /www/wwwroot/woniupai.net/wp-load.php:19) in /www/wwwroot/woniupai.net/wp-includes/feed-rss2.php on line 8
卡诺模型 – 蜗牛派 http://www.woniupai.net 关注大学生创业和职场励志的媒体博客! Mon, 20 Jul 2020 06:28:12 +0000 zh-CN hourly 1 https://wordpress.org/?v=5.4.18 http://www.woniupai.net/wp-content/uploads/2016/03/cropped-skidmark-32x32.png 卡诺模型 – 蜗牛派 http://www.woniupai.net 32 32 如何完爆KANO模型的WSJF模型? http://www.woniupai.net/170513.html http://www.woniupai.net/170513.html#respond Mon, 20 Jul 2020 06:28:10 +0000 http://www.woniupai.net/?p=170513

卡诺模型KANO模型)是对用户需求分类和优先排序的有用工具,以分析用户需求对用户满意的影响为基础,体现了产品性能和用户满意之间的非线性关系。本文做从高级产品经理角度出发,如何完爆KANO模型WSJF模型

需求太多优先级怎么排?完爆KANO模型的WSJF模型

01. 优先级评估问题自检

先抛3个问题,如果你在评估需求价值、排优先级的过程中也有类似的困惑,继续阅读也许能找到答案:

  1. 我的团队有优先级评估机制,但总是和需求方扯皮
  2. 产品经理排好的优先级列表,经常被紧急需求打乱
  3. 业务需求工作量很大,我们根本没有人力做有用的需求

经过我调研,这3个问题,在B端产研团队、科技转型企业、业务主导条线中经常发生。

如果不能善加解决,你的产品就会做得很臃肿、琐碎,体验也会很差,如下图:

需求太多优先级怎么排?完爆KANO模型的WSJF模型

这种就是我说的臃肿型APP。

因为业务的权重,会新增堆叠很多功能模块,同时因为权重相同无法排出先后,就只能抽屉式平级罗列。

这样就导致整个页面很臃肿,每个功能的使用率都不高,产品的ROI很差。

并非是产品经理不知道这个问题,只是在企业的战略要求下,业务需求权重就是更高的,难以抽出人力和精力去做功能的整合、体验的提升。

但难,并不是没有办法。

长此以往恶性循环,总有一天产品体验会跌到谷底,影响正常业务发展,这是一个可以预见的后果。

我们假设用户满意度(受用户体验影响)是一个观测指标,即只要在60分以上,用户就能忍、不会流失。

那么如果你的产品当前满意度在60附近,你可以认真考虑一下重新梳理优先级、提升用户体验的问题了。

如何能够满足业务需求的情况下,又能让用户体验不受损伤,或长期持续让用户满意,是每个产品经理必须承担的责任。

而用户体验问题,在产品经理能力都不差的今天,往往就是因需求优先级评估不当而导致的资源排布问题。

02. KANO模型和四象限为什么不行

说到需求优先级,很多人会说KANO模型和四象限法,很遗憾这两个方法在实战中很难奏效。

先看看KANO模型的背景和先验条件(不提先验条件直接摆方法论的都是耍流氓):

KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具,以分析用户需求对用户满意的影响为基础,体现了产品性能和用户满意之间的非线性关系。

如上所述,kano模型只展示了用户价值,但用户需求是无限大的,所以不能用户要什么就做什么。跟着kano模型走,做出的产品叫好不叫座,公司很容易倒闭。所以KANO模型的问题在于:

仅仅衡量了产品功能对于用户的价值,而没有衡量对企业的收益和成本。

也就是说,只有当你的企业当前目标是提升用户满意度时,才适合用KANO模型来排优先级。

需求太多优先级怎么排?完爆KANO模型的WSJF模型

但很遗憾如上文所说,大部分企业的目标都是盈利,次要才是产品的用户满意度(比如某通公司的盈利产品是电话卡,所以配套的某通APP是作为支撑的产品,电话卡盈利是第一位,某通APP体验是第二位)。所以问题都是:业务需求强势,产品经理苦苦维护用户体验。

于是,在考虑企业盈利、用户体验双因素平衡的情况下,KANO模型不适用。

再说四象限法,问题就更大了。

需求太多优先级怎么排?完爆KANO模型的WSJF模型

四象限法仅提供了一个原则,那就是重要紧急的先做,不重要不紧急的后做。而最难的点恰恰在于如何评判重要和紧急。

很多团队的周报,都是把事项按照四象限来分,但分完了之后,大家会发现一大堆的重要紧急,而里面细项哪个更重要?哪个更紧急?没有人知道。

所以四象限法:只知其然不知所以然。再更细分的实战场景,就失效了。

03. WSJF模型怎么用

那么正确的适合实战的模型是什么?

跟大家分享一下我这半年尝试的成果,叫做WSJF模型。

WSJF即Weighted Shortest Job First,中文翻译过来是加权最短作业优先,看起来这个概念很晦涩难懂,但其实非常简单。

WSJF是算出来的一个比值,分子是需求的价值,分母是实现的成本,也就是说,经过WSJF模型计算后,先做的需求,都是价值高且成本低的。

那么分子的价值高如何计算?分母的成本低又如何衡量呢?

因为每个公司的情况不一样,要各位都能从这个模型中受益,我还得啰嗦一下,讲讲前因后果,大家才能因地制宜去使用。

我是怎么建构这个模型的呢?

这几年和业务斗智斗勇(不是,互相帮忙)磨出来的。

第一步我把所有被插需求、被压紧急需求、已排期需求被调整优先级的理由整理了一下,大致如下(你也可以整理你们团队自己的):

  1. 老板要求
  2. 某某重点项目需求
  3. 已经承诺上线时间
  4. 关联团队资源到位就差我们配合了
  5. 积压很久了
  6. 功能要迁移下线了
  7. 用户骂街了
  8. 人情要帮帮忙

聚类分析之后发现,无非是4个维度:老板、战略、商业、体验。

老板大于战略,因为老板其实是把控核心资源的决策层,战略是老板决策的结果;

战略大于商业价值,假如你有一个商业价值很好的项目,但和目前战略相悖,也建议不要落地。这种情况下要么升级老板改战略,要么换公司,一艘大船必须水手往同一个方向努力,才能乘风破浪;

商业大于体验,目前大多数公司处在变现阶段,音乐视频软件加广告、快递柜收费,一味满足用户体验的产品很难盈利。

具体落地到优先级PK时,大概原则是:

  • 老板维度:哪个官大听哪个的。这不是政治原因,而是,第一,高层级老板担下属责任,第二,高层级老板信息比下层级更多。如果一个领导者掌控信息和资源,也对团队负责,那么他的需求也许是现阶段团队智慧之下的最优解,虽然大部分人没法理解。想清楚这个问题,需要产品经理对老板基本的同理心,想不明白这两个逻辑的同学自己去面壁。
  • 战略维度:战略级重点项目优先做。对的事情有很多,不代表都要去做,企业应该只做符合自己发展方向的事情,否则会因为各团队条线方向不同,无法发挥协同作用。
  • 商业价值:满足kpi的,对业绩有帮助的优先做。这是衡量业务需求价值的根本,如果一个业务需求不能完善地论证出价值,那一定是没想好或者形式主义的结果。产品经理要做的就是帮助那些没想好的业务需求,完善成产品方案;同时甄别那些形式主义的业务需求,去伪存真。
  • 用户体验:用户骂街的,严重影响满意度以至于业务开展不下去的优先做,切不可大动干戈刷存在感。很多产品经理喜欢做前端优化和改版,但改版对于用户一定是先伤害再受益的,因为影响用户习惯也是一种满意度下降,所以改版的timing很重要,一定要和业务节奏协同考虑。

这样我的WSJF模型分子就是:

  1. 老板分:从高到低10分满,权重为4
  2. 战略分:从高到低10分满,权重为3
  3. 商业分:从高到低10分满,权重为2
  4. 体验分:从高到低10分满,权重为1

这样一个需求的价值满分就是:100分。权重比值的计算可以用过往需求来估算,一般不需要特别精确,只要符合目前公司的价值观即可(如果是体验第一,那就体验权重高;如果是推重点项目,那就战略权重高)。

具体分值可以根据实际情况来定,比如CEO10分、10大重点项目10分、用户反馈问题超3次10分等。

分母的计算相对标准且简单,一般是用作业长度。

比如A功能价值100万(每个月)需10个月完成,另一个B功能价值20万(每个月)需1个月完成,在人力仅允许同时做一个的情况下,先做哪个?

通过WSJF模型计算,前者每个月价值是10万,后者每个月价值是20万。如果先做第一个,意味着我们只能在10个月后,拿到20万的收益,那么开发A功能的成本要计算上延期B带来的价值损失。

所以衡量下来,还是先做B要更划算一些。(当然如果你可以评估A功能价值和人力成本后,向老板申请加人力编制同时做A和B,也是很合理的解决办法,但那就不是优先级问题的讨论范围内了)

综上所述:WSJF模型在评判价值时,因为考虑到了决策、战略、商业价值而比KANO模型更完整,同时因为更加可量化,比四象限模型更加实用。

如果觉得复杂,可以用一个简单的口诀估算:

  • 先评估老板,老板指示一票否决
  • 同老板看项目,项目重点优先做
  • 同级项目看价值,评估紧急程度、ROI和量级
  • 最后看体验,核心功能和影响面大的优先

04. 说在最后

回答一开始的3个问题:

1. 我的团队有优先级评估机制,但总是和需求方扯皮

答:你的优先级评估机制不全面,没有涉及需求方的诉求的因素。

2. 产品经理排好的优先级列表,经常被紧急需求打乱

答:你的需求模型没有涵盖大家都认可的、全部影响优先级的因素,如果足够权威,比如老板会议纪要、专项任务等,不会存在扯皮的情况。

3. 业务需求工作量很大,我们根本没有人力做有用的需求

答:需要在现阶段人力和产能的基础上,评估产能瓶颈和需求价值,给老板预期or申请资源。

最后,一个好的需求价值评估模型,能够帮助产研团队省掉数不清的沟通扯皮,也能让整个产品良性发展,研发资源利用率更高。

但最好的方法和模型,永远是根据自己所处的条件分析改造得来的,而不是用已有的成型方法。

如果我的案例能帮助大家认知并思考到这个问题,相信每个人都可以不断拆解聚类评估需求价值过程中遇到的问题,得到更适合自己的企业和团队的评估模型。

方法诚可贵,思考价更高。

本文作者: 产品之术,其版权均为原作者所有,文章内容系作者个人观点,不代表蜗牛派对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。

免责声明:本文版权归原作者所有,文章系作者个人观点不代表蜗牛派立场,如若转载请联系原作者;本站仅提供信息存储空间服务,内容仅为传递更多信息之目的,如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈!

]]>
http://www.woniupai.net/170513.html/feed 0
浅析豆瓣APP中的影评详情场景设计 http://www.woniupai.net/166995.html http://www.woniupai.net/166995.html#respond Wed, 15 Jul 2020 09:52:42 +0000 http://www.woniupai.net/?p=166995

作者就以豆瓣APP的影评详情场景为例,解读它有哪些能够让用户兴奋的亮点,并且引申出了卡诺模型,为我们做了详细地介绍。

我认为APP豆瓣中的这种设计不太好
今天给大家带来的是豆瓣中的一个案例,场景如下:

当用户在豆瓣查看某部电影的影评详情时,页面中有一个【可播放全篇】的入口,用户点击后就可以看到能播放本影片的APP了,例如爱奇艺、优酷。

我认为APP豆瓣中的这种设计不太好

点击下面的按钮后就可以直接跳转到对应APP中,并直接进入本电影的播放页面:

我认为APP豆瓣中的这种设计不太好

一、案例的亮点在哪里

  1. 符合豆瓣用户的使用场景,用户在豆瓣查找高评分电影时,如果找到了心仪的电影那么此时是抱有【看全篇】这个目的的,这个功能恰好满足了用户的目的。
  2. 缩短了用户的行为路径、减少了操作成本,在这里用户只要点击3次就可以进入播放全篇片的页面,如果没有这个功能的话,则需要返回手机主页-寻找某视频APP-输入影评名-搜索-点击搜索结果,共5步才能完成目的。并且还有可能因为这个视频APP内没有这个电影而找不到播放渠道。
  3. 可播放全片的右侧直接显示了可播放此电影的APP,用户无需点击展开就可以知道播放渠道。就可以知道自己手机中是否有其中一个APP,如果没有的话用户直接返回寻找其他电影,减少了无效操作。降低了用户的失望情绪。
  4. 展开后(上面第二张图),用户可以知道在对应产品中播放本电影的条件,是VIP可免费观看?还是VIP需要付费观看?或者是无需VIP就能看?这里的好处与上面第3点是类似的,如果用户进入了某APP才发现自己没有VIP看不了这个电影,也是做了很多无效操作,会产生负面情绪。并且在播放渠道下方还显示了用户是否已经安装该APP,避免用户还要去下载。
  5. 如果这部电影不能在其他APP中看全片的话,豆瓣同样做了很有意义的设计,如下图,当这部电影不能在其他APP中看全片的时候,会引导用户订阅提醒,当本影片可播放时再给用户推送通知,这样就提高了用户活跃度,也减少了用户的失望情绪。
  6. 这个功能如果按照卡诺模型进行分类的话,是属于【兴奋型需求】,也就是说当产品中没有这个功能时,用户不会产生不满意的情绪,但是当产品中有这个功能的时候,用户的满意度就会有极大的提升,是由惊喜和超出预期产生的极好的用户体验。

但是要注意的是,需求的类型是会随着时间变化的,今天的兴奋型需求在几年之后可能就会变成基本需求。

例如饭店里有WIFI在五年前可能是一个兴奋型需求,用户遇到了会十分惊喜,但是在今天几乎每一家饭店都有WIFI了,用户已经习以为常,不再会有惊喜和超预期的感受,所以饭店里有WIFI就变成了一个基本需求。

即这个功能存在用户会认为理所当然,这个功能不存在用户的满意度会有所下降,甚至认为产品的功能不完整。

以上就是今天案例分享了,如果你需要了解更多卡诺模型的知识,可以阅读以下内容,详细了解卡诺模型中5种不同需求类型的特征和区分方式,我会以微信中的功能为例把每一种需求都举例说明。

二、卡诺模型

卡诺模型,是东京理工大学教授狩野纪昭发明的对用户需求分类和优先排序的有用工具,以分析用户需求对用户满意的影响为基础,体现了产品功能和用户满意度之间的关系。

1. 它将产品需求分为五类

1)基本(必备)型需求

也称为必备型需求、理所当然需求,是顾客对企业提供的产品或服务因素的基本要求,是顾客认为产品“必须有”的属性或功能。做得好无太大的功劳,但是没有的话,用户会感到失望。

比如:公司提供免费午餐或者餐补或者食堂,有就满足了基本需求,没有会有点失落。

2)期望(意愿)型需求

也称为意愿型需求,是指顾客的满意状况与需求的满足程度成比例关系的需求,此类需求得到满足或表现良好的话,客户满意度会显著增加。当此类需求得不到满足或表现不好的话,客户的不满也会显著增加。

比如:如果是个健身爱好者,酒店有健身器材,会更加高兴,如果没有这类器材的酒店,下次可能就不会入住。但若不是个健身爱好者,则无所谓。

3)兴奋(魅力)型需求

又称兴奋型需求,指不会被顾客过分期望的需求。

对于魅力型需求,随着满足顾客期望程度的增加,顾客满意度也会急剧上升,但一旦得到满足,即使表现并不完善,顾客表现出的满意状况则也是非常高的。反之,即使在期望不满足时,顾客也不会因而表现出明显的不满意。

比如:在买核桃,打开包装后发现里面还附送了开壳器和湿纸巾,惊不惊喜,意不意外!

4)无差异型需求

不论提供与否,对用户体验无影响。是质量中既不好也不坏的方面,它们不会导致顾客满意或不满意。

比如:航空公司为乘客提供的没有实用价值的赠品。

5)反向(逆向)型需求——Reverse Quality

又称逆向型需求,指引起强烈不满的质量特性和导致低水平满意的质量特性,因为并非所有的消费者都有相似的喜好。

许多用户根本都没有此需求,提供后用户满意度反而会下降,而且提供的程度与用户满意程度成反比。比如:一些顾客喜欢高科技产品而另一些人更喜欢普通产品,过多的额外功能会引起顾客不满。

我们在设计一款产品时可能会存在很多个需求可以做,这时就可以根据卡诺模型对需求的分类排定优先级,顺序为基本型 > 期望型 > 兴奋型 > 无差异型 > 反向型。

如果我们在工作中同时接到了很多个需求需要做,那么就可以直接询问产品经理或领导,哪些需求优先级最高。如果对方说都要做。那么我们就可以自己对需求进行分类,拿过去跟他讨论,哪些需求是基本型,那么这个比较重要,咱们可以先做这个,按顺序来。

当然一般的产品经理都懂这个,这样跟他交流是不至于让设计师那么被动,也是从专业上去让决策更加科学。

我认为APP豆瓣中的这种设计不太好

2. 五种需求在微信中的例子

1)基本需求

聊天、发送表情、修改昵称,类似的功能简直太多了,也很容易理解,就不过多解释。

2)期望需求

修改微信号,这个功能也是微信最近才推出的,已经被用户呼唤了多年的期望需求。

要注意的是虽然这个功能推出后用户满意度极高,但是由于这是用户能够想象到的,并且是在没有的情况下用户会不满意的,所以依然属于期望需求。

3)兴奋需求

已撤回的消息可以再次编辑,这个功能是我前几天亲身遇到的,某天我在写了1700字的工作总结发送给我们的美女leader时,不小心发错了发给了其他人,于是马上撤回了消息.

但是由于我是不是复制粘贴的,而是从一个文档直接剪切过来的,所以这1700字在两处都无法再找到了,当时真的是差点原地爆炸,还好微信有再次编辑已撤回的消息的功能,才保住了我两个小时的工作成果。

4)无差异需求

无差异需求对用户的价值是十分小的,像微信这样的大神团队几乎不会做这种需求,所以我只能虚拟举例来说明,例如在微信中添加一个【自动补全邮箱后缀名】的功能就可以算作无差异需求,因为大多数输入法都会提供这个功能,所以微信添加与否对用户来说基本没有影响,所以应属于无差异需求。

5)反向需求

这种需求会引起用户的强烈不满,像微信这么谨慎克制的产品真的是很难找到。

这里我们限定一个极端场景来举例:我在度假时查看了领导要求加班的微信消息,此时如果微信提供了【消息已读未读状态】这种功能,就属于一个反向需求。

本文作者: 设计的威严,其版权均为原作者所有,文章内容系作者个人观点,不代表蜗牛派对观点赞同或支持,未经许可,请勿转载,题图来自Unsplash,基于CC0协议。

免责声明:本文版权归原作者所有,文章系作者个人观点不代表蜗牛派立场,如若转载请联系原作者;本站仅提供信息存储空间服务,内容仅为传递更多信息之目的,如涉及作品内容、版权等其它问题都请联系kefu@woniupai.net反馈!

]]>
http://www.woniupai.net/166995.html/feed 0