設計體系：數字產品設計的系統化方法

我的感悟這本書的標題比較宏大，一眼略過難以快速明白其主旨。其實，它的核心內容講的就是——工作時掛在每一位設計師嘴邊的“設計規範”與“組件庫”。比如，AntDesign就是最知名且完善的組件庫之一。圍繞設計規範，作者提出了體系化的概念，並列出了清晰易懂的上手實踐指南。 熟稔“設計規範”與“組件庫”的設計師們是否仍有必要看這本書？仍然有必要。評論區的另一位朋友和我觀點相似——如果我們把書當做是一位很久不見的朋友，和這位朋友聊聊天，即使聊的都是很簡單的道理，你也會獲得新啓發，汲取到能量。 對我最有啓發的點有： 1、在團隊內， 共享語言（shared language）是非常重要的，即保證當我們使用同一個詞語的時候，我們指的是同一個東西。 2、要理解一個模式的目的，需要關注它的作用是什麼，而不是你認爲它是什麼。換句話說，要試着找到最能描述其行爲的操作。用動詞而非名詞來描述模式。 3、如何爲模式命名？有個性的名稱更容易記住。它們不僅縈繞耳旁，還能啓發其他名稱。也可以維護一份術語表。 內容摘錄◆ 第1章 設計體系 >> Web設計師開始擁抱更加模塊化、模式驅動的設計實踐。這樣做是有充分理由的：我們需要爲更多的屏幕類型、更多的設備類型、更多的場景和更多的用戶創造非凡的體驗。爲此，我們開始將界面拆解爲微小的、可複用的模塊，並藉助這些模式，以比過去快得多的速度構建產品、功能和界面。 >> 模式是一種用於解決特定設計問題的可復現、可複用的方案。 >> 從前端開發的角度來看，模塊建立在HTML的基礎上，而感知性模式則是典型的CSS屬性。 >> 語言是協作的基礎。如果你在一個團隊中工作，你的設計語言就需要在所有參與產品創建的人之間共享。如果不共享語言，團隊成員就無法有效地進行共同創造——每個人都對他們想要實現的目標有着不同的心智模型。 >> Abby Covert在她的How to Make Sense of Any Mess一書中指出，在開始構建界面之前，就應該通過討論、審議和記錄語言決策等方式建立起一套共享的設計語言。不僅高等級的概念需要這樣處理，討論設計決策的日常用語也需要如此。共享語言，便意味着我們能以相同的方法爲界面元素命名，爲設計模式下定義，並能讓設計文件和前端代碼使用相同的名稱。僅僅做到這些還不夠。有時，團隊裏的人以爲他們形成了共識，因爲他們建立了共享的詞彙表並已付諸實踐，但他們對這些詞的理解其實根本不同。例如，團隊的核心概念裏面有“場景”（scenario）這個術語，但用了一年以後才發現，團隊裏不同的人對這個詞的理解完全不一樣。我們不僅要對語言形成共識，還要對語言的用法形成共識。僅僅對按鈕這個詞的含義達成共識是不夠的，還需要對不同背景、不同目的下使用按鈕的原因和方法形成共識。 >> 如果團隊之間缺乏溝通，很可能導致只有一小部分人在用它，或者產生大量彼此割裂的模式。如果能保持更新，模式庫便可以成爲共享語言的詞彙表。 用戶的“十分鐘”訴求讓人印象深刻，是很適合植入團隊成員心中的錨點。 >> 案例：“十分鐘食譜”網站 我之前在寫工作覆盤時候，有提到一點：交互設計的靈魂是講好一個故事。一個好的故事，會讓項目中所有人都擁有同一個想象。讓所有人心兒往一處想，勁兒往一處使。在學生作品集中，很多人會放上“用戶畫像”，卻沒有想清楚用戶畫像的意義，於是淪爲一種擺設。其實，用戶畫像也只不過是幫助我們更好地代入想象用戶，並且讓團隊所有人都擁有同一個想象的工具而已。 >> 爲確保我們所做的所有事情都清晰地體現了產品目的，我們需要建立一些基本原則和價值觀。可以非正式地討論，也可以寫下來形成宣言。重要的是參與產品創建的人都認同這些價值觀，並承諾實踐它們。例如，十分鐘食譜網站團隊的每個人都需要了解時間的價值。他們需要時刻謹記食譜是有時間限制的，因此他們會努力讓網站的交互變得簡短、快速和流暢。 >> 這些原則不一定是很正式的，甚至不一定要寫下來。但是，團隊成員應就這些內容達成一致，這對於讓每個人的工作和優先級保持同步至關重要。這些內容還能輔助決策：從先實現哪些功能、使用何種方法，到制定用戶體驗流程、設計按鈕外觀、選擇字體，等等。 ◆ 第2章 設計原則 >> Atlassian是一家企業軟件公司。起初，他們針對市場營銷和針對產品的原則是不同的。隨着時間的推移，他們逐漸融合了這些原則，形成了一套統一的理念，彌合了市場營銷、產品設計和服務支持等工作領域之間的裂縫。現在，他們正基於一套統一的原則開展各項工作。“這是一套統一的體系。設計原則將散落的點串聯了起來。”——Jürgen Spangl, Atlassian公司設計負責人 >> 你可以設想自己是在做這樣一件事：一個新人加入了你的團隊，你需要向他解釋，在你的項目中做設計時最重要的五件事情是什麼。 >> 模糊的設計原則：“明確。”實用的設計原則：“第一優先級只有一個。什麼是你希望用戶最先看到的或最先用到的？”模糊的設計原則：“簡單。”實用的設計原則：“把界面做到牢不可破。就像兒童玩具一樣，確保用戶可以隨意探索，不會因爲錯誤操作而崩潰。”[插圖]模糊的設計原則：“有用。”實用的設計原則：“從需求開始。如果你不知道用戶需要什麼，就無法做出正確的事情。去做調研，去分析數據，去與用戶交流，而不是做假設。”[插圖]但是，即便是文字極佳的原則仍然存在多種解讀方式。只有將原則與應用原則的真實案例結合起來，纔是最爲實際的做法。 >> 好的設計原則不會試圖涵蓋一切。它們有態度，並積極地鼓勵設計師擁有自己的觀點。 >> 首先爲自己和同事而寫，尤其是設計師、開發人員、內容編輯、營銷專家、領域專家，也就是與產品的創建直接相關的人員。你們的目標應該是就“什麼樣的設計對你們的產品來說是好設計”這一問題達成粗略的共識，並提供如何實現共識內容的實操指南。 >> 牢記關鍵模式的目的，有助於瞭解設計體系的運轉方式，防止設計體系在發展過程中碎片化。 >> 要理解一個模式的目的，需要關注它的作用是什麼，而不是你認爲它是什麼。換句話說，要試着找到最能描述其行爲的操作。用動詞而非名詞來描述模式，有助於擴展模式的潛在用例，並更準確地定義其用途。設想你有一個簡單的推廣在線課程的模塊（見圖3-7）。當你試着描述它是什麼的時候，可以將其稱作“圖像標題”或“課程橫幅”。 >> 但是用這種方式描述模式，就過於侷限於其呈現和內容了，最終容易將模式的使用範圍限制在特定的上下文中。相反，如果根據操作——從用戶角度及你自身的角度——來定義模式，便可以發現它的目的：“推廣課程”（對你而言）/“發現課程”（對用戶而言），“從課程中受到啓迪”（對用戶而言）/“鼓勵人們加入課程”（對你而言）。通過關注操作，可以將模式與行爲聯繫起來，併兼容各種不同的用例。上面的這個模式除了推廣課程還能推廣什麼？在線討論區？還是一場新的活動？你給它起的名字也能反映這一點。在這個例子中，我們最終將模塊命名爲“廣告牌”（Billboard），以反映其注重操作的推廣功能。 >> 首先，列出讓模塊能夠有效運行的核心內容元素。例如，你們可能都認可界面中像“廣告牌”這樣的推廣模塊需要以下內容：❑ 標題❑ 強烈的行動召喚❑ 吸引眼球的背景（無論使用純色還是圖像）接下來，試着確定元素的層次結構，並決定如何對它們進行分組。例如，圖片是內容的一部分嗎？標籤頁是一定要有的嗎？在這樣做的同時，可以畫一些草圖，從而讓結構變得可視化。 >> 另一種思考方式是想象你的界面不是可視的，而是可以通過聲音讀出來的。這個聲音什麼時候需要增大音量並改變語調？思考如何通過模塊內元素間的相互關係和層次結構，完成對音量和語調的視覺表達。當然，這樣做還有助於提升對屏幕閱讀器[插圖]的可訪問性。 >> 看過多個團隊如何使用模塊的案例之後，我們注意到，設計體系中最有效的名稱往往具有這些特性中的一個或多個：它們使用了隱喻，它們是有個性的，它們能傳達模式的目的。 >> 有個性的名稱更容易記住。它們不僅縈繞耳旁，還能啓發其他名稱，甚至可以建立一個系列的名稱。FutureLearn的“耳語框”（Whisperbox）模塊旨在用於不會過分引人關注的促銷區域。但當另一個團隊需要更爲醒目的東西時，他們創建了“轟鳴框”（Boombox）。“耳語框”和“轟鳴框”是一對兒，這有助於增強詞彙的相關性，從而讓人更容易記住。 >> 維護一份術語表是分享和發展設計語言最有效的做法之一。創建並維護一份術語表會讓你有意識地關注自己所使用的詞彙，因爲你必須清楚地寫下這些詞彙。 運營活動頻率高且需求急，通常是最需要模塊化的產品類型 >> 通常，模塊化方法適用於具有以下特點的產品：❑ 需要擴張和發展❑ 需要適應不同的用戶需求❑ 需要大量重複的部件❑ 需要讓多個團隊能夠並行、獨立地開展工作這樣的產品包括電子商務、新聞、在線學習、金融、政府等大規模網站——任何需要擴張和發展以及應對不同用戶需求的網站。 通俗理解，功能性模式屬於交互層面，感知性模式屬於視覺層面 >> 最簡單的劃分結構的方法，是將模式庫分爲組件和樣式（即功能性模式和感知性模式）。 >> 只有當元素被複用時，纔會被添加到模式庫裏。有的團隊只有在第二次甚至第三次使用某個模塊的時候，纔會將其添加到模式庫裏。這樣做的邏輯是，在把元素添加到設計體系裏之前，必須證明該元素確實是一種模式。這有助於保持模式庫精簡。 ◆ 結語 >> 亞歷山大在1996年OOPSLA會議[插圖]上做的主題演講中強調，關於建築模式語言有一個根本性的問題：這些模式進入體系之後，會讓人類的生活更美好嗎？即使並非所有模式都能擁有這種能力，我們至少也要不斷努力實現這一目標。

極具指導和參考意義的設計方法論

特別實用，特別乾貨的好書，翻譯的也好。

本書主要講述了設計系統相關的設計理論和實踐兩大部分，其中關於組件落地方面還是比較有啓發價值的。根據個人思路梳理了下書中內容，可能存在一些誤解，歡迎各位同行批評指正。 設計系統應該是有態度的，可以給使用它的人提供一些創意的思路，否則直接拿個現成的組件庫不就行了。這個態度如何體現，個人覺得主要在於設計原則，而設計原則又根據產品的目的來定，和產品息息相關。 好的設計原則不是停留在表面的，而是可執行的參考建議。比如“簡化”這個詞作爲設計原則，是有些模糊的不明確的。因爲並沒有指出什麼是簡化如何簡化。而換成另一種說法，“消除無用元素”，則是可執行的，任何元素都有目的，也就是它所屬的目的，如果你不清楚一個元素爲什麼存在於此，那麼可能它就不應該放在這。頁面如此，產品在增加新功能時也是如此。 設計原則指導着功能性模式和感知性模式，功能性模式可以類比成動名詞，是具體的可操作的部分，感知性模式則類似形容詞，是描述的部分。比如按鈕是有明確功能的模塊，是用戶能提交某項操作，而按鈕本身的顏色、狀態、上面的文字等則是描述按鈕是什麼樣的，屬於樣式。在前端看來，模塊建立在html上，感知性模式則是典型的css屬性。 可以轉換成容易理解的組件，需要考慮組件的可落地性，比如： 1.共享命名。命名要和組件本身緊密聯繫，名字起的好，則容易被記住，也就容易被應用。每次應用又會強化記憶，屬於正循環。否則，一個記不住名字的組件很大幾率不會想到被使用，可能連知道都不知道，不如新創建一個。 理想情況下，參與產品創建的每一個人都應該知道這個元素是什麼：它的名稱和目的是什麼，爲什麼會被設計成這樣，應該如何使用它，以及何時應該使用它。 2.動態維護。組件庫是動態的，隨着時間不斷豐富，是需要維護的。前端和設計保持一致，能很大程度上提高協作效率，保證品牌統一和界面一致性。 關於維護方法，主要有兩種，一種是較爲嚴格的，每次創建新元素則設置成組件。這是有要求的，否則會不斷累積，產生很多功能相似的、重複的組件。需要先看現有組件是否滿足，如果不滿足，看能否改動後滿足，如果還不滿足，則創建新的。 另一種則相對寬鬆，每次創建新元素不設置成組件，但做好記錄。當再次使用的時候再搞成組件，這種理念也是很好理解的。再次使用說明存在複用性，做成組件也是理所當然的。 3.關注操作，將組件和行爲聯繫起來，併兼容不同用例，這樣可以擴展組件的使用範圍，比如上傳模型，上傳圖片，都是上傳，則可以用一個組件，強化了用戶認知。 4.關於迭代。過於一致，則可能歸於普通；賦予設計師打破常規的權力，則存在更多可能性，也更容易做出品牌差異來。 5.“應該與不應該”（dos and don'ts）很有用，特別是有可能產生誤用的時候。很多大廠規範中就採用了這種方法，確實很直觀。 一些妥協。一些少量不同步總是會有的，不可能那麼完美，我們要接受這個事實。 有了設計系統，可以有更多的精力去解決更重要、更有價值的事情，比如更好地瞭解用戶、讓產品體驗更順暢等。

看了大家評價還是很中肯的，我談下我的觀點。 首先這本書不存在過時，我覺得任何能被人推薦且有一定基礎的書籍都不存在過時。相反我們看書的人正是因爲避免過時纔會看書。 若果你把書理解爲一位很久不見或想聊一直沒聊到的朋友就會發現，即使很簡單的道理你也會吸取能量。 關於設計體系我也不認爲不適合現在的職場，職場首先是公司第二是自己，沒有一家公司不需要這些，而是成本不允許。那麼你作爲第二主體就必須學的很紮實，對自己的組建和梳理並不會因爲這些而變得陳舊和臃腫，反而會讓你在紛亂的思緒裏發現你很久沒覆盤了，且覆盤的規則該擴展了。 以我的經驗這本書又提供了思考，我們的框架和體系需要再次迭代，這個感覺就好像最近的那個教人坐火車的博主。你明知道這些是不需要再次迭代的，但出現後你會發現邊界不同了，可能是參與的人不同也可能是參與的市場不同了

書中關於體系化的解決問題的理念是將設計價值儘可能最大化纔是核心，引導用戶操作和傳達品牌達到商業目的。設計體系的建立和維護是爲提高設計師效率，以便做出更規範好用的頁面，可將更多的時間放在研究和探索上。 具體實施需要結合所在公司的實際情況，1-3的設計團隊建設和維護時間成本太高，在一直追求快速迭代現在執行起來確實有難度。反而是成規模設計團隊的優勢，能儘可能保證設計輸出質量和穩定性。

很好的一本書，是研究產品技術和語言理論的不錯選擇。“創新、優雅、人性化”是產品設計的無上真理，作者很好地把這個原則融入到了書中。體系一直是重要的框架，而在產品設計領域很少有人提及，這算是一部集大成之作，填補了產品設計框架的空白。值得推薦。

隨手挑選的一本，被書名“體系”“系統化”兩個詞吸引，而選作我入門UI UX設計的第一本書。 本以爲是關於UX設計基礎理論的書籍，結果看第一部分的時候發現完全不是這麼一回事，說的是具體的模式庫的構建，類似設計指導手冊（白皮書）的構建與編寫，導致我一度讀不下去。 不過從“過程”這一章開始，作者開始介紹一些具體內容，結合過往建築設計的經歷，倒是很有代入感。我一直非常痛恨重複的手工活，如何聰明地構建可複用模塊，減少重複性勞動，是永遠伴隨設計工業化流程的議題，很難一勞永逸。

什麼纔是有效的：只有當設計體系圍繞產品目的，綜合了設計過程中的成本效益及用戶體驗的效率和滿意度時，它纔是有效的。

產品目標、組織文化共同作用導出設計體系的價值和應用程度。將模式庫區分爲功能性模式（組件）和感知性模式（品牌、行爲、認知等感知元素）。視覺設計師對模式庫引發的“自我價值恐懼”，常未能從產品目標和設計初衷上去思考。設計體系和模式庫的應用，受團隊文化、資源限制，最終應以特定的程度和形式滿足需要，建立過程中管理和維護共享方式也決定其後期的落地實際價值。