設計體系丨如何創(chuàng)建設計體系?(四)
編輯導語:在上一篇文章中,作者詳細介紹了設計體系的價值與缺陷,《設計體系丨設計體系有什么用?價值與缺陷(三)》;本文作者從六個方面詳細分析了應該怎么樣創(chuàng)建一個設計體系,我們一起來了解一下。
介于網(wǎng)上的文章大多只是教大家如何建立“組件庫“或是”設計規(guī)范“,但卻說它這是建立”設計體系“,而本章的目的即是基于我的理解,在各種大佬的肩膀上,逐步構(gòu)建一個幫助大家構(gòu)建真正的設計體系的體系化方法思路。
為了更好的理解,本系列文章核心內(nèi)容我也是參照了4本書、4篇論文(其中3篇還是碩士論文)、網(wǎng)站文章(30+)、網(wǎng)站視頻(5+),相信已經(jīng)囊括目前關于設計體系相關知識的半壁江山。寫到最后的感受基本類似于大佬住我心,有些寫出的話難以找回原出處,但確實可能被某個實踐者說過;所有的參考內(nèi)容和推薦內(nèi)容,我會在另一篇文章進行分享,感興趣的朋友可以持續(xù)關注。
在創(chuàng)建設計體系之前,首先我們需要思考的問題,就是目前我們是否需要建立設計體系?
如果公司存在大量的產(chǎn)品需要進行遠期開發(fā)和迭代,或者公司已經(jīng)存在大量的設計師和前端工程師,并進行著重復工作時,這便是搭建和推行設計體系的好時機。
構(gòu)建設計體系有哪些階段?
不同的人有不同的理解,因為我是服務設計背景,因此在我的理解下,會將構(gòu)建設計體系的階段拓展到組織設計方面,并且分為以下6個階段內(nèi)容:
- 愿景建立:宣揚愿景,建立目標
- 團隊配置:配置團隊結(jié)構(gòu)與人員
- 資產(chǎn)清查:資產(chǎn)清查與體系用戶研究
- 資產(chǎn)建立:建立資產(chǎn)與體系內(nèi)容
- 流程搭建:搭建體系運行和維護流程
- 體系評估:體系效果評估
后面的內(nèi)容也將大致圍繞這些展開。
一、愿景建立:宣揚愿景,建立目標
要想從設計規(guī)范演變成設計體系,僅僅依靠組織內(nèi)幾個人用愛發(fā)電是很難的,發(fā)電往往只能產(chǎn)出小的體系,難以長期維護;為了實現(xiàn)更好的效果,我們需要從組織高層處獲取支持,并獲取更多資源用來建設體系。
我的第三篇文章講到的所有價值都可以作為觸動組織提供更多資源的基礎,不過對不同的人需要有不同的側(cè)重點。
- 面對組織高層,可以側(cè)重講提高工作效率、減少維護成本和開發(fā)成本、高設計質(zhì)量帶來的市場競爭力等角度出發(fā)。除此之外,有些企業(yè)可能會看重對行業(yè)的影響力和引領度而打算投資建設設計體系。
- 面對設計與開發(fā)團隊,可以側(cè)重談論減少設計與技術重復勞動,提升設計開發(fā)的效率,以花更多時間思索如何是實現(xiàn)多方面的需求,并創(chuàng)建一致化的品牌和流暢的用戶體驗,提高協(xié)作滿意度。
當然口說無憑,就算有第三方業(yè)務的數(shù)據(jù)還是很難說服他們,我們需要更加顯性具體的方式衡量ROI。在我們擁有初步的設計體系后,可以通過與設計和開發(fā)團隊進行類似設計沖刺的活動,來評估使用和不使用設計體系可以節(jié)省多少時間與財力,提供一個簡單的指標,來幫助獲取組織認同,獲取更多資源。
在這個過程中,我們也需要設定合適的期望以衡量設計體系的效果;以下幾個因素可以作為合適的標準(基于Termini & Martin,2018),可以通過上述的活動推算基本指標數(shù)據(jù),之后作為建設設計體系的OKR中的關鍵結(jié)果的衡量指標。
- 易用度:用戶使用某個產(chǎn)品/服務來解決問題的難易程度(Ant Design,2020)。
- 交付量:最明顯的是使用設計體系后同等時間效果下,設計與開發(fā)的交互量的變化。
- 錯誤率:這個指標用來衡量如果使用設計指標后,可以消除的失誤產(chǎn)生幾率。
- 可用性:通過可用性指標測試,用來測試產(chǎn)品的可用性情況,另外這個方面也可用客戶滿意度來衡量。
- 復用率:組件被使用者多次重復使用的幾率。
- 團隊滿意度:可以針對現(xiàn)有設計與開發(fā)團隊進行內(nèi)部調(diào)查,了解設計與開發(fā)使用設計體系的滿意度。
- 團隊NPS:一開始設計體系并不是強制使用的,除了依靠體系團隊的推廣外,十分依靠使用者的推薦,因此評估使用者的凈推薦值將是不錯的衡量,也能側(cè)面反應團隊滿意度。
二、團隊配置:配置團隊結(jié)構(gòu)與人員
現(xiàn)在如果資源就緒,組織也支持我們?nèi)プ觯矊ξ覀儽в幸欢A期和期望,那么著重準備我們的團隊吧,配置的關鍵是根據(jù)組織和產(chǎn)品發(fā)展情況合理調(diào)配。
1. 選擇合適的人員
盡管叫”設計體系”,但設計師只是其中一環(huán)而已。不同的組織當然會有不同的人員構(gòu)成,會有不同的適配性變化。
Nathan Curtis的文章,設計你的設計體系團隊(Designing a Systems Team,2017)結(jié)合自身建設體系的實踐經(jīng)驗就認為,需要一個包含設計、技術、管理等組成的多學科設計體系團隊來促進體系的使用和進步,在此文中也描述了不同規(guī)模團隊的人員構(gòu)成推薦。
不同規(guī)模團隊的人員組成,圖片源于Nathan Curtis(2017)
設計體系團隊中的子團隊,圖片源于Nathan Curtis(2017)
無論規(guī)模大小,團隊領導者必須分別具備設計、編程和產(chǎn)品管理技能。同時在大型體系團隊中,將包含產(chǎn)品(偏設計)主管和產(chǎn)品(偏工程)主管;同時搭配數(shù)個全職和兼職的設計與工程人員,甚至還可以加入內(nèi)容策略師、可訪問性專家、性能專家等等角色。
除了領導者之外,我們還需要找那些人?inVision的書中也提到了一個人員列表,例如:
- 設計師定義系統(tǒng)的視覺元素;
- 前端開發(fā)人員創(chuàng)建模塊化且高效的代碼;
- 可訪問性專家確保系統(tǒng)符合WCAG(網(wǎng)頁內(nèi)容無障礙指南,全稱Web Content Accessibility Guidelines,是一套幫助開發(fā)者開發(fā)能讓殘障人士更容易訪問Web內(nèi)容的國際標準)等標準;
- 內(nèi)容策略師可以幫助團隊確定表達內(nèi)容的方式和基調(diào);
- 用戶研究人員可以幫助您了解客戶需求;
- 性能專家可以確保系統(tǒng)能快速地加載到所有設備上;
- 產(chǎn)品經(jīng)理確保符合客戶與業(yè)務需求;
- 大領導(副總裁和主管)可以在整個公司(尤其是中高層管理層)內(nèi)倡導和協(xié)調(diào)愿景……
2. 選擇合適的管理模式
設計體系本身就可以作為產(chǎn)品,當然也可以作為方法論;如果把設計體系當成產(chǎn)品,那么體系用戶將會有三種劃分。
基于Nikolas Klein(Figma)的?劃分設計體系的成熟度(The spectrum of maturity for design systems)一文,我們可以將設計體系的用戶劃分為創(chuàng)造者(Creators)、使用者(Users,原文是Consumer消費者)、貢獻者(Contributors)等三種角色。
- 創(chuàng)造者是體系結(jié)構(gòu)的構(gòu)建者,不僅為現(xiàn)有問題提供初步設計解決方案和前端解決方案,也承擔推廣、分發(fā)、同步、質(zhì)量管理、版本管理和更新等任務,是設計體系的核心團隊。
- 使用者是公司內(nèi)外的團隊,使用設計體系中的指南、組件、資源、工具等元素來構(gòu)建產(chǎn)品。
- 貢獻者是在實際使用過程中,發(fā)現(xiàn)現(xiàn)有問題,提出新的解決方案,并通過體系流程協(xié)助設計體系團隊協(xié)同更新體系的人。
設計體系團隊會跟著組織大小適應性的變化。團隊小的時候采用少量人兼職管理;而團隊逐漸發(fā)展,當產(chǎn)品組合足夠龐大時,就不得不并行發(fā)展,或是引入顧問或成立專門的設計體系開發(fā)者與管理者。其中的體系用戶角色也會跟著變化:
- 小型團隊:所有創(chuàng)造者都是使用者,使用者多是貢獻者;
- 中型團隊:部分使用者是創(chuàng)造者,貢獻者多來于創(chuàng)造者;
- 大型團隊:貢獻者同時來于創(chuàng)造者和使用者;
- 平臺型體系:擁有大量外部使用者依賴該體系,貢獻者不止來源于企業(yè)內(nèi)部,也來源于外部使用者。
在實踐中,組織內(nèi)部通常有不同的設計體系管理模式。那么這里的關鍵是我們?nèi)绾芜x擇合適的設計體系關系模型?
例如Airbnb全球永遠2000余名員工,約有60+個產(chǎn)品設計師,同時有全職的設計體系團隊(設計師與工程師共同組成)(Kholmatova,2017)。
設計體系專家Nathan Curtis(2015)和Salesforce的Jina Anne(2015)提出了4種設計體系團隊與產(chǎn)品團隊的關系模型。
如下:
- 獨裁模式(Solitary Model, “The Overlord”)?單獨的一個設計團隊來建立設計體系,其他團隊根據(jù)需求進行使用。(一般初期的設計團隊會使用)
- 集中化模式(Centralized Model).一個全職、單獨的中央的設計團隊運營支撐其他團隊使用的設計體系。(如Atlassian設計體系和Airbnb的DLS)
- 聯(lián)盟模式(Federated Model)?多個產(chǎn)品團隊的設計師一起決策和管理設計體系。(如TED)
- 混合循環(huán)模式(Cyclical Model)。結(jié)合集中化模式與聯(lián)盟模式,有專門的管理團隊和其他內(nèi)部團隊的貢獻,同時不定期會將其他產(chǎn)品的人員調(diào)入設計體系團隊進行管理維護;同時通過開放設計體系,還加入一些生態(tài)系統(tǒng)中組織外部團隊的貢獻支持。 (如Salesforce的Lightning設計體系以及目前螞蟻集團的Ant Design設計體系)
圖源自Nathan Curtis(2015)和Jina Anne(2015)提出的4種團隊關系模式
當然不同的團隊模式有不同的優(yōu)缺點:
- 獨裁模式可以進行快速搭建,但因為缺乏生態(tài)貢獻而限制了體系的進一步發(fā)展。
- 集中化模式的核心負責團隊雖然方便管理,但容易丟失對用戶的理解。
- 聯(lián)盟模式集成了對用戶的理解,但缺乏合適的管理和負責制度則讓設計體系容易停滯。
- 混合循環(huán)模式目前得到更多的使用,但操作起來也十分復雜。
三、資產(chǎn)清查:資產(chǎn)清查與體系用戶研究
大型團隊的形成往往很難一蹴而就,但只要我們召集到足夠的人手,便可以開始行動,但不是立即開展體系建設,而是在著手開始設計體系的建設之前,需要對現(xiàn)有資產(chǎn)進行清查。
當然我們使用簡單或者更加標準化的清查方式都可以,例如Brad Frost就舉例了使用在線PPT來放置截圖的方式進行清查(Brad Frost,2016);并且在這一過程中,可以讓組織中盡可能多的人參與,例如UX設計師、視覺設計師、前端開發(fā)人員、后端開發(fā)人員、文案、內(nèi)容策略師、產(chǎn)品經(jīng)理等等任何的其他利益相關者,可以讓整個團隊了解到現(xiàn)有的問題,并建立共享詞匯表(Brad Frost,2016)。
圖來自Atomic Deign,P97(Brad Frost,2016)
HubSpot平臺中的所有按鈕的視覺組件
更加標準的方式則需要我們的的主力團隊來實現(xiàn)。除了視覺樣式之外,我們需要更加詳實的記錄出處、交互的狀態(tài)變化、交互模式等等變化;這里其實可以找測試專家,提供一份測試用例,能更方便的探查那些隱秘的彈窗、信息通知等方式(因為這些不容易被察覺到)。
1. 要清查哪些內(nèi)容?
我將在后面的文章中,放出我基于對御三家平臺級設計體系(Apple的HIG、Google的MDS、Microsoft的FDS)和國內(nèi)外企業(yè)級設計體系(Salesforce的LDS、Atlassian的ADS、螞蟻金服的AD)的資產(chǎn)清單。
資產(chǎn)清查這一過程,我們可以收集到最新的有可能繁復無比的UI組件的設計與編碼清單、內(nèi)容策略、文案策略、表達溝通策略等等,以及存在于這些基礎之上的不一致現(xiàn)象;這些產(chǎn)出可以不僅讓團隊們都了解現(xiàn)在的問題有多么嚴峻,也會讓高層領導真正意識到問題??梢詭椭鷪F隊了解確定設計體系的工作范圍,也可以獲取組織的資源支持。
剩下的就需要設計體系團隊對哪些模式應該保留,哪些應該走,哪些可以合并在一起等相關內(nèi)容進行核查、討論。
2. 體系用戶研究
設計體系的關鍵是體系如何與真實的人溝通,而不是組件本身。因此在我們清查、構(gòu)建和迭代的過程會不斷穿插體系用戶的研究。這個過程將會讓大家知道,我們正在建設體系,希望他們即時測試和使用,提出意見。
永遠不要閉門造車,直到最后扔出個不能用的廢鐵,被體系用戶棄置。
一開始就讓每個人都參與進來,并在整個過程中與他們合作,對于您所設計的語言的成功至關重要?!狹arco Lopes,TravelPerk高級產(chǎn)品設計師
通常來說設計體系的搭建不是從0到1,而是從0.1、0.2到1。因此我們除了了解現(xiàn)有的設計資產(chǎn)外,還需要知道現(xiàn)有的規(guī)則。設計體系的用戶包含高管、領導、管理層(關注效益目標),產(chǎn)品團隊中的設計師、前端工程師與產(chǎn)品經(jīng)理等(關注實際使用效果),以及內(nèi)外部社區(qū)用戶(關注輔助使用效果)。
這個過程,我們可以獲取到領導層期望目標、各個協(xié)作團隊成員的工作流、協(xié)作工具與軟件、協(xié)作規(guī)則。這里的協(xié)作工具不只是包含純粹軟件工具,還包括那些標注筆記等任何內(nèi)容。如果對資產(chǎn)有大致了解,也基本了解體系用戶的相關情況后,我們就可以著手建立資產(chǎn)。
四、資產(chǎn)建立:建立資產(chǎn)與體系內(nèi)容
1. 確立定位
在建立詳細的資產(chǎn)內(nèi)容前,可以思考一下設計體系的定位。設計體系從規(guī)模上可以分成平臺級設計體系(如Apple的HIG、Google的MDS、Microsoft的FDS)和公司級設計體系(如Atlassian的ADS、Salesforce的LDS和螞蟻金服的AD)。
平臺級設計體系除了服務自身企業(yè)團隊外,更加專注幫助生態(tài)伙伴建立生態(tài)應用;而公司級設計體系目前主要服務于企業(yè)內(nèi)某些產(chǎn)品的設計與開發(fā),通常也公開給外部人員使用。
并且每個組織根據(jù)自身業(yè)務特色所形成的設計體系的結(jié)構(gòu)都會所不同,沒有兩個完全一致的設計體系;例如Material中就有機器學習的組件,F(xiàn)luent中針對不同硬件也會有說明,Lightning中則會出現(xiàn)更多的數(shù)據(jù)、表單等組件,一些體系專門加入全球化與本地化的模式指南,是因為往往這些公司需要應對更多國際化的挑戰(zhàn),而對可訪問性要求高的體系的產(chǎn)品也多是體量大、用戶廣的產(chǎn)品。
2. 內(nèi)容建立
我在前面的文章中已經(jīng)預先提到了設計的體系的結(jié)構(gòu),接下來的重點就需要我們對三個層核心體系內(nèi)容進行適應性的重塑和建立。
下面是我提出的設計體系VGLT-MO三層一環(huán)結(jié)構(gòu),幫助大家理解設計體系。
- 愿景與原則(Vision & Principle),它們作為設計決策的參考,指導前行。
- 指南(Guidelines),包含樣式指南(Style Guideline)、模式指南(Patterns Guideline)、內(nèi)容指南(Content Guideline)等更多通過文字和圖像進行傳達的內(nèi)容。
- 庫與工具(Libraries & Tools),包含組件庫(Components Libraries)、工具包(Toolkits)、協(xié)同工具(Collaborative Tools)等可以直接進行使用的內(nèi)容。
一環(huán)是管理結(jié)構(gòu)(Management Structure)與組織流程(Organization Process),包圍著這三層內(nèi)容,它促進整個設計體系成為一個活的生態(tài)系統(tǒng)。
其中各內(nèi)容的描述如下:
愿景與原則(Vision & Principle):
愿景是最大的標記原則根據(jù)組織和產(chǎn)品的目的變化,主要作用是建立一種通用的評價標準,指導設計與開發(fā),幫助使用人員進行評估,以形成相關團隊的決策共識。也有稱設計價值觀、設計語言的。
模式指南(Patterns Guideline):
模式是可重用組件的集合,模式指南對功能性模式進行規(guī)則定義,其中包含大量的組件內(nèi)容,但其中的重點是對如何使用組件進行定義。另外除了組件外,還會對互動方式、輸入方式、可用性等等內(nèi)容進行定義。
樣式指南(Style Guideline):
樣式指南是對大部分非功能性模塊進行規(guī)范,對如配色、交互狀態(tài)、動畫、排版、間距、圖標樣式、形狀與邊框、插畫、照片、標志、布局、數(shù)據(jù)可視化方式,甚至可能包括品牌身份,設計語言,聲音和語氣,寫作,模式和代碼風格指南等進行描述和定義,提供最佳用例和錯誤用例。它們大部分無法形式單獨組件,但是可以提供代碼。
內(nèi)容指南(Content Guideline):
內(nèi)容指南通常無法提供代碼,但能通過描述和用例來對一些難量化的內(nèi)容進行規(guī)范指導。例如語氣和音調(diào)、音效、文案風格等。
組件庫(Components Libraries):
這是主要面向前端工程人員的工具,通常是開放的網(wǎng)站或者內(nèi)部的文件(是文件而非文檔)。組件背后是體系中的可重用代碼的一部分,它們是應用程序接口的構(gòu)建塊,開發(fā)人員可以快捷地使用它們。不同的體系中組件的大小和復雜性可能有所不同,如頭像框、對話框、彈窗、按鈕、橫幅、下拉式菜單、文本框、選擇框、菜單、導航等等。
工具包(Toolkits):
這主要面對設計人員,提供了可供常規(guī)設計軟件打開,由設計師直接使用的文檔。一般直接可以在體系網(wǎng)站或在設計團隊內(nèi)部流傳。
協(xié)同工具(Collaborative Tools):
更為前沿的設計體系搭建者,開始提供創(chuàng)建依托于生產(chǎn)力軟件的輔助工具,以進一步提升設計與開發(fā)者之間進行溝通的效率。如React-Sketch.app、Kitchen等。當然另一方面搭載設計體系的網(wǎng)站或文檔也算是一種協(xié)作工具。
管理結(jié)構(gòu)(Management Structure):
管理結(jié)構(gòu)描述的是設計體系維護團隊的職能和構(gòu)成結(jié)構(gòu),以及他們與組織的產(chǎn)品的關系。
組織流程(Organization Process):
組織流程描述設計體系如何得到形成、應用、更新和推廣,是使設計體系成為鮮活生命體的血液。
著手建立之前,我們需要了解進行資產(chǎn)構(gòu)建的82原則:心急吃不了熱豆腐,永遠不要試圖一個一個建完,我們可以先完成80%的成分建設,再用后面的維護升級完成剩下的部分;否則預先看起來不錯的內(nèi)容會在后續(xù)測試升級中將會被證明是無用的工作。
不管是愿景還是原則或是指南等內(nèi)容,我們都可以在持續(xù)更新中進行調(diào)整。
3. 構(gòu)建體系愿景與原則
我們首先可以在體系定位的基準下,構(gòu)建愿景(Vision),這里的愿景指設計體系的愿景,愿景通常是簡潔的一句話,描述設計體系要實現(xiàn)的效果,指導大方向;清晰的愿景讓人明白該往何方前進,更容易建立動力,為實現(xiàn)體驗目標和業(yè)務目標建立決策的基礎。
愿景通常比較隱藏,有些體系只說明了自己是什么,例如Alibaba Fusion只說自己是企業(yè)級的中后臺設計系統(tǒng)解決方案,而未詳細指出自己要達成的效果。
下面的設計體系的愿景可以作為參考:
- Material Design System——更快地構(gòu)建精美的產(chǎn)品
- Lightning Design System——創(chuàng)造世界上最好的企業(yè)應用程序體驗
- Polaris Design System——共同為Shopify的所有商家打造出色的體驗
- Ant Design——創(chuàng)造高效愉悅的工作體驗
根據(jù)愿景,我們可以形成3-5條的原則,通常由簡短的單詞或短句構(gòu)成,搭配詳細說明。原則描述了根據(jù)組織特色和產(chǎn)品特色下,該設計體系的發(fā)展方向。
我們看看Ant Design的原則:
自然:數(shù)字世界的光速迭代使得產(chǎn)品日益復雜,而人類意識和注意力資源有限。面對這種設計矛盾,追求「自然」交互將是 Ant Design 持之以恒的方向。
確定性:界面是用戶與系統(tǒng)交互的媒介,是手段而非目的。在追求「自然」交互基礎上,通過 Ant Design 創(chuàng)造的產(chǎn)品界面應是高確定性、低合作熵的狀態(tài)。
意義感:一個產(chǎn)品或功能被設計者創(chuàng)造出來不只是用戶的需要,而更多是承載用戶的某個工作使命。產(chǎn)品設計應充分站在工作視角,促成用戶使命的達成;同時,在「自然」、「確定」之上,兼顧用戶的人性需求,為工作過程創(chuàng)造富有意義感的人機交互。
生長性:企業(yè)級產(chǎn)品功能的增長與用戶系統(tǒng)角色的演變相生相伴;設計者應為自己創(chuàng)造的產(chǎn)品負責,提升功能、價值的可發(fā)現(xiàn)性。用發(fā)展的眼光做設計,充分考慮人、機兩端的共同生長。
如何建立原則?
在我參與的設計體系實踐中,其中我主要策劃了關于設計體系建立的企業(yè)共創(chuàng)工作坊。
這個工作坊由企業(yè)方品牌設計師、體驗設計師(偏工業(yè)設計)、用戶研究員等參與;在工作坊上,我們不僅對品牌現(xiàn)有典型用戶進行回顧(這些用戶均在項目中有入戶訪談過),建立對用戶對于交互體驗的需求,另外由于有品牌部成員的參與,也能結(jié)合品牌發(fā)展理念,輔助呈現(xiàn)在設計愿景和原則上。
基于ABB的設計體系建設過程的案例和我的經(jīng)歷,可以提出一種方法是:我們可以嘗試聚集產(chǎn)品和工程師團隊,然后劃分為不同的小組。其中一半從業(yè)務需求和用戶需求角度進行探討,另一半從產(chǎn)品設計、體驗設計、前端工程師等體系用戶角度進行原則構(gòu)建。
總之,我們需要在體系原則的建立中融合業(yè)務需求、用戶需求以及體系用戶的需求,通過關鍵決策,建立關鍵規(guī)則。這些規(guī)則能夠形成設計決策的評價指標,
當然詳細說明的原則讓設計與開發(fā)團隊向愿景前進,能作為評估決策的標準,并且會可以隨著體系和組織的發(fā)展不斷迭代改善,所以一開始我們不必想著完全定義清楚。
推薦大家閱讀加西莫多的《要想建立設計體系,必須先定義設計原則》。這篇文章論述在設計原則定義上的理解,可以去看看。
4. 指南與組件建立
根據(jù)清查的資產(chǎn)清單內(nèi)容,我們可以進一步建立指南內(nèi)容:
- 樣式指南(包含色彩、字體、網(wǎng)格、標志、材質(zhì)、插畫、圖標、陰影、形狀、版式等內(nèi)容)
- 內(nèi)容指南(聲效、視頻、圖片、文案風格、語音語調(diào)等內(nèi)容)
- 模式指南(可訪問性、環(huán)境、手勢、輸入方式、交互、動效、可用性、可訪問性、可視化定義等內(nèi)容),在模式指南中會包含大量的組件(包含通用組件、導航、基礎輸入、菜單與工具條、文本、選擇器、數(shù)據(jù)展示、反饋、狀態(tài)與訊息等內(nèi)容)。
指南提供最佳實踐,能夠?qū)⒋a實時渲染和呈現(xiàn),并且提供明確的規(guī)則,便于使用者使用。
我認為,每個指南中的內(nèi)容的建立我們可以遵循以下流程和方式:
- 清查:資產(chǎn)清查是指南重構(gòu)的基礎,在上面的步驟中,我們已做了資產(chǎn)清查工作。
- 重構(gòu):基于資產(chǎn)清查結(jié)果和已確立的體系愿景、原則,創(chuàng)建可視化的內(nèi)容(例如文案型的就寫出來,視覺組件就做出來,交互型組件就做出交互,聲音型的就形成聲音,重點是讓大家都能看的到、聽的到),并召集大家進行評判,確立保留的內(nèi)容或重建新內(nèi)容;
- 定義:根據(jù)確定的內(nèi)容,進行代碼編輯或較詳盡的內(nèi)容,形成可以組件或一些全局樣式等的代碼;
- 指導:對內(nèi)容進一步確定統(tǒng)一的命名,記錄其使用規(guī)則,并且提供最佳實踐和錯誤實踐,并建立設計令牌(Design Token)。
我們創(chuàng)建的每個內(nèi)容都需要根據(jù)業(yè)務需求在通用和靈活中抉擇。組件往往是獨立的,沒有依賴性。
通用組件可以處理多個用例,而靈活的組件可以調(diào)整和擴展以在各種環(huán)境中工作??山M合的組件可以組合起來創(chuàng)建新的模式;為了可重用和可擴展,我們建立的每個模式都需要模塊化、可組合,并且需要兼有通用性和靈活性。
通常這些指南通常圍繞數(shù)字產(chǎn)品建立,一定會有小伙伴說,啊,我們家這個不是數(shù)字產(chǎn)品,你這個方法用不上。但其實無論具體產(chǎn)品如何,思維都是適用的。
如果說數(shù)字產(chǎn)品的組件庫是設計+代碼,那么在工業(yè)設計中,有可能就是設計+材料和工藝;在視覺傳達設計中,如企業(yè)形象識別系統(tǒng)的樣式指南部分則是非常重要的部分,可以是設計+工藝,每個企業(yè)的袋子用的材質(zhì)和工廠都能通過這種方式進行鏈接;一些人機交互設計中的非接觸式互動,如語言、手勢等,模式指南則就提升了重要程度;營銷的設計中,內(nèi)容的指南就變得重要。
談談設計令牌:
協(xié)作中,共享的語言是關鍵。設計令牌(Design Token)是為需要設計一致性的多個在線和本地產(chǎn)品而構(gòu)建。較大的企業(yè)可能有多個子品牌,而這些子品牌若想要享受設計體系帶來的支撐,但每個子品牌又都需要不同的、品牌一致的外觀和感覺;于是Salesforce UX團隊針對這兩種情況推出了一種解決方案即設計令牌(Design Tokens)。
對設計和開發(fā)者而言,通過設計令牌標記的通用可視化語言,將改善設計者與開發(fā)人員間的交流,并且能支持個性化的定制,但又不失去整體觀。
設計令牌讓多品牌共享設計體系成為可能,總的來說,使用設計令牌有以下特性:
- 增強靈活性和易維護性;
- 可以建立單獨的庫可以支持測試,和代碼跨版本進行發(fā)布;
- 允許在多個團隊、產(chǎn)品和代碼庫之間共享代碼;
- 迫使獨立開發(fā)組件,這樣它們就不會局限于僅一個用例;
- 為強大的前端測試架構(gòu)提供了基礎框架;
- 為樣式指南奠定了基礎。
5. 內(nèi)容裝載
所有內(nèi)容制作完畢后,我們可以尋找合適的載體裝載這些內(nèi)容。目前來說開發(fā)者的代碼往往可以通過在線獲??;而對于設計師,仍然需要建立設計主文檔,以盡可能囊括所有組件,并且適配現(xiàn)有設計軟件工具。這種方法很費效率,未來的設計體系發(fā)展中,也在嘗試打破這些現(xiàn)象。
目前,設計體系往往都是打破純文檔,以在線化的方式存在,但由于不同團隊預算有限,不一定每個團隊都能建立起自己的體系網(wǎng)站??傊菀撰@取是關鍵。
另外不管是文檔還是網(wǎng)站,都需要確立是否公開的問題,例如Airbnb的DLS建立在內(nèi)部網(wǎng)站,不對外公開,也有些設計體系不公開源代碼,但公開設計資源。
6. 庫與工具建立
庫與工具(包含設計用資源、開發(fā)用資源、協(xié)同工具、學習教程等內(nèi)容)。
上一步我們已經(jīng)將內(nèi)容進行了裝載,有些組件已經(jīng)入庫了?,F(xiàn)在進一步,我們可以將一些內(nèi)容根據(jù)面向平臺的差別,而整合成面向設計者的資源文檔,以及在開源社區(qū)中建立模式庫,并放置在我們的載體中。
資源充足的團隊也可進一步建立定制化的協(xié)作工具或平臺等等,幫助設計體系進行推廣、分發(fā)、同步、質(zhì)量管理、版本管理和更新等工作,而接下來就需要一個合適的流程來進行管控。
五、流程搭建:建立流程搭建與維護
設計體系存在一些通用的挑戰(zhàn),如:
- 如何讓文檔與系統(tǒng)代碼保持同步?
- 如何處理重大變更?
- 如何避免性能下降?
- 如何建立更新的流程?
- 前端代碼如何進一步系統(tǒng)化?
- 設計者與開發(fā)者如何更好地協(xié)作?
- ······
因此我們需要組織流程的介入以幫助我們解決這些問題。
一個優(yōu)秀的設計體系重要的是各個模塊間如何溝通交流而不是模塊內(nèi)部的屬性的行為,而且是與組織進行一定程度的綁定關系的,反映組織的文化。讓設計體系真正活起來的就算體系流程。
遵循敏捷開發(fā)原則的工程師,和遵循以用戶為中心的設計師理念上的不同也容易造成在協(xié)作速度上的差異;協(xié)作工具的建立外,也需要一個合適的流程,進行統(tǒng)一。
統(tǒng)一的設計語言不應該只是一組靜態(tài)規(guī)則和單個原子。它應該是一個不斷發(fā)展的生態(tài)系統(tǒng)?!狵arri Saarinen,Airbnb首席設計師
樣式指南是設計過程的產(chǎn)物。設計系統(tǒng)是一個活的、有資金支持的產(chǎn)品,有路線圖和待辦事項,服務于一個生態(tài)系統(tǒng)。—— Nathan Curtis,設計體系專家
通過定義清晰的流程,可以為解決問題減少協(xié)作中的摩擦和不確定性,讓每個階段都有不同的目標和交付物。
——流程的價值
- 流程為每一步提供了明確的期望,讓體系用戶可以專注于目前手頭的任務,而不用擔心下一步該做什么。
- 標準化的流程可以每一步中建立數(shù)據(jù),這些數(shù)據(jù)可以被引用并用于通知未來的迭代或修正和快速的測試使用。
- 流程建立了在產(chǎn)品創(chuàng)建過程中,每個相關團隊成員的角色和職責的理解——即是在正確的時間引入正確的人,使每個人的參與都有利于產(chǎn)出的質(zhì)量。
- 一個可預測的過程將確保進展順利、高效和可預測,同時也提高質(zhì)量和一致性。
——什么樣的體系流程是好的流程?
總的來說,我們需要考慮對使用、定制、驗證、同步等各種情境,并形成清晰合理的流程,才能保證動態(tài)化的設計體系。
我們需要考慮以下的情境(Brad Frost,2019):
- 常規(guī)使用;
- 使用中發(fā)現(xiàn)組件不存在或不符合要求;
- 對新組件進行原型化和審查;
- 進一步設計/開發(fā)和測試;
- 文檔化和發(fā)布;
- 支持實際使用組件中發(fā)生新問題;
在建立過程中,一張詳盡的路徑圖不管是內(nèi)部保留還是公開,也是向自己的團隊和體系用戶表明狀態(tài)、展示價值的良好工具。這種版本控制方法,可以構(gòu)建持續(xù)開發(fā)的文化。
當我們的設計體系1.0搭建完成后,設計體系團隊也有更多事情要完成;例如進一步建立知識共享的流程、公開推廣、更新、管理,甚至是輔助入職培訓。
當設計體系逐漸成熟,也會形成不同的層次,以支持不同子產(chǎn)品的獨立開發(fā)。分層也算是相比于設計令牌的另一種解決辦法,但也能同時去使用。
圖源自Nathan Curtis,Design System Tiers(2019-2)
接下來,我們再看一些知名設計體系的組織流程例子:
1. inVision
inVision的流程分為6塊內(nèi)容,4個驗證循環(huán)過程。
- 理解(Understand):利用顧客研究獲取見解,以深入了解問題,并確定它如何與業(yè)務目標保持一致。PM領導這一階段,并與研究團隊合作進行訪談、收集數(shù)據(jù),并進行競品研究。
- 探索(Explore):設計團隊構(gòu)思并探索數(shù)個可能的解決方案,并與產(chǎn)品和研究團隊合作生產(chǎn)線框圖、核心流程和用戶旅程。
- 定義(Define):一旦確定了潛在的解決方案,產(chǎn)品團隊就努力讓每個人都知道成功是什么樣的。這項工作的輸出對問題描述和成功地衡量規(guī)則。
- 設計(Design):提煉解決方案是設計團隊的責任。他們與研究、產(chǎn)品和工程團隊合作,開發(fā)核心流程、原型,并確定技術需求。
- 構(gòu)建(Build):工程將設計和原型轉(zhuǎn)化為現(xiàn)實。產(chǎn)品團隊協(xié)調(diào)質(zhì)量保證、支持文檔以及銷售和營銷團隊。
- 學習(Learn):觀察推出的解決方案的有效性。產(chǎn)品團隊與研究、設計和工程團隊合作,根據(jù)成功衡量標準收集見解,以此來指導下一步或再循環(huán)。
2. Fluent Design System
Fluent Design是一個集體的、開放的設計系統(tǒng),可確保人員、團隊及其產(chǎn)品具有構(gòu)建的基本組件和流程以建立跨平臺的連貫體驗。(Joseph McLaughlin,2019b)Fluent Design System的組織支撐流程中包含F(xiàn)luent Process(流暢流程)的一種工作流程。
根據(jù)微軟全球開發(fā)者大會,我總結(jié)的流程圖片
流暢流程以共創(chuàng)(Co-creation)、連貫(Coherance)、創(chuàng)新(Innovation)作為核心原則;在原則指導下,這種工作方法首先是和共創(chuàng)者參與的孵化,到和開發(fā)者與設計者的系統(tǒng)性開發(fā),再到終端用戶參與下的大眾測試與評判,最后再到整個生態(tài)系統(tǒng)蔓延,這即為一次流暢設計浪潮(Fluent Design Wave)循環(huán);這種浪潮一般每半年在全球的開發(fā)者大會上發(fā)布一次,以迭代流暢設計體系,加快體系的快速發(fā)展。(微軟開發(fā)者大會, 2019)
流暢設計體系(FDS)帶來的不僅是一個跨平臺的設計、編程和交互行為的共享的用戶體驗框架集合,也是產(chǎn)品團隊跨學科工作的新方法;這種方法可以減少設計與開發(fā)間的鴻溝,簡化開發(fā)人員生態(tài)系統(tǒng),讓各種合作伙伴都能從這種框架下受益,并且可以為客戶提供全天全流程的無縫體驗。
就像產(chǎn)品設計一樣,我們將設計體系視為可以為我們的用戶解決問題的設計挑戰(zhàn),以用戶為中心,不過這次的用戶是我們的設計師、設計團隊、工程師團隊和產(chǎn)品負責人等等?!④浽O計總監(jiān)合伙人Joseph McLaughlin(2019b)
3. Ant Design
來自”Ant Design 資產(chǎn)工程化探索和實踐“(2021-1)視頻的截圖
Ant Design中也存在一個基本的流程,從研發(fā)到部署到驗收到發(fā)布;如果某個使用者因為業(yè)務需要,定制了自己的方案,會有一系列流程讓設計體系團隊知道發(fā)生了什么,這些清晰的流程讓每個人到明確自己在使用設計體系中的角色。
六、體系評估:體系效果評估
本文開頭已經(jīng)提供一些設計體系的評估指標:如易用度、交付量、錯誤率、可用性、復用率、團隊滿意度、團隊NPS等指標可以進行評估。
但進一步來說,哪個是核心考慮的因素?是重用率。因為這個指標其實也復合了一定的團隊的接受能力、使用效率、使用效果等因素,如果做簡要的評估,這就是一個重要的評估指標。
Thomas Derleth(2018)的研究表明,通過重用以提高生產(chǎn)率的潛力取決于集成用戶界面組件的成本、以可重用方式開發(fā)用戶界面組件的成本以及單個用戶界面組件的重用次數(shù);他也發(fā)現(xiàn)組件庫的成功取決于產(chǎn)品團隊對它的接受程度以及他們對用戶界面組件和CSS服務的重用行為。
只有一致地重用用戶界面組件和服務,才能最大限度地減少變更耦合,提高用戶界面的一致性,從而積極地提高每個產(chǎn)品團隊的生產(chǎn)力。
通過這樣的6個流程期望能建立富有生命力優(yōu)秀設計體系。
- 愿景建立:宣揚愿景,建立目標
- 團隊配置:配置團隊結(jié)構(gòu)與人員
- 資產(chǎn)清查:資產(chǎn)清查與體系用戶研究
- 資產(chǎn)建立:建立資產(chǎn)與體系內(nèi)容
- 流程搭建:搭建體系運行和維護流程
- 體系評估:體系效果評估
下一篇,我將分享設計體系的未來可能發(fā)展。謝謝閱讀??!
如果有任何不準確的地方,歡迎交流~
相關閱讀:
設計體系丨什么才是設計體系?結(jié)構(gòu)、原則與認知誤區(qū)(二)
作者:龍哩個龍 。公眾號:LONG說設計
本文由 @龍哩個龍 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
“我將在后面的文章中,放出我基于對御三家平臺級設計體系(Apple的HIG、Google的MDS、Microsoft的FDS)和國內(nèi)外企業(yè)級設計體系(Salesforce的LDS、Atlassian的ADS、螞蟻金服的AD)的資產(chǎn)清單” ,在哪里?
《設計體系丨根據(jù)六大設計體系總結(jié)出的資產(chǎn)清查清單(五)》
作者:龍哩個龍
https://api.woshipm.com/pd/4480138.html?sf=mobile
設計系統(tǒng) 跟設計體系 兩個怎么區(qū)別
我是這樣認為的,單純只是追求重用和一致性的具體產(chǎn)品解決方案,就是設計系統(tǒng)。而如果在產(chǎn)品形態(tài)之外,還開發(fā)了獨特的無形的流程(推廣、同步、分發(fā)等),就是設計體系。