你要考虑下沉用户啊!3个月获600万用户的小心得

本文转载自公众号见实
小影是一款短视频制作神器,也是知名的短视频社区,在全球拥有 5.5 亿用户。在传统印象里,制作视频是一个非常复杂的过程,借助APP,小影已经将这个过程压缩得非常简单。现在他们更进一步,用小程序进一步将视频制作的门槛拉低,并在短短 3 个月内吸引到近 600 万新用户。

与见实报道过的她Face+、黑咔等团队类似,小影在小程序端提供的功能也走了极简路线,以匹配平台特征和增量用户的实际需求。不太一样的是,小影是已在 App端取得过巨大成功的产品,拥有初创团队不具备的先验优势,尽管他们切入小程序的时间点相对晚,但谋定后动的结果是增速稳定,产品路径也十分清晰。**(小编注:本周四见实大神局沙龙,要不要一起?)**

现在,小影在小程序端的用户新增每天超 10 万,主要以三四线城市、超过40岁的用户为主。这个用户画像和原有用户有着巨大差异,也体现出了微信小程序的特点。新增用户的来源仍是分享本身,在小影,每2个用户中就会有1人分享,分享率达到50%。这是很多产品不具备的超高特性。是工具本身带来的优点?还是怎么做到的?

见实和小影创始人韩晟长聊了下这个问题。一起:

 

**如下,****Enjoy****:**

小影

**见实:****小程序在你们的产品布局中,处于一个什么样的位置?**

**韩晟:**小程序的用户生命周期和 App不一样, App更偏重留存,而小程序获取用户主要是靠微信群,传播才是核心指标。小程序是我们通过微信生态触达下沉用户一个很好的产品形态。

**见实:****考虑到产品特性,你们的分享数据应该非常不错,有多好?**

**韩晟:**目前制作完的用户分享率在50%左右,也就是每 2 个制作,就会有用户把内容分享给好友。

**见实:****小影的总用户量有多大,小程序现在有多少用户?**

**韩晟:**小影App有5.5亿全球用户,截至 2018 年年初,小影 APP 在 35 个国家 App store 的 图片、视频分类榜排名第一,在 60 个国家 Google Play 的传媒、视频分类榜排名第一。

小影小程序累计用户已经突破500万接近600万。

**见实:****目前的增长怎么样?怎么做到的?**

**韩晟:**小程序每天新增用户超10万,我们每天的视频制作量最近也超过了10万。视频制作量和新增用户是相辅相成的,目前的视频制作量由于我们丰富的模版数量、优质的质量,用户喜欢做, 而且做完愿意分享,而分享又为我们带来了新的用户、新的制作、新的分享。

**见实:****怎么理解微信生态中的传播?**

**韩晟:**小程序在微信生态里,微信提供了很好的传播渠道,我们获取用户主要是靠微信群,传播是核心指标。但是传播我们不是靠红包刺激或者其他和产品核心无关的,我们关注产品本身,让产品有传播属性,根据这个目标去做产品迭代和运营。

**见实:****小影在小程序端的主要人群画像是什么?你们针对这些洞察做了哪些工作?**

**韩晟:**以三四线城市、超过40岁的用户为主,女性偏多。而小影App在国内的用户则大多都是25岁以下的年轻人。

在app端我们提供了专业的视频剪辑工具,而在小程序端我们要降低用户的使用门槛,增加他们的乐趣。更多是提供视频模版的形式,让用户可以快速生成视频,且这个视频是好玩的,可以给用户提供乐趣的。

**见实:****小影的小程序是什么时候上线的,负责这个产品的团队是什么结构?**

**韩晟:**8月底上线,团队基本控制在10人以内,主要以技术为主。

**见实:****你们在小程序端核心提供什么功能?现有的模板中,哪一类是最受欢迎的?**

**韩晟:**我们希望帮助用户产生表达自己或者值得分享的视频,现有模板中以场景类的早安,晚安最受欢迎,点击率和制作率都是一般素材的3倍以上,还有就是祈福、祝福类、提醒类的模版,比如天冷加衣、问候群友等。一个好的模版,可能会有上万人使用,这上万人又会给带来数万新用户。

图:祝福类模板在这里更受欢迎

**见实:****从上线到现在,你们在小程序端进行了哪些重要迭代,这个过程是怎样的?**

**韩晟:**做了两个大的迭代,第一次是设计思维迭代,从 App设计思维到小程序设计思维,像 App关注更多的是留存,所以小程序刚做时我们也关注留存,但是这个生态又不可能达到 App那样的留存,后面会更多关注分享,产品和运营也会跟着相应做转变。

第二次是用户思维迭代,向下沉用户思维靠拢,简化视频的制作流程。我们的团队会做调研、分析数据,越来越了解下沉用户,发现他们更需要的是简单直接,连文案都要直白。这是两次大的转变吧,转变好思维,事情做起来就比较顺。

**见实:****经历过哪些试错的过程,给你们带来哪些新的理解?**

**韩晟:**整个团队对小程序的理解和对我们用户的理解也是不断变化的。我们的试错大到理念,例如注重视频质量还是简化生成方法的讨论,小到文案的简化纠正都是有的。

举个例子,我们在制作流程中,做过一次相对失败的改版,将制作流程复杂化相应出来的效果也有提升,但是导致了数据的下降。后来在调研中,我们了解到,对于复杂的流程,下沉用户反馈用不懂,他们更关注的是,如何快速看到效果。所以我们需要做平衡,而不是从自己的角度出发,要多熟悉下沉用户的使用习惯。

**见实:****现阶段你们如何做增长?**

**韩晟:**我们的驱动增长是多元化的,运营驱动支持用户喜欢的素材类型,去找更多素材的场景,比如节日场景的素材。

产品驱动增加分享动力和支持更多素材玩法。数据上我们会做a/b Test和详细的数据监控、分析,为增长做服务,比如我们在用户制作后的分享标题已经做了几十版的测试,刺激新用户的点击。

**见实:****如何获取收入?**

**韩晟:**目前还不焦虑做变现,更多的还是先把产品做好,服务好用户,几年前 App也很难变现,但是现在大家都不疑虑 App的变现了。App时代的经验在小程序也不一定有用,先做好产品吧,变现是水到渠成的一件事。

**见实:****小程序端上线后,对你们 App 的增长有什么影响?**

**韩晟:**对 App的增长不是我们做小程序的初衷,我们更多的还是希望服务好下沉用户,前面也提到了用户画像差别较大,没有必要让微信生态的用户一定要转到 App端,这个迁移成本还是很高的。

**见实:****你们还做了一些其他的矩阵产品,出于什么考虑,之间有什么样的联系?**

**韩晟:**主要是基于垂直场景做下沉用户的尝试,小程序的开发成本相对来说较低,试错成本较小,在 App时代,「小影音乐相册」和「天天拍一拍」可能会做在一个App里。

但在小程序时代,还是适合做成多个独立的小程序。每个小程序去解决一个特定的需求。毕竟用户打开这个小程序是为了满足特定场景的需求。如果在一个小程序里面做太多其它功能没有意义。矩阵小程序之间可以通过互相跳转来导流。

产品设计的多和少:如何找到灵活性和易用性之间的平衡点

本文转载自公众号一鸣说 作者一鸣 十二赞产品经理
摘要:本文阐述了什么是产品的「灵活性」和「易用性」以及相关的产品设计原则。

1 前言

在设计功能模块的时候,产品经理经常需要思考的一个问题是:「这个功能是否需要有用户自定义的部分,以及哪些内容开放给用户进行自定义。」这是什么意思呢?一般来讲,我们确定了功能及流程之后,很多内容都会「固化」,而有些内容会开放给用户进行「自定义」。哪些内容进行固化,哪些可以进行自定义,这是一个很大的命题,也是本文探讨的重点。

2 用户满意度

在开始讨论这个命题之前,我们先引入一个概念,即「用户满意度」。为什么先要提到用户满意度呢,因为这是后面判断那种方案更可行的依据。产品无论是新增功能还是减少功能,无非都是为了「取悦用户」,让用户「用得爽」。能够解决用户的问题,让用户用得爽的产品就是好产品,而不是功能多的才叫好产品。

2.1 什么是「用户满意度」

我们在互联网产品中提到的提升「用户满意度」和服务业中提到的提升「顾客满意度」的策略并不相同,在服务业中,我们可以因人而异,给每个人提供不同的服务,让所有人都满意。但是互联网产品却很难做到,一旦确定了产品的方案,必然有一部分满意,一部分人不满意,我们没有办法做到给每一个用户设计一款单独的产品,因此我们能做的是,确定的产品形态能够让尽可能多的用户满意。用户满意度中的「用户」,不是确定的某一个用户,而是所有用户的总和,这是一个泛概念。

2.2 如何计算用户满意度

尽管「用户」并不是明确的某个人,但是实际上这里说的「用户满意度」是一个所有用户「满意度」的一个平均数。例如可以采取十分制的策略(0分为很不满意,10分为很满意。)或百分制,所有用户给产品或产品中的某个功能打个分,计算得分的平均数,就是我们所说的「用户满意度」。

上面提到的计算策略是一个比较直观的办法,但是实际上,这几乎不可能做到,原因是:(1)邀请所有的用户打分几乎是一个不可能完成的大工程。(2)每设计一个新功能就让用户打分,过于频繁,会引起用户反感。

因此,我们需要一个策略来估算「用户满意度」,用户之间有共性和个性,我们可以对用户进行分类,用类别来表示具有同一个特征某一类用户。

3 用户分类

我们在产品设计之初,就会制定「产品定位」,以及与之相伴的「用户定位」,在toB类产品中,根据与「用户定位」的契合度,我们将用户分类为:头部用户、中部用户和长尾用户。

3.1 头部用户

「头部用户」是最与用户定位最为契合的一部分用户,他们有明确的产品使用目标,清楚地明白他们使用产品是为了解决他们存在的什么问题,他们是产品使用的「熟手」,使用产品过程中几乎不会遇到障碍。其中部分用户可能还会积极反馈使用中遇到的问题以及改进建议,是对产品良性发展具有比较大价值的一类用户。一般头部用户所占用户比例大概在总用户数的10%左右。

3.2 中部用户

「中部用户」是所占比例最大的一类用户,一般占比在80%左右。中部用户一般基本符合产品的用户定位,基本会使用产品,偶尔会遇到障碍,有些能够自己解决,有些需要在帮助下解决。

3.3 长尾用户

「长尾用户」是最让产品经理头疼的一类用户。前两类的头部用户、中部用户都有自己的共同点,长尾用户指的是剩下的几乎找不到共同点的10%的用户的集合。如果不加注意,产品的节奏很容易被长尾用户带偏。他们可能不是我们的目标用户,但是由于某些原因发现产品的某一个功能,刚好能够解决他们的某一个问题,于是着手使用产品。这一类用户的特点就是经常会说:「如果你们的产品再加个XX功能,我就会用你们的产品了。」比如说找到一个博客系统,告诉产品经理,如果你们的博客系统支持多个用户发言,我就用了。实际上,他是需要一个论坛系统。遇到这种情况,如果不加以区分,真的很容易被带偏节奏,需要产品经理拥有老到的需求挖掘能力,才能分析其中的伪需求。

3.4 补充说明

实际上,用户分类远没有上面说的这么简单,这里只是粗略地进行了分类,目的是辅助文章进行说明。由于用户分类不是本文的重点,所以仅做简单介绍,如需详细了解用户分类的知识,请关注后续文章。

4 什么是产品的「灵活性」?

产品的「多」,指的是产品具有对用户具有更高的灵活性,用户具有更高的「自由度」,能够满足更加复杂多变的需求场景。我举一个例子,依然以「商城系统」为例。

4.1 需求场景的多样化

以商城系统最为基础的「商品模块」中的商品展示策略为例,我们知道商品有个「上架」和「下架」功能,简单讲,上架就是可以买,下架了就是不能买,但是你知道这个功能背后对应的需求场景吗?实际上,涉及的环节包含了以下三个环节:

(1)商品列表页是否展示该商品。

(2)能否进入商品详情页。

(3)能否对该商品加入购物车或购买(下单)操作。

经过一定的用户调研,会发现仅仅就这个环节就存在以下需求:

(1)商品在列表页展示,图标显示不能买,无法点击进入商品详情页。(相当于商品预告)

(2)商品在列表页展示,可以进入商品详情页,可以加入购物车,但是不能下单。

(3)商品不在列表页展示,只能通过分享链接进入商品详情页。

(4)有的商品要去掉「立即购买」按钮,只能加入购物车再进行结算。

(5)有的商品不能「加入购物车」,只能立即购买。

(6)商品详情页只能通过列表页进入,通过分享链接进入商品详情页无效。

…………

4.2 场景剖析

仅仅这最常见、最普通的三个环节,就存在着几乎数不清的用户需求,我们经过分析,如果要满足以上用户需求,至少要设立以下几个开关:

(1)商品是否在商品列表页展示。(Y/N)

(2)能否通过通过商品列表页跳转商品详情页。(Y/N)

(3)能否进入商品详情页。(Y/N)

(4)能否通过分享方式进入商品详情页。(Y/N)

(5)是否存在「立即购买」按钮(功能)。(Y/N)

(6)是否存在「加入购物车」按钮(功能)。(Y/N)

(7)商品能否被下单。(Y/N)

4.3 灵活性

只要我们在产品逻辑中加入这7个开关,并且开放给用户设置,就可以满足所有的用户需求,支持他们特定的需求场景。功能的灵活性指的是能够满足尽可能多的需求场景。很显然,如果我们需要这个功能模块具备最大的灵活性,这7个开关一个都不能少,少了任何一个便会使其中的某些需求场景得不到支持。增强产品的灵活性很简答,就是「加开关」,增加用户可自定义的内容。

5 什么是产品的「易用性」?

「易用性」指的是尽可能大地降低用户实现特定产品目标的「操作成本」,这里的操作成本不仅包含手动去点击鼠标和敲打键盘等真实操作,还包含了用户的思考和理解成本。易用性的极致是用户不需要进行任何操作,我们直接提供用户想要的东西。用户体验原则中有一条很重要的原则就是:「不要让用户思考」,一个需要用户深思熟虑做出决策的功能,就是一个易用性、用户体验极差的功能。

提升易用性的办法是减少用户的思考和操作。最佳策略就是产品经理摸透用户心理,直接给他想要的。当然这是不可能的,理由上面已经给出了,用户是一群人,不是一个人。

5.1 用户期望

我们考虑一个功能设计的易用性的标杆是「用户期望」。达到甚至超出用户期望,这是易用性的标准。我们在进行某项操作前,心里都会做出一个简单的预估,「我需要进行怎么样的操作,最后达到什么样的结果」,这就是「期望」。我们举一个简单的例子,来阐述用户期望。

我们去吃火锅,我们的期望是「跟服务员点单,然后服务员把指定的产品呈递上来」,超出期望指的是「服务员告诉你,是不是照老样子来一份,你回答可以。」或者告诉你「今天做活动,所有餐品只要5折」等等。

在产品中,要超出用户的期望,方法无非是根据用户的期望,要么减少操作成本,要么增强操作结果。也就是上面举的那两个情况。

6 灵活性和易用性的平衡点

根据以上的定义,「灵活性」和「易用性」是天然的对立。如果用户是一个人,那么就很好做到这两者的统一,因为一个人的需求是明确的,即使会变,变化完之后也是一个确定的结果。一群人的需求也是明确的,一半人喜欢按钮是方的,一半人喜欢按钮是圆的。但是以上的两种「明确」并不是一回事。

面对需求以及需求场景的多样性,让用户自行自定义是一个很好的策略,但是我们为什么不这么做呢?

6.1 高「灵活性」的缺陷

我们继续使用「吃火锅」这个例子,你的期望是「点个菜,然后服务员把菜送上来」,结果服务员告诉您,你必须先告知你的星座、年龄、性别、家庭住址、工作才能点餐,你会骂这家店神经病,我就吃个火锅,还要这么麻烦,即便火锅店的用意是通过这些信息给你提供个性化的服务。

高灵活性的缺陷在于增加不需要特定需求场景的用户的思考和理解成本,造成用户体验的低下。这是不可避免的,用户心理:「我不想搞这么复杂的东西,你非要我弄,你说我烦不烦?」

6.2 找到平衡点的策略

为了便于讨论,我们将这个模型简单化处理,用户的选择进行两极化处理。

先来看一个极端情况,我们在无法满足所有用户的情况下,采取A方案会让99%的用户满意,但是剩下的1%的用户会不满意同时会放弃使用产品。采取B方案会让1%的用户满意,但是剩余的99%的用户会很不满意,同时放弃使用产品。如果你作为产品经理,你会选择采取A方案还是B方案?答案很明显,我就不赘述了。

然而以上这个例子太极端了,我们一般会遇见的问题是以下这个:采取A方案会让99%的用户满意,但是剩下的1%的用户会不满意同时会放弃使用产品。采取B方案会让1%的用户满意,但是剩余的99%的用户会不满意(仅仅感觉不爽,但是不会放弃使用产品)。我们再把这个比例网中间移,最后你会发现,很难得到这么果断的答案,但是确定的一点是,作为产品经理,你必须选择其中一个方案。

前面提到了,加开关(增加可自定义部分)会让产品能够满足更加复杂多变的需求场景,但是增加了不需要这部分需求场景的用户的思考和理解成本;不加这些开关,则会让产品无法支持这部分需求场景。我们如何取舍呢?我们可以使用「用户满意度」作为判断标准,去判定哪种策略更为合适。

6.3 计算用户满意度

计算用户满意度的初始策略是:所有的用户打个分,然后求平均数。我们也提到了这种做法不可行。那我们有什么更好的办法吗?那就是前面提到的,将用户进行分类,方便分析用户特点,去模拟用户进行打分。

例如某个功能当前三类用户均打分80分,因此用户满意度为80分。一些用户提到了想加一个A功能,这些用户分类为长尾用户,人数并不多,功能也非通用性功能,只是加个开关,提升产品的灵活性,此时我们就需要评估是否需要加这个功能?

头部用户不需要这个开关,但是加上开关不影响头部用户使用,只是觉得加个无关因素显得产品不专业,因此打分由80分变为79分。

中部用户因为这个功能加了个新开关,需要更多的思考和操作成本,增加了出错几率,觉得很不爽,因此打分由80分变更为70分。

长尾用户由于加了新的开关,满足了他的个性化需求,匹配了新的需求场景,因此很开心,因此打分由80分变更为90分。

我们统计新的用户满意度 = 79 x 10% + 70 x 80% + 90 x 10% = 72.9 分,加上这个新功能会降低用户满意度,因此这个功能属于负分项,属于「做了白做且不讨好」的功能。一般通过对用户满意度的核算,产品经理就可以对一个新功能做一个简单的判断,这个功能对于用户来说是加分项还是减分项。

当然以上是一个简化模型的案例,真是场景会更为复杂,但是基本思路是一致的。

我们进行总结,无论一个产品还是功能,评估用户满意度,一般有以下几个步骤:

(1)将用户进行分类,明确各类用户的特征。

(2)按照用户特征站在用户角度思考,做出各类用户的评分。

(3)对评分求平均值。

7 产品设计原则和技巧

实际上,我们如果对每一个新功能都做一次评估,这将会成为一个很大的工程。这里我总结了一些产品设计的原则和技巧,按照这些思路进行设计,一般可以直接到达灵活性和易用性之间的平衡点。

7.1 抓住主场景,放弃个性化场景

对于商城系统来说,买东西卖东西才是主场景。当然对于说在买家买东西的时候,听首歌,促进交易,这个需求场景也是存在的,但是我们要不要给商家做这个功能呢?按照「抓住主场景」的原则进行设计,可以很方便地避开很多烦恼,作为产品经理一定要记住一句话:「既然无法满足所有用户,那就去满足绝大多数的用户,如果为了满足小部分用户而去得罪大部分的用户,这就得不偿失了。」

7.2 如无必要,勿增实体

这句话来源于奥卡姆剃刀原则,这句话的意思是:「不要用更多的东西去做较少东西就能做到的事情」。每增加一个元素,就会增加用户的思考成本。缩短用户操作流程的路径,如果用户问某个东西要怎么操作,最好是「这个地方点一下就好了」而不是「先这样,再那样,最后再这样就可以了」。