[譯]如何讓你的設計系統被廣泛採用
這篇文章是關於 ofollow,noindex"> HubSpot Canvas ，我們新的設計語言系列的第二篇。點選 這裡 閱讀第一篇文章。
我是作為一個帶薪實習的軟體工程師來到 HubSpot 的。設計團隊在過去幾個月時間裡，創造了一套華麗的文字設計，顏色和基本元件組合，這套組合是我們在重設計整個平臺主要部分的奠基石。
但因為之前這裡並沒有任何一個設計風格指導——沒有單一資料來源——那意味著，現實中，我們需要完全重寫我們產品的前端。它意味著，我們需要分解超過 40 個團隊的工作產出並且完全使用一套新的元件來重建幾百個頁面，以此將整個重新的設計實現。
我加入了 HubSpot 的基礎架構組，這個團隊負責搭建我們整個內部構造系統，並且除了測試第三方依賴外，要為 HubSpot 開發者們提供全方位支援。他們自然成了這次重設計的先鋒，因此 5 個開發者，包括我自己，被分配去幫助每一個團隊升級到我們新的設計系統，HubSpot Canvas。當我得知我的任務時，第一想法就是：_史上最好的工作，_後面跟著： 哇。這看起來工作量很大。
確實，它確實有很大的工作量。但是如果我們不從中學到重要的一課的話，那就會有_更多_的工作需要做。
重新的設計只有在設計師和開發者達成共識時才會有效。
我們發展這種共識，在很大程度上，是通過建造良好的工具和文件的。我們的文件作為團隊中每一個人的單一資料來源，同時我們的開發者和設計師使用工具來互相呼應，讓每一個人都能使用同一種語言，並且讓他們參與到設計系統的管理中來。
這張圖描繪了文件是如何在幫助我們實現大量的重設計的同時，還讓我們作為一個團隊變得更好。
不利因素與有利因素
任何大型專案，都會有利於你的因素在起作用（tailwinds），也會有不利於你的因素在起作用（headwinds）。對我們來說，它們是：
有利因素
**我們整個的產品是構建在一個頗為相似的技術棧上。**JavaScript 的生態系統會在轉眼之間改變，因此我從來沒有期望任何一家像 HubSpot 這樣體量的公司會永遠處於同一個技術棧上。但在內部，由開發者推動的趨於 React 的趨勢，它遠離主幹，已經獲得大範圍成功。這意味著，團隊們可以重新設計他們的 app，而不需要遷移到其他的技術棧，並且我的團隊也可以輕易維護它們之間的一致性。
我們已經有一個可複用的元件庫和相對應的文件工具。隨著團隊開始向 React 遷移，我們其中的一個工程師迅速搭建了一個可複用的 React 元件庫，這個元件庫易於維護，示例程式碼可以直接編輯，這意味著我們不需要從頭開始寫文件。
不利因素
和我們的 app 不同，我們的元件庫沒有一個完善的 QA 流程。我來自一家金融軟體公司，在他們真正引入 QA 之前，我可能第一個周就問了我技術老大五遍 QA 工程師在哪裡。我們現在不僅處在自己做自己的質量保證階段，而且我們做的每一個改動都會影響後續的構建版本——並且因為我們的團隊一天要部署超過 1000 次，這表明任何的改動都會迅速被擴散到每一個 app 上。
我們需要前端基礎架構組和產品團隊協調工作，來確保，我們每一次啟動時，每一個螢幕都是準備好了的，同時要注意非主觀意識造成的 bug。但是隨著我們迅速的發展，可以輕易恢復任何不好的改動，我們可以將損失最小化。
HubSpot 的產品是由多個小型，自治化的團隊組成的。HubSpot 的團隊對產品每一個部分都有完整的所有權，有權利自由地調查，迭代和尋找解決方案。我們也曾擔心過，對於這些有高度自治化文化和歷史的團隊，為開發一個新的設計系統來最終讓他們保持一致，是很棘手的。
在轉變過程中，他們需要完全停止新功能的開發，並且我們也會開發一些流程和標準，整個團隊接下來都必須嚴格遵守這些流程和標準。在使用一套新系統來幫助你的同事和拿走他們的創造力之間達到一個微妙的平衡。但我們也相信，通過移除掉那些低階的，重複性的問題，我們可以解放我們的同事讓他們把更多的創造精力放到解決更大的問題上來。
我們所擔心的事情大多數沒有發生。團隊們也為一個系統級的重設計做好了準備，因為:
- 沒有人需要改變他們的技術棧或者商業邏輯。
- 不一致性正在拖我們後腿。產品經理們在使用者反饋中看到了這點。設計師在產品無數的陰影中看到了這點。開發者們在_太多_的日期選擇器庫中看到了這點。一個有其他團隊打造和維護的可靠的，可複用的元件庫，看起來像是一個不錯做解決方案。
- 我們的新設計體系，HubSpot Canvas，看起來不錯. 看起來,相當不錯.
從專案到流程
當別的公司在做大的重設計時，他們經常上來就吹噓自己，就像汽車釋出新款時——昨天你有的是一箇舊的，但今天你會擁有一個全新的。
這對我們來說是沒有用的。
我們的產品和產品團隊太繁雜，以至於沒法一次性做完。比起一個一個地處理產品的不同部分，我們決定從那些不怎麼有使用者的產品開始，循序漸進的發展到軟體的核心部分。這個流程會_極大_地減少破壞性，意味著在新的設計系統廣泛使用之前，我們可以對它不斷進行優化。
我們想快速進行，因此我們制定了一些規則。我們強調第一個版本將只是一個簡單的視覺重新整理——沒有新的功能。我們想要重新粉刷我們的房子，而不是額外建造一個。如果團隊們在重構產品時不斷新增新的功能，我們將會無限地拖延時間線。
我們將每一個設計團隊的初始工作產出作為指導，將少數已存在的元件轉變成基礎性的一組可響應的，易用的，瀏覽器相容的 React 元件。為了儘快完成工作，我們在不同團隊的 app 內部工作，將元件替換掉。
但是。
這並不快。我們團隊只有 5 個工程師，並且是基於不熟悉的程式碼進行工作，因此我們進行得很慢。更糟糕的是，因為_我們_是開發設計系統的，app 團隊並沒有機會掌控整個設計語言，留給了他們一個部分程式碼他們瞭解，部分完全不瞭解的 app。我們意識到，這個重設計需要從親自動手的專案，轉變為一個真正的_流程_，所有的團隊都可以自己解決。
我們促進這個流程的發展是從提供技術支援和搭建並維護元件庫開始的。我們和設計團隊協作，讓每一個產品設計者重設計他們所負責的產品模組，使用一個包含我們所有設計系統元件元素的Sketch kit。隨後我們進行了一次元件回顧討論，因為每一個團隊已經開始了他們負責的重設計，所以我們通過這次回顧討論來探索潛在的新元件，新的變化或者已存在元件的新的功能性。
然後，我們的團隊在 GitHub 上建立 issue，這樣在搭建元件的過程中，我們可以持續的在開發與設計間進行協作，並且每一個團隊都可以追蹤他們需要的元件的搭建過程。我們與每一個 app 的時間進度交錯安排，這樣我們可以保證我們團隊的待辦任務不會拖慢別的團隊的重設計進度。
它平穩運行了一段時間。隨著各團隊完成了他們的重設計，他們又重新返回了新功能的開發，但他們的 app 完全由閃閃發光的全新元件組成。
但有些時候，團隊們並不知道如何來以及何時來正確地使用元件，亦或是一個元件的表現是否符合意向的。隨著他們把問題提給我們，我們被諮詢和說明的請求狂轟濫炸。我們越來越背離最初的想法，我們原本想嘗試提供支援給那些已經完成的團隊，然後我們也支援了那些正在進行重設計的團隊。
解決方案比較明確，但是並不簡單。
我們需要更好的文件系統。
建立一個套生動的風格指南
良好的文件系統是一樁很好的買賣。你花費的每一秒，寫的每一行字，都會在未來節省你無數的時間——時間花費，比如你正在嘗試記住一個超有創意的東西，突然你要停下來去給你同事找一個連結來解釋元件相關的東西，比如，提示框和彈出框的區別。你應該把這些時間放在_新的_問題上，而不是已經被討論過，解決過並且確定好的問題上。
我們知道我們希望我們的文件系統是這樣的:
- 易於探索的。 我們並不希望任何人花時間來建立一個已存在的元件或是其變種，亦或是需要詢問管理者這個元件在哪裡。
- 相關並且有用的。 它應該是設計系統中的決定性資源，每一個人都應該有信心在上面找到他們想找的問題。
- 自我維護和自動化的。 因此沒有東西會過時。
埋下種子
為了讓我們的文件系統正確的發展，我們決定像為客戶搭建產品一樣搭建它。我們從採訪各種產品團隊中的人開始，他們包括設計師和開發者，有已在 HubSpot 工作多年的，也有到剛加入的。我們進行了一個卡片排列練習，我們將已有元件的螢幕截圖打印出來，要求 HubSpot 的成員來對他們命名，然後他們這些元件分類並且給分類命名。
令人驚訝的是，我們發現開發者和設計師對於我們的元件所使用的語言存在巨大的差異。開發者們經常會引用其他前端庫(比如jQuery 和Bootstrap)中的物件名稱。設計師們常引用 Google Material Design System 中同類型元件的名稱。我們發現人們會使用相同的詞語來描繪兩個及其不同的元件，亦或是不同的名字來描繪同一個元件。
沒有失敗，每一個設計師或開發者都不希望在設計的使用者體驗（設計師的原型）和實際的使用者體驗（開發者開發的產品）中來回分心。並且他們知道，確定這些東西並不僅僅是設計或者開發的責任——這是每一個人的責任。
相對於構建另一個元件庫，專注於開發者，我們意識到我們需要搭建一個資源，它適用於團隊中的每一個人。這一套文件系統和工具會在設計師和開發者之間，對設計系統建立一個共享的所有權。
我們從重新命名一小部分元件開始，對一些元件新增一些標籤，以便於更好的發現和搜尋，並且在元件設計之初就詢問一些推薦的名字，這樣設計師和開發者可以共同地決定一個合適的名字。同時我們根據元件的相似性將它們分組——目前，舉個例子，所有提醒和訊息的元件已經可以在同一個頁面中找到了。
為了讓設計師們可以無縫地在 Sketch 和元件文件系統中移動，我們決定在 Sketch kit 和 UI 庫中使用同樣的導航，結構和術語，並且同時開發了一個系統，來保持 Sketch kit 和 UI 庫步調一致。
完全綻放
隨著基礎工作做完，我們便開始致力於讓設計師和開發者每天的工作變得更簡單並且更有效率，將我們調研中的理解的剩餘部分實現。
開發者們提到他們經常會在尋找匹配設計師原型的 React 元件時遇到問題，因為我們添加了一層可見的搜尋檢視，提供了真實的，全自動生成的螢幕截圖，讓他們更容易找到他們想要的。他們也需要一個地方來看到每個元件包含的所有選項，還有一個地方他們可以找到元件的 API 資訊，因此我們把它們展示出來並放到元件描述的中心位置。
開發者們也需要一個沙盒來快速測試元件，因此我們提升了元件庫中元件的實時編輯的體驗，讓每一個規劃中的元件都包含一個 React 程式碼編輯器（用語法高亮和Prettier 的功能完成）。我們將它變得更簡單，把所有的例子都移動到一個免受干擾的編輯器，它會即時的渲染元件，這樣開發者們可以使用它來構建設計的初始版本或者來測試一組特殊的元件組合。接著，他們可以輕易地與其他同事分享它，讓他們迅速的迭代，除錯，並且方便與分享想法和提出解決方案。
設計師們需要一個地方來引用和分享資源，因此我們為我們的顏色，文字設計，插畫，圖示和產品複製指南建立了瀏覽頁面，和一個連結可以下載最新版本的 Sketch kit。我們也將全部的設計流程文件化處理，放到了 UI 庫，幫助新的設計師能跟上進度。
無論設計師或者開發者都一直清楚，哪一個元件允許使用者完成一項特殊的互動模式（想複製一條連線或者在在一步一步的過程流程中前進），我們也建立了模式的頁面來解釋哪一個元件應該在常見的使用者場景中使用。
我們想讓更多的開發者參與到設計語言中，所以我們將如何建立元件的指南分享出來，並且在基礎元件上開始構建，並且將它們和我們最喜歡的開源框架結合。這給嘗試 OSS 社群中的新工具提供了自由，給我們的技術棧添加了更多更能性和生產力，並且，誠實來說，讓 HubSpot 所有希望創造的開發者去創造。因為我們最初目標就是讓我們的元件作為所有前端 app 的視覺基礎，這給在他們上層新增額外的圖層留下了很多空間。這給我們的開發者對於一致性的嘗試做了選擇。
為了激勵大家每天多和文件系統互動，我們增加了一些按鈕，點選按鈕會彈出一個建議替換當前元件的新元件，或者是報告一個 bug，或者是請求一個插圖。這些按鈕會提前建立好 GitHub issues，包含必要的標籤和相關的問題，這樣流程中所有的問題都會排好隊。這讓新來的設計師和開發者在第一天就對於我們整個的 HubSpot Canvas 生態系統有了一個統一的參考源。
效果
現在，設計師和開發者對於我們的設計系統都共同分享一個單一資料來源，而且彼此的理解也加深了。對於文件系統的信任得到加強，也意味著整個設計系統有了更強的信任度。我在幾個星期之前看到我們其中一個前端技術負責人發了這個 tweet，這讓我感到很驕傲：
我們每年都會對工程師做兩次平臺基礎架構的調查，自從我們開始將 UI 庫的問題包含進來之後，我們不斷地收到類似這樣的反饋：
100,000/10 我的天啊，前端 UI 框架實在是太美了，領先了任何現有的開源 react UI 框架好幾年
我們的努力讓文件系統變得完善，活躍的文件永遠不會過時，但是像這樣的反饋會幫助我們知道，我們還在正確的軌道上。
自己來看一下吧
下面來看一下你是如何可以迅速從一個提前做好的模板開始，使用我們 UI 庫中的沙盒編輯器來構建一整個頁面。
- YouTube 視訊連結：youtu.be/Jw__JImMhXE
看，這就是我們的開發者如何能夠使用 UI 庫編輯器和我們的可複用的 React 元件來構建和原型中一模一樣的頁面。
我們已經做了一個我們HubSpot Canvas UI 庫的公開版本。在這裡面，你會找到我們元件和風格指導的一部分，直接從我們的產品程式碼中拉取出來的。這對了解我們在 HubSpot 是如何打造產品，提供了一個視窗，我們將它分享出來，是因為我們對於我們在開發我們的設計系統和為設計師和開發者們不斷優化以讓它保持長青上所付出的時間和努力感到很自豪。我們邀請你們來看一看並且分享你的想法——我們等不及想聽到它們了。
感謝Sue Yee 製作的插圖
最初發布在 HubSpot Product Blog
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為掘金 上的英文分享文章。內容覆蓋 Android 、 iOS 、 前端 、 後端 、 區塊鏈 、 產品 、 設計 、 人工智慧 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃 、官方微博、 知乎專欄 。