論設計系統的銷售：展示產出，而非操作過程

隨著一個公司團體內部的設計任務複雜化和規模化，要想確保自身輸出所有產品的一致性，給設計流程配置一套可參考的明確標準顯然是不可避免的趨勢，但是我們應該如何向客戶或者非設計師們說服這一決定的主要目的並非是為了偷懶減輕工作量，或者想一勞永逸後高枕無憂，同時還讓他們也加入到這一標準的建立中，共同創造出被公司內所有人認可的方案呢？

這篇文章就是針對這一問題很好地提供了幾種可以使用的成功策略，更好的是，它也幫助了我們加深對建立一套模組化的設計系統所帶來好處的認識。

作為設計師和開發人員，我們知道一個占主導地位的（設計）系統能夠為公司的不同體驗輻射一致性。但有時候構建這樣一個系統被認為是一項極具風險的投資，並且它的價值不一定能立即可見。因此你應該採取什麼樣的方式向客戶推銷一個設計系統？你又應該怎樣做才能說服公司將構建一個模式庫放到戰略路線圖之中呢？

你可以把一個公司的所有網站介面一頁頁打印出來，再集中到一個大展板上，來顯示公司內部是多麼的四分五裂。

Dan Mall 在他「銷售設計系統」一文中，談到我們可以把一個公司的所有網站介面一頁頁打印出來，再集中到一個大展板上，來顯示公司內部是多麼的四分五裂。這個例子也可以說明每次都從頭開始，一個個地搭建網站，沒有意義地重複造輪子，會浪費多少金錢和精力。

將這些不一致視覺化，有助於發現和找到網頁中潛在的問題，但我們如何才能證明一個模組化的設計系統對實現網頁的一致性有幫助呢？

畢竟設計系統是由一個個模組，而非頁面構建而成的。我的經驗告訴我，最有效的方法是向客戶展示有形的利益，而不是向他們解釋操作過程或者具體步驟。

因為客戶並不想知道原子設計、模組化設計或者獨立模式，他們更願意看到實際產出，比如一個可操作的原型或者一個包含了所有元件的介面。

圖片來源於 Brad Frost 網站

一種更好地展示產出的方法是使用 project hub（專案中心）

還有一種能更好地展示產出的方法是使用 project hub ① （專案中心）—— 一個可以將專案中所有重要的素材集中起來，按時間順序排列，並保持不斷更新的網站連結。這樣客戶可以透過隨時訪問它來檢視專案的程序。你甚至可以給響應式原型中新增可編輯內容的屬性，來使原型中的文字變得可編輯，因此當一個專案的利益相關者想要調整文字時，她可以在任意瀏覽器中進行操作，然後透過調整視窗大小來檢視文字是否也可以適用於窄屏。

當我們與其他公司合作時，我們從來不會推銷原子設計方法②，也很少推銷設計系統。相反，我們銷售的是一個能快速看到產出，（恰好）包含了模組化設計方法論的新方案。我們“銷售”的是 專案中心和快速的週轉時間，而構建一個設計系統通常只存在於設計師和前端開發人員交流之中，而不是客戶需要思考的問題。

① 一個由 Brad Frost 提出，用於跟蹤設計專案進度的工具。通常是一個線上（公開或受密碼保護）形式的檔案連結，以便團隊中每個人都可以進行訪問。

②原子設計是一種方法論，由原子、分子、組織、模板和頁面共同協作以創造出更有效的使用者介面系統的一種設計方法。

將一個設計系統納入到公司發展路線中的策略

有時我們不再是向客戶推銷一致性，而是要將它變為一整個公司團隊，無論市場營銷，內容管理，還是技術支援團隊，都明確的優先考慮事項。而此時展示產出也同樣很有幫助，特別是因為這些產出可能不僅只是一組可操作的原型。Nathan Curtiss 在最近（由 Jina Bolton 精心策劃的） Clarity 會議的演講中建議，設計系統一定要確保紮根於一個公司團隊之中。

在他的個人經歷中，確保一個設計系統在公司團隊中的成功，對提高團隊的工作效率至關重要，比如：設計系統能幫助各方參與者節省時間並快速獲得結果。但你要如何讓團隊去相信一些他們還沒有體驗過的價值呢？

很簡單，為他們創造這種價值。想象一下，如果在一塊具有不一致性體驗的展板旁，放一塊能帶來一致性體驗的展板進行對比；或者是對頁面的基本外觀（可能只是一個標題和幾個關鍵按鈕）進行重新設計來使頁面間的體驗一致，然後也打印出來，並將修改前後的兩塊展板放在一起對照會怎麼樣呢？

也許你還沒注意，設計師和開發人員就已經興奮地對其他更多的 UI 元件進行規範化了。

測量並提供可操作的資料

顯然，視覺設計是非常主觀的，因此引入指標和資料 —— 比如轉換率 —— 比其他任何方式都能更有效地闡明論點。

定義一個包含了多種體驗（例如：一個使用者先從登入頁面進入，然後瀏覽商品，提交訂單，並在自己手機的本地應用程式中檢視物流狀態）的使用者旅程，然後記錄針對這些體驗的使用者訪談結果，並展示給利益相關者。

或者更好的是，你可以邀請他們來直接觀察訪談的過程。接著快速繪製出一個原型再進行一次使用者訪談，並保證兩次訪談中其他條件的一致，比較並清楚記錄下你的結果。如果這些結果遠低於你的預期，你最好繼續迭代你的設計，直到能獲得滿意的結果。

解決痛點

如果第一種方法沒有效果或者並不適用，你可以試試去尋找公司內的痛點。不一致的視覺體驗通常是由於背後使用的系統不一樣——大部分情況是因為使用了十分過時的系統。當然，這些系統之間或多或少還是有所聯絡的，就算這種聯絡可能只是為了監測銷量或者把控質量。

或者有時我們可以花點時間來回顧一下客戶支援部門中積壓的工作和技術/設計上亟待解決的問題：通常與資深的客戶支援人員進行一次簡短交流，對揭示損害轉換率或者使用者參與性的常見痛點極有幫助。然後你可以專門針對這些痛點，找到一個方式——可以透過使用一個具有一致性的設計系統——來解決它們。再次強調，主要關注產出結果而不是操作過程。

優先考慮最不可見的一致性

然而，無論是利益相關者還是忠實使用者都不會喜歡重大的，具有顛覆性的，或者 “大爆炸式“ 的新設計——不管它們與之前設計具有多麼無可挑剔的一致性——對於那些多年來一直使用該網站的使用者來說都是弊大於利的。

因此比起進行一次翻天覆地的設計改革，我們是不是可以規定並使用不同級別的一致性？

這些級別可以從最不可見的一致性（行間距、印刷比例）到最可見的一致性（按鈕、圖示、排版）進行分佈，很顯然在專案最開始階段 “可見” 級別的一致性甚至不用被提及。

在使用者訪談同時進行短時間設計衝刺

實現幾張關鍵頁面的初級一致性並不困難。但隨著專案的複雜化，這一任務可能會讓人望而生畏。這時為了保證效率並快速地獲得結果，最好的辦法是設計衝刺：一個用來回答關鍵性商業問題，由設計、原型繪製和使用者測試組成的五天設計流程。

圖片來源：https：//www。gv。com/sprint/

設計衝刺採用了一個透過設計、原型繪製和使用者測試來回答關鍵性商業問題的概念。

一旦在公司範圍內解決問題時，無論是規範使用者體驗還是最佳化前端，我們都不會有太多的時間來獲取有價值的結果。根據具體情況，我們會盡早地進行使用者訪談，通常在第三天就會安排上 4 次緊湊的使用者訪談。

原則很簡單：消除干擾並建立約束條件，以便在使用者訪談之中就能進行創造。理想狀態是，下午 1 點我們先進行 15 分鐘的使用者訪談，然後接下來 1。5 小時內——我們依據直覺和談話內容——來修改設計方案，因為 2 點半我們有另一個15分鐘的使用者訪談。

第二次訪談結束之後，我們會再花 1。5 小時進行第二次迭代，並在下午 3 點準時開始第三次的使用者訪談。只有在整個團隊都按計劃推動程序的情況下，你才能在使用者測試之前完成所有訪談工作。因此這意味著每位成員都必須能夠當機立斷出下一個衝刺環節要完成的工作。

顯然，你可能需要一個計時器來避免你的安排被打亂。另外，既然使用者就在現場，在團隊思考下一個迭代版本的時候，你還可以再安排幾場其他的使用者測試。

用網頁應用程式輻射一致性

但是你要如何戰略性的選擇優先針對哪些元件進行設計衝刺呢？

比如：對於一家提供多種體驗，覆蓋從內容驅動型網站（如介紹一家酒店），到任務驅動型網頁應用程式（如預訂房間，帳戶管理），再到本地應用程式（如預訂房間，帳戶管理 ）等多種系統的公司，能為它的整體“性質”帶來一致性的最佳方案是什麼？

根據 Nathan Curtis 所說，由於網頁應用程式最具可追蹤性、交易性和實用性，並被證明能很好地指導設計系統的構建。最有效的方法是 “用網頁應用程式輻射影響力”，或者說是，“優先實現核心產品的一致性，並以此為中心向營銷類網站和本地應用程式傳遞影響力” 。

圖片來源：https：//twitter。com/sophshepherd/status/715611781733834752

Nathan Curits 在 Clarity 大會上提出我們應該用網頁應用程式，而不是網站或者本地應用程式來輻射一致性。

這的確有一定道理。比方說，網頁應用程式無論是與本地應用程式還是與網站之間都要比一個內容驅動的營銷類網站和一個功能驅動的本機應用程式之間有更多的共同點。所以把握網站中關鍵或核心的元件，就相當於同時把握了分佈在整個體驗中的所有重複性模組，在所有“屬性”中“輻射”。值得我們試試。

為設計系統制作一張 PDF 工作表

③在開始構建設計系統前，我們需要讓整個團隊達成共識。為此團隊可以先召集所有成員共同完成一張兩頁的 PDF 工作表（或 INDD③）來定義系統中所需要的部件、產品和人員。製作這張表單的目的在於收集資料，最終幫助團隊決定構建系統的戰略和優先事項。顯然它也會被用在接下來的研討會之中。

③ InDesign檔案（ InDesign Document ）的縮寫。

一張兩頁 PDF 工作表示例（部分），其作用是為團隊開始構建一個設計系統達成共識。

元件剪裁研討會

為了完成表單，Nathan 建議召集儘可能多的專案成員到同一個房間，參與一場元件剪裁研討會 —— 打印出所有的介面，邀請每個人來分別識別和剪裁上面的元件，再對它們進行分組和命名，從而生成一份團隊共享的詞彙表。FutureLearn 的互動設計師 Alla Kholmatova 也鼓勵設計師和前端開發人員都參與到這樣的研討會中。

圖片來源：Alla Kholmatova

在一場元件剪裁研討會中，團隊成員正在對元件進行剪裁和分組。

除了剪裁和命名元件之外，Alla 還建議將這些元件類別賦予不同的抽象名稱來表明它們的優先順序和功能，包括了 “助手”（不能獨立存在的元件，如 “回覆” 功能的按鍵），“橋樑”（作為聯結器的元件，如麵包屑導航④ 或者分頁），以及 “單行本”（可以被看作一個完整獨立單元的元件，如一個 “hero”⑤ 框）。

④ 一個用來顯示使用者在網站或者網頁應用程式中位置的輔助導航系統。

⑤ 在網頁中指一個位於網頁最突出，最中心地方的獨立元件，通常是一個首頁中佔據全屏的頂圖，其中可能包含文字，按鈕等其他元素。

元件的分組和命名

圖片來源：Alla Kholmatova

你還可以在 Slack 中新增一個元件並邀請整個團隊來對其命名和分組。你甚至還可以讓使用者也參與到元件剪裁、分類和命名的過程中，即使是以特別不正式的形式，比如就在一家最近的星巴克裡。

總結

但這樣做真的值得嗎？每個網站都一定要有一個設計系統嗎？我們是否應該遵從我們對一致性和可預測性設計模式的痴迷，使它們在不同使用者體驗接觸點上保持重複呢？我並不能確定。

但我知道模組化的響應式方法對於以下公司非常有利：

提供的體驗中包含了大量的相似元件；

希望解決移動裝置碎片化和維護問題的公司是極具價值的。這也正是設計系統的用武之地。

坦白說，我還沒有遇到一個會真的對原子設計方法或模組化命名研討會感興趣的客戶。但每個人都會對能節省時間的功能，以及更快更好的產出產生強烈的好感。因此下次如果你再碰到有人還沒有意識到模組化方法的好處時，試著用專案中心，可操作的資料，已解決的痛點和無間隙的迭代這些有形的利益和產出來說服他們，而不要用你的操作過程。這樣你才更有可能成功。

原文作者：Vitaly Friedman

原文地址：https：//www。smashingmagazine。com/2016/05/design-systems-responsive-design-sell-output-not-workflow/

編譯作者：大團子，上海，在讀研究生評審指導

編輯整理：三分設運營編輯皮皮

本文由@三分設 翻譯釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議