之前连续写了两篇关于概念定义的文章，今天继续探讨一下我对使用场景这个概念的理解。与用户体验相似，使用场景也是如今汽车行业热度极高的词汇，但大家经常各说各话。都是同一个词，内涵却大不相同（实际上就连什么是目标用户，车企不同部门所指的含义也不一样）。

那么什么是汽车的使用场景呢？这个概念既简单又复杂。

首先，从普通用户视角，大家经常挂在嘴边的那些类似于上下班代步、上街买菜、自驾游之类的肯定属于使用场景。显然这些场景通常指向汽车的具体用途，而且是存在某种大家约定俗成的分类的使用用途。在SoCar的用户体验管理架构当中，什么是产品定位？无非就是你准备把车卖给谁，谁来用，以及这些人准备把车用在哪些场合。这里场合就是用途，卖给谁以及谁来用就是利益相关者。于是乎，我们可以把这些最容易被大家理解的场景与利益相关者叠加，形成对产品定位的描述。

那么这种场景描述有什么问题呢？显然，这太笼统，既无法解决竞争策略问题，也无法解决产品定义和产品设计问题。但这种场景很容易被统计出来，因为用户很容易理解，也容易自己统计各自实际用车过程中对这些场景的覆盖问题。于是我们可以在这类场景中构建一个结构化的数据，通过场景覆盖和频次分布更加具体地解释产品定位问题。当然这里我们明确反对给这类场景赋权，因为这种权重既没有绝对意义（比如99%的上下班代步和1%的其他场景，在权重上该如何分配，有什么明确的含义？），也缺乏相对意义（因为这些场景太笼统，无法具体指向产品的开发目标）。

也正是因为上面那种场景描述的太过于笼统，我们才看到技术开发人员往往会从更小的颗粒度，更具体的使用环境出发描述每个场景。当然也有这种情况，也就是现有功能或者创意，再去梳理他们可以展现能力的场景有哪些。比如哨兵模式这组功能，他起作用的场景往往指向非常具体的事件。再比如当我们对比NFC钥匙和传统钥匙的时候，也可以拿NFC钥匙不具备蓝牙定位，也不具备机械钥匙在车辆断电时仍可开启车门的能力。这里我们看到的也是一个个需要使用这些功能的具体使用场合或者面对的事件。比如拿着NFC钥匙下车离开，这个就是一个非常具体的使用片段，而车辆断电则是一个事件。

看了这类案例，我们可以理解为了解决功能定义和功能开发问题，场景的描述必须是具体的，有细节的。但这又一定会带来一些新的问题，比如这些场景缺乏体系感，场景的数量无法穷尽，也很难梳理场景与场景之间的关系。因此我们需要一个逻辑框架管理这些更加具体的场景。

三个月前我在另外一篇文章《什么是可用场景库》当中，曾经给场景下了一个定义：场景是由一组条件变量共同描述的，对应明确用户意图的，由特定事件触发的状态。基于这个定义，构成一个新场景的必要条件至少包括以下3条：

1、 用户意图是明确的，用户意图既包含显性的用户任务，也包含车辆正常行驶必须的控制条件。

2、 由上一个场景切换至当前场景的触发条件是某一个或某类事件。

3、 用户意图在两个相邻场景中是不同的。

这样的定义意味着场景的本质实际上是由车况、路况、车上乘员状态、天气、时间等一系列条件变量共同描述的一个组合。但在构建场景库的过程中，我们又不能一下子深入如此多的细节，我们需要一个分层结构沿着上述定义去发现、梳理并管理一个庞大的场景库。

在SoCar的场景库中，我们将场景分为三个层级：

一级场景，由前文所说的使用场合与利益相关者共同决定，用来描述产品定位问题。

二级场景，我们在每个一级场景的基础上，沿着User Journey对这些场景进行切分，然后每个用户旅程的片段就成为叠加各类复杂事件，向下一级衍生各种新场景的基础。在SoCar的产品定义逻辑中，二级场景解决的是竞争策略问题。

三级场景，也就是经过具体事件叠加后的形成的细节状态。由于它们源自于每一个二级场景，而二级场景又能够展示具体的使用环境和用户所处的用车步骤，于是每个事件产生的影响，以及用户需要针对这些影响作出的响应（也就是用户意图）就是明确的。因此这些用户意图对应的功能和服务需求也就是明确的。因此SoCar的三级场景指向具体的产品开发目标定义问题。

我们认为智能车最重要的本质就是在硬件数量有限的前提下，持续通过提高硬件在不同场景下的多用性、多样性以及复用性，再通过软件持续激发这些硬件的潜能，达到可以为用户提供更多功能和服务的目标。如果站在这个角度看，每一个硬件以及硬件的具体功能都是车辆的原子级属性，这是构成车辆的最小单位。但车辆的化学属性是由一个个功能组合决定的，也就是把这些原子按照具体的使用场景和用户意图巧妙地组合起来，创造出一组组多样化的功能组合。如果做到这一点，汽车才会真的如今天的智能手机那样，虽然只有几个模块化的硬件，但通过软件却可以向用户提供上百万种功能组合。在这个体系中，场景库起到了连接整个链条的关键作用。

返回第一电动网首页 >