之前我們看到很多說法提到汽車行業將進入“軟件定義硬件”的時代，實際上這種說法并不準確，由于汽車產品使用環境的復雜性，車規級別要求的嚴苛性，硬件的復雜度短期很難大幅下降。而且隨著電動化探索的加快，很多燃油車上的硬件結構又必須做出改變。從特斯拉等新造車公司的很多做法看，這種硬件結構的探索過程很有一種汽車行業早期的感覺。想必這種探索還要持續相當一段時間，直至電動化的技術路線成熟穩定為止。但行業變革導致汽車功能增多，功能組合的個性化要求進一步提升卻是一定的，也就是說未來描述汽車的語言更應該以功能作為切入點。因此與其說軟件定義硬件倒不如說功能定義汽車更準確。

既然是以功能定義汽車，我們對功能本身的描述就會變得更加重要。在這個問題上，我們需要給功能下更加準確的定義，并沿著這些定義梳理和積累Function list。從概念上，既然每個用戶任務都是通過使用一組功能組合完成的，那么反過來，功能的本質就是用戶任務的最小單位。或者說，每個功能都可以被定義為“有明確目的的明確操作”。

比如籠統而言，打開車窗這件事可以算是一個功能。但如果在具體use case當中，打開不同位置的車窗、在不同位置打開同一個車窗、使用不同方式打開同一個車窗都是不同的功能，或者說實現同一個結果的不同操作。之所以車上需要對應同一個結果有多種不同的操作，是因為進行這些操作的目的不同。目的是與具體產生這些目的的使用場景密切相關的。比如還是打開車窗，如果你從停車場出來要交停車費，這個時候你的場景就是坐在駕駛座上，需要用觸手可及的方式把左前車窗打開。目的是為了把手伸出去交錢，因此使用左手旁邊的按鈕是完成這一操作的最佳選擇。恐怕你不會為了完成這個操作使用語音控制或者到大屏幕上尋找打開車窗的菜單，更加不會使用遙控鑰匙。而如果當時的場景是在車外，比如夏天回到車里之前想給車內降降溫，你打開車窗的最佳方式基本就是遙控鑰匙了。因此即便對于打開車窗這樣一個相同的結果，由于目的不同、操作路徑不同，對應的功能也是不同的。

沿著有明確目的的明確操作，一方面我們可以把每一個用戶任務不斷向下拆分，直至不可拆分的階段。另一方面，我們還可以描述影響這個具體use case的維度有哪些。比如當時的環境、車上的人數、路況、天氣等等。這樣我們不僅可以形成一張龐大，但具體的Function list表單，還可以圍繞每個function 梳理影響這個function的關鍵因素有哪些，而這些因素本質上也是用來描述場景的。這樣場景庫的管理工作也等于被向前推進了一大步，而且這樣梳理出來的場景庫不僅更具可操作性，還會控制冗余數據的規模，效率更高。

在完善了Function list之后，既然這一功能列表同時連接體驗主線、用戶任務、開發目標、性能要求和成本等多個關鍵維度，他就應該成為用戶體驗管理在產品層面最終的落腳點，也應該成為用戶體驗管理的“法典”。

基于這個法典，從產品定義階段開始，我們就要對每個功能做出盡可能詳細的需求描述，包括這些功能的典型使用場景、功能利益、可能衍生出的其他功能、可能的交互或者操作方式等等。如果可能，還可以給出這些功能現有的參考案例或者描述這些功能的草圖。

更加重要的，從功能角度定義汽車，也意味著我們有機會反思車輛到底需要多少種硬件，需要什么樣的底層架構。這會幫助我們找到重新定義車輛底層結構的重要線索或者約束條件。實際上類似變革在智能手機領域早已發生過了：今天我們的智能手機在硬件結構上非常簡單，只有屏幕、主板、WIFI模塊、移動通訊模塊、GPS、陀螺儀、兩個攝像頭、閃光燈、指紋識別等不超過10個模塊化組建。但這些智能機卻可支持上百萬種功能，每個APP都是一個功能。不同的APP把硬件模塊的潛能調用起來，變成各種巧妙的實用化功能。

顯然汽車行業也會像這個方向發展，或者已經在朝這個方向發展了。盡管汽車本身的復雜性使得基礎硬件模塊的數量會遠遠高于智能手機。如下圖這個例子，隨著無人駕駛功能的增加，車輛對環境、路況的感知能力得到很大提升，芯片的算力也需要比之前有更多冗余。這等于在車輛的基礎架構上做了很多加法。與此同時，這也給我們打開更多功能或者使用場景提供了更多可能。比如通過視覺系統，調用存儲空間，即可實現行車記錄儀的功能。這個組合如果到了野外風景秀美地方還可以成為自動記錄路書的功能。當然，如果希望讓這個路書更生動，可能還會強化一下對于拍照功能的定義，以及增設一些路書模板。再如利用車輛外部的各個傳感器，還可以設置電子圍欄。總之，只要車輛的感知、分析和決策能力具備了，調用這些基礎能力就可以打開更多功能，與此同時硬件的復雜度并不會出現顯著上升，當然成本上升幅度也會比堆積硬件小得多。關鍵是我們需要準確定義車輛的基礎能力。

總之，在汽車產品形態不斷變革的過程中，我們看到所有一切的本質都是為用戶創造更好的體驗。為了創造這種更好的體驗，我們需要在用戶最期待的場景中，提供對完成用戶任務最有幫助的功能組合，并且給這組功能組合設定與體驗要求最匹配的呈現方式（設計）以及性能設定。反過來，當我們把功能組合的問題研究清楚后，如何支撐、如何實現這些功能又是另外一個問題。從功能需求反推，我們又可以更準確地給下一代產品架構提出更加明確的要求。

這是未來產品定義的關鍵邏輯，也是幫助我們穿越這個變革周期的最佳路徑。這一切都應緊密圍繞在Function list這個法典周圍。

最后，再多說一句，汽車行業用戶體驗的形成過程與互聯網行業是存在本質不同的。互聯網行業的使用場景更加單一，也很難劃分淺層體驗與深層體驗過程。因此那些來自互聯網行業的用戶體驗模型更多聚焦于從user journey角度將體驗過程步驟化，比如將用車過程劃分為出發前、上車過程、駕駛過程、抵達和停車過程、離車過程……然后再梳理每個過程的用戶任務、體驗要求、情緒曲線等等。我不能說這種方式一定是錯誤的，但由于這種方式并不是根據汽車行業的特征進行的歸納和抽象，應用這種方法后續對應的場景數量會非常恐怖，他與產品定義、研發、營銷等整個鏈條的協同關系也很難被有效定義。因此，若要在汽車行業貫徹用戶體驗管理目標，就必須從這個行業自身的特點出發，定義屬于這個行業的方法論。

返回第一電動網首頁 >