[譯] 如何建立一個設計體系來賦能團隊 —— 關注人，而非畫素
這篇文章是有關我們新的設計語言 ofollow,noindex"> HubSpot Canvas 的系列文章的第一篇。
這有一個老喜劇小品，大意是一個郵遞員對送信失去了興趣 —— 他更願意去送玉米卷。
在這個小品中，一個男子在他的郵箱旁邊一直等郵遞員的出現，想質問他為什麼郵箱裡一封信都沒有。儘管他也喜歡玉米卷，但是他說：「如果讓我在玉米卷和郵件中二選一，我不得不選擇郵件。」
玉米卷比郵件裡的賬單刺激多了，但是這個男子 不需要 玉米卷，他 需要 的是他的郵件。
HubSpot 的顧客 需要 一個始終如一、功能強大、令人愉快的產品。所以 HubSpot 設計團隊需要創造一個設計體系，來幫助我們持續地滿足這些需求。
在過去的幾年裡，我們已經：
- 創造了一個新的設計語言（我們叫它「HubSpot Canvas」，我們已經在這上做了很多工作）
- 重新設計了 HubSpot 平臺，更新了我們品牌的視覺形象
- 建立了一個鮮活的設計體系，可以隨著我們的商業進展而擴充套件
為了實現這一切，我們需要進行人才投資。我們將我們的 UX 團隊從 14 位產品設計師、2 位研究員和 1 位作家擴充套件到超過 34 位產品設計師、8 位研究員、3 位作家和 1 位產品插畫師（並且仍在持續招聘中）。
這就是我們如何致力於投遞郵件的故事（並且忙裡偷閒也捎帶點玉米卷）。
我們為什麼重新設計
我們需要重新設計 HubSpot 平臺，主要有兩個原因。首先，更好地履行我們品牌的承諾。我們的客戶喜愛 HubSpot 這個品牌，它很有趣、有活力、有個性。但是目前的產品並不是這樣，它配不上客戶投入到生意中的努力。
其次，消除蔓延到我們 UI 中的不一致性。我們的使用者介面在平臺上不一致，導致難以使用、難以導航。以 Marketing Hub 中的兩個模態頁面舉例：
注意到按鈕位置、選項卡設計和互動模式中的不一致了嗎？這些不一致增加了客戶的認知負擔，使他們執行像儲存或關閉對話這樣簡單的操作都變得困難，這每天都會拖慢他們的效率。
所以我們決定從收集使用者針對當前設計的反饋開始，反饋並不「美麗」，但是卻 很 有價值：
「看起來比實際需要的複雜多了。」
「太多選項，我已經眼花繚亂了。」
「有點密集恐懼症，沒有留白。」
「配色過時，看起來不爽。」
「太多灰色，所有的東西好像都被小方框圈起來。」
「沒勁。」
我們意識到需要對客戶徹底地重新定位和奉獻 —— 根據他們的個性、怪癖、動機、渴望、甚至（或尤其是）他們的焦慮。最終，我們決定給我們的產品打造全新的設計，像我們的客戶每天都用的那些普通應用那樣，不僅好看，而且用起來簡單。
但隨之而來的是殘酷的現實：
重新設計我們的平臺意味著我們必須分裂橫跨兩大洲的 40 多個產品團隊。也意味著我們需要從創造新體驗的資源中轉移一些設計和工程師資源，以便我們修復現存的資源。並且在上線期間，我們的支援和服務團隊還有客戶需要不斷適應產品的變化。
我們開始這個程序時就知道，我們不僅僅是開始重新設計我們的產品 —— 我們需要完全重新思考我們設計和打造產品的方式。
我們首先需要了解在我們的組織架構和工作流中有什麼導致了使用者體驗的碎片化和低效率，並將它們替換為有效的例項和系統。
所以這個故事的第一部分就是，我們怎樣定義這些挑戰、我們如何著手重新設計我們的產品，以及我們創造的工具，它可以賦能我們的設計團隊，使之能夠儘可能保持持續、高效、自主的狀態。
問題的根源
去年，我的父母決定賣掉我兒時的房子，我被他們弄去幫助清理閣樓 —— 一個塞滿了積累 20 年雜物的閣樓。你可能會想到，清理期間我吐了無數個槽。比如： 「WTF，我們居然保留著這玩意？太棒了！」 但更多的是： 「WTF，為什麼我們還留著 87 年的豆豆娃？（譯者注：一種毛絨玩具）」
好吧，以同樣的方式，我們的設計團隊首先需要審查我們過去十年在 HubSpot 暢想過、開發過、交付過的每個元件。我們需要降低到細緻的程度來更好地理解目前產品的體驗如何。每個設計師都被要求仔細檢查他們各自的 App，找到每個元件、截圖、命名並存檔，以便評審。
做個小測試：你認為多少個日期選擇器（date picker）算「太多」？
三個還是四個？
呃，我們現在有八個。
這是在我們的「閣樓」裡發現的其他東西：
- 100 多個灰色陰影
- 3 個不同字型對應著 40 多個文字樣式
- 16 個不同樣式的模態頁面
- 6 種不同的主級別按鈕（這意味著根本 沒有 主級別按鈕）
- 5 種表格過濾方式
- 確認操作在左側的模態頁面
- 確認操作在右側的模態頁面
- 成千上萬行自定義 CSS
這是同時存在於 HubSpot 平臺的所有按鈕樣式：
這裡有你的按鈕樣式嗎？
是什麼導致了這種情況？我們怎麼有這麼多按鈕？我們怎麼有這麼多的日期選擇器？
這是那段古老、黑暗的日子裡，Slack 上的真實對話：
讓 SaaS 來阻止這些無意義的討論吧。
真實的情況是，沒有一個 HubSpot 的設計師或開發者真的想去花時間來重做日期選擇器。
我們意識到，我們的團隊創造了這麼多看起來多樣化但本質相同的樣式和元件的原因，是我們的組織架構出了明顯的問題。簡而言之，構造新東西看起來更簡單，正在起作用的東西卻很難被發覺。
HubSpot 的產品團隊由圍繞解決客戶特定需求的小規模、自治團隊構建而成，這讓我們作為一個產品開發組織可以迅速發展，並且可以對客戶變動的需求迅速做出反應，但這種方式對於保持不同的產品團隊的一致提出了挑戰。
當你們有超過 40 個能夠快速構建、釋出、迭代的產品團隊時，確實很容易出現忽視總體客戶體驗的情況，緊緊地專注於一個特殊的問題通常意味著戴著「眼罩」看其他所有問題。因為有這些眼罩的存在，我們的設計師和開發者不知不覺地在使用者介面上重建已經存在的元素、元件和圖案，這導致了使用者體驗的碎片化和混雜的設計，還有技術債。
我們小型、自治的團隊架構不準備改變 —— 因為這是我們基因的一部分。所以很明顯，我們需要為創造更好地調整我們的產品團隊的工具和系統付出更多的努力。通過把所有人連線到集中的設計體系這種方式，保證在持續發展的同時，有一套統一的使用者體驗。
這可以讓我們的設計師和開發者的心思從「畫素」中解放出來，讓他們有更多的時間考慮「人」。
講原則
審查可以幫助我們識別設計過程中的問題，並且明確我們發展文化的哪些方面導致了效率低下。但是在建立情緒板前、在研究排版前、在我們激烈的討論橙色的完美色調之前，我們需要 講原則 。
我們需要對我們的核心信仰達成共識，這是遇到難以抉擇的問題時我們唯一可以依靠的標準，我們需要發現我們的團隊認為有責任維護的理想。
所以設計團隊進行了一些構思練習來建立我們新設計語言的基礎。我們爭論，我們排序，然後我們確定了五個核心設計原則，這五個原則指引我們完成了一百萬個微觀和巨集觀設計決策。
這些原則是：
清晰我們的設計原則是清晰和專注，我們的工作幫助使用者在功能優先順序、視覺化層次和上下文識別性方面進行下一步正確的選擇。
人性化我們培養一種給體驗賦予人性的觀念，使得不同文化之間產生共鳴，我們的工作每次都給給使用者提供有趣並且優雅的互動。
Inbound我們加強了 Inbound 方法的資訊和含義，我們的工作使使用者的入站路徑清晰，幫助他們理解為什麼這是正確的。
整合我們通過建立統一的系統解決使用者的需求來簡化使用者的體驗，我們的工作通過提供改進的、高效的方法幫助使用者達到偉大的目標。
協作我們設計了強有力的系統鼓勵人們一起無縫地工作，我們的工作幫助人們用自然、直觀的方式互相創作和協作。
我們在重新設計產品的許多細節時，這些原則幫助我們保持一致和專注。你可以修改按鈕顏色、線寬、頁首尺寸，但是你不能改變你的基本信仰，在設計的這些方面，你必須保持堅定。
一個新的視覺角度
我們的設計團隊進行了若干個會議來重新設計我們產品中的核心頁面，然後選擇四個產品設計師作為一組，讓他們花一週的時間完全投入到形成概念、設計中，並且最終和客戶一起測試幾個不同的視覺方向。這些會議產出了一些非常不同的設計方向，讓我們感到很新穎，令人興奮。
這是設計語言團隊中的兩個成員 Drew Condon 和 Jackie Barcamonte 最初的設計概念，請欣賞：
HubSpot 以前的設計
是不是耳目一新？與眾不同、令人興奮，和那些呆板、沉悶的「商業軟體」明顯不一樣。
設計語言團隊和客戶通過多輪的調查和訪談，最終嘗試了三種不同的設計方向。當我們看到下面的敘述，我們知道我們找到了成功的方向：
「讓我感到生產力大增。」
「我感到自己很牛，我想我完全知道應該做什麼。」
「這很有趣，這才是我想要的 HubSpot。」
「新一代的網頁。」 （有些人真的這麼說）
「看起來不像商業軟體。」
「讓我感到掌控一切。」
下面是我們採訪的客戶最喜歡的設計方向的進化：
HubSpot 以前的設計
第一輪訪談最受歡迎的設計
第二輪訪談改進的設計
當我們讓使用者驗證過我們的設計方向後，就是時候把這些視覺樣式應用到我們所有的核心 UI 元件上了。我說的是 上百種 元件：按鈕、連結、查詢框、表格、定位、模態頁面、輸入框、彈出框（這個列表還很長）。這是重新設計過程中不那麼有趣的部分，但卻更需要一絲不苟，而且十分耗費精力。
但是這些一絲不苟、耗費精力的工作對於我們公司和客戶來說是一個長期投資。我想起有一個週五下午，設計語言團隊和我花了整整兩個小時來開會，這使我們十分崩潰。
我們那天的工作是決定我們大多數獨立元件（按鈕、控制元件、輸入框等等，都是我們使用者介面的基本要素）的外邊距和內邊距。
那次會議有五個人蔘加，我們花了差不多15分鐘仔細推敲我們所有新按鈕的外邊距。這意味著 HubSpot 支付五個設計師的工資，讓他們坐在一個屋子裡辯論像「文字和文字框的距離」這種索然無味的問題。
但是。
自從兩年前那次討論之後，我們沒有一個前端工程師、產品設計師、研究員、作者或插畫師需要再考慮按鈕的外邊距了。
這就是建立一個設計體系的美好之處。推敲一個細節一次，你就可以把你全部的產品開發團隊解放出來，讓他們專注於解決客戶的實際問題。
我們把我們所有精美的新元件，包括使用他們的引導，放進了 Sketch（我們的設計工具）中。這讓我們團隊的生產力立即爆發了出來，並同時（突然地）讓我們的設計工作緊密一致了。
團隊協作
在這個程序開始前，我們並沒有一個集中的地方讓設計師知道哪些元素或元件已經存在，也沒有讓他們在自己的設計中使用這些現成的元素或元件的方法。設計師和開發者盡他們最大的努力決定使用哪個元件或圖案，但是他們的主要參考點是那些已存在的產品 —— 那些明顯不一致的產品。
為了解決矛盾（當我們加速我們的工作流的時候），我們為我們的新設計語言建立了一個健壯的樣式和元件庫。這個 30 頁的 Sketch 檔案被以「元件族」的形式組織起來，它儲存了組成我們產品使用者介面的每一個獨立元素或元件。這個元件庫每週更新，並且被一個小規模輪值設計師工作組和專門的前端開發者團隊管理。
需要一個圖示？過來拿。
圖示由Joshua Mulvey、Sue Yee 和 Chelsea Bathurst 設計。
需要資料視覺化？給你。
資料視覺化由 Drew Condon 設計。
需要一個按鈕？如你所願。
我們現在有一種主級別按鈕了，是橙色的，我們喜歡橙色。
還需要其他任何東西嗎？HubSpot Canvas 有一切你想要的。
每個 Sketch 包中存在的元件，同樣在 React 中有一個元件對應，方便你將任何模型轉化為程式碼，就像組裝樂高玩具那樣。
這表示著我們的設計師不需要花時間調整畫素、撰寫說明書或者擔心有關他們設計的響應性。也意味著我們的開發者們不需要花時間把自定義 CSS 調來調去（實際上他們幾乎完全不用寫了）。
這意味著我們的開發者可以有更多的時間構建，也意味著我們的設計師可以用更多的時間研究、設想和迭代，不僅僅快，而且高保真。
這是 HubSpot 設計師一般情況下的工作流的概覽，使用了 Sketch 庫和 Runner、Craft（由 Invision 開發）外掛。
- YouTube 視訊連結：youtu.be/d4RuKwOwqnM
為了適應 HubSpot 的發展，我們的元件庫也在持續更新。它主要由一個由設計師和開發者組成的核心團隊維護，但產品團隊的每個人貢獻著自己的力量，並幫助改進。任何時候，一個新的元件被建立或修改，它都會被儲存進 Sketch 庫並對所有人開放，這極大地減少了「野元件」和重複元件的數量。
擴充設計體系
我們的 Sketch 包也只是更大的設計體系中的一小部分，為了讓它在長時間內真正發揮作用，我們需要建立一些對於開發者來說切實有效的工具。我們認識到，創造始終如一、功能強大、令人愉快的產品體驗的最好方式，是讓創造這種體驗的人們更簡單方便地工作。
閱讀 下一篇 來了解文件如何培養設計和開發之間的共同所有權、我們如何廣泛使用我們的設計體系，以及我們為開發者建立了哪些工具。