作為一名產品經理，可能會遇到沒有資源給你做互動，也沒有資源給你畫UI的情況，這種時候便需要學會自給自足。這個系列是作者在兩年中“自給自足”做設計的一些發現，本文分析了設計體系和模態對話方塊，一起來看一下吧。

眾所周知（大霧，黑帕雲這樣的產品幾乎使用了所有型別 B 端的元件。

由於我司設計資源有限，所以在擁有了元件庫、設計師定好了設計規範之後，作為產品經理就直接可以手擼設計稿了。

作為一個長大了的產品經理，有時候沒有資源給你做互動沒有資源給你畫 UI 的，你要自己學會自給自足。

這個系列就是作為產品經理的我，在這兩年中“自給自足”做設計的一些總結與發現。

自給自足的前提是，前面說的元件庫和設計規範，即擁有一個設計體系（Design System）。

01 什麼是設計體系？

關於設計體系的定義和內容各家都不同，我找出來了以下案例供參考。

1. 《設計體系：數字產品設計的系統化方法》

Tilio（一個寫作和筆記應用）聯合創始人，有十年 UX 設計經驗的阿拉·霍爾馬託娃在《設計體系：數字產品設計的系統化方法》一書中這麼定義：

設計體系是為了實現數字產品的目的而組織起來的一套相互關聯的模式和共享實踐。模式指的是介面中那些重複的要素：使用者流程、互動方式、按鈕、文字框、圖示、配色、排版、文案，等等。實踐則是我們如何建立、捕獲、共享和使用這些模式，尤其是在團隊協作時做這些事情的方法。

書中將設計體系分成以下幾個部分：設計目的、設計原則、元件庫、樣式指南，以及用於提高設計師和開發人員溝通效率的工作流程和實用工具。

整理之後，可以參考下圖：

2。 Salesforce：Lightning Design System

3. Material Design

可以發現，以上設計體系無論如何定義概念，都是由

設計原則+設計指南+一些基礎的元素（比如 Design Token、Material Foundation、Icons）+元件庫+其他資源工具

構成。

形成這些內容的目的都是為了給自己產品建立一套保證設計質量、提升設計決策、提升溝通效率的“工具包”，從而讓產品形成自己的符合設計原則的風格。

所以設計體系是什麼不重要，

重要的是如何在遵循設計原則下，能夠高效做出高質量的設計。

02 設計原則（Design Principes）

一個開源設計原則和方法的網站 Design Principle這樣定義設計原則：Design Principles are a set of considerations that form the basis of any good product。

譯為“設計原則是構成任何好產品的一套基礎考慮因素。”

比如 Salesforce 的設計原則是：清晰、高效、一致、美觀。並且優先順序由前到後。

可以理解為 Salesforce 會追求清晰大於高效、一致、美觀，比如在產品設計中，讓使用者清楚的看到、理解、自信地去操作要比任何事情都要重要。

這個準則很容易理解，可以推論出 Salesforce 在度量體驗時，將“易用性”放在了第一位，即作為一個 SaaS 產品，不能有任何讓使用者產生疑惑的地方。如果在設計上的美觀而要犧牲清晰，這就是不可取的。

03 元件庫

有了設計原則之後，下一步是需要一個元件庫。這裡說的元件庫囊括了無論是原子化的顏色、字型、陰影、Icon 這些基本的元素，還包括了已經封裝好的元件，如 Button、Alert、Toast、Text Input。

關於為什麼要元件化，也不多說了，之前看過一篇閱文體驗設計 YUX 的《元件化思維—— 適應並推動業務及產品變革的設計案例》寫得非常清楚。

接下來我透過 Minecraft 這個遊戲來總結了元件庫。

玩過生存模擬類遊戲大家都知道，在遊戲中會有一些可以靠雙手勞動得來的基礎材料，比如砍樹砍來的木頭、地上撿的石頭、挖礦挖的燧石。這些基礎材料可以合成一些簡單處理過的材料，比如把木頭合成為木板。然後可以再把半成品進一步加工，比如木棍。

在 Minecraft 這個遊戲中，如果玩家要製造一個弓箭，需要一個弓和一個箭。弓和箭的合成又需要一些半成品和成品或者原材料來加工製作，如下圖：

對應在設計元件庫中可以對照檢視，一個完整的頁面是可以透過一些元素、控制元件、元件、大元件組成：

04 適用人群

關於 「B 端設計總結」這一系列，主要是我個人在已有了我們的設計規範和元件庫後，“自給自足”的情況下探索出來的一些元件使用規則，更偏向

產品經理

或者

互動設計師

來參考。

所以系列中不會寫設計規範，比如說字號、顏色、間距等等這些屬於設計規範中內容。

而是基於已有的規範，總結之前我們功能中涉及到的該使用哪些元件，也可以稱之為狹義上的設計指南（Design Guidelines）或者設計模式（Design Patterns）

。

05 設計原則 Design Principes

正式開始之前，想整理一個合格的設計應該有哪些方面的考量因素，這樣能夠幫助我們在做設計時，盡大可能地保證設計的質量。

在前言中提到設計原則，使用了 Salesforce 作為案例介紹了他們的設計原則是：清晰、高效、一致、美觀。

但這更像是宏觀層面的品牌原則，不僅是設計，而是覆蓋在方方面面傳遞給使用者的感知。

而國內的設計團隊，會把設計原則落實在細節。這也更通用、更加能指導設計執行。

比如騰訊雲的 Element UI 的設計原則是：

京東的 LEGAO Design 的設計原則是：一致性、可控性、秩序性、提高效率、及時反饋、簡潔美觀、寬容性。

這兩個設計團隊給出的設計原則都包含了一致、反饋、效率、可控，LEGAO Design 在基礎上增加了秩序性、簡潔美觀和寬容性。

在 LEGAO Design 的設計原則中有非常詳盡的舉例和說明，在此就不搬運了，建議像我一樣沒有設計基礎的產品經理同學仔細學習。

說點兒不同的。

其中 Element Design 和 LEGAO Design 的“可控”稍有不同，Element Design 的可控包含兩個方面：

使用者的決策是可控的，要根據場景給予操作建議或安全提示，但不能代替使用者決策。

結果要求是可控的，使用者可以自由決策，包括撤銷、回退和終止當前操作。

LEGAO Design 在此基礎上將“使用者決策”和“結果可控”結合在一起，認為在危險操作或者破壞性操作需要提前告知使用者，並且應該要提供撤銷、回退和終止等操作。

另外還對“可控”增加了“進度可控”：清晰地告知使用者當前處在系統的什麼位置，從哪裡來，可以到哪裡去。比如提供清晰便捷的導航方式，非必要條件下導航各個標籤權重保持一致，不要因為差異化對使用者產生選擇性干擾。

此外， LEGAO Design 在可控的基礎上，格外增加了“寬容性”，宣告應當允許使用者犯錯：

設計應該是幫助使用者避免犯錯，當危險發生時能保護使用者免受傷害。寬容性設計是透過約束和良好的功能可見性來防止錯誤的發生，能提示潛在的危險，當某一選擇能帶來傷害時會要求先確認後執行。

寬容性設計允許錯誤發生時的動作可逆性操作。

在《互動設計精髓中》也單獨列了一章來講“防止錯誤，通知決定”。

沒有人能夠保證所有的設計都是“清晰”（Salesforce 的 Design Principe）的，即便是設計是清晰的，也會有意外的情況。所以好的設計應該是清晰，並且允許使用者犯錯的。

容錯處理能夠在心理上暗示

鼓勵使用者安心地多去探索你的產品

。

而在一些情況上，容錯處理有較大的成本，還來不及進入開發，這時應該換一種思路：

我們需要儘可能地攔截錯誤的發生

（這一部分見文末的小節「危險提示 Danger Alert」）。

設計原則說的差不多了，下面開始這個系列的正文。

06 模態框 Modal

在寫什麼是模態對話方塊（Modal Dialog）之前，先來寫寫模態框（Modal）和對話方塊（Dialog）。

模態框一詞最早是從技術同事那聽來的，因為我那會兒一直管這些叫彈框，事實也確實是如此。

在維基百科中這麼定義：

In user interface design for computer applications， a modal window is a graphical control element subordinate to an application’s main window。

A modal window creates amodethat disables the main window but keeps it visible， with the modal window as achild windowin front of it。 Users must interact with the modal window before they can return to theparentapplication。 This avoids interrupting theworkflowon the main window。 Modal windows are sometimes calledheavy windowsormodal dialogsbecause they often display adialog box。

不專業地翻譯一下：

在應用程式的互動設計中，模態視窗是一個從屬於主視窗的圖形控制元素。

一個模態視窗建立後，主視窗就失效了，但仍然保持可見。模態視窗能夠作為一個子視窗在主視窗的前面。此時使用者必須先與模態視窗進行互動，才能返回到父視窗。這避免了中斷主視窗的工作流程，模態視窗有時候也被稱為重視窗（？）或者模態對話方塊，因為他們經常以對話方塊形式展示。

在一個 React UI框架 Material-UI中這麼描述模態框：

“模態框”（Modal）這個詞有時也被用來指代“對話方塊”，但是這種用法屬於誤用。模態框的視窗描述了 UI 的一部分。如果一個元素阻擋了使用者與應用的其它部分的互動，這個元素就是模態的。

簡單總結就是：

當這個模態框被開啟後，當前的所有程序都被阻斷了，直到這個模態框關閉。

基於上述的定義，歸納模態框常見的型別可以有以下幾種：

注意

：這些型別不代表只屬於模態，也可以以非模態形式存在。

07 對話方塊 Dialog

第一次接觸“Dialog”這個詞還是在《互動設計精髓》中，書中給了很明確的概念：

對話方塊以對話的方式讓使用者參與進來，在對話方塊中它給出訊息或要求輸入。

對話方塊又可以分為模態（Modal）和非模態（Modeless）兩種型別。

模態框在前面已經描述過了，與之相反的就是非模態：當非模態對話方塊被開啟後，使用者可以執行其他事情。

關於為什麼要使用模態對話方塊這種型別，簡單快速地可以使用這樣的決策原則：

有重要的資訊需要來阻斷當前的程序，希望使用者必須完成操作之後才能繼續往下進行。

08 模態對話方塊 Modal Dialog

這篇文章主要寫我們常用的模態對話方塊。

在《互動設計精髓》中，將模態對話方塊按照“目的導向”分為五種型別：

屬性（Property）

功能（Function）

進度（Process）

通知（Notification）

公告（Bulletin）

因為書中也沒有具體舉例，所以我接下來會按照這五種型別列舉在黑帕雲中的對話方塊示例。

1. 屬性對話方塊 Property Dialog

屬性對話方塊常見在一些設定、詳情中，比如電腦的系統設定、黑帕雲的小元件配置。

這個對話方塊通常由一些複雜的設定項構成。這種對話方塊適用於一些不太頻繁的操作。

2. 功能對話方塊 Function Dialog

功能對話方塊通常在選單或者某個具體的按鈕開啟，對話方塊中有一些對接下來這個功能事件的設定，這種對話方塊通常都會有一個［下一步］或者［確定］的主按鈕（Primary Boutton）用來確認設定、關閉對話方塊並且執行功能。

另外成對出現的還會有［取消］按鈕。

3. 進度對話方塊 Process Dialog

這種對話方塊向用戶表明正在忙於某些內部的功能，其他處理能力可能會降低。

在一些耗時較長的進度對話方塊中，還應該有以下資訊：

什麼事情在進行中

現在一切正常

最好能展示出現在還需要多久完成

現在進度是多少，可以用“完成百分比”或者“已完成數/總需要完成數”表示

取消程序的按鈕入口

上圖的例子中，macOS 軟體更新中的取消程序是在 hover 進度條時出現了“×”，代表可以取消下載。

黑帕雲中批次編輯由於耗時較短（通常情況下小於 10 秒），在使用者等待感知的範圍內，只需告知操作正在進行中，一切正常即可，無需提供詳盡的進度資訊。

4. 通知對話方塊 Notification Dialog

通知對話方塊是將一些重要的資訊彙報給使用者，來源可以是一些觸發的事件，也可以是其他使用者的通知。

常見的有通知中心對話方塊，處理完成某個操作的告知等等。

5. 公告對話方塊 Bulleting Dialog

公告對話方塊也是由程式自動啟動的。包含三種類型：錯誤、警告、確認。

這種對話方塊通常不會要求使用者填寫什麼，只會詢問你“真的要進行嗎？”或者告訴你一件事情。

所以在這種對話方塊上，一般只會有隻有［取消］和［確認］，或者［OK］。

這種對話方塊比較特殊，因為沒有一般對話方塊的 Header 和關閉按鈕。 的框架，他們把這種型別的對話方塊直接做成一種元件，命名為警告對話方塊（Alert）。

我之前犯的錯誤就是用這種對話方塊承載了一個功能性的操作對話方塊。

當時是在做“複製應用”這個功能，需要一個對話方塊來承載複製的應用時是否複製應用中的資料。可以理解為，複製一個文件時，只複製這個文件的目錄結構作為模板，還是連同文件內容一起復制。

當時不瞭解功能對話方塊和公告對話方塊的區別，所以直接用 Alert 元件這樣畫圖：

09 危險提示 Danger Alert

前面在設計原則中提到了“容錯處理”，在這一小節也詳細寫一寫曾經被教育過的經歷。

在很多破壞性的操作都會

二次進行提醒

，讓使用者確認操作，比如說刪除操作。在刪除之前都會詢問使用者“你真的要刪除嗎？”

想一想……你在看到這些提示的時候，是不是眼疾手快地按下那個［確認］按鈕？

在《互動設計精髓》中有一節把這樣的行為叫“大喊‘狼來了’的對話方塊”。

所以這種對話方塊在沒有容錯處理時，非常容易被我們這種無腦按［確認］的使用者釀成大錯。比如我手賤只是試試這個刪除，然後就把某個表幾千條辛苦寫了一個月的資料刪掉了。

所以，如果沒有撤回或者回收站之類的功能的話，我會非常崩潰……然後聯絡產品的客服人員找某個倒黴的運維大哥幫我在資料庫恢復資料。

你看容錯處理多重要，有效幫助運維大哥延年益壽。

如果產品本身已經具備了容錯能力，聽起來喊“狼來了”的危險提示似乎不是必要的？

是的。我們在 macOS 中刪除檔案時，沒有任何提示，直接被刪掉。在郵箱刪除郵件時，一樣沒有任何提示。

因為你知道可以在用 CMD+Z 進行撤回，也可以在回收站找到它們。

但是，如果產品還來不及做回收站或者撤回時，你不得不想點別的辦法讓刪除確認變得不那麼“狼來了”。

一個傻瓜但是有作用的辦法是讓刪除確認增加一點成本：

自從我們研發老哥哥花了 5 分鐘做了這個輸入驗證的功能之後，誤刪應用、誤刪業務表的使用者來找我們的次數直接斷崖式下降到了 0。

10 寫在最後

這個系列會寫的比較隨意，大概會按照我覺得哪些容易寫就會先寫。

在完結之後，再根據常見的結構再進行梳理。

下一篇不出意外的話會寫輸入和選擇控制元件（Entry&Selection Control），包含常見的文字輸入（Text Input）、選擇輸入（Select Input）、日期輸入（Date Input）、單選輸入（Radio Input）、多選輸入（CheckBox Input）、開關輸入（Switch Input）。

作者：高拉，微信公眾號：高拉

本文由 @高拉 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。