意见反馈

从用户出发,互联网产品策划方法论

阿翘
12

【一】从用户到需求

产品经理需要具备两个非常重要的技能,一个叫策划,一个叫感知用户。

我们在分析问题的时候往往会说“这么做,我认为用户会怎么怎么样”、“用户会认为这样很不爽”,当我们这样说时,很有可能是把自己当成了用户,用某些特定的情感或记忆代表了用户。


当我们问到设计一个校园图书馆时学生群体更关注哪些方面,一些80后的产品经理会说“书籍的种类、丰富程度、归还的时限等”,一些90后的产品经理则会告诉我们“桌椅的数量”。仔细去想这两种答案,都是典型的“我就是用户”的思维。因为我们都经历过学生时代,所以很自然我也曾经是用户,我能够代表用户。
80后的朋友所处的学生时代大学里的书籍普遍比较匮乏,存在很多书想看但是图书馆没有或者是已经被借走的情况,因此他们会认为书籍的丰富程度对于学生而言就是一个强有力的痛点,也是一个图书馆最应该解决的问题。
而90后的朋友所处的学生时代早已经把图书馆当成自习室的替代品,有更强的学术资料补充同时也有更安静的学习氛围,所以成为学生自习的首选。因此自习区的位置少也成为了这一代学生很重视的问题。因此我们可以看到,不同的产品经理可能产生了不同的用户群。
不要把自己当成用户,但很多人却做不到。产品经理都是一群容易性格分裂的人,即不能把自己的情感或记忆带入用户的同时,又要想办法去感知用户,感同身受用户正在经历的事情、正在思考的问题。


用户是多元的

上述例子中关注“书籍种类”的用户和关注“桌椅数量”的用户无疑都是使用图书馆的用户,他们都是学生,但他们在学生群体中又会产生意识的分歧,所以用户是多元的。设计一款产品时,我们经常会提到核心用户、次级用户以及边缘用户三种,希望通过被服务人员的区分为产品找到一个定位。依据不同的参考标准,我们能得到不同的群体划分范围,例如学生、教师、外部研究人员这样的分类中我们可以定义学生是核心用户群,但是用考研学生、中年级学生、新生,我们又能定义更细分的核心用户群。产品设计的第一步,永远是找到最精准的受众。


为用户分类

因为用户是多元的而产品是有限的,我们希望通过提取用户身上共同的一些特征以便找到对应的核心客户群体并解决他们的问题,所以我们需要为用户进行分类。传统思维中我们习惯对用户的客观事实特征进行分类,例如性别、年龄、地域、职业等。然后就会产生“一线城市90后学生”这样的标签,但细想这样的标签是不具有代表性的,因为这群人中同样存在千差万别的思维方式,同样会发生不同的行为与喜好。
试想“一线城市90后学生”这样的一群人在选购笔记本电脑时也会有不同的关注点,喜欢玩游戏的同学更关注性能、家境一般的同学更关注价格、喜欢看剧的学生则更倾向一个轻便的拿到床上也很方便的笔记本等等。如果我们用这样的分类方式很难去归纳共性以及切入点、痛点的选择,更不用想往后展开更深层次的需求洞悉了。
所以对用户进行正确的分类,是展开后续用户研究工作的前提。
麦肯锡认为,一个人的成长经历是价值观形成的基础,而价值观又决定了一个人的行为倾向。人的价值观有一个形成过程,是随着知识的增长与生活经验的积累而逐步确立起来的,而价值观又体现在行为倾向中。
在中国,整个大环境下有几个对人们的价值观影响深远的事件。50、60年代的人在意识形成的阶段经历过文化大革命,受当时的环境影响这一代人普遍相信权威、相信专家 ,因此电视购物则很聪明地运用了这群人的特点,利用电视和所谓的专家营造一种权威的感觉让中老年用户更容易相信他们。
70年代的人正好赶上了改革开放,无数的人从当时白手起家打拼出了自己的事业。这一代人非常的勤奋、独立自主相信“爱拼才会赢”因此他们身上有很强的责任感、自信、追求成功、激进等这一类的特点。
80年代的人在父辈成功学、以及外来新兴事物涌入的交错影响下,这代人会显得有些迷茫、焦虑。一方面父辈喜欢用他们成功的经验去教导他们该做什么,大学读什么专业甚至以后做什么工作都喜欢帮他们安排妥当,另一方面受到外来文化的影响他们在心理又藏着自己的萌芽的想法与追求。
90年代的人大部分都是独生子女,生活条件比较优越,对新兴事物都非常感兴趣。由于他们接收信息的渠道方式更多元化也让他们的知识面、早熟度远超父辈。同时很多的社会现实让他们很早就明白把价值取向关注于具体的事物,更注重工具理性。所以这一代人普遍有自由主义、自我实现精神、理想化、孤独这一类的特点。

通过以上例子我们可以看到一代人的成长经历对他们的价值观塑造是产生巨大影响的。因此麦肯锡的市场人员会选择一代用户大环境下的成长经历去研究他们,从地理位置、人口特性开始选取一群相近的人群,然后再对使用行为进行分类,分析这群人的生活方式、购买动机和态度等,对客户有一个全面的了解。


作为产品经理可以直接对用户的行为倾向进行分析,使用成长经历、价值观以及数据加以佐证分类的标准。使用行为倾向作为分类的依据,每一个群体对产品的主观感受以及行为都有足够的共性,可以获得对后续的需求洞察更具象的结果。

【二】从需求到产品

用户分群是我们的第一步,对用户有一个较为清楚的认知后,接下来我们开始对他们所在不同场景下产生的需求进行剖析。

所有用户需求及内部需求收集完之后我们会形成一个需求池。当需求变得繁多时,如果没有对需求进行有效管理以及优先级的评判那么产品规划将变成一团乱麻。

所以在产品方案设计阶段我们首先要知道需求的轻重缓急,知道哪些是我们现在应该做的,哪些是放在以后我们可以慢慢优化的。评估需求之前我们先通过以下三个方法查漏补缺,补充需求,明确需求的范围。



第一个方法是同类场景横推法,想一想这个需求是用户在什么情况下会产生的?有没有存在类似的场景呢?比如前面提到的线上问诊这个行为会发生在用户已经发病的情况下,那么还有没有类似的场景,是否可以思考用户在复诊的过程中会不会也希望使用线上问诊的方式呢?

第二个方法是特定场景纵向分析法,想一想这个需求的场景中,存在哪些关联行为可以提供支持?还是线上问诊这个行为,我们提供了问诊之后顺着需求链思考,用户是不是会有预约就诊这类的需求?这个场景如果打通是不是能帮助用户更好地解决问题?

第三个方法是行为目的深究法,这个方法就是产品经理的内心中不断问自己,这真的是用户确实需要的功能吗?这样做真的能解决用户的问题吗?

需求三要素



在进入需求管理阶段,我们要明确需求的三要素,问题、业务背景以及对应的解决方案。

了解清楚用户目前面对的问题是什么,线下是如何解决这个问题的,以及对这个问题有一个范围界定的精确定义。对问题有一定的认识后才能深究问题产生的背景,充分了解用户所处的场景。

在这个过程中除了需要搞清楚业务场景、业务术语以及业务环境(比如就诊行为的一些专业名词和流程等)以外,我们可以尝试询问用户希望给出的解决方案用以评估用户目前的认知水平和对问题的认识。

根据以上的反馈再形成完整的解决方案,值得注意的是给出方案的同时我们务必要有解决问题的方法以及实际成本的评估,这也是对后续方案采纳的重要考量因素之一。


还原需求

在评估需求的优先级之前,我们还有两件事要做。首先我们不妨做多点工作确认需求的真实性。吾日三省吾身,产品经理每天三省的问题应该就是:



1.要解决的问题是什么?--这里面的核心问题是什么,这个核心问题又带来了什么样的衍生问题,在这个核心问题中有没有包含细分的问题。

2.用户的场景是什么?--比如我们要做一个手机快捷多任务切换的交互方案,那么就要去想用户是在通知朋友的时候、看视频打发时间的时候还是查看资讯时要回信息的时候最需要用到多任务切换这个功能呢?

3.用户的环境是什么?—环境对产品的使用也会有很大的影响,比如用户在车上使用、在出行过程中使用手机是否只能进行单手交互?交互的过程中是不是不容易按到手机上方的按钮?

思考这些问题帮助我们在面对繁多的需求池时也能保持清醒,清楚知道自己在做什么需求,产品会有什么样的改变。


需求分类

接下来我们需要对需求进行有序的分类。首先我们可以有三个比较大得分类分别是:功能型需求、数据需求以及非功能需求。

功能型需求一般指有具体完成内容的需求,比如登录行为、线上问诊行为、商城购物等等。这些行为根据不用的场景我们还可以细分为:使用场景、维护场景以及运营场景。

非功能需求一般指为满足用户业务需求而必须具有且除功能需求以外的特性,包括系统的性能、可靠性、可维护性等等。像我们常看到的要求系统需满足2W人同时在线使用、页面反应时间不能超过2秒这些就是常见的品质类非功能需求。

数据需求一般指的是数值系统的设计以及报表监控指标的设计等等。



不同类别的需求尽量不要放在同一个维度评判优先级,在产品的不同阶段对不同类型的需求也有不同优先级。产品迭代的初期,我们更重视功能型需求的建设,这个时期就像一个拓荒的时期,需要快速做出功能实现需求占领用户;在产品日渐成熟稳定之后,为了维持稳定的运营情况,非功能性需求的保障就变得尤为重要,这时候我们就要重点评估新的功能需求对系统性能以及稳定等各方面的影响。

需求评估、优先级划分

完成了以上工作,我们终于进入需求评估的阶段。正如前面所说,当需求变得繁多时,如果没有对需求进行有效管理以及优先级的评判那么产品规划就会变成一团乱麻。那么如何有效评估需求的优先级呢?在这里我重点讲四个最实用的方法。



第一个方法是卡诺模型(KANO),在KANO模型中定义了三个层次的用户需求:基本型需求、期望型需求和兴奋型需求。

基本型需求指用户认为产品“必须有”的属性或功能。例如一个摄影软件最基本的就是要支持拍照功能,但客户并不会因为你有拍照功能就对你感到满意,充其量只是满足了基本要求。

期望型需求是指提供“比较优秀”的属性或功能,期望型需求通常是一个产品的加分项,比如一个摄影软件支持多种调整图片的工具,不但支持傻瓜式的滤镜也能在这个基础上进行参数的调整,这样用户就会感觉很满意,当没有这些功能时用户就会感觉不满意。

兴奋型需求是指提供给用户一些完全出乎意料的产品属性,使用户产生惊喜。兴奋点和惊喜点常常是一些被用户无意中发现的需求,顾客在看到这些功能之前并不知道自己需要他们。还是刚才摄影软件的例子,如果在拍人时会有与拍景色时完全不同的表现效果,那么用户在潜意识中就会产生惊喜,同样也会越发提升用户的忠诚度。

在应用这个模型的时候首先我们要搞清楚我们的需求到底会放在图中哪一个界限哪一个点,由图中可以看出,右下方的箭头一旦实现了一定的数据的必须功能,就无法再通过增加这类功能来提高客户的满意度了。无论增加多少功能,客户满意度都不会超过中点以上。左上方的箭头指示实现了一小部分就能明显提升客户满意度,这就是一个产品中的杀手锏功能。中间的箭头代表期望型功能的增加和客户满意度呈线性增长,所以这类需求越多越好。



第二个方法是RFM模型,这个模型是衡量客户价值和客户创利能力的重要工具。我们实现任何的需求做任何的功能升级都是围绕创利这一目标的,这里的利不一定代表实际的资金收入,也可以是流量、口碑等间接创利的东西。

RFM三个字母分别代表了最近一次消费、消费频率以及消费金额,我们可以把这个模型转换为对需求价值的评估,从而确定优先级。R代表实现这个需求能够吸引多少用户回头使用你的产品?F代表实现该需求能够增加客户访问、使用产品或者消费的次数吗?M代表实现该需求能够增加客户的直接消费(现金)或间接消费(PV)吗?

我们可以用1-10分去量化这三个维度,把需求放在这个模型中,得出3个维度的评分,评分越高代表优先级也越高。



第三个方法是上一章提到的痛点模型,通过对需求的持续性、厌恶程度、可替代度的分值量化,同样把这三个维度用1-10分去量化,然后计算出需求的强烈程度,有限解决强烈的需求。因这个方法在上一章有详细的讲述,所以在这里不展开分析过程。



第四个方法是重要性象限判断,这个方法是由麦肯锡提出,根据事件的重要性和紧迫性为坐标轴,可以将所有事情区分在四个象限中:重要且紧急、重要不紧急、不重要但紧急、不重要不紧急。对所有事件分类后,才能做更好地分析处理。

但这个方法其实是具有争论性的,原因在于重要与紧急的定义没有一个大致统一的定义,所以只能根据不同公司的不同情况按照你认为的重要与紧急去进行区分,在这里我就不展开讲述。

场景、问题与方案

分清楚了需求的优先级,这时候我们就把优先级高的需求挑选出来,重点分析这个需求当前的场景、问题以及解决的方案。



在这个阶段,我们可以借助UML中的工具帮助我们进行系统地分析。通过图中的问题可以帮助我们快速思考这个需求对应的场景中目前的做法是怎么样的?期望通过解决方案带来什么样的改进?这个思考的过程一方面帮助我们理清思路,另外一方面也能够形成一个较为完善的用例(USE CASE)。


用户实例



用例是一个UML中非常重要的概念,用例是对一组动作序列的抽象描述,系统执行这些动作序列得到相应的结果。这个定义可能有点拗口,我们可以理解成用例其实就是为了实现一个目标所需要的人机交互流程。比如我们常用的理财软件中存在“提款”这样一个实例,我们首先需要登录到理财软件,然后点击提现按钮,输入提现金额,输入密码,转账至银行卡这样一系列的流程,这个过程的描述就是一个用例。

但是在这个用例中,我们还必须考虑可能发生的各种其他情况,比如提取的余额不足、输入密码错误等等,这些可能发生的情况(包括正常的和异常的)就被称为用例的场景,场景也被称为用例的实例。

下图为一个用例的详细描述过程,实际工作中我们挑选需要填写的项目即可。



那么用例有什么好处呢?用例方法的有点就是完全站在用户的角度上来描述系统的功能,我们可以把系统看成一个黑箱,不需要关心系统内部是如何完成它所提供的功能,我们可以使用用例与实例来表述系统的功能性需求。对于一个完整的实例而言,我们需要补充这个用例当前发生的场景以及前置后置条件。前置条件代表完成这个用例需要得到什么的支持,比如我们提现这个用例首先得成功登录软件、判断银行账户没有被冻结、绑定了银行卡等等,后置条件代表这个用例完成后需要产出什么,比如提现后我们的银行卡内需要能查询到提现出来的金额。

流程图

有了这样一条条具像化的实例,我们能够轻松把业务流程图转化成人机交互的流程,明确每个阶段的产出物以及关注的重点信息。这种人机交互的流程展示一方面来说可以帮助我们查漏补缺,梳理现有流程,找到不合理可优化的地方,从而改善流程;另外一方面也帮助我们能够轻松完成后续的原型设计。



制作原型的第一步需要根据上述得到的流程图把每个页面模块中的功能以及跳转流程做一个直观的展示,同样也是帮助我们梳理思路发现问题的方式,在这个环节也许你能看到某些功能放在同一个页面同一个优先级是否合理?某些功能是否另外一些功能的分支功能?通过这样的模块功能展示图可以帮助我们更合理安排每个页面的功能布局以及流程设计的可用性检验。

原型制作与UI实现

最后终于到了产品经理日常工作中一个很重要的环节,产品原型的制作。原型是产品、交互设计师与开发工程师之间沟通最好的工具,当我们有了上述几个图表的铺垫,相信大家在制作原型时会感到异常的轻松。

我们可以根据模块功能展示图思考真实使用时页面信息的架构、元素的摆放以及每个页面之间的连接跳转和交互方式。原型有几种不同的选择,我们可以选择输出交互式原型或者流程式的原型、低保真原型以及高保真的原型,这些根据每个人的时间以及团队的习惯都可以有不同的选择,我建立落入实际开发阶段可以使用流程式的原型进行详细的开发评审,在展示想法以及效果评估阶段可以采用高保真的原型进行效果演示;



最后一步是把原型图交给UI设计师形成设计稿,看到最终呈现的界面效果。

在最后,我们补充一个概念叫MVP模型,即最小可行产品。当我们开发一个全新的产品实现一个全新的想法时,没有必要把所有东西都做得尽善尽美再落入市场等待检验,我们可以通过一个最小可行性产品,保留最核心的几个功能去掉一些锦上添花的功能,尽快上线验证用户以及市场的反馈,通过MVP产品实行快速的迭代,逐步完善。同样值得注意的是最小可行性产品往往是确定了一个方向之后,从一个方案开始经过快速迭代优化形成更好的产品,并非每次上线都根据市场的反馈对产品进行大刀阔斧的调整。

---------------------------------------------------------------------------------------

至此,整个产品策划的流程就告一段落了。希望以上的内容对大家有一些思考与帮助。