汽車進入智慧化時代，軟體定義硬體逐漸成為必然。然而配置表依然是大家最為常用的用來描述汽車產品的語言，這顯然已經越來越不合時宜了。舉一個最為直接的例子，如果你去各大汽車網站上通過引數和配置表對比一下特斯拉和賓士，你可能看不出有什麼顯著的不同，但只要你認真開過這兩種車，你會感受到真實存在的天壤之別。

也正因如此，過去兩年來我始終在倡導使用功能、效能和體驗三個維度重新構建描述汽車的語言。首先功能是很容易被所有人理解的語言，他用來描述汽車能為使用者做哪些事。效能則是這些功能在解決問題時的能力，他與技術水平、成本和設計策略直接相關。最後是體驗，這裡所說的體驗更多是建立在功能組合之上的綜合體驗。當然每個具體的功能也會給使用者帶來某種體驗，綜合體驗在一定程度上相當於這些區域性體驗的加法。

改變描述產品的語言，本質上意味著產品定義思考方式的顯著變化。過去我們定義產品更多是在一個相對固定的基礎（平臺）上疊加配置組合以及某種內外飾造型概念。配置表實際上是過去我們描述產品最常用的語言，他與今天我們所說的功能幾乎是一一對應的關係。但現在隨著智慧車時代的來臨，功能與配置分離的趨勢越發明顯，單純從配置角度描述產品就會出現文章開頭說的那種不合時宜。為了更準確地定義智慧車時代所要達成的創新目標，我們必須使用更加場景化的思維，只有把創新置於確定的場景中，大家才能真正理解產品該解決使用者的什麼問題，以及解決到什麼程度。這恰恰就是產品該為使用者提供的功能，以及每個功能的效能水平和使用體驗。這實際上是一種從使用場景角度出發的，圍繞產品功能利益和使用者體驗開展的產品定義思路。

如果單純使用上面的文字描述前後兩種思路的差異肯定有些乏味和空洞，也許大家看到下面這個案例就會更有感覺一些：

這是www.electrek.co 上面爆出的來自奧迪E-tron的行車電腦截圖，這臺電動車在提示使用者需要更換機油了。顯然，如果延續過往的那種開發組織模式，一旦遭遇行業變革就有可能出現這種問題，畢竟各專業領域在產品誕生過程中均有各自積澱多年的成熟標準。在使用者看來是一個整體的汽車產品，在開發過程中是被分割成若干部分平行推進開發程序的。矩陣式管理以及集中評審雖然可以解決大部分系統協同問題，但無法解決問題的全部，更加不能完全站在使用者體驗的角度讓整個體驗過程連貫、統一。就像上圖這種從燃油車時代延續過來的標準，最終到了電車上還是會有"漏網之魚"。

其實類似的例子還有很多，比現在天很多車輛都開始使用雙聯屏方案，但螢幕左側的儀表介面來自一家供應商，右側的車機介面則是來自另一家供應商。這兩部分雖然在硬體上拼接在了一起，但介面設計、互動感受卻並不統一。再比如我們近期體驗過的一款車，他的音響系統和導航系統均可通過語音控制調節音量，但音響音量的最大值是40，而導航音量的最大值是10。顯然作為使用者的你是很難記住這種差異的，於是當你通過AI讓他把導航音量音量設定為10的時候，喇叭都會炸裂，而用這個數字的音量放歌你還不怎麼能聽清楚！

圍繞這些使用者體驗觸點上的各種分工協作，其實存在大量"三不管地帶"。使用者體驗管理的首要目標就是消滅這些盲區。以使用者體驗為核心進行產品定義，首先需要明確誰（目標使用者）在什麼場合下（場景）使用這個產品，以及他們需要這個產品解決哪些問題（使用者任務），給自己帶來何種體驗感受。

基於上述線索，我們即可構建從建立使用者預期，到定義使用者使用過程，形成使用感受，乃至設計產品想要帶給使用者的最終回憶這樣一個完整的閉環。在這個閉環當中，我們必須清楚產品的每個功能在發揮什麼作用以及如何發揮作用，只有這樣我們才能判斷這些功能是否具有價值，以及該用什麼樣的解決方案實現這種功能。同樣，基於這樣的思路，我們才能更順利地迎接產品形態變革帶來的挑戰，向軟體定義硬體時代過渡。