前言

筆者在車聯(lián)網(wǎng)行業(yè)任職HMI視覺設計師，由于HMI設計發(fā)展的較晚，所以基本上在開始進入到這個領(lǐng)域的人，大多來自于互聯(lián)網(wǎng)行業(yè)。由于互聯(lián)網(wǎng)行業(yè)發(fā)展的比較早，形成了一套成熟的工作流程，即：分工明確的遞進式協(xié)作：交互設計師要等到產(chǎn)品PRD評審結(jié)束才開始介入需求，然后交付黑白線框稿等給到視覺設計師繼續(xù)跟進。這種工作模式可以讓每個人在自己的崗位上做得更加專業(yè)，成為垂直領(lǐng)域的專家。在車聯(lián)網(wǎng)行業(yè)發(fā)展初期的時候，這種工作模式對于傳統(tǒng)行業(yè)的來講，比較新穎、高效，所以在一定程度上促進了行業(yè)發(fā)展，但汽車操作系統(tǒng)的設計還是有很多不同于互聯(lián)網(wǎng)設計的地方，所以本文旨在討論HMI工作流程，如何分工，怎樣高效的進行設計協(xié)同，以期望探索更適合車聯(lián)網(wǎng)行業(yè)的設計協(xié)同方案，希望對你可以有所助益。

什么是設計協(xié)同

對于HMI設計來講，需要了解很多專業(yè)知識，比如：屏幕、硬件、三電、法規(guī)……這些東西都會影響到設計的視覺表達，所以設計協(xié)同就顯得尤為重要，那么什么是設計協(xié)同呢？指設計師在設計之初，即可開啟分享與協(xié)作，讓協(xié)同者盡可能早的參與到設計中，通過提供一系列工具，讓協(xié)同者有更加友好地體驗，保證每個人都可以準確找到相應需求的內(nèi)容，并且快速提出修改意見與反饋。簡單地講，就是讓每個人都參與到設計過程中，以使最終的結(jié)果能夠滿足用戶的需求。

為什么設計協(xié)同很重要

從產(chǎn)品功能邏輯層面來講，HMI設計的“復雜度”是具有有一定的“限制性”的，即保證安全第一，過度復雜的設計必然影響駕駛和乘坐人的安全。所以對于設計，是需要進行全方位評估的，必然會涉及到不同的角色。同時隨著項目的不斷發(fā)展，設計團隊也在不斷壯大，設計師之間的協(xié)作也越來越多，相應的溝通和協(xié)作成本就會不斷增加。如何才能更高效的合作，并把設計質(zhì)量和一致性做得更好，是我們需要解決的問題。所以設計協(xié)同的最終目的是為了解決問題，做正確的事，讓設計師做真正該做的事情。

設計協(xié)同的特點

• 設計協(xié)同軟件可以在不增加任何工作負擔，不影響你的任何設計思路的前提下，幫助你理順設計的每一張界面，記錄清楚每個歷史版本，讓你的設計不再凌亂。
• 相當于設計中的得力助手，以一種協(xié)作的方式，使成本降低，可以更快的完成設計。
• 隨著社會信息共享化日益普及，設計協(xié)同逐漸成為設計行業(yè)發(fā)展的必然趨勢和技術(shù)革新的一個重要方向。

設計協(xié)同的價值

消除合作障礙

讓設計師專注于真正重要的事情，而不是把精力放在可以自動化處理的事情上。對所有人員的工作進行集中化管理，所有人員基于統(tǒng)一數(shù)據(jù)源進行協(xié)作。

沉淀設計規(guī)范，讓設計有能力傳承

通過構(gòu)建團隊資產(chǎn)庫，比如設計規(guī)范、控件組件庫等，通過建立健全設計規(guī)范，讓數(shù)據(jù)沉淀，一方面讓設計師的設計有據(jù)可依，提升設計的專業(yè)性，另一方面，減少因為人員變動造成的數(shù)據(jù)丟失。

合作設計

在設計之初，就讓協(xié)同者參與到設計之中，保證每個人都可以準確的找到他們的需求內(nèi)容，并快速提出修改意見與反饋，讓設計師更有針對性的解決問題，讓設計師無需做重復性的工作。

當前主流的工作流

在HMI設計的工作流程中，主要涉及到的角色有產(chǎn)品經(jīng)理、交互設計師、視覺設計師、研發(fā)工程師、測試工程師、項目經(jīng)理。

不同角色主要工作內(nèi)容是：

產(chǎn)品經(jīng)理

• 根據(jù)市場調(diào)研、競品分析或者是已上線產(chǎn)品用戶反饋，發(fā)現(xiàn)創(chuàng)新或改進產(chǎn)品的潛在機會。
• 確定產(chǎn)品需要做什么，撰寫產(chǎn)品需求文檔。
• 與研發(fā)、設計、測試等部門溝通，確保各個協(xié)作部門對產(chǎn)品需求的充分理解。

交互設計師

• 根據(jù)需求文檔，撰寫詳細的產(chǎn)品流程設計文檔、產(chǎn)品界面及原型設計文檔。
• 與產(chǎn)品、設計、研發(fā)、測試等部門溝通，確保各個協(xié)作部門對交互流程充分理解。

視覺設計師

• 負責項目中各種交互界面、圖標、LOGO、按鈕等相關(guān)元素的設計與制作。
• 積極與開發(fā)溝通，推進界面及交互設計的最終實現(xiàn)。
• 軟件界面的美術(shù)設計、創(chuàng)意工作和制作工作。

研發(fā)工程師

• 根據(jù)UI界面進行代碼化。
• 前端表現(xiàn)層及前后端交互的架構(gòu)設計和開發(fā)。
• 配合后臺開發(fā)人員實現(xiàn)產(chǎn)品UE及UI頁面結(jié)構(gòu)的代碼編程及腳本編碼。

測試工程師

• 編寫測試計劃、規(guī)劃詳細的測試方案、編寫測試用例。
• 根據(jù)測試計劃搭建和維護測試環(huán)境。
• 執(zhí)行測試工作，提交測試報告。包括編寫用于測試的自動測試腳本，完整地記錄測試結(jié)果，編寫完整的測試報告等相關(guān)的技術(shù)文檔。
• 為業(yè)務部門提供相應技術(shù)支持，確保軟件質(zhì)量指標。

項目經(jīng)理

• 對項目進行全方位把控，對工作進行分解、落實在人，在項目開始階段，進行排期。
• 在項目進行過程中，對遇到的問題及時跟蹤，修正，不斷溝通協(xié)調(diào)、以便推進項目的進展，還要對各類臨時出現(xiàn)的事項進行拍板和決策。

圍繞著HMI設計的整個工作流程是：

產(chǎn)品經(jīng)理確認需求，輸出PRD文檔；交互設計師收到PRD文檔以后，基于需求，梳理功能，完善業(yè)務流程，完成交互文檔的制作，輸出UE文檔；視覺設計師在收到UE文檔以后，針對交互文檔中的流程頁面，進行視覺設計，輸出UI文件給到研發(fā)同學；研發(fā)同學根據(jù)UI文件和交互文檔進行代碼化，完成以后進入測試環(huán)節(jié)，測試工程師和產(chǎn)品、交互、視覺都需要參與到測試過程中，當完成測試工作以后進行發(fā)版。

目前常用設計協(xié)同方式

設計師自我協(xié)同

涉及角色

自己、設計師小團隊。

痛點

工作中很多重復的內(nèi)容，比如：Button、List等使用的地方很多，如果每個元素都重新繪制，勢必會投入很多時間，同時因為人為因素，難免會出現(xiàn)不統(tǒng)一的地方。那么怎么樣解決這個問題呢？

協(xié)同方式

當團隊初期發(fā)展的時候，或者整個團隊只有少數(shù)幾個設計師的時候，通過匯總通用樣式和組件，形成視覺指導Guide，方便通用樣式的復用，減少重復工作量，達到快速完成視覺設計的目的。

優(yōu)點

通過樣式庫和控件組件庫的搭建，形成了一定的共有樣式，方便復用，有效的減少了重復工作量。

缺點

由于控件組件庫是在設計進行到一定程度以后提煉的，會存在滯后性，并且隨著設計工作越來越往后，會發(fā)現(xiàn)前期的控件組件存在不合適的地方，需要對之前的工作進行修正。

設計團隊協(xié)同

涉及角色

設計團隊內(nèi)部。

痛點

當公司發(fā)展到一定的階段：

1. 公司有不同的產(chǎn)品，且都需要長期的開發(fā)和迭代。
2. 越來越多的設計師加入公司。

當設計團隊越來越大，大家分工越來越細，想法越來越多，就會發(fā)現(xiàn)，復制粘貼guide的方式，已經(jīng)無法滿足團隊的發(fā)展了，經(jīng)常出現(xiàn)組件不能滿足使用的情況，或者是組件相似但不知道怎么選擇等問題。
同時因為沒有統(tǒng)一的流程，會發(fā)現(xiàn)不同的業(yè)務對于同一功能交互邏輯的不統(tǒng)一現(xiàn)象，比如：搜索是很多業(yè)務都會使用的功能，因為沒有統(tǒng)一定義，有的業(yè)務會采用即時搜索模式，有的業(yè)務必須點擊搜索以后才可以進行搜索，并且這種問題，前期很難發(fā)現(xiàn)，只有到了中后期走查的時候才會發(fā)現(xiàn)。
所以在后期會針對每一個差異點進行統(tǒng)一，需要全流程重新來一遍，費時費力。那么怎么才可以避免這種情況的發(fā)生呢？答案就是構(gòu)建設計系統(tǒng)。

協(xié)同方式

設計系統(tǒng)不同于guide的地方是：樣式，控件組件只是設計系統(tǒng)中的兩個組成部分，除此以外，設計系統(tǒng)還包括了一系列的標準來指導設計。比如：圖標、動效、音效等。這些標準記錄了設計團隊內(nèi)達成一致的一系列的決定，比如如何選擇控件，如何在不同的控件中選擇。正是這些標準才確保了設計方案不僅僅只解決一個問題，而是可以被復用的。這些標準也是為什么用戶能獲得一致的體驗的原因。
通過設計系統(tǒng)的建立，讓設計規(guī)模化，繼而進一步強化車機系統(tǒng)的統(tǒng)一性，同時為設計師在做設計時提供一個很好的指導方向，讓團隊內(nèi)不同成員的設計在風格上保持一致，提升設計團隊的專業(yè)度。關(guān)于設計系統(tǒng)的建立本文就不再過多描述，后續(xù)會出專門的文章進行詳述，這里主要是講述設計系統(tǒng)搭建以后的協(xié)同方式。
設計系統(tǒng)的搭建需要專門的人或者團隊進行，當搭建完成以后，需要輸出的資源有：UE控件組件庫、顏色/字體樣式庫、UI控件組件庫、UI控件組件說明文檔。這些資源各有什么用呢，接下來進行詳細說明：

UE控件組件庫

提供給交互設計師，基于提供的內(nèi)容，交互可以快速的構(gòu)建界面、交互和流程等，就像搭樂高一樣。可以快速的構(gòu)建一些產(chǎn)品原型或者是實驗性的功能，來進行測試以快速驗證想法。

顏色/字體樣式庫、UI控件組件庫

提供給UI設計師，形式可以是Sketch Libraries，一方面方便設計師調(diào)用，使不同的設計師的設計變得更加統(tǒng)一，且更加可預測，同時組件也可以讓設計師更多的時間專注于如何構(gòu)建更好的用戶體驗，而不是去糾結(jié)于樣式的調(diào)整。

UI控件組件說明文檔

提供給研發(fā)，可以是pdf之類的文檔形式，主要是詳細的描述每一個組件的各種屬性，以及里面包含的交互邏輯等，幫助研發(fā)搭建起研發(fā)自己的底層代碼平臺。
那么這些資源和不同的角色之間是怎么協(xié)作呢？UE控件組件庫不需要常常更新，完成后給到交互設計團隊，供交互設計師使用搭建UE文檔。在項目開始之前，負責設計系統(tǒng)的UI團隊進行顏色/字體樣式庫、UI控件組件庫制作，完成以后分享到團隊內(nèi)，供業(yè)務設計師使用進行界面設計，同時進行UI控件組件說明文檔的編撰，完成以后提供給相應的平臺研發(fā)，讓平臺研發(fā)進行組件代碼化。當代碼實現(xiàn)以后進行走查，檢查是否按照UI準確的實現(xiàn)。當業(yè)務設計師完成了業(yè)務的界面設計以后，進行評審，輸出給對應的業(yè)務研發(fā)，研發(fā)對于相應的視覺界面進行對應的代碼化，使用組件的地方直接調(diào)用平臺代碼，剩下的由業(yè)務研發(fā)進行代碼化。

優(yōu)點

組件由專門的UI設計師和研發(fā)團隊負責，當出現(xiàn)設計變更以后，業(yè)務設計師可以快速通過組件庫更新最新的視覺樣式，同時和平臺研發(fā)對接，進行代碼修改，而不需要每個業(yè)務研發(fā)單獨修改，大大減少了跨部門的協(xié)作溝通成本。

缺點

團隊內(nèi)需要專門的設計師構(gòu)建設計系統(tǒng)并負責日常維護。

設計師和交互協(xié)同

涉及角色

設計、交互團隊。

痛點

由于需求的不確定性，以及車聯(lián)網(wǎng)項目周期較長等特點，會出現(xiàn)需求經(jīng)常變更的情況，那么交互就需要不停的更新交互文檔，UI也需要不停的輸出視覺文檔，往往一個項目結(jié)束以后，會有幾十份甚至上百份的設計文檔的情況出現(xiàn)。

協(xié)同方式

隨著云端化辦公軟件Figma的興起，為多角色協(xié)作提供了可能性，目前主流的工具有：Figma、MasterGo、Pixso、即時設計等在線軟件。
設計文件現(xiàn)在是一個鏈接，這意味著：

• 設計師可以更輕松地并行工作。
• 工程師可以更早的查看設計稿進行技術(shù)評審。
• 利益相關(guān)者或任何有鏈接的人都可以看到設計從想法到實現(xiàn)的過程。
• 設計現(xiàn)在是一個整體而不是在設計過程被分割成多個文件。

UI設計師不必再等到交互完成評審，輸出交互文檔以后進行視覺設計，交互和設計完全可以合二為一，輸出一份高保真交互流程文檔，并且輸出的文檔可以供研發(fā)直接瀏覽器查看，而不需要像之前一樣，不停的進行設計資源的輸出。極大的節(jié)省了設計師輸出時間。優(yōu)化了協(xié)作工作流。

優(yōu)點

協(xié)作設計，云端辦公，多角色參與。
一鍵獲取文件，不需要通過其他平臺轉(zhuǎn)化，步驟簡單；自動生成代碼與標注。設計稿修改后自動更新，無需重復下載。

缺點

云端保存，會有數(shù)據(jù)泄露的風險。
必須在線操作。

設計和研發(fā)協(xié)同

涉及角色

UE、UI、研發(fā)。

痛點

由于公司發(fā)展，業(yè)務線增加了很多適配線，這塊的工作基本上屬于：把已有的UI適配到另一個屏幕尺寸下，需要設計的地方不太多，需要花更多的時間去重新按照最新的屏幕尺寸搭建一遍UI界面，屬于用時間換業(yè)績，為了達到這個目標，可以采取的方式大致分為兩種：
第一種是增加更多的人力，不管是招更多的人，還是增加更多的供應商人員，都會增加業(yè)務支出，并且由于業(yè)務無法一直保證飽和，所以會出現(xiàn)一段時間忙的要命，招了很多人員，過了這段時間，業(yè)務不太多了，大家都閑了下來，但是開支還是必要的，所以這算是一種沒有辦法的辦法，對于團隊或是公司來講，并不可持續(xù)。
另外一種方式就是重新梳理工作流，減少一些重復無意義的工作，比如像是系統(tǒng)設置等瀑布流式的界面，不同車型下的區(qū)別只來自于功能的有無，界面上并無太大區(qū)別，這里所說的工作，不僅僅指設計師的界面設計工作，同時也包括了研發(fā)同學的研發(fā)落地工作，同時因為研發(fā)同學的適配，也會造成測試走查環(huán)節(jié)，這些都是一些重復性的工作量，所以是否有一種更好的協(xié)作方式可以避免這種情況的發(fā)生呢？
答案就是我們接下來要講的一種全新的工作模式：C2D2C模式。

協(xié)同方式

由于設計團隊在早期的發(fā)展中，積累了大量的設計資產(chǎn)。這些設計資產(chǎn)的沉淀就是設計標準化的基礎(chǔ)，將設計資產(chǎn)轉(zhuǎn)為封裝好的代碼組件，也就是C2D的過程。然后將封裝好的組件通過低代碼平臺進行屬性配置、搭建頁面、布局調(diào)整實現(xiàn)頁面的設計就是 D2C 的過程。通過平臺設定交互行為和綁定后臺數(shù)據(jù)，完成整個系統(tǒng)，最后再進行站點發(fā)布，就實現(xiàn)了 C2D2C 的完整流程。
C2D2C（Code to design to design）的模式，簡單講就是研發(fā)同學把設計資產(chǎn)通過設計標準化和研發(fā)工業(yè)化的方式完成代碼化，然后讓設計師調(diào)用已經(jīng)代碼化的設計資產(chǎn)進行設計工作，這樣子當設計師完成了界面設計的時候，相當于同時完成了前端開發(fā)，接下來研發(fā)同學只需要根據(jù)拿到的界面添加簡單的邏輯就算完成了研發(fā)工作，實現(xiàn)中后臺設計研發(fā)流程的整體提效。

優(yōu)點

由于樣式、組件已經(jīng)完成了代碼化，那么在適配工作中，控件組件化高的界面就可以直接生成代碼，不需要設計師重復設計，同時由于減少了設計師和研發(fā)的參與，節(jié)省了大量溝通成本，也減少了很多因為人為因素而產(chǎn)生的bug。
由于設計師減少了重復工作量，可以有更多的時間集中在視覺表現(xiàn)上，有效提升了設計輸出的質(zhì)量，保證了產(chǎn)品的設計感。
對于大量適配項目的團隊，可以由設計師直接配置項目組件，無需經(jīng)過研發(fā)，減少出錯概率，極大提升工作效率。

缺點

前期需要研發(fā)同學代碼化基礎(chǔ)控件，所以需要投入人力、精力進行前期的工作。
由于控件提前進行了代碼化，后續(xù)可能會出現(xiàn)無法滿足業(yè)務需求等情況出現(xiàn)，所以需要有人及時對代碼進行維護更新。

全角色協(xié)同

涉及角色

產(chǎn)品、UE、UI、研發(fā)、測試。

痛點

基于上面講述的C2D2C模式，已經(jīng)完成了一個共享平臺的搭建，由于配置需要研發(fā)的參與，所以始終需要研發(fā)同學作為集成人員，并不利于其他角色的使用，那么怎么樣可以讓產(chǎn)品同學，設計同學，或者說是普通用戶使用呢？

協(xié)同方式

一個優(yōu)秀的共享平臺是需要所有人都可以在其中使用的，所以，當公司或者團隊發(fā)展到穩(wěn)定階段，我們需要重構(gòu)工作流，以需求為導向，搭建全員工作平臺，基于設計師和研發(fā)搭建的平臺基礎(chǔ)上，提煉需求，強化個性化和定制化，滿足品牌產(chǎn)品的個性化需求，具體來講，就是把UI界面中元素提煉出相應的功能，生成功能清單，通過選擇不同的功能，生成相對應的界面。
當完整的共享平臺搭建完成以后，團隊中的每個角色的工作內(nèi)容都發(fā)生了變化，產(chǎn)品的工作是構(gòu)建更多的需求，交互設計師的工作是構(gòu)建更多的交互形式，產(chǎn)品架構(gòu)，UI設計師的工作是設計更多更好的界面布局，視覺表現(xiàn)，然后研發(fā)把上述內(nèi)容通過代碼匯總進我們的需求池中，擴展我們的平臺豐富度。
HMI設計工作，就變成了：客戶在我們的配置面板中選擇需要的需求，喜歡的布局，想要的視覺，點擊完成，就可以即刻看到高度定制化的一套系統(tǒng)。

優(yōu)點

讓每個人回歸工作的本質(zhì)，不需要為了一些重復的繁雜的內(nèi)容而疲于奔命，做更有價值的工作，實現(xiàn)工作的價值
賦能行業(yè)，可以滿足車企定制化的需求，提供車企一套完整的車機系統(tǒng)解決方案。

缺點

投入大，對于小體量的業(yè)務來講短期無法創(chuàng)造價值。

最后

對于現(xiàn)在的行業(yè)環(huán)境，增速提效已經(jīng)達成了基本共識，設計協(xié)同就成了一個大課題，但是不同的企業(yè)，不同的團隊面對的具體問題不一樣，可使用的資源也不太一樣，那么采用哪種協(xié)同方式并無定式，需要根據(jù)實際情況，進行具體分析，畢竟效率的提升是為了創(chuàng)造最大的價值。我們所有的努力最終目的是為了解決問題，做正確的事。