用户画像项目简介（用户故事与用户故事地图）
用户画像项目简介（用户故事与用户故事地图）这样的描述对吗？对！但是太狭隘了。“描述对用户有价值的功能，好的用户故事应该包括角色、功能和商业价值三个要素。用户故事通常的格式为：作为一个<角色>，我想要<功能>，以便于<商业价值>。”全文包括什么是用户故事、如何讲故事、用故事进行沟通、用故事进行产品设计、用户故事地图、用户故事与用户画像、应用实践七部分。用户故事这个词源于敏捷，什么是产品设计中的用户故事？就是以用户能自我代入的方式，设计产品，用产品讲述用户的故事。你上网去查，肯定会得到的解释大多解释都是：
全文包括什么是用户故事、如何讲故事、用故事进行沟通、用故事进行产品设计、用户故事地图、用户故事与用户画像、应用实践七部分。enjoy~
以下是正文：
我们开始分享平台设计的用户体验部分，这个是平台建设中，平台的用户体验，是企业全链路精准用户体验管理的子集。平台用户体验，更偏向于互联网产品的体验设计，在没有进入到全链路深度数字化的阶段时，用户体验部分主要包括确定性设计，用户体验的五个层级，用户故事，Design WorkShop 体验设计工作坊、用户体验地图，设计蓝图，平台用户激励系统七部分。
如果说一个人最具价值的能力是什么？那我会说：创造力、讲好故事的能力、提出真问题的能力。你可以认为，几乎人类社会所有成功的营销活动，都是通过塑造不同的故事，引起共鸣，触发情绪，最后达成交易。
全文包括什么是用户故事、如何讲故事、用故事进行沟通、用故事进行产品设计、用户故事地图、用户故事与用户画像、应用实践七部分。
01 用户故事：概念与意义
用户故事这个词源于敏捷，什么是产品设计中的用户故事？
就是以用户能自我代入的方式，设计产品，用产品讲述用户的故事。你上网去查，肯定会得到的解释大多解释都是：
“描述对用户有价值的功能，好的用户故事应该包括角色、功能和商业价值三个要素。用户故事通常的格式为：作为一个<角色>，我想要<功能>，以便于<商业价值>。”
这样的描述对吗？对！但是太狭隘了。
用户故事首先应该是一个种思维，即故事思维，是运用故事的元素进行思考和设计，以求解决某种问题，达到特定效果的思维。在用户故事设计中，核心是要通过故事来传递信息，引起共鸣，解决问题。
优秀的故事设计能力，是能够通过故事，“带领”用户解决一个个现实的问题。记住，用户故事的目的是解决用户的问题，产品在里面的作用是“带领”，扮演着领袖的角色，组织资源，提供方案，制定路线，克服困难，达成目标。
1. 产品设计中的故事思维
产品设计中的故事思维是将故事思维运用在产品的需求收集、创新、设计、改进，帮助我们在做产品的过程中看清用户使用产品的现状是什么，了解用户在使用现有产品遇到什么困难，解决用户现有场景不能被满足的需求下，我们的解决方案是什么，以及描述产品以后会是什么样子，能解决用户什么问题，为用户带来什么价值。
2. 要将情感代入故事中
在进行产品设计的时候，需要有故事思维，很重要的原因是讲故事容易打动用户，容易引起用户情感上的共鸣，但是并非所有的故事对所有的人都有这个效果。平台产品的设计人员，需要把情感化及同理心带进来。我们讲故事，需要了解用户内心的预期，了解用户所处的阶段，了解用户情感方面的需求以及渴望。
宫斗剧为什么会这么火？韩剧为什么会火？美国英雄主义的电影为什么会火？
其实所有的这些，都是套路，韩剧里面男主角是高富帅、霸道总裁，女主没权没势还能受到几个霸道总裁追求。这种故事反映了有很大一个女性群体内心在爱情方面的情感需求。甚至情节越是超乎观众预期就越是火爆。漫威的电影里，英雄都是从小人物，背井离乡，历经磨难，失去亲人，失去爱人，最后建立一番宏伟大业，荣归故里，等等。所有的这一切都是套路，有一本书叫《前面英雄》，讲述了所有英雄故事的套路，你可以找回来看看。
从这个角度而言，企业数字化转型、平台产品设计和电影、电视剧是一样的。
02 如何讲述用户故事？
1. 找到关联
前面我们在用户画像中介绍过，保险公司在做平台产品的时候，要选择目标用户，进行用户分群，充分了解目标用户的群体构成，这些群体有什么特点，他们使用产品的主要场景是什么？搞清楚了这些因素，我们才能和用户建立起关联，产品改进的思路才能切中用户的需求。同样的，故事也要跟用户建立关联，建立关联是打动用户、产生共鸣的基础。
关联点分为显性关联点和隐性的关联点。前面一核三环中，所说的服务存量用户的关联点就是保单，这是显性的关联。
隐性的关联点是什么？例如说到吃辣、火锅，大家的关联点可能都是四川火锅；说到肉夹馍大家的关联点都是西安；春节就是中国这个群体最大的隐性关联点；“相夫教子”就是旧时中国对女性群体强加的隐性关联点等等，说到这，是不是想起一些东西？隐性关联点就是集体潜意识层面的东西。
2. 构建群体故事
找到群体的关联点（也可以是群体和企业的关联点），我们就可以依据关联点，开始构建用户故事，故事应该具备的基本要素：
- 可信的环境（时间、地点）；
- 可信的角色（谁、为什么）；
- 流畅的情节（是什么、怎么样）。
基本要素饱满后，然后通过生动、连贯的语言将其有效的串接起来即可。
3. 故事必须真实或构建的足够真实
故事真实与否，一个分水岭就是“情感代入”。前面说了，要将情感代入到故事中去，这种故事一般都是源于生活，通过适当的加工改造而成的，很多时候故事就是生活，生活就是故事。
03 用故事进行沟通
怎么样进行故事设计？或者说产品和设计人员怎么样才能做到故事设计？
这就要求产品和设计人员要有同理心。同理心没有长时间的训练，做起来相当困难，人往往会不自觉地从自我出发，以为他人都跟自己一样，你认为的就是别人认为的，实际上每个人的世界观都很不相同。以下是沟通过程模型图，发送方在沟通过程中处于信息传递的主动地位，是沟通的起点。
在确定性一文中，我们介绍过，有效沟通的目的是彼此达成共识，实际情况下，由于信息传递、噪音干扰、接受者解码方式不一等等造成巨大的信息衰减，最终导致双方理解上的巨大差异。理解这一点非常重要，因此尝试用故事的方式沟通，是有效解决信息衰减的方式之一。
互联网的上半场，因为人人都是用户，产品和设计人员也是用户，所以在面对C端用户进行设计的时候，理解自己就可以很好的应对。但是到下半场，面对更多的是B端，这时候很多场景是无法亲身体会的，通过故事所塑造的场景代入就较为重要。
具体做法：
- 构建场景目录清单。场景目录清单有大有小，大的主要是《平台场景目录清单》，小的主要是产品设计人员下用户调研过程中，所制作的场景需求，可以是随手记录，也可以是团队通过固定的表格来统一管理，后者更有利于跟踪、改进和工作的交接。
- 场景拆解。将故事场景需求，拆解成场景步骤，列出每个步骤中所对应的角色。
- 步骤拆解。将上一步中的步骤进行拆解，拆解出具体的功能，最后得到详细的功能列表。
- 优先级排序。将上面拆解获得的功能，根据场景的核心动线，划分优先级。
最后，我们会形成一个《用户故事场景目录清单》，清单中包括该故事下的所有场景，场景的所有步骤，每一步相关联的功能，功能的优先级等等。同时标明制作人、审核人、相关实施方以及推进的时间节点。
到此，我们就将抽象的故事拆解成了一个个可落地的产品功能。
04 用故事进行产品设计
互联网平台的设计，一定是由粗到细逐步拆解，由细到粗逐步搭建的过程，从搭建平台产品的框架，到具体单个页面的设计，都是在讲述一个个故事。
上图是将沟通过程模型抽象后的信息传递模型，加入了逻辑思维、故事思维和受众思维，如果能将这三种思维在信息传递中利用起来，将会大大提高传递的效率。
平台产品的设计，也是传递信息的一种，大致的思路是：
- 通过故事思维理解需求。这一项在上面已经分享。
- 运用受众思维和逻辑思维，设计合理的框架结构和页面交互。
互联网平台是n个平台协同构成的一个平台体系，所有平台既有C端的平台，像我们当前讨论的；也有B端的平台。不管是C端还是B端，框架设计都非常重要，这个框架和一本书的目录、一篇文章的脉络结构一样，都是为了引导用户（读者）快速理解文章和作者思路。
平台产品的设计也一样，框架的设计，需要注意：
- 明确产品的使用者。2C还是2B？B端角色繁杂，既要满足共性，又要满足个性，因此制定一套科学完善的用户权限机制至关重要。
- 确定产品的基础框架和底层结构。基础架构决定了哪些是标准能力，哪些是客制化能力。底层结构，也有人称之为底层架构，是产品设计团队要明确的系统基础核，如果把一款产品比作一棵树，基础框架就是树干，底层结构就是树根。
- 考虑产品的灵活性。产品的灵活性主要目的是方便共性和个性之间的转换。
- 了解产品的收费模式。
到此为止，用户故事，故事拆解，功能列表，架构选择，基础结构全部确定，剩下的就是干了。
05 用户故事地图
用户故事地图的绘制，普遍采用的方法就是工作坊，这里的工作坊主要是“故事编写工作坊”，通过工作坊的形式，团队一起来梳理产品的用户故事地图。
1. 用户故事地图
要建设一个平台，毫不夸张的说，要做的事情多到我们无论有再多的人，都会很快就不堪重负。另外，团队成员来自不同的团队、不同的领域，所有人的沟通方式、认知和价值观都不一样，这时候，有两样工作就显得非常重要，他们就是MVP和用户故事地图。
MVP是指最小可行性产品，这里面的最小是针对确定用户群体的需求而言的，当然MVP也可以是最小可行性方案。
第二个就是要想让团队快速达成一致，齐心协力交付产品，用户故事地图就是用来建立共识，帮助团队以可视化的方式展示依赖关系最好的工具。用户故事的另外一个好处就是将调研阶段无数个用户故事，有效的组合在一起，同时还能保证不偏离组织的目标。
所谓的用户故事地图，就是使用用户故事组成的一个地图。地图的作用就是为了寻找路径，了解全貌。
2. 绘制用户故事地图
绘制用户故事地图，需要召开一次用户故事会议，参与会议的人必须是各岗位关键角色，包括产品负责人、项目负责人、业务负责人、技术和老板，人数控制在7人以内，但不要少于3人。这些人都代表了平台建设中的主要角色的看法。
同时，要提前准备材料。和WorkShop一样，我们在开始之前，要准备一个白板、不同颜色的便利贴、胶带等等。同时还要明确产品目标，要解决的用户问题以及或许有的收益等等。
（1）第一步，进行产品定义
我们要确定我们的用户是谁？解决什么问题？用户目标是什么？产品目标是什么？通过这些问题，可以基本框定整体的范围。
（2）第二步，梳理骨干故事
梳理故事要确定好一级故事、二级故事，保证故事的完整性，同时要广度优先，而非深度。最后的效果就是看到故事群。
（3）第三步，拆分故事
在刚刚梳理的每一个二级故事下面做停留，去拆分二级故事获取更多细节内容。项目组会围绕这个故事写出很多细节来。我们可以按照以下几个维度对细节进行归类，分别是：故事细节、想法、痛点、机会、情绪。其中情绪可以通过固定的问题获得，也可以通过用户想法、用户的痛点结合主观判断。
在这个过程中，先让大家在一定时间内按照自己的想法写出来，每一条写在一张卡片上，做到相互不干扰，然后每个人出声说出自己的卡片内容，让所有人了解并贴在墙上。
项目组人在写想法的时候，相当于脑暴的过程，这时可以通过一些问题来刺激大家脑暴出更多的内容，比如：
- 用户在这步具体做什么?
- 用户还有其他选择么?
- 用户怎么做才能更爽?
- 出现问题如何处理?
- 其他用户来到这里该如何处理?
- 在真实业务当中，发生特殊情况该怎么办？
所以这一步我们将尽量多的关注到所有场景的故事。做完这步，我们已经获取到了足够多的细节信息，整个项目组都会做到对产品又见森林又见树木的状态。
（4）第四步，沟通确认
这一步是将前面丰满而又臃肿的故事，通过对标标题、充分讨论，把公认的留下来，无用的剔除掉，同时区分要做的故事细节的优先级。完成所有故事梳理后，就出现了下面这张图：用户故事地图。
或者这样的：
3. 提效
由于日常工作任务非常重要，所以整个过程中，较高的效率就非常重要，所有组织者一定要在事前准备、事中协助、事后电子化。
- 事前准备：提前三五天准备好故事地图模板，会议流程，并将其发给参会者，让所有人能够相对结构化的对产品有一个整体的梳理和思考，这样可以帮助在工作坊中提高产出数量和质量。
- 事中协助：特别是需要优化某些产品，可以将设计好的页面或者原型提前打印好，以增强大家的代入感，提高产出质量。
- 事后电子化：专门配置一个设计熟手，通过sketch或者Axure快速制作出用户故事地图电子版，方便现场进行测试，并将讨论结果高效传播。
06 用户故事与用户画像和数据的关系
1. 用户故事与用户画像
用户画像中，有一部分是用户分群，分群的结果是将相同关联的用户划分成一个群体，然后在进行故事化设计的时候，利用关联性将这个群体共同的故事。这个就是用户故事和用户画像之间的关系。
实际上，用户故事是前置的，出现在产品设计之前，用户画像是结果，后置的，是产品上线后通过用户数据积累形成的。但是完整的用户画像，在故事的丰富程度上，能有效的指导故事的积累，同时发现一些我们在调研过程中很难觉察的用户故事，从而丰富平台用户故事。
2. 用户故事与数据
通过故事主导产品设计，还是依赖数据进行产品设计？个人认为故事比数据更重要，数据是水管里流的水，是一个常态，是一个结果。而用户研究，重要的不是零散地收集数据，拿数据证明自己的对错，而是建立一个有代表性的故事。
每个人对数据的解读都不一样，大家拿着数据和逻辑相互撕，是很难有说服力的，但是通过讲故事，情感代入，效果就不一样。国内产品设计能力最强的互联网公司腾讯内部，从来不讲数据，而是要讲用户故事，自上到下，所有人都在观察你对用户的感觉有多强，你和用户的关系有多深多好。
如何判断你跟一个人关系好不好，无非就是你知道多少他的信息，以及他的最新动态信息会有多少跟你同步。你掌握的信息越多，说明你们的关系越好。
你对你的经典用户故事是否足够了解，足够深入，足够完整，足够洞察，是判断你跟你的用户关系的标准。
所以一个好产品是从“第一只羊”被真正被满足开始的。我们充分认识这“第一只羊”，能够完全用他的语言说话，你需要了解他的故事。
一个好产品，是从一个好故事开始的。
07 应用实践分享
英国OU（开放大学）是英国最大的大学，目前已经开始提供远程教育，它的网站起着两个关键作用： 连接学生与大学；帮助潜在生源找到学校。
我们来看一下开放大学网站交互设计的变化。
一开始，开放大学提供的课程目录是典型的数据库和目录。从学院列表开始，再进入到具体的课程介绍。这种设计的前提是，网站假设用户最想知道的内容是每个课程的详细信息介绍。
这种设计其实是给明确知道自己想要什么的用户（我们和用户画像里面的称呼一样，叫大明）用的，和京东的定位一样，所以它的检索、产品目录很强。这种设计可以让需求明确的用户，沿着搜索、目录，找到自己要的东西。
选课的交互设计上线之后，设计人员很快发现这种方式不是最佳的。为什么？
因为开放大学网站的设计人员认为他的用户是知道自己想要什么的用户（大明），但其实他的用户是想进修但不知道这怎么开始的用户（我们和用户画像里面的称呼一样，叫笨笨）。他们其实不知道自己要学什么课，更不了解详细的课程信息，他们更关注自己的梦想如何能实现。
我们来分析下，开放大学可能有以下几种用户：
- 一位同学烦透了他的工作，他想寻找更具挑战性的转变；
- 一位做会务策划工作的同学，想将这份兼职工作转化为全职，但并不知道这种转化如何实现。
有少数用户是大明，他有简单直接的目标，学习、考试、拿下一个学位或者证书。但是绝大部分人其实不太了解自己到底要学什么专业，具体要学的是什么课程，以及他们所学的知识能把他们带往何方。
有一个用户的故事是：一个叫Pritti的年长的巴基斯坦女士，曾经为了家庭而放弃了她的学业。现在，她想拿到她在年轻时错过的大学学位，所以她来开放大学选课。她刚开始的想法是，第一门课要选一门可以帮助她提高英语阅读能力的课，并能帮她恢复良好的学习习惯。于是她和她的朋友努力地查，最后选择了显然不适合她的高级语言学。
事后她跟产品经理讲她的选课思路，产品经理发现她点击每一个链接都有充分的理由，但是为什么选了不适合她的课呢？
因为这个网站没有用Pritti女士能理解的语言表达，网站没有告诉他们应该如何选择。这个网站是给大明用户设计的，产品设计默认用户知道如何根据课程介绍选课，但其实大量来选课的人是笨笨用户，他们不知道自己要什么。
从这个故事开始，开放大学决定在学生选课之前，先向他们展示其他人上这门课的目的，把一系列用户故事放在网站的课程介绍上。比如：茫然的年轻人，通过学习成功转行的故事；Pritti这种年纪比较大的人，重拾学业的故事。其中有一个人通过学习取得了法学硕士学位的故事，开放大学网站是这样描述的：
“我花了整整六年的努力学习，每周超过16小时的学习时间，牺牲看电视的美好时光，然而这一切的付出绝对是值得的。我空出星期天的时间来放松，与家人相处，但是我每天晚上和周六都预留出来用于学习，以保证学习进度。这意味着为了保证学习进度我必须要工作到凌晨一点，不过这6年我坚持做到了。”
下面页面上展示的，就是他的课程安排。
对于笨笨这类用户，他们先看了与自己相似的人生故事，知道了对方的困惑和付出，再看这些人选了什么课，花了多长时间完成这些课程，是不是更有感觉？
开放大学做了什么改变？
从一开始，假定用户为大明用户，他们知道所有学院、课程的意义，提供干巴巴的课程信息；转化为了提供给笨笨用户可以理解的场景故事。在此之后，开放大学的宣传从“我们有什么老师和课程”，变成了“我们有什么用户”、“用户故事是什么”。
这就像淘宝早期传播淘宝卖家的传奇故事一样，故事更容易在淘宝的卖家中传播。
回到我们说的用户画像中的“第一只羊”，我们刚才举例的Pritti，就是开放大学新版的“第一只羊”，一只笨笨羊。她自己选课的结果是选了最不合适的课程，如果真的开始学，她一定坚持不下来，这就是羊不适应，死掉了。
如果我们只关注数据，而不关注用户故事，那么我们很容易做出的决策是导更多的羊进来。这批被导进来的用户肯定会有问题。
如果压力过大，有人就会诡辩数字形成的原因，甚至还会对数据作弊。这就是不关心用户故事，只关心数据转化率的结果。
全文结束，希望对你有所启发~
参考与推荐：
- 图书《用户故事地图》
- 图书《Storytelling for User Experience》
- 推荐阅读《故事经济学》、《千面英雄》
- 电影观赏《驯龙高手》这部电影真的是一部荡气回肠的数字化转型史
相关阅读
创新型服务“智能推荐” | 互联网平台建设（十二）
创新型服务“场景串接” | 互联网平台建设（十三）
保险需求的智能分析：智能保顾 | 互联网平台建设（十四）
平台的核心交互与基础角色 | 互联网平台建设系列（十六）
为用户提供确定性 | 互联网平台建设（十八）
用户体验分析 | 互联网平台建设（十九）
作者：李有龙，公众号：IAB物智链
本文由 @李有龙 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
