以微保/众安/今日头条为例,分析“用户画像”对互联网保险的意义


怎样定义保险产品的用户画像模型?用户画像对互联网保险意味着什么?拿到用户数据后如何服务于业务转化?来吧,看看互联网巨头们都是如何探索用户画像的。

全文思维导图如下:

一、几个标准的用户画像模型

以下提供几个标准的用户画像模型,基本都是在海量的产品和长期的实践中验证过并反复打磨的模型。各位就地取材直接使用即可。

1. 经典画像模型:羊群模型和人像模型

早期的用户画像重在写实,一般是根据产品本身的用户使用场景进行提炼

大体可以区分为2个大类:

A 基于社交属性的羊群模型

原始的社交场地就像一片未经开垦的草地,植树种草都是为了吸引羊群进入,一支头羊会带来一群羊,当羊的食草需求超过了草地的负荷,羊群可能会离开,而草地可能也会荒芜。这个场景形象地描绘了大部分社交产品的形态,比如:微博/微信等。

这与传播学中的“创新扩散理论”也有一定印证,早期的创新和使用者将承担KOL意见扩散的职责,成为头羊,吸引并带来大量的中后期进入者,即羊群。

我们类比如下:

B 基于电商属性的人物模型

在电商的场景下我们需要提取经典用户想象,以这个用户形象往外辐射。所以虽然现在巨头电商的商品重合度是较高的,你可以在京东淘宝买电器也可以在拼多多买,但最原始的经典用户形象则决定了他们最核心的用户群体和最基本的产品调性

我们类比如下:

结合

互联网保险产品因其特殊的属性,往往兼具了两者特色:

  • 一方面保险本质贩卖的是契约是产品(电商属性),这就像你在平安APP/支付宝APP买了一年期的医疗险;
  • 另一方面保险需要基于信赖感,尤其是在中国这一片大部分还对保险存在偏见的地域,基于“羊头”的引领将更好完成保险的销售,即:你更可能在信赖的人/平台/公司购置保险产品。

2. 用户标签体系

用户画像由标签库构成,PM着力通过不同场景和条件提取尽可能海量的标签,并对散乱的标签池进行加工提取和维护。

进而,每个用户基于个人的人口统计学+基础操作反馈,将得到各种专属的标签,比如:“男性”“三线城市”“成熟用户”“睡前活跃”“收入中等偏低”等等。

另外我们需要注意的是:不同标签在不同场景有不同含义

比如:某个保险公司接入电商平台,在用户购买某类型产品后提供对应的保险产品和服务,用户性别上的“男”和“女”,在电商是商品推荐逻辑,在保险却是可配置产品逻辑。

(图自网络,侵删)

3. 分布式智能画像阶段

用户画像模型是随着用户数据的完善和技术力量的强大持续优化的,当平安保险拥有了几亿的用户量后,再用粗放的标签库处理海量用户,则是对用户数据的极大浪费。

大型的产品,基本都会维护自身的全视角画像,比如:自然信息+社会信息+业务信息+特殊偏好。

不同的产品可能需要维护的360度全视角画像不同,需要结合产品的业务属性一起考虑。

(图自网络,侵删)

二、巨头们是如何探索保险用户数据的?

上文我们讲到,当产品已经到了亿级别,海量的用户画像原本就是最有价值的资源库,尤其是对于保险类产品。

互联网巨头们均先后下场瓜分保险这块沃土,处于金融监管的严格要求,通过收购或者入股的方式拿到牌照的仅有少数,如:腾讯/阿里/字节跳动等,而更重要的是如何在合规的层面上做更大的突破。

1. 今日头条对保险兴趣人群画像的初步探索(2017年)

早在2017年,今日头条已通过资讯获取方式的不同,探索了对保险有兴趣的人群画像的特质。而现在,大大小小的创新保险服务,如:蜗牛保险公司,深蓝保,白熊保等,均是通过生产原创的保险内容来直接获客完成付费转化,这份2017年的报告,或许对现在的保险内容原创还有一定借鉴价值。

A 人群基础属性

男性 >女性,北上川渝关注度领先全国

注意:因为这是基于今日头条APP上的调查,因此原本的APP用户画像的人口标签则有可能影响保险星群人群的用户画像。

B 资讯偏好

1. 话题:养老保险话题强势霸榜;购买保险的相关常识最易被收藏,在收藏排行帮上,车险话题强势霸榜;最易被分享的,则是购买保险陷阱类文章。

2. 品牌偏好:中国平安、中国人寿稳居前两名,泰康人寿关注人群有年轻化趋势,安邦保险在30岁以上人群中认知度更高。从地域分析,中国平安、中国人寿全国性覆盖优势明显。安邦、众安保险在超一线、一二线城市的品牌偏好度较高。央企、国企则在三四线城市的地域覆盖优势突出。

3. 热门话题top10:养老保险/医疗保险/失业保险/生育保险/工伤保险/财产保险/账户保险/车险/旅行保险/碎屏险。

4. 关注疾病top10:糖尿病/白血病/血友病/高血压/尿毒症/癌症/艾滋病/骨折/中风/痴呆。

2. 微保的用户画像调研(2018年)

微报是腾讯控股的保险平台,去年,微保联合腾讯用户研究与体验设计部(CDC)发布了《2018年互联网保险年度报告》,将保险成熟用户(即已经购买过复杂险的人群)分为四类:

  1. 高知新贵(33.9%)
  2. 思路清晰的奋斗青年(19.4%)
  3. 不爱计划的普通人(24.9%)
  4. 耳根软的传统大牌粉(21.8%)

该数据截止2018年6月,8.02亿网民中约有2.68亿人为保险成熟用户,占比33.4%。

而保险的高潜用户(指未来一年内有较为确定的购险计划的人群)规模估计2.17亿,未来用户(指没有较确定的购险计划用户)规模估计5.60亿。这2部分群体将是未来互联网保险公司继续深入的主要人群。

根据微保的这份报告,我们看到:高潜用户特征为“高学历、已婚、高收入”,对风险的担忧突出,除了保障外最看重保险的“强制储蓄”功能。而未来用户以两端用户(24岁以下和40岁以上)居多,超过半数未来用户没有在进行投资理财,因此对保险的投资理财属性更为期待。

3. 众安:技术方案产品化,输出海外

中国首家互联网保险公司,平安/腾讯/阿里联手的产物,2017年已在香港联交所主板上市。是业内第一家真正把“保险”+“科技”深度结合的互联网保险公司,通过收割长尾市场(如:退货运费险/碎屏险等)破局。

旗下的众安科技,基于成熟的自身互联网保险力量,已经可以对外输送保险相关的技术解决方案。以其智能营销平台为例:

其风控资深副总裁梁玉苹也曾强调:

“通过同时切入不同的消费场景,向用户提供保险服务来积累用户在不同消费场景下的信用标签,由此构建出全面而立体的用户画像。这些多场景、细颗粒度、实时动态的保单数据也是帮助用户触达到资金成本较低的传统金融机构的重要信用数据。

三、未来可发展方向

1. 互联网保险公司更精细化运营自身的用户模型

未来是用户数据时代,这意味着掌握的用户数据和画像越精确,可变现可改变的机会越多。相较于其他产品的不同,保险所收集的都是全真实个人信息及核心健康/财务数据

没有人会在买保险时填一份假数据,即便这是一份赠送的保险。

参考我们上述的各种用户画像模型,我们可总结如下:

内部画像(360全景画像)+外部行为数据=分类管理后精准触达/设计产品

  • 内部:客户个人信息,财务情况,健康状况,已购投保情况,每年保费支出,保险意识等等。
  • 外部:消费习惯,消费能力,人生状态,兴趣爱好等等。

2. 基于用户画像模型的精准营销

该营销多基于最开始的免费赠送展开

以微保等公司为例,0元免费赠送的短期险将获得用户的真实个人数据/财务数据/健康数据等核心数据,基于该数据更精准的营销方案已搭建好,就等着后期中长险的转化。

可营销场景包括:

1)人生阶段变化

毕业(就业险),结婚(家庭财产/重疾/账户安全),生子(寿险/女性专用险/养老金),儿女成长(健康险/意外险/教育基金/少儿意外),退休(住院医疗/防癌险)

2)人生状态变化:

账号被盗(账户安全/电信诈骗),买机票(航空/旅游意外),意外伤害(运动意外险),亲友得病(重疾/防癌/住院医疗)

3)场景结合:

网购/玩乐活动/乘坐地铁等互联网场景

概而言之,免费险种获取用户数据,以数据获取收益,如协助保险公司定价/精准锁定用户/增值服务等。

真实说明:世上没有免费的午餐。

3. 改变保险售前场景

A 产品需求:定制化的产品

传统的需求来源于保险公司主动开发(基于市场调研)+代理人或中介反馈+企业定制需求+第三方合作方定制。

有了精细的用户画像模型后,基于不同互联网场景,将产生大量新型需求及长尾需求。更“定制化”的产品将出现,而不再仅限于人寿意外健康险等,也不囿于碎屏和退换货险,再小众的保险需求也能找到对应的类需求用户群体。

该场景已在部分国外保险创新公司中出现,颠覆式保险模式。

比如:

Bought by many,基于社交吸引相同保险需求的人。

  1. 吸引类似客户(基于强大的用户画像模型库),签订统一保险条例。
  2. 根据需求定制化保险,完全打破传统产品结构设计/定价原则/销售方式,注重长尾和个性化。

B 产品定价革命

用户画像可与大数据等技术创新结合,使定价更精准,颠覆传统精算模型(定价因子+定价公式)。

保险的定价路径将随之改变:

从一口价(5%费率)——>精算定价(历史出现率为唯一定价因子)——>数据定价(多因子统计建模)——>大数据+用户画像模型定价(实时,动态的关联数据建模)。

高收益低理赔概率的产品将陆续出现。

注意,而该场景已在国外等多家创新公司实现,以车险为例,通过手机用户数据改变保险定价规则,提供增值服务。

比如:

Metromile,美国一家保险公司。

通过智能OBD(车载诊断系统)接入用户汽车,获取用户驾驶数据从而对车险重新定价,打破旧有统一化的定价模式。真正的“千人千价”。另外,还整合OBD和APP:APP提供终端服务,如停车场定位,汽车健康检测等增值服务。

Discovery,来自南非。

其健康险“健行天下”通过督促计划对客户健康行为干预,另外线上+线下数据评估用户健康状态,并提供奖励。这一模式在平安也早开始使用,App与你的每日运动及步数关联,鼓励用户运动并提供奖励。

4. 基于大量用户数据的核保模型

当前的核报模型已经可以基于“用户画像数据”+“案例经验”+“核保知识”提供及时准确自动化核保。

  • 其中,用户数据将形成评级体系,基于标准体系快速核保。
  • 另外,用户画像可与生物科技(即:基因检测+基因诊疗)结合,你的保险客户可能会骗你,但是他的基因数据一顶不会骗你。从而预知疾病及遗传病,防癌结合,补充完善了核保模型。
  • 此外,基于也出现了基于大量用户数据的反欺诈模型,数据来自:往期理赔case+央行征信+公安数据+芝麻信用等,反欺诈是保险公司风控的重点,也帮助了核保筛选剔除掉部分投保申请。

四、总结

互联网保险归根到底是对“人”的服务,而当社会生活中的“自然人”或者“集体”进入互联网保险世界,将标准化为一整套精准/极细颗粒度/360度全景式的“用户画像模型”,掌握这个模型,对互联网保险链接“人”的服务,将事半功倍。

参考数据

微保&腾讯CDC:2018年互联网保险年度报告

小米金融科技研究中心:用户画像在互联网保险领域的应用分析

今日头条:2017保险行业用户数据报告

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

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

怎样用数据分析方法应用KANO模型?

本文从数据分析的角度,重新解读如何应用kano模型。

一、 kano模型简介

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

图中的横坐标代表一个需求的实现程度高低,越往右越高。纵坐标代表用户的满意度,越往上越高。

这里的满意度从低到高就是从不满意一直到满意,在中间是没有不满意和没有满意的中间状态,也就是用户觉得理所当然的状态。

图上标出了五种不同类型的需求实现带来的用户满意度变化,分别是必备型需求、期望型需求、魅力型需求、无差异需求和反向需求

这五类需求,简单地说就是:必备型需求关心能不能用,期望型需求关心好不好用,魅力型需求关心是否惊艳,无差别需求用户根本不关心,反向需求关心的是这功能什么时候撤掉

二、 如何确定一个需求属于哪种类型?

KANO模型的应用目前最常见的是问卷调查法。

通过问卷分别询问用户,如果提供某功能时用户的感受,以及不提供某功能时用户的感受。用户答案和功能的分类对应如下表。

根据最终用户的反馈比例,选出分数最高的一类,确定其需求类型。这里面的计算方法比较复杂,不是本文的重点,有兴趣的同学自己百度。

通过问卷调查的方式进行需求分析有一个很大的缺点,问卷类型的数据容易出现幸存者偏差”的情况,即反馈的用户本身就有较强的反馈意愿,无法体现全体用户的真实情况。

不光如此,用户在回答问卷的过程中,得到的结果也并非可靠

说个案例:在过去,电视台统计收视率是通过日记调查法。所谓日记调查法,简单地说就是在被抽中的样本中留一本日记,可以是一张纸,卡片或者小册子。请样本家庭中的每一户成员及时填写一周自己收看电视的情况,内容包括观众姓名,收看的频道,收看的时间等等。然后每周反馈给调查人员。

随着科技的发展,机顶盒大规模地应用,调查人员可以直接通过机顶盒的数据获取用户收看电视的情况。调查人员发现,那些黄金时段的节目、知名度较高的节目,日记法的数据相比更精准的机顶盒的数据要高得多

出现这种情况的原因是因为人们在回忆自己看过的电视节目时,往往会放大那些名气更大的节目的收看时间。因此问卷法得到的信息往往是不准确的,而真实的用户行为数据却不会说谎

所以用数据来反应用户的行为将会更为准确,我们完全可以尝试通过用户行为数据进行kano模型的分析。

三、 利用数据应用KANO模型

由于大部分产品提升用户产品的满意度的目的主要是为了提升用户的粘性,表现在数据上就是产品的留存率提高。如果一个功能用户感到更加满意,那么这款功能的留存率必然会上升,或者当天的人均点次数上升。总之,用户会更有意愿使用该产品

那么根据页面的数据信息,我们可以大概推测出该功能目前所处的满意度水平,从而确定后续调整的优先顺序。这种方式相比问卷法最大的优势是信息的来源真实地反映了用户的实际反映,而不是被用户的情感因素加工过的二手信息。

不过通过数据的方式进行KANO模型的思考也有不足之处,即数据只能分析当前存在的功能用户是不是爱用,而不能发现用户目前并不存在的需求

如果该产品连基本的必备型需求都没有满足,那么在产品页面上没有用户的需求点,数据也就无法找出用户究竟需要什么样的需求。当然,我们可以通过其他功能的使用数据去发现用户的需求,不过这种情况下需要用产品思维去揣摩用户心理,有一定猜测的成分,数据不是决定因素。

另外数据也很难预测出魅力型需求

还是以iPhone为例,如果当时的诺基亚有用户的数据分析,那么数据必然可以得出用户有更大屏幕,更便捷交互的需求。但是这种方向如果没有配合上产品经理的创意,最终诞生的可能也只是更大屏的带触控笔的塞班机而已,这依然在用户的预期范围之内,最多只能算期望型需求

要想成为魅力型需求,需要数据提供方向 + 产品提供创意。在用户意想不到的方向解决用户需求才能成为魅力型需求。

这样的表述有些理论,我们看几个例子。我们首先看一下现状分析的情况。

例子一:某产品或功能的留存率非常低(多少算低,每个产品有不一样的标准),那么这个功能很可能处在下图中的蓝色框线位置。

此时用户的状态是不满意,结合kano模型进行分析,必备型需求只要基本满足即可以大幅提升满意度,那么很有可能是该产品的必备型需求的方向是错误的,用户根本没有这样的需求。

在找到用户的必备型需求之前,不管是调整当前页面的排版,还是增加相同类型的信息等都无法从本质上提升用户的满意度。因此这时页面改版最优先的方向是找到用户的真实需求。只有找到了用户的真实需求,那么改动带来的效益就是指数型增长的。

面对这样的产品状况,数据分析是很难帮助产品经理找到用户的真实需求的方向的。因为前面提到过数据分析的优势在于找到当前页面上用户感兴趣的功能,当前页面如果没有满足用户的需求,数据也无法告诉我们用户到底要什么。这时候就需要复盘产品经理当时上线该产品时的用户需求分析,找到问题所在。

再比如:

例子2:某产品或功能的留存率较好,那么这个功能很可能处在下图的蓝色框线位置。

在这个位置上,用户的必备需求基本得到了满足,再增加必备型需求的意义不大,我们需要找到期望型需求。

我前面提到过,期望型需求是必备型需求的升级版,那么找到用户最感兴趣的必备型需求,然后给出优化的方向就是该必备型需求的升级方向。

这个区域可以说是数据分析的舒适区,这类产品的数据不仅可以反映出大部分的问题,并且还能给出进一步的方向。

当留存率继续向上升时,产品已经相当成熟,用户达到了“满意”的状态,接下去可以开始尝试一些魅力型需求,这类需求无法从数据中得出,只能通过产品经理的创意进行试验,上线后再进行数据验证。

可以看出,KANO方法告诉我们数据分析在产品分析中的适用范围,在产品未找到用户的必备需求之前,数据分析是不太容易帮助产品提升满意度的。只有在产品找到用户明确的需求后,数据才能协助产品对产品进行优化。而在产品已经非常成熟时,数据也是很难找到突破口的。

数据最佳的发挥空间是把产品从四五十分提高到八九十分。太高或太低分数的产品,更多地需要创造性的产品思维。

 

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

题图来自 Pexels ,基于 CC0 协议

让沟通变得友好的用户故事地图如何创建?

让沟通变得友好的用户故事地图如何创建?

一、用户故事地图是什么?

1、瀑布模型

1

图(1)

在进入正题前,让我先来讲讲敏捷开发的诞生。在很早以前的软件开发中,并没有系统的流程管理方式,所以造成大量的人员、时间以及金钱的浪费。于是,在1970年,一个叫做温斯顿·罗伊斯的人提出了针对于软件开发的一种架构,叫做“瀑布模型”,他把大型软件开发分为:分析与编程,像工厂流水线一样把软件开发过程分成各种工序,流程如上图(1),之后,“瀑布模型”便沿用下去。但是随着时代的进步,人们的需求越来越多,软件迭代越来越快,“瀑布模型”的缺点暴露的也越来越明显:因为这种“一去不复返”的流程中没有迭代与反馈,应变能力差,所以对客户需求非常不容易适应,只要有一处修改,就意味着前面的工作都白做了。所以“瀑布模型”逐渐被淘汰,一种叫“敏捷开发”的管理新模式应运而生。

2、敏捷开发的优势

2
图(2)

敏捷开发避免了传统瀑布方式的弊端,主要是吸收了各种新型开发模式的“动态”特性,敏捷开发把关注点从文档转移到了开发者,管理方式也从工厂的流水线到团队的自我放松式的组织。在这种模式下,客户的需求可以随着进程的推进和实际情况而改变,团队输出的产品也是“最小可行产品”(MVP),即可以产生预期成果的最小发布方案。这样,就大大降低了成本,提高了灵活性,减小了风险,修改起产品也不需要全盘重做。所以,“敏捷开发”模式一直沿用至今。

3、用户故事地图的诞生

在以前,人们确定项目时总要写厚厚的几大本说明,好让开发人员对要做的东西有统一认识,但很快,这种充满条条框框的说明就被淘汰掉了,取而代之的是“敏捷开发”模式中的“用户故事”。当然,这并不代表人们不用再写那些恼人的文档,“用户故事”的创建依然要有文档作为依据,只不过文档的篇幅和格式已经大大优化。通过“用户故事”这一步骤,避免了团队成员的主观影响,可以客观的搜集整理大量用户需求,形成一个个用户问题、客户问题、公司问题的解决方案。

但是问题又来了,因为对于大型产品的开发,用户需求的内容会很多,像是一个庞大的地图,而“用户故事”擅长聚焦于构建小的特性,专注于小的细节就没法掌握整体,所以会带给人们困惑,不知何时才能完成开发和发布。不同的用户故事块也容易出现互不相匹配的产品部分,所以,为了避免这种管中窥豹的错误出现,人们改进了用户故事的处理方法,这种新的方法就是“用户故事地图“。下面,就来介绍如何创建用户故事地图。

二、如何创建用户故事地图?

1、前期准备

召集3-5名产品核心人员,可以包括产品负责人、项目经理、业务分析师、架构师,因为这些人代表了项目中的主要角色的看法,所以创建出故事地图后,在以后的全体计划会上就可以避免出现许多不必要的辩论。准备一面空出的白板,或一面墙壁,若干颜色和数量的便利贴,一卷彩色胶带。

2、整理创意框架

在正式开始创建用户故事之前,大家要在一起重新明确产品的创意框架,如:

  • 明确产品的目标是什么?
  • 能为用户解决哪些问题?
  • 公司、用户都能获得哪些收益?

然后大家统一答案,把明确的目标写在便利贴上,按照优先级排好顺序。

3、刻画用户画像

下面针对优先级最高的目标开始讨论,开始头脑风暴:

  • 产品面向的主要用户群是那些?
  • 产品的潜在用户群有哪些?
  • 谁会为我们的产品付钱?

基于这些问题,罗列不同类型的用户,讨论他们能从中得到什么好处,使用的动机,需要的功能等。精炼出若干类用户,制成“用户画像”卡片,卡片上的内容不用很详细,可以描述出基本特征即可,给每个类型的人群起一个人的名字,张三李四随意,目的是方便日后讨论,以后这个名字就代表这一类人群,再对每个用户做一下简单的诉求描述。最后,把这些写着用户类型的卡片,按照优先级排好,重要的用户放在上面,贴在白板上。

为了讲解的更加清晰,我把之前参与过的一个项目当做例子,演示“用户故事地图”的产生过程:这是一款大学生的微电影服务平台,我们的初衷是想要“大学生影视团队”和“有拍微电影意愿的人”在平台上对接起来,由于摄影团队所驾驭的影片难度低,需要的资金少,所以我们的目标很可能包括这些:“学生拍毕业季微电影“”学校社团宣传“”婚礼开场微电影烘托气氛“等等(下面我所绘制的用户故事地图只是想让大家看起来更直观,如果有不严谨之处还望大家见谅)。

3

4、大故事

从最重要的用户类型下手,这里依然使用头脑风暴,可以按照时间顺序挖掘,描述这个人在一天中使用产品的情景,“首先他会怎样,然后怎样,然后……“这些故事可以比较概括,如“用户注册”或“修改日程”,团队中安排专门的人负责记录把每一件事都写到一张便利贴中,按照时间顺序从左到右排好便利贴。当有遗漏的故事被挖掘出来时,可以随时调整卡片顺序。在这个过程中,做到了团队成员对所要做的东西达成了一致,产品创意精彩的细节部分被所有人所消化。

下图以其中的一个用户类型为例,写出大故事:

4

5、深挖细节

在完成第五步的“大故事”后,“用户故事地图”的框架已经结束,下面要做的是深挖细节。白板上的卡片已经出现了第一列,这些都是大故事,我们要在每一个大故事上深挖,写出包括的细节:

  • 用户在这一步具体要做什么事情?
  • 用户在这一步还有其他选择么?
  • 如何做才能更符合用户的习惯?
  • 出现问题时如何解决?

在完成以上等等问题后,记录员要把每一个小细节都写在便利贴上,竖向排列在“大故事”卡片的下面,如果有与大故事无关的其他细节,可以放在“用户卡片”的上方区域。到此为止,一个巨大的恐龙骨骼一样的“用户故事地图”出现在白板上,甚至,它可以占满一面墙。

5

6、划分MVP发布计划

在第五步我们所创建的“用户故事地图”涵盖了多个用户故事和叙事主线,包含了项目人员所有的愿景,但是它太庞大了,如果同时研发这些功能点,可能几年时间都做不完,“敏捷开发”也不允许我们这么做。所以,为了缩短项目周期,我们要在“用户故事地图”上进行MVP的内容筛选,把最重要的内容放在前面。横向移动用户目标,纵向移动深挖出的细节,然后用胶带做出分隔,如下面这个例子,在第一个版本中,我只开发标号为1的部分,随着软件的不断迭代,用户故事地图也不断向下推移。此时已经完成了这个产品的发布路线图。

6

三、说在最后

“用户故事地图”以直观易变的方式进行项目的良好沟通,大多数人看重的是地图的形式部分,横向是讲述大故事的部分,纵向是逐步的细化,但是最关键的是产品的构思框架,让团队成员对想要做出的产品一目了然,大大提高了团队之间相互协作的默契度,但是要注意的一点就是,功能的开拓要适度,否则这幅用户地图永远都画不完。正如《用户故事地图》的作者Jeff Patton所说:“如果不需要讨论,就不必绘制用户故事地图。”

 

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

如何基于数据快速构建用户模型(Persona)?

用户模型(Persona)是Alan Cooper在《About Face:交互设计精髓》一书中提到的研究用户的系统化方法。它是产品经理、交互设计师了解用户目标和需求、与开发团队及相关人交流、避免设计陷阱的重要工具。但在现实中,一般只有很少的成熟公司,产品经理、交互设计师或用户研究人员才会花时间构建用户模型,个人认为之所以这样,至少包含两方面原因:

  • 一个主要原因在于,按照传统方法构建用户模型的成本高、时间长,不是一般公司和团队所能承受的;
  • 另一个原因在于,传统方法对用户模型构建者的要求很高,尤其是对用户的访谈和观察,其中有很多的方法和技巧,不少产品经理不敢尝试,有些人尝试后并没有得到有用的信息,后面往往就不再做了。

本文将尝试提出一种基于用户行为数据的快速构建用户模型的方法。

用户模型构建的传统方法

Alan Cooper提出了两种构建用户模型的方法:

  • 用户模型:基于对用户的访谈和观察等研究结果建立,严谨可靠但费时;
  • 临时用户模型(ad hoc persona):基于行业专家或市场调查数据对用户的理解建立,快速但容易有偏颇。

方法1:基于访谈和观察的构建用户模型(正统方法)
继续阅读

几乎是最完美的用户体验模型——CUBI

我们都希望能做出引人注目的创意项目——能解决业务问题,同时通过有意义、有价值的体验吸引用户的项目。然而,紧缩的预算以及紧张的时间安排,都给创造真正新颖的设计、确定设计流程中的遗漏,以及充分考虑创造有效的用户体验设计诸多因素带来了挑战。

为了解决这些普遍性的挑战,笔者研究了现有的用户体验模型和框架,发现大多数UX图示是混乱的、无组织的、复杂或者过时的,这些对于设计师和客户都是毫无用处的。这就是为什么笔者决定自己创建模型。 继续阅读