体验
驱动
变革

基于用户体验形成过程，重建产品价值评价标准

如前文所述，我们提出了汽车产品用户体验形成的范式，即：谁，在什么场合用车，使用什么功能，解决什么问题，期待什么感受。与这组概念对应的就是用户、场景、Function list、任务以及体验要求。接下来我们建立体验评价系统的逻辑也需要从这个范式展开。

首先，我们必须要明确每个品牌或者产品的目标用户，理解他们的生活方式、用车方式以及产品要求和产品认知规律等。获取这些内容必须要进行消费者洞察，当然能够支撑这种洞察的操作方式、数据来源存在很多种。只要我们目标明确，再匹配合理的执行方案，要想解决这一问题并不复杂。只不过描述用户这件事是没有终极答案的，每个用户的特点和需求也是千人千面的，为此我们必须找到一种合理的，更能解释产品定位问题的用户群划分标准，并且这种标准是相对固定，可以跨周期跟踪和对比使用的。

其次，我们需要明确目标用户的使用场景，并且把这个场景与目标用户群对应起来。为此我们需要解决的关键问题是建立描述场景的语言体系和数据体系，只有这样才能把“场景”真正管理起来，并且引入评价体系当中。尽管从概念上每一个场景都是一个具体的用车画面，描述这些画面的维度可以包括里面的人物（包括人物数量与人物关系等），用车目的以及用户环境（时间、路况、天气等等）三个主要维度。但是如果沿着这些维度，以及每个维度的细分维度不断穷举的话，这些场景将会有数千万种以上。而且上述维度交叉出来的场景当中，很大一部分都是无效场景。问题的关键在于哪些场景有效，哪些场景无效，这个判断必须由人来完成，他不是一个简单的算法拓展问题。显然这不是一个具有可行性的数据模型构建和管理思路，为此我们必须另寻他法。

为了解决这个问题，SoCar & EFS的经验是将场景和用例（use case）分开，使之成为两个层级的概念。场景是由人物以及用车目的两个维度描述的，可以有效区分产品定位问题的更高一个层级的概念。而用例是指前文提到的由各种主要维度交叉组合而来的，可以详细描述每一个用车画面的精确概念。基于这样的概念设定，我们可以沿着参与者（用户）以及车辆用途（目的）两个维度形成一组场景框架，并且通过特定的数据来源研究这些场景的频次或者重要性。如下图所示：

按照上述规则，场景的概念和数据结构都被大幅简化了，但Use case的描述仍需解决。事实上我们并没有回避这一概念，而是将Use case的梳理与Function list结合到了一起，这一问题我们后续详谈。

第三，在清晰描述用户和场景之后，我们需要进步明确用户在每个场景下需要解决的主要任务，以及用户期待产品给自己带来的体验感受。完成这一任务首先还是需要基于消费者洞察，通过了解用户的生活方式和用车方式，找到这些关键任务。此外，更加重要的是，我们需要通过消费者洞察，真正理解目标用户的所思所想，建立与用户的“同理心”。在这里我们还是借用了消费者研究或者设计策略研究行业常用的一个工具—同理心地图，如下图所示：

使用同理心地图，我们通过分析目标用户在车辆选择和使用过程中看到的内容、听到的内容、感受到的内容以及这些用户的行为表现，可以更进一步理解他们的价值标准，他们的体验要求，并预测他们的行为模式。只有建立的同理心，用户体验研究才能真正站在目标用户的立场上思考和判断问题。事实上我们在通过这种方式替代很多细节问题对用户的直接调研，因为汽车产品的复杂度太高，越是细节的问题，通过直接调研获得的数据越容易失真。表面上建立同理心之后，我们是再让评价团队替代真实用户进行判断，但由于评价团队本身的专业能力，以及他们对完整信息的掌握更加充分，他们在细节问题上的判断反而更加准确。

最后，解决完了上述问题后，我们需要明确体验评价的触点和主体。实际上我们设定的整个评价是有一支专业团队，在充分理解用户（建立同理心后）的基础上，沿着一组特定的场景和任务列表，探索被评价车辆解决这些任务的能力。在尝试解决这些任务的过程中，评测团队会探索各种可能涉及的功能，以及每个功能的具体性能表现。在这个逻辑中，评价的直接对象是每个用户任务，但体验或者探索触点是具体的每个可能被使用到的功能。因此我们等于是在探索每个任务完成过程和方式的过程中，操作每个可以为解决任务作出贡献的功能。再去评价和记录每个功能在解决任务过程中的性能表现，发挥作用的方式，并且记录这些功能的实现方式（硬件、软件或者设计等等）。

在具体评价的操作中，与解决用户任务对应的是一个个功能组合，但评价记录的细节是具体的每个功能，并且我们还要详细讨论这些功能目前的实现途径。最后，我们还需要针对整个任务列表，将体验到的所有功能组合加总到一起，形成对于整车功能、性能和体验的综合评价。这些概念的具体对应关系如下图所示：

之所以要使用这种对应方式，而不是沿着特定的功能进行逐点评价，这是因为功能本身是异常多样和复杂的。而且每个车拥有哪些功能，每个功能的具体实现方式都千差万别。用户对产品的体验要求并不能完全穿透到具体某个功能的呈现形式上面，直接深入细节的评价就会失去标准。

此外，不同车辆解决每个用户任务的途径也是不同的。比如一个家庭周末自驾游的过程中，想要让全家人在车上获得更多娱乐。不同车辆就可能提供截然不同的解决方案。有些车可能只能听收音机或者CD；有些车可以通过车载APP寻找网上音乐；有些车可以让副驾以及后排乘客看一部电影；有一些车可以支持车上卡拉OK或者玩游戏；还有些车的AI可以和全家人互动……因此，针对每个用户任务，我们都必须充分探索车辆各种可能完成这些任务的途径，并且详细记录和对比这些途径。从完成任务的具体途径出发，再去审视每个任务、每种途径当中涉及到的具体功能。这样每个功能发挥的价值完全取决于本次他要支撑的这项用户任务对应的价值。从任务角度出发，我们也可以更加清晰地定义每个功能的具体要求了。

有了上述概念准备，我们可以把整个体验评价的工作划分为以下几个步骤：

Step1-明确体验评价的背景和目标： 每一次评价我们都必须首先明确评价的背景和目的，不能仅仅是为了评价而评价。以SoCar & EFS的项目经验判断，通常用户体验评价可以解决以下几类问题：

只有我们明确了每次评价的目的，理解了每次评价的具体背景，才能更有针对性地设计体验评价的更多细节。虽然大体操作步骤和方法是类似的，但具体项目肯定存在诸多细节差异，往往真正有价值的地方也恰恰就隐藏在这些细微的差别之内。

关于评价的背景，我们还需要了解每个车企的品牌战略背景和产品战略背景。尽管市场中可能存在很多直接竞争的产品，他们的尺寸、性能、价格，甚至设计理念都有很强的相似性，但这些产品可能对于每个车企的战略布局而言是完全不同的。比如红旗H5和吉利博瑞就是这样的例子。前者是红旗品牌的入门级车型，后者则是吉利品牌轿车领域的旗舰车型。尽管两个产品在市场中的定位是大致重叠的，但他们各自承担的产品使命是不同的，只有真正理解这种使命的差异，才能准确理解他们在各种战术选择上的异同。

Step2-确定目标用户： 这一步骤前文介绍过，为了更有效地跟踪和描述用户，我们需要建立一组更加标准和规范化的人群分类系统。在这方面SoCar & EFS基于自己的数据系统，建立了一个将用户沿着购车预算以及产品价值诉求两个维度进行分类的坐标系统，如下图所示：

上述人群分类标准等于是把一个多维坐标投影到了一个二维坐标系下，这样可以更方便确定每个品牌或者每个车型的用户定位问题。当然，此图也对应着车企品牌与产品战略协同的问题，这一问题我们将在后续章节中展开讨论。总之，通过在上述坐标系中圈定一个范围，我们便可以描述目标用户群的更多信息。

Step3-圈定关键场景：这一问题我们需要引入上文提到的场景框架，使用这个框架我们可以研究不同细分市场，不同产品在场景层面的数据差异，也就是可以从场景覆盖角度审视产品定位问题。如下图所示：

基于这样的场景框架，在面向新产品策划、定义，或者开发目标检验的评价工作中，一方面我们可以根据相同细分市场，类似产品的场景覆盖作为目标车型场景覆盖的一个重要参考。另一方面我们也可以结合车企的品牌战略或者其他方面的目标诉求，有侧重地选择某些特定场景。结合这两大方面，目标车型的场景即可得以明确。

如果是面向现有产品的体验评价，我们可以直接筛选目标车型以及该车型所在细分市场的场景覆盖，以此作为后续梳理用户任务的基础。

当然，应用上述场景架构我们能获得的并非一款车需要关注场景的全部，事实上这个架构更多是在向评测团队展示目标车型在高频场景上与其他产品的差异。除了这些场景之外，我们还需要补充很多与之相关的，难以在这个架构中描述的其他场景，比如：

梳理这些场景很多需要研究团队的不断积累，但幸运的是，这类场景在数量上并不恐怖，只是不同产品，不同细分市场在描述场景的很多细节维度上略有差异。

Step4-建立与目标用户的同理心：在这一步骤当中，我们需要通过消费者洞察，让评价小组真正理解目标用户，建立与他们的同理心。由于目标用户的整体特征早在step1中即已界定，在这一步骤我们需要沿着step1的结果进一步深入。最典型的做法就是进行一定样本的目标消费者走访、焦点小组或其他形式的调研。

当然无论采取哪种形式的消费者调研，我们都必须聚焦在这一环节需要达成的目标上，也就是建立与目标用户的同理心。关于这一部分有很多成熟的工具，本书中我们不做重点探讨。

Step5-形成任务列表和体验要求： 在进行消费者洞察的过程中，我们还需要充分理解目标用户在各个关键场景中需要解决的主要问题有哪些，也就是确定用户任务。我们可以通过目标用户的深度访谈先构建出一个大致的任务列表，然后再通过焦点小组中引导更多的用户围绕这个列表进行讨论、补充、再激发，形成更多的任务列表。最后，我们再对调研获得的这些任务进行筛选，合并相似内容，并且结合目标用户的体验要求，形成评价所需的一组任务。由于不同细分市场面对的场景和任务具有很强的重复性，我们在每次评测过程中需要对调研整理的这些任务列表进行积累，这些积累可以作为下一轮或者其他细分市场体验评价的基础。这就需要我们对场景和任务进行更加规范的记录，通过建立相应的数据库，对每个场景和任务进行编号管理是我们最推荐的做法。

在确定任务列表后，我们还需要真正理解用户在这些任务当中的体验诉求。也就是说，我们需要与用户建立同理心的基础上，真正理解用户为什么需要完成这些任务，以及完成每个任务过程中他们期待获得的收获或者规避的痛点是什么。这些收获或者痛点往往可以指向一组特定的体验因子（也就是前文我们提到的体验要求）。

在分析每项任务对于目标用户价值的过程中，我们可以借用一些相对成熟的工具，比如用以设计价值主张的用户任务分析地图。他可以将每个任务进一步朝着给用户带来的利益以及用户期待规避的痛点进行拆分。如下图所示：

这一步骤我们最终需要的是，明确目标用户在每个任务上需要获得的体验因子，也就建立任务列表与体验因子的对应关系。

以上相当于是实车评测前的数据准备工作，当然最为重要的是，我们需要组建一支能够胜任此次评价的专业团队。一方面他们必须受够专业训练，能够顺利发现和操作车辆的主要功能，并且能够对这些功能给出恰当的评价。这就要求这组人员必须体验过数量足够的车，他们头脑中要存储足够的产品设计和功能案例。另一方面，这个团队需要真正理解用户，理解市场。只有这样他们给出的洞察和评价才能真正与目标车型相匹配，而不是像很多汽车网站的评测编辑那样总是陷入教条。这就要求这支团队必须具备多年的市场分析经验，并且与众多真实用户进行过大量面对面的交流。除此之外，支持评测团队背后的数据系统和知识库也至关重要，因为很多洞察都必须建立在大量数据和知识的积累之上，而且每次评价也需要成为下一次评价的知识积累。

Step6-进行体验评价的实际操作： 在完成了上述准备工作后，我们需要进入实车体验的操作环节。

这里首先说一下评价团队的构成和分工。由于SoCar&EFS是一家咨询公司，我们更多的项目实践是帮助车企提升产品战略能力的。因此在这类项目当中，我们一方面需要组织并执行评价，另一方面需要向车企客户转移知识。这个评测团队就需要兼顾上述两方面的目标。在这种情况下，评测团队由4~5人组成，他们会始终在一起完成每部车，每个场景以及每个任务的体验。在这4~5人当中，有3名来自SoCar&EFS的人员，一人负责车辆的各种驾驶和功能操作。因此这个人必须是前文提到的产品专家，他需要拥有非常充分的产品知识和驾驶经验。该小组的第二个重要成员负责确保每个场景和任务按照计划推进，并且他需要全程参与此前的数据分析以及消费者洞察，他是整个团队当中最理解用户的人，他需要基于自己建立的同理心与整个小组进行讨论。第三个人主要负责在过程当中进行拍照、摄像或者其他形式的记录工作。在评级结束之后，他还面临非常繁杂的资料归集任务。 该小组的另外1~2人来自我们的客户，他们可以在全程参与评价，通过与小组的讨论获得对产品最直观的理解，当然他们也要把这些感受在后续的workshop中传递给其他同事。

尽管上述小组每个角色有明确的分工，但我们还是希望团队当中的每个成员都具备足够的产品知识，以及对用户充分的理解能力。只有这样评价小组对产品细节的讨论才能足够充分，形成的洞察才能更加深刻。

具体评价操作阶段，用户体验评价对于场地和测量工具并没有确定的要求，无非就是评价小组按照场景和任务列表中的要求，逐车探索每个任务的完成途径，并且记录这些途径，以及每个途径涉及到的功能组合等。

Step7-完善评级记录和洞察文档：在整个体验评价当中，最为重要的就是评价记录和洞察文档的形成。一方面，我们需要建立规范的评价记录文档，并在评测团队内部设置明确的分工；另一方面，我们也需要更多设备把整个评价过程全面、多角度地拍摄记录下来，以便大家事后查阅相关信息。

这里不得不说目前的用户体验评价工作还有很大的“自由探索空间”存在，这主要是由于不同产品在响应同一组用户任务的时候，往往提供了多种不同的解决方案。因此体验评价团队需要探索并记录各种可能的途径。当然这也给记录和后续整理工作带来很大挑战，但我们认为至少在变革过程中，这种局面短期是不会改变的。因此SoCar& EFS的记录文档更多是记录每项任务的多种实现路径这一前提设计准备的。每项任务的记录表达如下图所示，每一项用户任务，每一部车都需要完整填写这样一张表单：

在记录过程中，我们还需要针对每个任务的完成情况，每个功能的性能和设计情况形成更加具体的记录。其中也会用到很多概念，相关说明如下：

Step8-量化结果统计与关键发现总结： 如果仅仅服务于产品定义或研发部门，上述表单形成的记录和洞察便足以说明很多问题。但为了服务于更多部门，乃至在车企内部形成更为广泛的共识，我们就必须对每个产品形成一些量化评价结论。尽管我们认为量化结论会损失很多信息，或者误导管理层把注意力集中到得分而非具体问题上。但任何事情都是双刃剑，没有量化结论的评价是无法在企业内部广泛传播的，为了降低风险，我们能做的更多是在打分的同时，提供更多关于得分的具体描述和洞察文本。

由于在上一节的评测记录表格中，我们已经对很对维度进行了量化打分，在这一步骤当中我们需要做的更多是使用合理的方式将这些打分汇总起来，用以揭示每部车的用户体验结果。为了将针对用户任务和具体功能形成的评价与整个用户体验的形成过程结合起来，我们需要回到上一章节梳理的那个用户体验圆环。在此我们不妨把此前的诸多概念放在同一张图表中展示一下他们之间的逻辑关系，如下图所示：

上图的左侧中心位置是用户体验在每次User journey当中的形成过程，圆环周围是站在供给方（车企）以及需求方（用户）角度对应的各种概念。右侧则示例了用户体验圆环的形成过程。

为了能够填满这个圆环的几个主要步骤，我们需要将评测涉及到的场景和用户任务以合理的权重放置在合适的位置上。为此我们需要返回到各个场景以及每个场景下的各个任务当中，为这些场景和任务赋权。正如上文说到的，赋权本身是为了降低信息的复杂度，但鲁莽的降维是危险的，因此我们需要尽可能保留更多有效信息。SoCar & EFS的经验是把这些场景和任务按照浅层体验和深层体验两大类别建立两套权重，这样前者可以解释营销问题，后者可以解释产品和品牌的根本问题。

这里需要说明的是，整个体验评价过程，我们能够量化描述的更多是使用和感受两个环节，也就是将每个功能对应的性能按照他们被使用到的场景和任务进行评价结果的得分加总，同时也把每个功能对应的体验进行加总。前者指向使用环节，后者指向感受环节。至于预期环节，更多是通过评价操作前分析每个品牌，每个产品的背景信息，浏览这些产品的官网介绍以及其他宣传资料获得的，也就是记录这些产品试图为用户建立的预期有哪些。这个节点的描述只能是定性的，而非定量的。

最后，关于回忆环节，他来自于整个评测团队的后期讨论，但是大家必须给出每个观点的详细理由，最后这个理由要在评测团队内部达成共识。回忆环节的评价也是定性而非定量的。

针对整个用户体验圆环，我们需要分析影响每一步骤的关键信息，并梳理成与体验形成过相关的主要发现，具体展示如下图所示：

Step9-团队整体的研讨与结论输出：评价最终还是为了应用服务的，尽管不同目的的评价需要解决的具体问题，涉及到的人员以及操作的模式有所不同，但都需要在团队内部进行充分的讨论，并达成共识。作为用户体验评价的最后一个步骤，组织相关部门和管理层进行workshop，全面介绍评价结论，讨论争议问题，梳理自身的行动策略都是必不可少的工作。有时候在体验评价小组完成具体评价以后，为了向管理层更清晰、准确地传达结论，除了各种PPT汇报文档以外，剪辑各种视频文件，甚至设计一个新的体验主线，邀请管理层一起参与实车评价和研讨也都是非常有效的工作方式。