之前我们看到很多说法提到汽车行业将进入“软件定义硬件”的时代，实际上这种说法并不准确，由于汽车产品使用环境的复杂性，车规级别要求的严苛性，硬件的复杂度短期很难大幅下降。而且随着电动化探索的加快，很多燃油车上的硬件结构又必须做出改变。从特斯拉等新造车公司的很多做法看，这种硬件结构的探索过程很有一种汽车行业早期的感觉。想必这种探索还要持续相当一段时间，直至电动化的技术路线成熟稳定为止。但行业变革导致汽车功能增多，功能组合的个性化要求进一步提升却是一定的，也就是说未来描述汽车的语言更应该以功能作为切入点。因此与其说软件定义硬件倒不如说功能定义汽车更准确。

既然是以功能定义汽车，我们对功能本身的描述就会变得更加重要。在这个问题上，我们需要给功能下更加准确的定义，并沿着这些定义梳理和积累Function list。从概念上，既然每个用户任务都是通过使用一组功能组合完成的，那么反过来，功能的本质就是用户任务的最小单位。或者说，每个功能都可以被定义为“有明确目的的明确操作”。

比如笼统而言，打开车窗这件事可以算是一个功能。但如果在具体use case当中，打开不同位置的车窗、在不同位置打开同一个车窗、使用不同方式打开同一个车窗都是不同的功能，或者说实现同一个结果的不同操作。之所以车上需要对应同一个结果有多种不同的操作，是因为进行这些操作的目的不同。目的是与具体产生这些目的的使用场景密切相关的。比如还是打开车窗，如果你从停车场出来要交停车费，这个时候你的场景就是坐在驾驶座上，需要用触手可及的方式把左前车窗打开。目的是为了把手伸出去交钱，因此使用左手旁边的按钮是完成这一操作的最佳选择。恐怕你不会为了完成这个操作使用语音控制或者到大屏幕上寻找打开车窗的菜单，更加不会使用遥控钥匙。而如果当时的场景是在车外，比如夏天回到车里之前想给车内降降温，你打开车窗的最佳方式基本就是遥控钥匙了。因此即便对于打开车窗这样一个相同的结果，由于目的不同、操作路径不同，对应的功能也是不同的。

沿着有明确目的的明确操作，一方面我们可以把每一个用户任务不断向下拆分，直至不可拆分的阶段。另一方面，我们还可以描述影响这个具体use case的维度有哪些。比如当时的环境、车上的人数、路况、天气等等。这样我们不仅可以形成一张庞大，但具体的Function list表单，还可以围绕每个function 梳理影响这个function的关键因素有哪些，而这些因素本质上也是用来描述场景的。这样场景库的管理工作也等于被向前推进了一大步，而且这样梳理出来的场景库不仅更具可操作性，还会控制冗余数据的规模，效率更高。

在完善了Function list之后，既然这一功能列表同时连接体验主线、用户任务、开发目标、性能要求和成本等多个关键维度，他就应该成为用户体验管理在产品层面最终的落脚点，也应该成为用户体验管理的“法典”。

基于这个法典，从产品定义阶段开始，我们就要对每个功能做出尽可能详细的需求描述，包括这些功能的典型使用场景、功能利益、可能衍生出的其他功能、可能的交互或者操作方式等等。如果可能，还可以给出这些功能现有的参考案例或者描述这些功能的草图。

更加重要的，从功能角度定义汽车，也意味着我们有机会反思车辆到底需要多少种硬件，需要什么样的底层架构。这会帮助我们找到重新定义车辆底层结构的重要线索或者约束条件。实际上类似变革在智能手机领域早已发生过了：今天我们的智能手机在硬件结构上非常简单，只有屏幕、主板、WIFI模块、移动通讯模块、GPS、陀螺仪、两个摄像头、闪光灯、指纹识别等不超过10个模块化组建。但这些智能机却可支持上百万种功能，每个APP都是一个功能。不同的APP把硬件模块的潜能调用起来，变成各种巧妙的实用化功能。

显然汽车行业也会像这个方向发展，或者已经在朝这个方向发展了。尽管汽车本身的复杂性使得基础硬件模块的数量会远远高于智能手机。如下图这个例子，随着无人驾驶功能的增加，车辆对环境、路况的感知能力得到很大提升，芯片的算力也需要比之前有更多冗余。这等于在车辆的基础架构上做了很多加法。与此同时，这也给我们打开更多功能或者使用场景提供了更多可能。比如通过视觉系统，调用存储空间，即可实现行车记录仪的功能。这个组合如果到了野外风景秀美地方还可以成为自动记录路书的功能。当然，如果希望让这个路书更生动，可能还会强化一下对于拍照功能的定义，以及增设一些路书模板。再如利用车辆外部的各个传感器，还可以设置电子围栏。总之，只要车辆的感知、分析和决策能力具备了，调用这些基础能力就可以打开更多功能，与此同时硬件的复杂度并不会出现显著上升，当然成本上升幅度也会比堆积硬件小得多。关键是我们需要准确定义车辆的基础能力。

总之，在汽车产品形态不断变革的过程中，我们看到所有一切的本质都是为用户创造更好的体验。为了创造这种更好的体验，我们需要在用户最期待的场景中，提供对完成用户任务最有帮助的功能组合，并且给这组功能组合设定与体验要求最匹配的呈现方式（设计）以及性能设定。反过来，当我们把功能组合的问题研究清楚后，如何支撑、如何实现这些功能又是另外一个问题。从功能需求反推，我们又可以更准确地给下一代产品架构提出更加明确的要求。

这是未来产品定义的关键逻辑，也是帮助我们穿越这个变革周期的最佳路径。这一切都应紧密围绕在Function list这个法典周围。

最后，再多说一句，汽车行业用户体验的形成过程与互联网行业是存在本质不同的。互联网行业的使用场景更加单一，也很难划分浅层体验与深层体验过程。因此那些来自互联网行业的用户体验模型更多聚焦于从user journey角度将体验过程步骤化，比如将用车过程划分为出发前、上车过程、驾驶过程、抵达和停车过程、离车过程……然后再梳理每个过程的用户任务、体验要求、情绪曲线等等。我不能说这种方式一定是错误的，但由于这种方式并不是根据汽车行业的特征进行的归纳和抽象，应用这种方法后续对应的场景数量会非常恐怖，他与产品定义、研发、营销等整个链条的协同关系也很难被有效定义。因此，若要在汽车行业贯彻用户体验管理目标，就必须从这个行业自身的特点出发，定义属于这个行业的方法论。

返回第一电动网首页 >