汽車進入智能化時代，軟件定義硬件逐漸成為必然。然而配置表依然是大家最為常用的用來描述汽車產品的語言，這顯然已經越來越不合時宜了。舉一個最為直接的例子，如果你去各大汽車網站上通過參數和配置表對比一下特斯拉和奔馳，你可能看不出有什麼顯著的不同，但只要你認真開過這兩種車，你會感受到真實存在的天壤之別。
也正因如此，過去兩年來我始終在倡導使用功能、性能和體驗三個維度重新構建描述汽車的語言。首先功能是很容易被所有人理解的語言，他用來描述汽車能為用戶做哪些事。性能則是這些功能在解決問題時的能力，他與技術水平、成本和設計策略直接相關。最後是體驗，這裡所說的體驗更多是建立在功能組合之上的綜合體驗。當然每個具體的功能也會給用戶帶來某種體驗，綜合體驗在一定程度上相當於這些局部體驗的加法。
改變描述產品的語言，本質上意味著產品定義思考方式的顯著變化。過去我們定義產品更多是在一個相對固定的基礎（平臺）上疊加配置組合以及某種內外飾造型概念。配置表實際上是過去我們描述產品最常用的語言，他與今天我們所說的功能幾乎是一一對應的關係。但如今隨著智能車時代的來臨，功能與配置分離的趨勢越發明顯，單純從配置角度描述產品就會出現文章開頭說的那種不合時宜。為了更準確地定義智能車時代所要達成的創新目標，我們必須使用更加場景化的思維，只有把創新置於確定的場景中，大家才能真正理解產品該解決用戶的什麼問題，以及解決到什麼程度。這恰恰就是產品該為用戶提供的功能，以及每個功能的性能水平和使用體驗。這實際上是一種從使用場景角度出發的，圍繞產品功能利益和用戶體驗開展的產品定義思路。
如果單純使用上面的文字描述前後兩種思路的差異肯定有些乏味和空洞，也許大家看到下面這個案例就會更有感覺一些：
這是www.electrek.co 上面爆出的來自奧迪E-tron的行車電腦截圖，這臺電動車在提示用戶需要更換機油了。顯然，如果延續過往的那種開發組織模式，一旦遭遇行業變革就有可能出現這種問題，畢竟各專業領域在產品誕生過程中均有各自積澱多年的成熟標準。在用戶看來是一個整體的汽車產品，在開發過程中是被分割成若干部分平行推進開發進程的。矩陣式管理以及集中評審雖然可以解決大部分系統協同問題，但無法解決問題的全部，更加不能完全站在用戶體驗的角度讓整個體驗過程連貫、統一。就像上圖這種從燃油車時代延續過來的標準，最終到了電車上還是會有"漏網之魚"。
其實類似的例子還有很多，比如今天很多車輛都開始使用雙聯屏方案，但屏幕左側的儀表界面來自一家供應商，右側的車機界面則是來自另一家供應商。這兩部分雖然在硬件上拼接在了一起，但界面設計、交互感受卻並不統一。再比如我們近期體驗過的一款車，他的音響系統和導航系統均可通過語音控制調節音量，但音響音量的最大值是40，而導航音量的最大值是10。顯然作為用戶的你是很難記住這種差異的，於是當你通過AI讓他把導航音量音量設置為10的時候，喇叭都會炸裂，而用這個數字的音量放歌你還不怎麼能聽清楚！
圍繞這些用戶體驗觸點上的各種分工協作，其實存在大量"三不管地帶"。用戶體驗管理的首要目標就是消滅這些盲區。以用戶體驗為核心進行產品定義，首先需要明確誰（目標用戶）在什麼場合下（場景）使用這個產品，以及他們需要這個產品解決哪些問題（用戶任務），給自己帶來何種體驗感受。
基於上述線索，我們即可構建從建立用戶預期，到定義用戶使用過程，形成使用感受，乃至設計產品想要帶給用戶的最終回憶這樣一個完整的閉環。在這個閉環當中，我們必須清楚產品的每個功能在發揮什麼作用以及如何發揮作用，只有這樣我們才能判斷這些功能是否具有價值，以及該用什麼樣的解決方案實現這種功能。同樣，基於這樣的思路，我們才能更順利地迎接產品形態變革帶來的挑戰，向軟件定義硬件時代過渡。
閱讀更多 張曉亮 的文章
