2023-4-6 博博
筆者在車聯網行業任職HMI視覺設計師,由于HMI設計發展的較晚,所以基本上在開始進入到這個領域的人,大多來自于互聯網行業。由于互聯網行業發展的比較早,形成了一套成熟的工作流程,即:分工明確的遞進式協作:交互設計師要等到產品PRD評審結束才開始介入需求,然后交付黑白線框稿等給到視覺設計師繼續跟進。這種工作模式可以讓每個人在自己的崗位上做得更加專業,成為垂直領域的專家。在車聯網行業發展初期的時候,這種工作模式對于傳統行業的來講,比較新穎、高效,所以在一定程度上促進了行業發展,但汽車操作系統的設計還是有很多不同于互聯網設計的地方,所以本文旨在討論HMI工作流程,如何分工,怎樣高效的進行設計協同,以期望探索更適合車聯網行業的設計協同方案,希望對你可以有所助益。
對于HMI設計來講,需要了解很多專業知識,比如:屏幕、硬件、三電、法規……這些東西都會影響到設計的視覺表達,所以設計協同就顯得尤為重要,那么什么是設計協同呢?指設計師在設計之初,即可開啟分享與協作,讓協同者盡可能早的參與到設計中,通過提供一系列工具,讓協同者有更加友好地體驗,保證每個人都可以準確找到相應需求的內容,并且快速提出修改意見與反饋。簡單地講,就是讓每個人都參與到設計過程中,以使最終的結果能夠滿足用戶的需求。
從產品功能邏輯層面來講,HMI設計的“復雜度”是具有有一定的“限制性”的,即保證安全第一,過度復雜的設計必然影響駕駛和乘坐人的安全。所以對于設計,是需要進行全方位評估的,必然會涉及到不同的角色。同時隨著項目的不斷發展,設計團隊也在不斷壯大,設計師之間的協作也越來越多,相應的溝通和協作成本就會不斷增加。如何才能更高效的合作,并把設計質量和一致性做得更好,是我們需要解決的問題。所以設計協同的最終目的是為了解決問題,做正確的事,讓設計師做真正該做的事情。
讓設計師專注于真正重要的事情,而不是把精力放在可以自動化處理的事情上。對所有人員的工作進行集中化管理,所有人員基于統一數據源進行協作。
通過構建團隊資產庫,比如設計規范、控件組件庫等,通過建立健全設計規范,讓數據沉淀,一方面讓設計師的設計有據可依,提升設計的專業性,另一方面,減少因為人員變動造成的數據丟失。
在設計之初,就讓協同者參與到設計之中,保證每個人都可以準確的找到他們的需求內容,并快速提出修改意見與反饋,讓設計師更有針對性的解決問題,讓設計師無需做重復性的工作。
在HMI設計的工作流程中,主要涉及到的角色有產品經理、交互設計師、視覺設計師、研發工程師、測試工程師、項目經理。
不同角色主要工作內容是:
圍繞著HMI設計的整個工作流程是:
產品經理確認需求,輸出PRD文檔;交互設計師收到PRD文檔以后,基于需求,梳理功能,完善業務流程,完成交互文檔的制作,輸出UE文檔;視覺設計師在收到UE文檔以后,針對交互文檔中的流程頁面,進行視覺設計,輸出UI文件給到研發同學;研發同學根據UI文件和交互文檔進行代碼化,完成以后進入測試環節,測試工程師和產品、交互、視覺都需要參與到測試過程中,當完成測試工作以后進行發版。
涉及角色
自己、設計師小團隊。
痛點
工作中很多重復的內容,比如:Button、List等使用的地方很多,如果每個元素都重新繪制,勢必會投入很多時間,同時因為人為因素,難免會出現不統一的地方。那么怎么樣解決這個問題呢?
協同方式
當團隊初期發展的時候,或者整個團隊只有少數幾個設計師的時候,通過匯總通用樣式和組件,形成視覺指導Guide,方便通用樣式的復用,減少重復工作量,達到快速完成視覺設計的目的。
優點
通過樣式庫和控件組件庫的搭建,形成了一定的共有樣式,方便復用,有效的減少了重復工作量。
缺點
由于控件組件庫是在設計進行到一定程度以后提煉的,會存在滯后性,并且隨著設計工作越來越往后,會發現前期的控件組件存在不合適的地方,需要對之前的工作進行修正。
涉及角色
設計團隊內部。
痛點
當公司發展到一定的階段:
當設計團隊越來越大,大家分工越來越細,想法越來越多,就會發現,復制粘貼guide的方式,已經無法滿足團隊的發展了,經常出現組件不能滿足使用的情況,或者是組件相似但不知道怎么選擇等問題。
同時因為沒有統一的流程,會發現不同的業務對于同一功能交互邏輯的不統一現象,比如:搜索是很多業務都會使用的功能,因為沒有統一定義,有的業務會采用即時搜索模式,有的業務必須點擊搜索以后才可以進行搜索,并且這種問題,前期很難發現,只有到了中后期走查的時候才會發現。
所以在后期會針對每一個差異點進行統一,需要全流程重新來一遍,費時費力。那么怎么才可以避免這種情況的發生呢?答案就是構建設計系統。
協同方式
設計系統不同于guide的地方是:樣式,控件組件只是設計系統中的兩個組成部分,除此以外,設計系統還包括了一系列的標準來指導設計。比如:圖標、動效、音效等。這些標準記錄了設計團隊內達成一致的一系列的決定,比如如何選擇控件,如何在不同的控件中選擇。正是這些標準才確保了設計方案不僅僅只解決一個問題,而是可以被復用的。這些標準也是為什么用戶能獲得一致的體驗的原因。
通過設計系統的建立,讓設計規?;^而進一步強化車機系統的統一性,同時為設計師在做設計時提供一個很好的指導方向,讓團隊內不同成員的設計在風格上保持一致,提升設計團隊的專業度。關于設計系統的建立本文就不再過多描述,后續會出專門的文章進行詳述,這里主要是講述設計系統搭建以后的協同方式。
設計系統的搭建需要專門的人或者團隊進行,當搭建完成以后,需要輸出的資源有:UE控件組件庫、顏色/字體樣式庫、UI控件組件庫、UI控件組件說明文檔。這些資源各有什么用呢,接下來進行詳細說明:
UE控件組件庫
提供給交互設計師,基于提供的內容,交互可以快速的構建界面、交互和流程等,就像搭樂高一樣??梢钥焖俚臉嫿ㄒ恍┊a品原型或者是實驗性的功能,來進行測試以快速驗證想法。
顏色/字體樣式庫、UI控件組件庫
提供給UI設計師,形式可以是Sketch Libraries,一方面方便設計師調用,使不同的設計師的設計變得更加統一,且更加可預測,同時組件也可以讓設計師更多的時間專注于如何構建更好的用戶體驗,而不是去糾結于樣式的調整。
UI控件組件說明文檔
提供給研發,可以是pdf之類的文檔形式,主要是詳細的描述每一個組件的各種屬性,以及里面包含的交互邏輯等,幫助研發搭建起研發自己的底層代碼平臺。
那么這些資源和不同的角色之間是怎么協作呢?UE控件組件庫不需要常常更新,完成后給到交互設計團隊,供交互設計師使用搭建UE文檔。在項目開始之前,負責設計系統的UI團隊進行顏色/字體樣式庫、UI控件組件庫制作,完成以后分享到團隊內,供業務設計師使用進行界面設計,同時進行UI控件組件說明文檔的編撰,完成以后提供給相應的平臺研發,讓平臺研發進行組件代碼化。當代碼實現以后進行走查,檢查是否按照UI準確的實現。當業務設計師完成了業務的界面設計以后,進行評審,輸出給對應的業務研發,研發對于相應的視覺界面進行對應的代碼化,使用組件的地方直接調用平臺代碼,剩下的由業務研發進行代碼化。
優點
組件由專門的UI設計師和研發團隊負責,當出現設計變更以后,業務設計師可以快速通過組件庫更新最新的視覺樣式,同時和平臺研發對接,進行代碼修改,而不需要每個業務研發單獨修改,大大減少了跨部門的協作溝通成本。
缺點
團隊內需要專門的設計師構建設計系統并負責日常維護。
涉及角色
設計、交互團隊。
痛點
由于需求的不確定性,以及車聯網項目周期較長等特點,會出現需求經常變更的情況,那么交互就需要不停的更新交互文檔,UI也需要不停的輸出視覺文檔,往往一個項目結束以后,會有幾十份甚至上百份的設計文檔的情況出現。
協同方式
隨著云端化辦公軟件Figma的興起,為多角色協作提供了可能性,目前主流的工具有:Figma、MasterGo、Pixso、即時設計等在線軟件。
設計文件現在是一個鏈接,這意味著:
UI設計師不必再等到交互完成評審,輸出交互文檔以后進行視覺設計,交互和設計完全可以合二為一,輸出一份高保真交互流程文檔,并且輸出的文檔可以供研發直接瀏覽器查看,而不需要像之前一樣,不停的進行設計資源的輸出。極大的節省了設計師輸出時間。優化了協作工作流。
優點
協作設計,云端辦公,多角色參與。
一鍵獲取文件,不需要通過其他平臺轉化,步驟簡單;自動生成代碼與標注。設計稿修改后自動更新,無需重復下載。
缺點
云端保存,會有數據泄露的風險。
必須在線操作。
涉及角色
UE、UI、研發。
痛點
由于公司發展,業務線增加了很多適配線,這塊的工作基本上屬于:把已有的UI適配到另一個屏幕尺寸下,需要設計的地方不太多,需要花更多的時間去重新按照最新的屏幕尺寸搭建一遍UI界面,屬于用時間換業績,為了達到這個目標,可以采取的方式大致分為兩種:
第一種是增加更多的人力,不管是招更多的人,還是增加更多的供應商人員,都會增加業務支出,并且由于業務無法一直保證飽和,所以會出現一段時間忙的要命,招了很多人員,過了這段時間,業務不太多了,大家都閑了下來,但是開支還是必要的,所以這算是一種沒有辦法的辦法,對于團隊或是公司來講,并不可持續。
另外一種方式就是重新梳理工作流,減少一些重復無意義的工作,比如像是系統設置等瀑布流式的界面,不同車型下的區別只來自于功能的有無,界面上并無太大區別,這里所說的工作,不僅僅指設計師的界面設計工作,同時也包括了研發同學的研發落地工作,同時因為研發同學的適配,也會造成測試走查環節,這些都是一些重復性的工作量,所以是否有一種更好的協作方式可以避免這種情況的發生呢?
答案就是我們接下來要講的一種全新的工作模式:C2D2C模式。
協同方式
由于設計團隊在早期的發展中,積累了大量的設計資產。這些設計資產的沉淀就是設計標準化的基礎,將設計資產轉為封裝好的代碼組件,也就是C2D的過程。然后將封裝好的組件通過低代碼平臺進行屬性配置、搭建頁面、布局調整實現頁面的設計就是 D2C 的過程。通過平臺設定交互行為和綁定后臺數據,完成整個系統,最后再進行站點發布,就實現了 C2D2C 的完整流程。
C2D2C(Code to design to design)的模式,簡單講就是研發同學把設計資產通過設計標準化和研發工業化的方式完成代碼化,然后讓設計師調用已經代碼化的設計資產進行設計工作,這樣子當設計師完成了界面設計的時候,相當于同時完成了前端開發,接下來研發同學只需要根據拿到的界面添加簡單的邏輯就算完成了研發工作,實現中后臺設計研發流程的整體提效。
優點
由于樣式、組件已經完成了代碼化,那么在適配工作中,控件組件化高的界面就可以直接生成代碼,不需要設計師重復設計,同時由于減少了設計師和研發的參與,節省了大量溝通成本,也減少了很多因為人為因素而產生的bug。
由于設計師減少了重復工作量,可以有更多的時間集中在視覺表現上,有效提升了設計輸出的質量,保證了產品的設計感。
對于大量適配項目的團隊,可以由設計師直接配置項目組件,無需經過研發,減少出錯概率,極大提升工作效率。
缺點
前期需要研發同學代碼化基礎控件,所以需要投入人力、精力進行前期的工作。
由于控件提前進行了代碼化,后續可能會出現無法滿足業務需求等情況出現,所以需要有人及時對代碼進行維護更新。
涉及角色
產品、UE、UI、研發、測試。
痛點
基于上面講述的C2D2C模式,已經完成了一個共享平臺的搭建,由于配置需要研發的參與,所以始終需要研發同學作為集成人員,并不利于其他角色的使用,那么怎么樣可以讓產品同學,設計同學,或者說是普通用戶使用呢?
協同方式
一個優秀的共享平臺是需要所有人都可以在其中使用的,所以,當公司或者團隊發展到穩定階段,我們需要重構工作流,以需求為導向,搭建全員工作平臺,基于設計師和研發搭建的平臺基礎上,提煉需求,強化個性化和定制化,滿足品牌產品的個性化需求,具體來講,就是把UI界面中元素提煉出相應的功能,生成功能清單,通過選擇不同的功能,生成相對應的界面。
當完整的共享平臺搭建完成以后,團隊中的每個角色的工作內容都發生了變化,產品的工作是構建更多的需求,交互設計師的工作是構建更多的交互形式,產品架構,UI設計師的工作是設計更多更好的界面布局,視覺表現,然后研發把上述內容通過代碼匯總進我們的需求池中,擴展我們的平臺豐富度。
HMI設計工作,就變成了:客戶在我們的配置面板中選擇需要的需求,喜歡的布局,想要的視覺,點擊完成,就可以即刻看到高度定制化的一套系統。
優點
讓每個人回歸工作的本質,不需要為了一些重復的繁雜的內容而疲于奔命,做更有價值的工作,實現工作的價值
賦能行業,可以滿足車企定制化的需求,提供車企一套完整的車機系統解決方案。
缺點
投入大,對于小體量的業務來講短期無法創造價值。
對于現在的行業環境,增速提效已經達成了基本共識,設計協同就成了一個大課題,但是不同的企業,不同的團隊面對的具體問題不一樣,可使用的資源也不太一樣,那么采用哪種協同方式并無定式,需要根據實際情況,進行具體分析,畢竟效率的提升是為了創造最大的價值。我們所有的努力最終目的是為了解決問題,做正確的事。
作者:菘藍C 來源:站酷網
藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請加微信ban_lanlan,報下信息,藍小助會請您入群。歡迎您加入噢~~
希望得到建議咨詢、商務合作,也請與我們聯系01063334945。
分享此文一切功德,皆悉回向給文章原作者及眾讀者. 免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。
藍藍設計( paul-jarrel.com )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務、UI設計公司、界面設計公司、UI設計服務公司、數據可視化設計公司、UI交互設計公司、高端網站設計公司、UI咨詢、用戶體驗公司、軟件界面設計公司。