- 原文地址:Atomic design: how to design systems of components
- 原文做者:Audrey Hacq
- 譯文出自:掘金翻譯計劃
- 本文永久連接:github.com/xitu/gold-m…
- 譯者:H2O-2
- 校對者:ZhangFe,LeviDing
現在,數字產品須要同時適用於任何的設備,屏幕尺寸和媒介:前端
全部媒介如今均可以顯示咱們的界面元素react
因此咱們爲啥還在依據「頁面」或者屏幕設計本身的產品?!android
咱們應該經過設計優美、簡潔且兼容一切設備、屏幕尺寸或內容的訪問方式取而代之。ios
依據以上原則以及受到模塊化設計的啓發,Brad Frost 構想出了從最小的界面元素:原子,着手的原子設計方法。這個巧妙的比喻讓咱們理解了咱們到底在創做什麼,尤爲是應該如何創做它。git
我對這個方法深信不疑:它終於可讓咱們同時考慮部分和總體,擁有對產品或品牌的全局視野,而且可以以更接近開發者的工做方式工做。github
所以我自忖道:
「沒錯兒了,就是這樣!咱們就須要像這樣工做!」
可是說實話,我徹底不知道該怎麼作...後端
在花了幾個月的時間而且作了幾個實打實的項目以後,我才終於對「原子設計方式」的內在含義,以及它將會如何改變個人設計師之路有了些瞭解。網絡
在這篇文章裏,我將會簡要介紹一下我學到的知識,以及在經過原子設計方式設計組件系統時須要注意什麼。app
對於我來講,每個項目,不管大小均可以使用原子設計的理念。ide
這種方式能夠統一團隊的視野。組件易於複用、編輯和組合,使得項目的發展變得簡單。至於小的項目嘛... 每一個小項目總有一天均可能成爲大項目,不是嗎?
和大部分人的認知相左的是,我認爲原子設計方法並不僅適用於網絡相關的項目 ... 事實上截然相反!我成功地在一個我的項目中(一個叫作 TouchUp) 的 iOS 應用,能夠清理你的地址簿)引入了原子設計,並且與我合做的開發者很是欣賞這種方式。當咱們想快速開發並迭代產品的時候,它幫了大忙。
同時我推薦那些擔心創造性與構建組件系統是否可能共存的人讀讀這篇文章:「原子設計與創造性」
常常有人問我:
「可是這和咱們過去的工做方式有什麼不一樣呢?」
我認爲原子設計對界面設計方法只作出了很小的改變,但最終卻帶來了巨大的影響。
部分塑造總體且總體塑造部分
直到最近,咱們仍會單獨設計產品的每個界面,而後把它們裁剪成小組件,以此來建立設計規格或 UI 套件(UI Kits):
以前:咱們解構界面來製做組件。
這樣製做出來的組件有一個問題,它們並不通用,且互不依賴。所以組件的重複利用是很是有限的:咱們的設計系統具備侷限性。
現現在,原子設計的理念是從能夠最終構建出整個項目的通用原材料(原子)入手。
現現在:咱們從原子開始而且用原子構建。
所以咱們不只擁有了充斥在全部界面之間的「家庭氣氛」(譯註:「家庭氣氛」是一部法國的喜劇電影),更擁有了一個帶來無限設計可能性的系統!
如今你也許在想:
「若是咱們想以原子的方式設計,該從哪開始呢?」
對這個問題我給出了一個極富邏輯性的回答:從原子開始 ;)
所以咱們首先要爲產品設計出一個獨特的視覺語言做爲起點。它將會定義咱們的原子和原材料,並且顯然它應與品牌識別緊密相連。
這個視覺語言必定要有力度、易於擴展、而且可以從其展現媒體中解放自我;它必須能在全部地方奏效!
好比 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、前端、後端、產品、設計 等領域,想要查看更多優質譯文請持續關注 掘金翻譯計劃。