將您的設計系統付諸實踐
作者：Diana Mounter
如何開發您的設計系統將影響您分享和鼓勵採用該系統的方式。從廣義上講，開發和推出新設計系統有兩種通用方法：增量和大規模重新設計。
在本章中，我們將介紹這兩種方法，突出每種方法的優缺點，並討論採用策略。
Tina Koyama，Ashlie Ford和Devon Beard討論了Twitter建立和推出Horizon Design System的方法。
大規模重新設計
當團隊採用這種方法時，通常意味着他們花費更多時間設計系統，然後再將其推廣到各處，包括進行視覺刷新或組件整合。這允許團隊開發更完整的系統 - 從原始的顏色和排版層到組件，頁面佈局和交互流。
一些團隊通過創建虛構產品來接近他們的新系統，以幫助他們擺脫在實際應用程序中工作的限制。其他團隊在重新設計真實產品或功能的同時設計新系統。
用試點項目進行測試
在Etsy，我與設計師和工程師團隊合作，重新設計賣家工具。該項目提供了一個很好的機會來測試CSS的新方法並刷新我們的視覺樣式。我們與賣家工具重新設計一起構建了新的樣式指南，記錄了實施和設計指南。
這成爲測試新設計系統的試點項目。重建產品的真實部分爲我們提供了一個測試新組件，響應式佈局和新排版樣式的絕佳場所。
在From Design Systems：Pilots＆Scorecards中，Dan Mall撰寫了他用於尋找設計系統試點項目的優秀候選人的標準。儘管我們在Etsy的方法更具投機性，但Mall列表的許多屬性恰好與賣家工具項目相匹配：
共同組件的潛力。該試驗有哪些組件可以在其他產品中重複使用？
常見模式的潛力。這個試點有多種模式可以在其他產品中重複使用嗎？
高價值的元素。即使不常見，在這個項目的核心是否有一個具有高商業價值的組件或模式？我們談論的是流程中不可或缺的元素，或者對組織具有異常高價值的受衆。
技術可行性。設計系統的技術實現有多簡單？是否需要大型重構？
可用的冠軍。是否有人正在使用該產品，並使用設計系統慶祝/傳播（甚至爲此做出貢獻）？
範圍。這項工作是否可以在[3-4周]的試驗時間範圍內完成（在此插入您的時間）？
技術獨立。這項工作與其他傳統設計和代碼是否有足夠的分離，有明確的起點和終點？
營銷潛力。這項工作會激勵他人使用設計系統嗎？
與產品一起構建新設計系統有一個缺點 - 它最終會偏向於該產品的需求。之後，需要進一步開發才能爲整個Etsy應用程序工作。使用最少的外部反饋在孤島中工作使我們能夠快速取得進展，但這意味着我們必須更加努力地鼓勵其他團隊採用設計系統。
通過沙箱環境顯示價值
在處理新的Etsy樣式指南時，我們設置了一個簡單的沙箱環境，使我們能夠快速構建HTML / CSS模型原型。當我們準備與其他設計師分享新的風格指南時，我們意識到沙箱可能有助於採用。
我們的目標之一是減少設計人員和開發人員花在編寫CSS上的時間，這樣他們就可以花更多的時間來迭代設計。我們採用CSS的新方法與沙箱環境相結合，使瀏覽器中的原型設計變得快速而簡單。
人們看到價值的最佳方式就是體驗它。
我們爲每個人設置沙箱進行培訓。這種方法使人們能夠使用沙箱對樣式指南進行原型設計和實驗，通過動手使用來揭示價值。
爲了讓人們獲得成功，我們編寫了教程，教他們如何應用不同的樣式 - 例如原子與組件類，構建移動優先響應佈局，以及創建複雜視圖（如搜索結果頁面） - 無需編寫CSS。爲了幫助人們瞭解我們決策背後的原因，我們在示例場景，代碼示例和實時編碼演示中介紹了我們的設計原則。
沙盒的CSS環境反映了生產，因此設計人員的原型很容易轉化爲開發人員的生產工作，避免了昂貴且不必要的新CSS。由於代碼原型是用相同的語言編寫的，因此它們使開發人員比靜態模型更好地理解了意圖。開發人員不必像使用設計工具中的comp那樣進行翻譯。這進一步有助於採用。設計師和開發人員都喜歡的設計系統有更大的成功機會。
文檔是關鍵
採用的另一個關鍵是最新文檔。正如設計系統同行所說，“如果沒有記錄，它就不存在了。”
當樣式沒有記錄時，你冒着人們編寫新的但重複的代碼的風險。引入新設計系統時，文檔變得更加重要，因爲舊模式可能超過新模式。文檔有助於促進這些新模式，減少編寫新代碼的需要，並通過代碼示例和指南簡化實施。
過時的文檔也可能導致損壞，因爲它可能導致人們走錯路並導致挫敗感。值得花時間開發可幫助您保持更新文檔的實踐。
找到檢查文檔準確性的機會 - 例如在入職會話之前和之後，或者在添加新樣式時。即時編寫文檔可幫助您測試代碼並避免構建文檔債務。如果可以，請添加測試，以便在添加和更新模式時檢查文檔，並嘗試使人們輕鬆報告不準確性。
記錄樣式
添加文檔樣式。當你編寫代碼時，它更容易做到，而不是等待稍後再做。
在Etsy，一些工程團隊爲新工程師創建了入職項目。這通常涉及從積壓中構建一個小功能，這將有助於他們熟悉工程堆棧。我很高興看到他們在沒有設計師幫助的情況下實現UI佈局，只需遵循樣式指南文檔即可。
推出後續跟進
設計系統永遠不會完成。新系統的推出應該被認爲是版本1.0，隨後將進行許多迭代。
客戶，同事和利益相關者應該接受數字世界的柔韌性，以創建適應媒體不斷變化的性質，用戶需求和業務需求的生活設計系統。
布拉德弗羅斯特
作者，原子設計
無論您是否組建一個全職團隊來進化和維護您的系統，您可能會有一些人與系統製造商，系統用戶以及也爲系統做出貢獻的用戶進行交互。無論您的團隊採取何種形式，製造商都需要與用戶和組織的需求保持聯繫。
在Etsy推出新設計系統幾個月後，我們與來自各個團隊的員工一起開展了工作會議。我們的目標是學習如何改善使用和貢獻系統的人的體驗，我們在推廣系統方面取得的成功以及缺乏的地方。我們採取了定性研究方法，以便我們可以開放發現我們沒有意識到的事情是問題 - 這意味着很多面對面的討論與輕鬆的議程激發對話。
貢獻者
我們與首次參與者一起開展了用戶旅程測繪研討會，以瞭解他們的體驗。我們懷疑人們有各種各樣的經歷 - 有些人似乎很掙扎或完全放棄他們的貢獻，有些人花了很長時間才加入他們的新模式。
調查結果：我們發現，即使貢獻成功，經驗也會如此緊縮。這促使我們開發了一種更具協作性的配對方法，併爲首次貢獻者的代碼審查採取了令人鼓舞的思維方式。
工程早期採用者
我們在產品團隊中遇到了早期採用者，特別關注瞭解工程視角。大多數工程師沒有參加培訓課程，並且通過閱讀風格指南學會了使用新的設計系統。
調查結果：我們在文檔中瞭解了很多漏洞。例如，教程不適合工程師，實用程序很有用但卻被埋沒，人們對如何在實驗中安全地使用樣式感到擔憂。這使我們能夠預先重組和提升重要信息，改進搜索和導航，添加更多吸引工程師的教程，並提供更清晰的樣式用法。
產品經理
我們與產品經理進行了一次會議，以瞭解新系統，並討論重構和構建響應式佈局的影響，作爲功能開發的一部分。構建一個默認響應的設計系統是一個核心目標，也是Etsy Web應用程序許多部分的新目標。
調查結果：我們瞭解到，大多數產品經理都信任他們的工程經理，以指導他們對範圍產生影響 - 這與工程師的確認溝通是一個優先事項。PM理解最初可能會有額外的工作，但轉移到新的設計系統將使前端實施更容易。我們向他們展示了他們可以擴展工作範圍並反覆進行。
親自反饋
花時間與內部利益相關者進行面對面的反饋會議，這將使您瞭解可能永遠不會被發現的見解。
協作創造了對採用的投資
將整個公司納入設計系統決策可能在邏輯上不太可能，但某種程度的協作是值得的。
在Etsy成立專門的設計系統團隊之前，由跨設計師組成的工作小組推動了系統的發展。該小組定期開會，計劃項目並確定其優先順序，分享工作並獲得反饋。小組成員在需要時與工程師和專家合作，例如在高轉換頁面上運行實驗和測量性能。
這些合作進一步推廣了採用，並在整個公司內產生了設計系統的支持者。花時間爲系統做出貢獻的人被投入其中並將其推廣給其他人。在一個孤島中工作在短期內幫助了我們，但是在團隊之外擴展貢獻使我們在長期內取得成功。
增量推出
並非所有設計系統團隊都能夠在推出之前花時間開發完善的系統。許多團隊必須一次推出部分設計系統。
從好的方面來說，通過增量部署，團隊可以在系統可用時採用系統的新部分，這可能會讓人覺得不那麼令人生畏和破壞性。但是，團隊還需要更多地考慮系統的溝通和推廣。沒有發佈，沒有一個重要的時刻來吸引所有人的注意力。相反，您需要找到並創建將人們介紹到您的設計系統的場合。
當我加入GitHub並開始探索那個小型的兼職團隊如何將Primer變成一個更強大的設計系統時，我知道我們無法長時間離開並開發出一個完整的系統。飛行中有大量的工作，沒有計劃的重新設計或孤立的功能我們可以用作試點項目。
我們需要弄清楚最大的痛點，將它們減少到最小的部分，並逐步推出Primer更新。
解決問題並贏得早期採用者
GitHub最大的痛點之一是人們花在編寫CSS上的時間，特別是那些應該系統化的東西，比如間距和排版樣式。
我們的解決方案最終是基於系統變量引入實用程序（單用途類，通常稱爲原子或函數類）。我們無法從審計組件和頁面佈局開始 - 我們必須從小規模開始並在擴展到更大的部件之前測試系統的基礎。添加實用程序使我們能夠在不重構大量UI的情況下提供樣式。設計人員和開發人員一旦推出就可以開始使用系統的原始樣式。
一旦人們發現他們可以使用實用程序而不是編寫新的CSS，Primer就開始趕上速度。它解決了一個真正的問題，同時允許我們測試系統的原始層。從那裏，我們可以開始替換和更新樣式的組件層。
改進文檔和可查找性
與Etsy一樣，文檔是GitHub採用的關鍵。GitHub代碼庫中大量廣泛使用的模式不在Primer中，因此沒有記錄。
我們通過成堆的自定義CSS進行分類，並在GitHub代碼庫中創建了一個目錄，該目錄爲應該移入Primer的模式形成了“等待室”。我們集中了大量精力來儘可能地記錄，無論是否在Primer中。我們還專注於添加更多層文檔，包括描述我們的類命名約定，可訪問性原則，與我們的系統一起使用的工具建議，如何運行linters，以及我們的樣式組織和包的概述。
但是，記錄樣式是不夠的。我們需要確定樣式指南導航的優先級並搜索可查找性。
我們最初建模導航以匹配我們的包組織 - 核心，產品和營銷 - 優先考慮信息，而不是搜索特定樣式的可查找性。樣式指南還缺少多層導航背後的搜索和隱藏樣式，在人們找到他們想要的內容之前強制進行多次點擊。
我發現自己是一個人類風格的指南搜索，人們叮囑我找到他們想要的東西，而不是自己找到它。
隨着研究概述人們尋找風格的困難，以及我們正在努力解決我們最初用於風格指南的老化網絡應用程序這一事實，我們認爲重建和重新設計是值得的。
新文檔站點在導航中列出了我們的所有樣式，並添加了一個上下文搜索，幫助人們找到具有相似關鍵字的文檔 - 例如在實用程序和支持變量中查找“顏色”。
圖2. Primer文檔和搜索。
儘早建立文檔站點非常重要。回顧過去，我認爲首先重新設置一箇舊的Web應用程序並不是錯誤的選擇 - 它可能不是理想的，但它做了我們需要的。重要的是，隨着時間的推移重新評估文檔站點的質量，以確保它滿足用戶需求，並隨着設計系統的發展而擴展。
通過許多接觸點逐步採用
當您沒有那麼重要的時刻來啓動您的設計系統時，請利用每個機會分享其價值。您正在構建解決實際問題的系統，並且您知道自己的目標是什麼 - 需要一些時間來分享這些目標以及您計劃如何實現這些目標。當您試圖展示如何改變像幾行CSS這樣的東西時，這些細節很有用。
在GitHub，我們使用了許多小的交互來推廣Primer和設計系統團隊。以下是我們使零碎方法取得成功的幾種方法：
代碼審覈中的創意評論
我們開始跳入並評論GitHub應用程序中的拉動請求，這些應用程序涉及CSS或我們試圖改進的設計模式。這使我們有機會根據新的設計系統提出建議，並將人們指向我們的文檔站點，以便他們知道它存在。
我們通過添加簡單的評論來提取請求，例如“Ping設計系統團隊”，或“在設計系統鬆弛渠道中找到我們”，宣傳我們的團隊和我們的可用性。
隨着時間的推移，人們開始向我們提出問題並提出請求，我們利用代碼所有者等功能，因此當有人進行CSS更改時，我們會自動請求審覈。
圖3.關於建議使用系統變量而不是靜態值的pull請求的Servbot註釋。
最近，我們開始添加機器人腳本，通過簡單的反饋評論拉取請求。通過關於我們團隊和Primer的大量溝通，我們提高了對設計系統的認識和採用。
顯示，不要告訴
我們注意到當團隊更新GitHub UI時，他們會轉到網站的另一部分，然後複製並粘貼標記和CSS。重構舊的模式實例是我們對舊模式的持續重用的最好的鬥爭。這是一項長期舉措，但我們可以優先考慮最受歡迎和最麻煩的模式。
快速響應支持請求
GitHub的大多數團隊都有一個名爲First Responder的隨叫隨到輪換。這意味着一個或多個團隊成員隨叫隨到分類問題，響應支持請求或提供代碼審查。
隨着設計系統支持請求的增長，我們採用了這一流程來幫助及時響應人員。隨着時間的推移，我們對流程進行了迭代，並創建了許多自動腳本，以幫助跟蹤需要注意的通知項目。快速響應人們會增加他們對我們的團隊和建議做出積極反應的可能性。
圖4.第一響應者使用hubot腳本來查看需要他們注意的項目。
存在和響應
特別是在早期，我們通過Slack做出了簡單的努力來回答問題，對代碼進行配對，或者通過電話跳過某些事情。離開更深層次的工作需要時間，但是爲此分配時間對於幫助贏得其他團隊的朋友和冠軍是值得的。
圖5. GitHub設計系統團隊可以幫助我們的鬆弛渠道。
大規模出版和發行
我最近在設計系統方面的工作經驗主要集中在Etsy和GitHub等大型Web應用程序上。這些系統需要分發和發佈的規模通常需要比具有小型系統和小型團隊的小型公司更復雜的基礎設施。
但是，許多公司打算隨着時間的推移增加其團隊規模和產品規模，因此瞭解如何設置您的設計系統以實現可擴展性將在未來受益。
讓我們來看看樣式組織，分發，公共與私人文檔和代碼的方法，以幫助您考慮適合您和您的團隊的方法。
包管理和組織模塊
設計系統應該爲變化而建立，無論大小。這對於您對系統進行編碼或使用變量或設計令牌等內容的重要性並不重要 - 這對於您如何組織模塊，版本以及分發它們非常重要。
在GitHub，我們重複了多次組織和打包樣式的方式。像Etsy一樣，我們將我們的設計系統從GitHub monorepo中拉出來，成爲它自己的回購。我們希望能夠更好地控制所做的更改以及這些更改何時重新進入GitHub.com。
我們還在GitHub.com之外的更多網站和應用程序中使用Primer。像git-merge.com這樣的會議網站是使用Primer以及developer.GitHub.com和opensourcefriday.com等社區網站構建的。
並非所有這些網站都需要我們用於GitHub.com的全套樣式，而GitHub.com並未使用核心應用程序中的所有營銷導向樣式。這導致採用模式化方法進行風格組織，並影響了我們打包和分發Primer的方式。
對整個系統進行版本控制與按模塊進行版本控制
對整個系統進行版本控制意味着系統中的所有內容都只屬於一個版本號，並且只能完整安裝。這可以比作瀏覽器或軟件版本。例如，當您更新到新版Google Chrome或手機操作系統時，您將一次性更新整個軟件。
如果您以相同的方式對設計系統進行版本化，則意味着設計系統中的所有內容也會更新。
例如，您可能已更新了字體樣式，添加了新的導航組件或棄用了舊的網格佈局。當您的設計系統的用戶選擇升級時，他們會同時獲得所有這些更改。這仍然爲團隊提供了何時更新系統的靈活性，但隨着系統的擴展，更精細的方法可能會有所幫助。
對單個模塊進行版本控制意味着爲設計系統中的每個組件或一組樣式設置版本號。因此，如果您將按鈕組件放入一個模塊並將實用程序樣式放入另一個模塊中，它們將各自具有自己的版本號，例如[email protected]和[email protected]。
您仍然可以維護一個包含整個模塊集和版本的包。例如，[email protected]包括引物按鈕，引物實用程序和所有其他Primer模塊。因此，您可以提供兩全其美的選擇 - 使用整個系統的選項，或只使用單個模塊。
這種模塊化版本控制方法確實需要更多的工作來進行初始設置，因爲您需要確定將每個模塊煮沸的內容。例如，您是否有一個用於佈局實用程序的模塊以及一個網格系統，或者將它們全部組合到一個佈局模塊中？
這種方法的好處是您的設計系統的用戶可以選擇僅升級他們需要的位。給團隊選擇在他們有時間做時有選擇地更新可能意味着他們更有可能迭代地保持最新 - 而一次性更新整個系統的開銷可以作爲障礙。
通過軟件包進行版本控制使設計系統團隊能夠更頻繁地推送更新，而無需強制更新整個系統。
與一次性對整個系統進行版本控制相比，按模塊進行版本控制可爲主要設計系統版本創建更大的靈活性，從而實現持續開發的文化，並使您的系統團隊整體上更快地移動。
版本，分支和版本號
設計系統團隊通常必須平衡競爭優先級。出現錯誤修復或其他承諾必須與需要更多研究和規劃的密集項目相平衡，例如開發新的顏色系統或引入新的支持功能，如CSS網格。
您的發佈工作流程需要適用於設計系統的用戶和維護人員。維護者希望對他們測試和運輸的內容充滿信心。系統用戶希望清楚地瞭解狀態以及他們獲得的更新類型。
在GitHub，我們發現版本化和組織版本與Git分支的組合爲我們提供了規劃和發佈新設計系統版本的適當靈活性。
圖6.使用GitHub項目板跟蹤多個Primer版本。
我們維護一個“dev”分支，其中包括正在進行的工作，併爲每個單獨的版本創建一個新的分支。由於Git允許我們創建設計系統代碼的多個分支，因此我們可以在主要版本的同時處理次要版本或補丁版本。這意味着我們可以花時間處理可能包括重大更改的主要版本，同時還在次要版本和補丁版本中發佈及時更新和錯誤修復。
對我們的系統進行版本控制並使用Semver可以實現此工作流程。我們可以清楚地指出每個版本的特定版本號，並且Semver系統知道它包含哪些類型的更新，因此我們需要做什麼類型的測試。
由於Semver是一個公認的版本控制標準，它有助於清楚地與GitHub內部的Primer內部用戶或外部進行通信 - 他們獲得了哪些更新以及他們爲了使用更新可能需要做什麼類型的測試。
公共與私人
隨着您的系統和用戶數量的增長，您可能會發現自己在考慮是否在某種程度上公開您的設計系統。沒有一個通用的解決方案 - 它應該基於適合您團隊的方法。使系統公開並不一定是一種全有或全無的方法，有多種方法可以分解公開的內容。
許多開創性團隊創建併發布了精美設計的文檔，例如Material Design，Lightning Design System和Shopify的Polaris。我們不應該假設適用於這些公司的解決方案適合其他所有人。這些公司在設計系統方面進行了大量投資。此外，他們有更廣泛的目標，希望外部開發人員使用這些系統在他們的平臺上構建。
在決定什麼（如果有的話）公開時，您應該根據公司的需求確定優先順序，而不是其他公司設定的標準。
您可以通過以下幾種方式公開您的設計系統：
僅限公共文檔
您可能決定公開源代碼不適合您的團隊，但您希望公開文檔。
Marvel的樣式指南和Mailchimp的模式是公共文檔站點的例子，它們還沒有（還）共享它們的源代碼。
開源設計系統
許多公司開源他們的設計系統。這意味着一般公衆可以打開問題來請求新功能，提供反饋，或讓維護者知道錯誤。維護者還可以選擇通過拉取請求以代碼或文檔更改的形式接受貢獻。如果維護者選擇，他們可以通過添加許可證使設計系統可用於修改和重用。
在美國的Web標準，底漆，幫助偵察和固體的設計系統開放源代碼對所有例子 Github.com。
圖7. Buzzfeed的設計系統Solid在GitHub上是開源的。
使用GitHub上的代碼開源文檔
您不一定要共享精心製作的文檔網站 - 您只需共享以markdown格式編寫的文檔，它將在GitHub上呈現和設置樣式。另一種選擇是通過GitHub頁面發佈文檔。由於GitHub託管文檔，因此這可能是共享文檔的低屏障方式，如果您不添加自定義域，則會爲您提供默認的公共URL。
共享ZIP文件進行下載
如果您想將源代碼和/或npm軟件包保密，您可以選擇共享設計系統的代碼，以便其他人可以使用它。如果您不希望在系統公開上進行正在進行的工作，或者增加管理開源貢獻的開銷，但仍然樂於分享供其他人使用的代碼，那麼這可能是一個不錯的選擇。
像Lab by Compositor（用於爲設計系統創建React組件的設計工具）之類的項目使用GitHub上的Releases功能來共享發行說明和軟件的ZIP文件下載。他們還使用repo來託管文檔和問題以獲得用戶的反饋。
圖8. Storybook中的顏色樣本。
發佈UI組件的故事書
故事書已經成爲設計系統團隊的一種流行工具，特別是對於那些使用React的人，儘管它也可以與Sass或基於CSS的設計系統一起使用。正如Brad Frost所描述的，Storybook是一個“工作室”工具，旨在輸出您的樣式和組件的渲染示例，您可以在開發中使用它們來測試更改。樣式指南文檔是您的“店面”，包括精心製作的詳細文檔以及使用指南和代碼樣式原則等信息。
圖9. Storybook中的通知樣式。
即使沒有詳細的文檔，提供組件的渲染示例對於設計系統的用戶，維護人員和潛在貢獻者仍然非常有用。它提供了設計系統中包含的內容的目錄。
Pattern Lab（由Brad Frost創建），Fractal和React風格導師是其他工具，它們爲Storybook提供類似的功能，包括文檔和代碼示例選項。所有這些工具都可以在不共享設計系統源代碼的情況下使用，併爲您提供有關您共享的文檔級別的選項。
在考慮對系統的不同程度訪問時，還要考慮團隊公開系統的一些原因：
沒有共享的身份驗證障礙
身份驗證背後的任何事情，如外部VPN或防火牆，都意味着訪問的另一個障礙。我知道這是第一手的，因爲我們有一個新的，正在進行的Primer文檔站點，需要員工登錄。人們經常認爲風格指南已被刪除或甚至不知道它存在。
身份驗證還使外部承包商難以訪問。這是一個小障礙，但它可能會產生負面影響，並且意味着可能使用您的設計系統文檔的人不會或不會因爲它太麻煩。
通過預覽設計成熟度幫助招募人員
設計系統現在是設計和前端社區中的熱門話題，可能是潛在客戶決定選擇一家公司而非另一家公司的一部分。
設計系統可以成爲團隊成熟的標誌，也可以洞察在該公司工作的可能性。特別是如果您正在嘗試直接爲您的設計系統團隊招聘，那麼公開文檔是吸引人們和設定期望的明顯方式。
打開您的社區意見
無論是通過簡單的反饋意見還是對代碼的直接貢獻，使您的文檔和/或源代碼公開，都可以讓您獲得外部貢獻。這會帶來開銷，特別是如果您的系統變得流行，但好處是您可以從更廣泛的人那裏獲得反饋和見解。
Primer是在GitHub上開源的。我們越來越多地致力於開放和分享問題並提出請求，以便人們可以看到我們的工作方式。我們注意到社區和內部GitHub貢獻者的貢獻逐漸增加。人們通常爲能夠使任何人受益的開源項目做出貢獻感到自豪。
結論
在您的設計系統的推出中有很多內容，其中大部分內容將自然地延伸到您決定構建系統的方式，與您合作的人員，以及在公司內部推廣採用的最佳方式。
制定完美的推廣策略不如確保您與合適的人員交流，明確您的最終目標以及您的策略如何支持這些策略，並通過每個步驟有條不紊地記錄您的計劃。
設計系統總是在不斷髮展，您分享和鼓勵採用新迭代的方式也將隨之發展。一個有規模的，有意識的，有意識的策略將大大有助於確保採用被視爲建設過程的關鍵部分。