設計體系的響應式設計

編輯導語：如何做好設計體系的響應式設計、由此提升設備適應性、提供更精細化的用戶體驗？本篇文章里，作者結合實際案例，從設計策略、設計模式、實施模式與設計方案四個方面總結了設計體系響應式設計的原則與方法策略，一起來看一下。

一、導讀

在螞蟻內部有著數量繁多且復雜的中后臺業務系統，Ant Design 一直以來致力于從設計策略和資產的角度解決這些產品的體驗一致性問題，隨著螞蟻產品生態的多端化進程，越來越多的跨設備和不同屏幕尺寸導致的問題也逐漸暴露，例如：

XX 能力要在手機上使用，不得不單獨為移動端開發幾個頁面甚至一個產品（反之亦然）；產品數據量很大，Ant Design 默認字體 / 間距太大了，不夠緊湊；版式不夠優化，造成空間浪費……

Ant Design 基于如何在小屏幕中解決信息展示問題這樣的出發點也在很多組件中提供了響應式設計，但擁有更加完備的環境適應性應該是一個設計體系長期的目標之一，因此在全局性地考慮跨端、跨多屏幕尺寸、信息密度等響應式設計方面還值得我們繼續深入研究。

本篇文章橫向調研了 Fluent – Microsoft、Material Design – Google、Fiori – SAP、Lightning – Salesforce、Carbon – IBM、Alta – Oracle、Atlassian Design – Atlassian 等 10 余家企業級產品設計體系的響應式設計部分，從設計策略、設計模式、實施模式、設計方案四個層面大致歸納了一些信息，旨在對響應式設計有一個籠統的了解。

關于 Adaptive Design 與 Responsive Design先厘清兩個概念。

關于響應式設計通常會有兩個普遍認識，即 Aaron Gustafson 與 Ethan Marcotte 分別在 2011 年自己的著作中提出的 Adaptive Web Design（AWD）與 Responsive Web Design（RWD）概念，它們的核心區別在于 AWD 針對不同的設備或屏幕尺寸定制化設計多個固定布局的尺寸，而 RWD 是同一套代碼做彈性的適應，本質上它們都在解決產品設計如何適應于不同設備以及不同屏幕規格的問題。

本篇所指的「響應式設計」 概念包含了兩者，不做明顯區分，關于 Adaptive 與 Responsive 設計怎么界定以及具體的規則本篇也不進行展開。

二、移動優先設計策略

提響應式設計不得不提「移動優先」設計策略。

移動優先的概念最早是 Google 在 2010 年世界移動大會上提出來的一種產品策略，基于 Google 對未來趨勢中移動設備將會逐漸擁有核心地位的判斷。后來「移動優先」更多被提及是作為一種在響應式設計中應用的設計策略，它認為在響應式設計中優先為屏幕限制更大的移動設備設計，再擴展到大屏幕的 PC 端是一種更有效的設計方法。

例如 Alta、Lightning、Fiori 均在設計體系中明確采用「移動優先」的設計方法，Fiori 尤其指出「移動優先」專注核心功能，專注增強而非降級，提前考慮移動端更多的獨特特性以及異常情況，能提供更好的體驗。

Material Design 可能算是移動優先的最佳實踐，它本身就誕生于 Android 平臺，而后再通過大量響應式規則擴展到桌面及 Web 端，使得 Material 在多端都擁有一致貫穿的良好體驗。

（Material Design 的響應式設計）

「移動優先」本質上是基于一種「增強」的設計思想，一個產品如果要同時適應于不同的設備，一直以來有兩種策略：優雅降級 vs. 漸進增強，后者認為先從最小和最受限制的低級設備（移動設備）入手，再為更高級的設備（桌面設備）增強信息和交互。這意味著在更多限制下，迫使設計考慮如何減少、匯總，分組信息，有利于聚焦核心信息以及為更多限制考慮。

然而移動設備已不再是「低級設備」，Fiori 盡管強調「專注增強而非降級」，但它同時提出的「提前考慮移動端更多的獨特特性」卻與漸進增強的設計思想相悖，讓「移動優先」淪為了某種形式化的概念而難以執行。

例如下面這個報告界面的場景里，移動端僅展示匯總的報告圖表信息，但匯總圖表并沒有「擴展」到 Tablet 里而是用明細數據替換圖表，而在桌面端同時包含了明細數據與圖表兩部分信息。這看上去并不像是一個「增強」的設計思路，更像是在全量需求下基于設備限制所采用的「降級」策略。

（Fiori 報告界面的 Adaptive Design）

因此「移動優先」并不一定是形式上優先設計移動端，它被廣泛接受和應用的是背后的漸進增強的核心思想。

我認為在移動設備高度發展的當下，「移動優先」不再適合作為單獨概念提出來，而漸進增強的設計思想應該體現在更細分的場景中，例如在布局、信息排版以及交互反饋中，我們應該優先考慮限制更大的移動端；在一些交互方式上，優先考慮限制更大的鼠標操作。甚至在復雜業務場景里，優先滿足核心業務流程順暢也屬于漸進增強的策略范疇。

三、設計模式

這里講的設計模式是指設計師在具體業務中針對不同的情況可以采用的通用性設計方案，這些設計模式除了單獨應用外，有時候也可以多種模式結合應用。

Fluent 歸納了 6 種對應不同情況的響應式設計模式，非常全面地涵蓋了其它設計體系中的絕大部分方案，分別是：調整大小、重新定位、重新排列、顯示/隱藏、替換、重新構建。

1. Resize——調整大小

調整大小是最基礎的設計模式，是一個容器默認的響應式模式，通常有等比縮放、固定高度、或是在不同尺寸下按不同比例規格縮放三種形式。

即便在無響應式設計的體系里，容器跟隨屏幕尺寸而變化也是一個常見的應用方式。

（Resize）

2. Reposition——重新定位

改變 UI 元素的相對位置，以充分利用不同尺寸的空間。

重新定位在響應式應用里多見在框架上，或是在組件里對一些特定元素的處理，例如 Material 的全局浮動按鈕與浮動的下拉菜單以 Reposition 的形式分別在桌面端與移動端處于不同的位置。

（Reposition）

3. Reflow——重新排列

改變 UI 元素的排列方式，這在內容彈性布局里較常見，通常是基于某種排列規則自動向下折行，并結合調整大小與柵格系統應用在響應式布局方面，例如 Carbon 的 Fluid Grid。

（Reflow）

4. Show / Hide —— 顯示 / 隱藏

基于屏幕空間、設備不同特性、特定情況等顯示或隱藏 UI 元素，例如大多數設計體系的框架設計應用在小屏幕上會隱藏側邊菜單。

Material 在組件響應式行為里提到的 Expand 也屬于 Show / Hide 的延伸。

（Show / Hide）

5. Replace——替換

針對不同尺寸的屏幕采用不同形態的組件，通常應用在對具體的組件做針對性響應式設計中，但需要注意用戶面對變化時的認知成本。

（Replace）

6. Re-architect——重新構建

折疊或拆分信息架構，這種模式在 Web 端較難實現，通常出現在一些 Native App 的場景。

（Re-architect）

7. Density——內容密度

除了上述 6 種模式以外，我把內容密度也歸納為一種設計模式，Fiori、Material Design、 以及 Atlassian 都提出了內容密度的概念。

Fiori 基于移動優先在移動端采用默認密度，而針對大屏幕的 Web 端則提供緊湊密度的方案，他們認為移動端手指交互所需的空間要求更高。

Material 則是針對很多組件都定制了 Default、Comfortable、Compact 三種密度的視覺表現。通過被動響應式或主動控制內容密度很好地解決了不同尺寸屏幕的信息獲取效率問題。

（Material Design 的內容密度示例）

值得一提的是 Atlassian 通過柵格系統的間距來控制密度而非對內容密度本身進行設計，越緊湊的布局柵格間距越小，這看上去很合理，卻很容易造成內容密度增加的同時整體信息獲取效率反而降低的問題。

Material 也有關于柵格空間的定義，但在內容密度的處理上和 Atlassian 恰恰相反，它認為高密度內容適用更寬松的柵格空間，相對是一個更合理的設計。

在信息密度的問題上，我們的核心目的其實是提升信息效率而非單純提高視覺密度，因此解法上需要更完善的考慮。

（Atlassian 與 Material 的柵格密度對比）

四、實施模式

實施模式是指設計體系為實現具體設計方案而定義的一系列基礎規則、解決方案或技術手段，經過整理總結為相對尺寸單位、屏幕斷點、彈性布局、柵格系統 4 個方面。

1. Rem——相對尺寸單位

幾乎所有應用于 Web 的設計體系的技術方案中都采用 rem 相對單位，Material、Fiori、Carbon 和 Lightning 均沿用了瀏覽器默認的 root 尺寸，即 1rem = 16px，Alta 默認采用是 14px 的規格，并允許基于不同應用選擇 12px 或 16px 的規格，默認情況 Alta 采用更小規格的單位會在小屏幕電腦上有更好的表現，這也許和他們的產品特性相關。

相對尺寸單位是非常具有實施價值的，它使產品能在保持信息節奏的情況下根據不同的情況等比例縮放內容，這使得設計能更方便地調整內容密度，或許還可以配合 Media Queries 解決部分跨端的尺寸適配問題，且幾乎沒有前端成本。

國內的前端業界包括我們自己的前端同學更多將 Rem 運用在移動端，主要為了兩個目的：方便計算尺寸、在不同寬度的設備上等比縮放內容，這樣的用法是出于前端工程師解決屏幕兼容性的一種技術手段，在使用上本身也存在一定爭議。

而在響應式設計領域我們還沒有發揮出 Rem 應該發揮的作用，甚至很多設計師還并不了解相對尺寸單位的使用方法，廣泛應用 Rem 能為我們帶來哪些實際價值是接下來需要繼續研究的。

2. Breakpoints——屏幕斷點

屏幕斷點是響應式設計的基礎依據，它決定了我們要適配到什么樣的設備或屏幕規格，并通過 Media Queries 這樣的技術實現不同 Breakpoint 條件下的不同 UI 表現。

一般情況 Breakpoints 都是基于 Phone、Tablet、Desktop 的維度來設計的，包括考慮了移動設備的橫評豎屏情況，關于詳細的規格設置其實并沒有太大參考價值，設計體系都是根據自身定位以及設備覆蓋的情況來制訂的，例如 Material 的斷點在低分辨率范圍分得非常細，是因為 Material 主要服務的 Android 平臺有著數量繁多的設備分辨率。

在滿足自己需求的前提下，屏幕端點不需要太多，無論怎樣基于數據驅動的屏幕斷點設置將會是一個更科學的方法。

（屏幕斷點分布）

Fiori 的斷點設計比較有意思，在設計文檔中僅有基本的布局規則，沒有明確的 Breakpoints 規則。

Fiori 對于不同的組件會設計不同的 Breakpoints，例如在 Table 這個組件中定義了 0 < 220 < 270 < 350 < 460 < 570 < ∞ 的規格，而在 Form 的組件中，Breakpoints 變成了 0 < 600 < 1024 < 1440 < ∞，從這點上看出 Fiori 認為不同的組件有不同的表達模式，因此應該針對性對組件進行優化。

（Fiori 的 Table 組件適配情況）

（Fiori 的 Form 組件適配情況）

3. Flex Layout——彈性布局

Flex 布局是 CSS3 提供的強大布局能力，從更自然更具語義化的角度實現界面元素的自適應。

應用于 Web 的設計體系基本上都在組件代碼里廣泛采用了 Flex 布局，Lightning 還將柵格與 Flex 布局結合定義了自己更完善的布局方法。

在響應式設計中，Flex 布局通常結合 Breakpoints 使用，在兩個 Breakpoints 之間讓界面做更平滑的過度。除此之外其它平臺也都有類似的彈性布局能力，例如 Fluent 在 windows 采用 XAML 構建布局系統。

無論是 Flex 還是最近興起的 Grid 布局都是 CSS3 的基本布局能力，響應式設計要解決布局的問題將會深度依賴這些基礎技術手段，本篇不進一步展開。

4. Grid System——柵格系統

柵格系統是所有設計體系必備的，我們通常將頁面橫向分為 N 列，定義每一列的尺寸與間距，這為界面布局提供了一致性和成本便利。

傳統的柵格系統在響應式方面的應用主要是結合 Breakpoints 與一些 Responsive Token 來實現的，通過給 UI 元素指定不同的柵格數來決定他們分別在不同屏幕下占多少列，同時一些設計體系還提供了可見性相關的 token，來控制界面元素在不同屏幕的顯示與隱藏。

Fluent、Fiori、Lightning、Material 以及大多數設計體系都采用了 12 柵格系統，因為 12 的因數夠多，能滿足足夠多的布局細分同時又不至于太復雜，Carbon 的做法更加 geek 一些，他們的「2x grid」采用了 16 柵格系統，布局粒度更細但放棄了 3，6 這樣的因數。

Ant Design 為了滿足復雜的業務情況，采用了 24 柵格系統，24 柵格提供了更高的靈活性的同時，也大大增加了復雜度，面臨柵格系統的響應式設計 24 柵格是否適用還有待商榷。

另外 Material、Carbon 還明確提出了「Fluid Grid – 流體柵格」的概念，核心思想是在較小的屏幕上降低柵格數量，將多余的柵格自動折行彈性布局。

（Carbon 的柵格定義）

在屏幕尺寸變化時，柵格主要有兩種響應模式：Fluid、Fixed。

（Fluid）

（Fixed）

這種將柵格系統與彈性布局相結合的方式基于一些簡單的規則設置，在不需要特定響應式的場景中不再需要指定繁瑣的 token，且能滿足大部分高頻且通用的情況，在一定程度上降低了成本。

五、組件應用

除了通用的響應式規則以外，設計體系在具體組件中的響應式方案還有許多值得挖掘，能為我們的組件設計提供參考價值，本篇不再一一展開，僅提兩個典型的應用情況：

1. 框架

（Carbon 的框架設計）

框架算是一個特殊的組件，在不同的設備中界面框架的適用有非常大的差異。

幾乎提到響應式的所有設計體系都給出了框架響應式方案，例如 Alta 將界面框架分為四塊，以 Off-Canvas 和 Reposition 兩種方式在不同尺寸的屏幕中顯示或隱藏以及通過特定的方式展開或呼出。

通常情況下設計體系的框架組成按形式可以分為：

• Header——通常情況下常駐；
• Sidenav——分為左側右側兩種情況，一般用于放置導航，在不同設備會有展開、收縮、隱藏三種狀態；
• Content——內容區，通常由 Grid 控制布局；
• Footer——如有，固定在頁面底部；
• Float——浮動框架，用于臨時狀態，通知或彈窗等。

設計體系通過對框架的定義，以及控制不同部分基于什么樣的模式響應屏幕尺寸來實施對框架的響應式設計。

（Material 的響應式框架）

2. 組件

Fluent 或 Material 在設計文檔中更多基于基礎的網格、布局、設計模式來闡述通用性的響應式規則，因此他們的響應式設計有非常好的延續性，組件的響應式方案基本上都遵循這些規則。

而 Fiori 以及 Lightning 在通用性響應式設計模式上的定義上沒有那么全面，他們側重于在組件層面對所有組件都考慮了針對性的 Responsive 或 Adaptive 的方案。

例如 Fiori 在響應式表格的組件里，在桌面端與移動端分別是 table 和 list 的模式，這個方案并不是通過全局抽象規則得出來的，而是基于對組件的針對性設計，正如他們為不同的組件設計了不同的 Breakpoints，這種針對性也適用于特定的 UI 解決方案。

（Fiori 針對 Table 的響應式設計）

在一定程度上抽象規則的同時，如果我們能夠為每一個組件都考慮到不同場景的響應式，當然就會提供更精細化的體驗。在一個完備的設計體系里，在設計每一個組件資產時都以漸進增強的設計策略，考慮到不同的設備及屏幕適配是非常有必要的。

響應式設計的世界煙波浩渺，書不盡言，言不盡意。Ant Design 目前計劃從布局基礎規則以及內容密度的解決方案切入，逐步完善響應式設計的體系，這是一個重要且漫長的過程。

至于文中挖下的坑還需要深入研究逐一補充，本篇初探先到這里，歡迎大家留言指出問題，也很希望大家能留下想法共同探討。

設計體系

Fluent – Microsoft：​www.microsoft.com

Material Design – Google​：material.io

SAP Fiori | User Experience and Apps​：www.sap.com

Lightning – Salesforce：​www.lightningdesignsystem.com

Homepage – Carbon Design System​：www.carbondesignsystem.com

Alta – Oracle：​www.oracle.com

Atlassian Design​：atlassian.design

 

作者：TC，螞蟻集團設計師

本文由 @Ant Design 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于 CC0 協議