- 原文地址：Atomic design: how to design systems of components
- 原文作者：Audrey Hacq
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：H2O-2
- 校對者：ZhangFe，LeviDing
原子設計：如何設計元件系統
如今，數字產品需要同時適用於任何的裝置，螢幕尺寸和媒介：
所有媒介現在都可以顯示我們的介面元素
所以我們為啥還在依據「頁面」或者螢幕設計自己的產品？！
我們應該通過設計優美、簡潔且相容一切裝置、螢幕尺寸或內容的訪問方式取而代之。
依據以上原則以及受到模組化設計的啟發，Brad Frost 構想出了從最小的介面元素：原子，著手的原子設計方法。這個巧妙的比喻讓我們理解了我們到底在創作什麼，尤其是應該如何創作它。
我對這個方法深信不疑：它終於可以讓我們同時考慮部分和整體，擁有對產品或品牌的全域性視野，並且能夠以更接近開發者的工作方式工作。
因此我自忖道：
「沒錯兒了，就是這樣！我們就需要像這樣工作！」
但是說實話，我完全不知道該怎麼做...
在花了幾個月的時間並且做了幾個實打實的專案之後，我才終於對「原子設計方式」的內在含義，以及它將會如何改變我的設計師之路有了些瞭解。
在這篇文章裡，我將會簡要介紹一下我學到的知識，以及在通過原子設計方式設計元件系統時需要注意什麼。
針對何種專案？
對於我來說，每一個專案，無論大小都可以使用原子設計的理念。
這種方式可以統一團隊的視野。元件易於複用、編輯和組合，使得專案的發展變得簡單。至於小的專案嘛... 每個小專案總有一天都可能成為大專案，不是嗎？
和大部分人的認知相左的是，我認為原子設計方法並不只適用於網路相關的專案 ... 事實上截然相反！我成功地在一個個人專案中（一個叫做 TouchUp) 的 iOS 應用，可以清理你的地址簿）引入了原子設計，而且與我合作的開發者非常欣賞這種方式。當我們想快速開發並迭代產品的時候，它幫了大忙。
同時我推薦那些擔憂創造性與構建元件系統是否可能共存的人讀讀這篇文章：「原子設計與創造性」
這和過去有什麼不同呢？
經常有人問我：
「但是這和我們過去的工作方式有什麼不同呢？」
我認為原子設計對介面設計方法只做出了很小的改變，但最終卻帶來了巨大的影響。
部分塑造整體且整體塑造部分
直到最近，我們仍會單獨設計產品的每一個介面，然後把它們裁剪成小元件，以此來建立設計規格或 UI 套件（UI Kits）：
之前：我們解構介面來製作元件。
這樣製作出來的元件有一個問題，它們並不通用，且互不依賴。因此元件的重複利用是非常有限的：我們的設計系統具有侷限性。
現如今，原子設計的理念是從可以最終構建出整個專案的通用原材料（原子）入手。
現如今：我們從原子開始並且用原子構建。
因此我們不僅擁有了充斥在所有介面之間的「家庭氣氛」（譯註：「家庭氣氛」是一部法國的喜劇電影），更擁有了一個帶來無限設計可能性的系統！
一切始於品牌識別（Brand Identity）
現在你也許在想：
「如果我們想以原子的方式設計，該從哪開始呢？」
對這個問題我給出了一個極富邏輯性的回答：從原子開始 ;)
因此我們首先要為產品設計出一個獨特的視覺語言作為起點。它將會定義我們的原子和原材料，而且顯然它應與品牌識別緊密相連。
這個視覺語言一定要有力度、易於擴充套件、並且能夠從其展示媒體中解放自我；它必須能在所有地方奏效！
比如 Gretel agency 就為 Netflix 的品牌識別做了些出色的工作。
Netflix 的視覺語言：有力度、辨識度高且易於擴充套件。
多虧了強有力的品牌識別，我們會覺得已經有充足的材料釋出最初的一系列原子了：色彩、字型選擇、表單、陰影、空白、節奏、動畫原則...
因此很有必要花時間設計品牌識別、思考重點是什麼、以及如何能讓品牌和產品與眾不同。
讓我們回到元件上來
有了原材料（目前仍然比較抽象），我們就可以根據產品目標以及我們辨識出的初始使用者流程來設計我們最初的元件了。
從關鍵特徵開始
最讓那些構建元件系統的設計師們膽寒的莫過於建立與什麼都不關聯的元件 ... 很顯然，我們不會在沒有購物功能的產品裡設計購物車元件的！這完全不合常理！
最初的元件將會和產品或品牌目標緊密結合。
重申一遍，忘掉「頁面」這個概念，我堅持側重於產品特色或使用者流程，而不是介面...
我們應該側重於一個行為，而不是某個特定的介面。
我們會把注意力集中在某個我們希望使用者去執行的操作以及它所需要的元件上。介面數量則會根據使用者環境變化：也許在臺式電腦上我們只需半個介面，智慧手機卻需要三個連續的介面來顯示某個元件...
充實元件系統
接下來為了充實元件系統，我們要在已經存在的元件和新功能間迴圈往復：
通過在已經存在的元件和新功能間迴圈往復來充實元件系統。
最初的元件可以幫我們建立出最初的介面，接下來，最初的介面又會幫我們在系統中創造新的元件，或改變已有的元件。
「通用」思維方式
在用原子設計方法設計時，我們應該牢記，同一個元件會在不同的上下文環境中被否決或重複使用。
因此我們將會把元素的結構和其內容真正區別開來
例如我要建立一個「聯絡人列表」元件，我可以馬上把它轉變成一個通用的「列表」元件。
然後我會想想這個元件可能有的變形：如果我要新增或刪除元素怎麼辦？如果文字佔了兩行呢？這個元件的響應式行為會是什麼？
把一個特定元件轉變為通用元件。
預見到這些變形後，我可以在這個元件基礎上，建立出其他的元件：
通用元件的可能變形。
如果想讓我們的元件系統內容豐富且可被再利用，這麼做是必須的。
「流體」思維方式
我們仍傾向於把響應式設計想成塊狀元素在特定斷點上的重新組合。
然而實際上元件自身必須擁有它們自己的斷點和流體行為（fluid behavior）。
多虧了像 Sketch 這樣的軟體，我們終於可以測試元件的各種響應式行為並且決定哪些元件應該是流體的，哪些元件應該是固定的。
我們需要預測元件的流體行為。
我們也可以預想到，一個元件在不同的使用者環境中可能會有很大區別。
比如一個在臺式電腦上顯示為圓角矩形的按鈕，在智慧手錶上可能就會變成一個帶有圖示的簡易的圓形。
部分和整體
通過原子設計構建元件系統有一個有趣的地方：我們在有意識地建立一系列互相依賴的元件。
完成細節部分後再後退一步，在更大的格局中審視結果。
我們不斷地把視線拉近或拉遠來進行作業。我們會先在一個細節、一個微互動、或是一個元件的微調上花時間，接著後退一步在上下文環境中審視其視覺效果，接著再後退一步檢視整體效果。
這就是我們改進品牌識別，開發元件以及檢驗元件系統正常運作的方法。
使成品相關聯
我們所有的元件都與原子相連。因此我們將可以輕鬆地更改部分元件系統，並觀察這種更改對系統其餘部分的副作用！
如今身為設計師的我們是何其幸運：利用改良之後的工具，我們終於可以創造出靈活且不斷演化的系統了。
當然，現在已經有可以讓我們建立共享樣式並使相似元件相互關聯的軟體了，例如 Sketch 和 Figma。但是我確信在接下來的幾年內會出現更多這樣的軟體。
我們終於可以像開發者一樣擁有自己的風格指南（style guide）並圍繞它構建整個元件系統了。對系統中一個原子的微調就會自動反應到所有使用它的元件：
所有元件都與原子相連。
我們很快就會意識到對元件的修改會如何影響整個系統。
我們也會意識到，通過使元件相連，一個新增的元件將會影響到整個系統的核心部分，而不僅僅是一個孤立的介面。
共享系統
為了保持多個產品的一致性，系統的共享是必須的。
我們都知道，當我們獨立完成一個專案時，一致性很快就會消失，但當我們越來越多地和其他設計師合作時，保持一致性會更加困難。
這時又一次，我們已經擁有可以圍繞一個共同的系統進行團隊協作的工具了。
例如 Sketch 的 Craft，或是 Adobe 的共享庫，這些工具使我們擁有一個公有且一直保持最新狀態的單一資料來源（single source of truth）。
共享庫：一直同步並保持最新狀態。
共享庫使多個設計師可以從相同的基本元件開始他們的設計。
這些庫同時也精簡了我們的工作，因為我們一旦在共享庫中更新了一個元件，這個更改會自動應用到每個設計師使用的所有與其相關的檔案上：
在庫中的一個更改會自動改變所有與其關聯的元素。
我必須承認，在我試用過的所有共享庫中，還沒有一個完美契合原子設計工作的... 原子和元件間強大的相互依賴性仍然缺乏，這一特點使我們可以建立靈活且不斷演化的系統。
另一個問題是我們仍然有兩種不同的庫：設計師的庫和開發者的庫... 因此這兩種庫需要同步維護，帶來了錯誤和許多額外的工作。
我理想中完美的共享庫是這樣的：一個可以同時滿足設計師和開發者需求的的庫：
我理想中的未來：一個可以同時滿足設計師和開發者需求的單一的庫。
但在我看到如 React Sketch app（由 Airbnb 在近期釋出） 這樣使程式碼寫成的元件可以直接在 Sketch 檔案中使用的外掛之後，我對自己說，也許這個未來已經不遠了...
React Sketch 外掛：程式碼寫成的元件可以直接在 Sketch 中使用。
寫在最後
我想你應該已經理解了：我堅信需要使用元件設計介面，考慮靈活且不斷演化的系統，並且我認為原子設計方法會幫助我們有效的達成這些目的。
如果你也有在大小專案上使用元件系統的反饋，就在評論區分享你的經驗吧！
這篇由 Audrey 撰寫的文章旨在分享知識並扶持設計社群。所有在 uxdesign.cc 上發表的文章都遵從這一理念
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、後端、產品、設計 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃。