产品经理

首页 - 产品经理 - 聊聊产品经理是如何确定核心用户、用户建模和场景的|用户建模|场景分析|

聊聊产品经理是如何确定核心用户、用户建模和场景的|用户建模|场景分析|

互联网和移动互联网产品的用户基本上分两大类:

  • 个人用户,也就是C端用户(Customer);
  • 企业用户,也就是B端用户(Business);

而用户群指的是,有共同动机、行为方式、特征的一群用户,我们产品的受众就是我们产品的目标用户群。本节我们主要讨论的是C端产品。

国内互联网和移动互联网C端用户基本上可以分为草根、学生、白领和精英四个群体:

640.jpeg

每个阶层用户数量大概的人数和比例:

640-1.jpeg

思考

产品到底应该从哪个用户群切入呢?

案例

QQ和人人网(原来叫校内网)的不同命运!

QQ是从即时通讯工具(InstanMassaging)切入的,满足用户之间沟通和交流的需求,任何人都可以用。

起初QQ的大规模推广是从网吧开始,因为2000年初家庭的入网率还不高,人们多数会从网吧上网。

人人网之前叫校内网,目标用户直指学生群体,即是更名后目标用户扩展到白领群,这些用户关系的维系都是通过加入或者进入同一个组织之后才开始的,然而草根并没有这样的组织。

我们从是否免费、目标用户群、切入点三个维度横向对比下QQ和人人网。

640.png

结论:

  • 产品的定位决定了目标用户群;
  • 目标用户基数越大获取大量用户的机会也就越大。

思考

如何描述我们的目标用户?

这里我们利用一个叫「用户模型」的工具来描述。

用户模型也叫人物模型,是一种用户原型,用以描述用户的行为、态度、天赋、目标,以及动机的明确分组,是场景中的主角。

用户模型为产品的需求决策、设计、研发和运营推广提供用户基准,而且贯串了产品的整个生命周期。

之所以要使用「用户模型」,是因为:

  • 使我们得以更加专注于目标用户
    • 实践告诉我们“不可能建立一个适合所有人的网站”。马化腾也曾说:“不能为1%的用户需求骚扰99%的用户。”
    • 产品设计原则之一,不求大而全,但求小而美。我们只需做到满足具有代表性的大部分目标用户的需求。
    • 大多数成功案例中,成功的商业模式只会针对特定的目标用户群体。
  • 引发同理心
    • 实践又告诉我们“你不是你的产品的目标用户”;
    • 不能总出现“我认为应该这样”,“我觉得这与做不好”的想法和言论;
    • 设身处地得把假设成目标用户:如果我是目标用户,我会怎么做。
  • 聚焦的同时会提高开会效率
    • 避免开会时大家讨论的话题不一致,用户模型就是最好的聚焦;
    • 用户角色在后面的需求传达、界面设计、产品推广方面,效率会大大提高。
  • 统一团队内部意见
    • 避免无尽的撕逼,一个精确而又共享的用户模型,是大家讨论的基础;
    • 避免今后的产品偏离方向,大家一定要统一意见。

思考

具体如何做「用户建模」?

640-2.jpeg

1、发现用户

出发点:目标用户是谁?用户规模有多大?他们主要行为有哪些?

调研方法:定量数据收集。

输出产物:调研报告。

具体的有:

获取用户元数据

获取用户元数据有几个途径:面对面访谈、观察法、二手信息、调查问卷、行业调研报告。

2、用户信息收集

出发点:用户之间的差异有哪些?

方法:查看资料,将用户群初步分组。

输出:目标用户群概述文档。

举例:比如职业、职业习惯等。

3、证实验证

出发点:收集更多用户角色信息(喜欢/不喜欢、内在需求、价值观)、环境信息(工作场所、工作条件)、场景信息(工作策略和工作条件),进一步验证当初的信息,是否与当初信息有冲突。

方法:定性数据收集。

输出:调研报告。

注意点:这一步的重点是寻找用户数据支持最初的用户分类模式,同事支持用户角色描述和场景。

比如用户喜欢什么、讨厌什么,价值观是什么,对某网站/系统的态度是什么,什么条件下会使用该网站/系统。

4、聚类用户

出发点:判断是否抓住了主要用户群?是否需要考虑调研其它用户群?这些用户群是否同等重要?

方法:聚类分析。

输出:用户群分类描述文档。

注意点:将用户分类描述文档与团队内部成员交流,如果大家觉得你讲的是对的,说明当前用户群确实是主要用户群。

5、创建用户角色

出发点:基本信息(姓名、性别、照片)、性格(外向、内向)、背景(职业)等。

方法:聚类分析。

输出:用户群分类描述。

注意点:用户角色不是为了描述用户,而是将用户角色的需求作为出发点的解决方案。创建用户角色时,团队相关成员都应该积极参与,了解用户角色是怎么来的,用户角色有什么用。

6、情景定义

出发点:用户角色的需求是什么?是在什么样的情景下产生的?

方法:寻找情景及其产生的需求

输出:情景分类和需求

具体的:这一步是为了创建场景做准备的,场景主要描述用户使用系统/网站的情景及在该情景下产生的需求。

7、验证和认可

出发点:验证团队内其他人是否认可用户角色。

方法:知道用户角色的相关人员阅读用户角色信息并就此发表意见和反馈。

注意点:询问每个人的意见,让每个人都参与其中。

8、统一认识

出发点:周知大家我们是如何确定用户角色的,以及这些信息背后的数据。

方法:组织会议、发送邮件等。

9、创建场景

出发点:在设定的情景中,既定目标下,用户使用技术的时候会发生什么?

方法:叙述式脚本,使用用户角色描述和情景形成场景。

输出:场景、用例、需求规格说明书。

注意点:用户角色本身没有什么价值,只有形成场景后才具有价值。场景就像是一个故事,有主人公、地点、目的、实现目标的行为(与系统/网站/设备的交互行为),包含四大要素:人物、时间、地点、事件,其中事件包括起因、经过、结果。如何描述场景呢?通常我们通过讲故事的方式描述用户场景,比如,主人公是谁(人物),在什么时间(时间),什么地点(地点),要做什么事,怎么做的(经过),结果怎么样(结果)。

10、持续跟进更新

出发点:跟进用户角色信息变化。

方法:可用性测试、新的用户数据。

输出:专人负责更新用户信息。

注意点:建议任命一位用户角色维护专员,负责更新维护用户角色。

本文转自:http://www.pmcaff.com/article/index/666295811226752?from=related&pmc_param[entry_id]=1000000000140621

作者:  老杨jd  (京东产品经理)

(0)

本文由 NiuPM资深产品社区 作者:rudy 发表,转载请注明来源!

热评文章

发表评论