汽车行业的产品经理和互联网产品经理，到底有什么区别？在互联网产品中，我们谈论的是点击率、留存和日活；但在智能座舱里，我们谈论的重点变成了空间、感知和反馈。
我见过太多从手机圈跳槽过来的同行，他们很容易习惯性地把座舱当成带轮子的手机或平板，试图在大屏上堆砌功能，却经常忽略了驾驶场景下这些功能可能对用户丝毫没有价值。
互联网产品经理习惯了在屏幕那块二维平面上去吸引用户，而车是三维的物理空间，我们需要关注屏幕，更需要关注屏幕以外的要素。
同样是“听音乐”这个动作，在车里涉及的是整套硬件链路。当你开始考虑用户的疲劳程度，试着去联动调节座椅的倾角、车内氛围灯的颜色和变化节奏，甚至音响的指向性。这些要素的变化会让“听音乐”这个任务瞬间变得更多样化。
给大家分享一个我经常用来校准功能定义的工具——CPTH模型，它能帮你跳出手机端的存量思维。
C (Context) 场景： 谁？在什么时候？在什么地方？
场景定义得越细，后面的功能逻辑就越稳。
比如：早高峰通勤、雨天高速驾驶、午间车内小憩、接孩子放学。
P (Psychology) 心理： 用户当下的情绪是什么？
要区分用户的显性需求和隐性心理。
比如，在“暴雨驾驶”这个场景下，用户的心理不是“想看路”，而是“恐惧”和“不确定感”。抓住了“恐惧”，你给出的方案就不只是打开雨刮，而可能是AR-HUD的增强路径引导。
T (Task) 任务： 在这样的场景下，用户和座舱各需要做什么？
为了消解用户的心理焦虑，座舱系统需要执行哪些动作？
是主动弹窗提醒？是自动调节空调？还是发起一段语音对话？
H (Hardware/Data) 硬件与数据： 我们调动哪些传感器和执行器去支撑任务的完成？
比如需要DMS摄像头还是车外环视摄像头？需要座椅按摩还是氛围灯光？数据来源是车内传感器还是地图的API？
当CPTH模型的四个维度都定义完了，一个场景便完整地经过了从“虚”到“实”的链路。下一步就是拿着这个场景定义去跟对应的部件工程师讨论信号和硬件是否能支持了。
并且，CPTH模型还可以反着用。
比如当你发现竞品出了一个新功能时，你可以试着用 CPTH 拆解它：
如果拆解下来发现P很牵强，或者H的数据源无法稳定，那这个功能大概率不适合真实用户场景或者因为硬件性能达不到而不适合在目标车型上跟进搭载。
最后
CPTH模型的本质，其实就是把感性的场景描述翻译成可以拿在台面上跟设计师、工程师一起讨论可行性的场景方案。希望这个模型能帮你在日常工作避免一些因主观讨论而浪费过多精力的问题。
文章来源公众号 AI HMI
