對於如何設計一款學習成本低、辨識度高、有個性的APP，iOS和安卓均給出了對應的建議，就是《iOS設計規範》和《安卓設計規範》。規範中對導航、手勢、通知、控制項等方面都做了描述，並給出了相應的建議和檢查清單。

實際工作中，當然並不是一定要按照規範中描述進行APP設計，然而依然可以使用上述規範作為我們設計的參照，以期盡量避免一些明顯的問題。

在通篇仔細閱讀了兩份設計規範之後，基於兩個平台的用戶一致性的體驗、以及節省UI設計和研發成本的考量，求同存異，整理了一份適用於兩個平台APP的規範，以供參考

1 寫在開始之前

用戶的使用場景決定了他們需要什麼，我們的產品目標決定了我們做什麼以滿足用戶的需要。

在決定做什麼的過程中，建議遵循二八原則，即聚焦於80%的用戶會需要什麼。大部分的人不需要的話，就暫時別管了。

在設計APP之前，做什麼就應該經過和相關干係人反覆討論並達成一致的。而做什麼，決定了我們如何設計APP。

2 導航

目前常見的導航有這麼幾類：標籤式、抽屜式、九宮格。

標籤式的好處和壞處：

好處1—清楚當前所在的入口位置；

好處2—輕鬆在各入口跳轉而不會迷失方向；

好處3—直接展示最重要入口的內容信息；

壞處1—功能入口過多時，該模式顯得笨重而不實用。

抽屜式的好處和壞處：

好處1—節省屏幕空間，讓導航隱藏在策劃抽屜里，釋放了更多空間給主要內容；

好處2—提供了在非頂級視圖間切換的能力；

壞處1—可見性差；

壞處2—並非一看即知的，低效；

壞處3—和某些平台的固有設計模式衝突。

九宮格式的好處和壞處：

好處1—清晰展現各入口；

好處2—容易記住各入口位置，方便容易找到；

壞處1—無法在各入口之間靈活跳轉，不適合多任務操作；

壞處2—容易形成更深的路徑；

壞處3—無法直接顯示入口內容；

壞處4—不能顯示太多入口次級內容。

當然，更多的是採用兩兩、甚至多個混搭的方式處理的。

標籤式的代表：微信；

標籤式+抽屜式的代表：QQ；

標籤式+九宮格的代表：支付寶。

先想清楚應用需要展示什麼內容，然後再選擇合適的導航。

3 首頁

你的典型用戶會用它做什麼，那就在首頁展示什麼。

4 交互

4.1 手勢

對於標準手勢本身，用戶已經被操作系統教育，並知曉如何使用如下圖所示：

我們所做的，更多的是不和標準手勢衝突，包含以下方面：

1. 不要為標準手勢賦予不同的行為；

2. 不要創建和標準手勢類似的手勢動作；

3. 可以用複雜手勢作為完成某些複雜任務的方式，但避免稱為唯一的觸達方式。這樣用戶可以專註於內容，而不是手勢本身；

4. 除非是遊戲，避免定義新的手勢；

5. 特定環境下可以使用多指操作，這是因為非標準手勢可用性差，盡量少用，且不要用這種方式作為完成任務的唯一方式。

4.2 如何暗示交互

對於如何暗示交互，蘋果給出了自己的建議：

1. 使用線索暗示交互，例如，使用顏色、位置、上下文、表意明確的圖標和標籤；

2. 關鍵的顏色；

3. 在內容區域，有必要給按鈕添加邊界或者背景

5 輸入

輸入要儘可能的簡單。可以選用的方式包括以下幾種：

1. 盡量從其他方式（內置應用、或硬體設置）獲取用戶信息，而不是要求用戶自行輸入；

2. 讓用戶更容易的進行選擇，而不是彈出鍵盤；

3. 提供有用的反饋來平衡用戶的輸入。

6 控制項

在APP的設計中，我們需要儘可能的以內容為核心，然而，在必要時，我們仍然需要使用各種樣式的控制項。了解各種控制項的作用，也就成了我們選擇控制項時的依據。

控制項主要分為這麼幾類：

1. 標籤選項卡——滾動標籤、固定標籤；

2. 列表——區域分割、單條或多條展示；

3. 網格列表；

4. 滾動容器——類似於通訊錄的樣式；

5. 下拉菜單——展示離散型的單項數據；

6. 按鈕——僅包含圖標的按鈕不需要使用背景色，如果一定要選擇帶有背景色的按鈕，請仔細斟酌。因為這種按鈕看起來比較沉重，一個屏幕上最好就放一到兩個。它們比較適合以下情況:

1) 用戶一定需要使用的操作 (例如:註冊)。

2) 非常重要的操作 (例如: 接受/拒絕)。

3) 對用戶有很大影響的操作 (例如:清除所有數據、立即購買)。

7. 文本框——多行和單行模式；

8. 滑塊——類似於音量之類的；

9. 進度條和活動指示器——下載進度條和轉圈圈表示正在處理；

10. 開關——複選框、單選按鈕、開關；

11. 對話框——有交互的、僅起到提示作用的toasts;

12. 選擇器——空間的考慮，類似於日期和時間的選擇。

7 術語和措辭

簡短

1. 只告知用戶最必要的信息。
2. 避免冗餘的表述。
3. 儘可能的縮短文本長度。

簡明

1. 使用短詞語、行為動詞和簡單名詞。
2. 先說重要的事。一句話的開頭兩個詞 (一共大約 11 個字母，包括空格) 應當表達出重要的信息。
3. 僅說明必要的信息。不要費力解釋細枝末節。大部分用戶不關心那些。

友好

1. 使用縮寫。
2. 使用第二人稱和用戶對話 (「您」或「你」)。
3. 保持隨意、輕鬆的腔調，但避免使用俚語。

標點符號

1. 句號:如果toast、標籤或通知消息等控制項中只包含一句話，無需使用句號作為結尾。如果包含兩句或更多，則每一句都需以句號結尾。
2. 省略號:使用 省略號 (…) 表示以下含義:

1) 未完成的狀態, 例如表示操作進行中 (「下載中...」)或是表示文本未能完全顯示。

2) 菜單中需要進一步 UI 操作的條目 (例如 列印… or分享…) 。例外: 如果該條目的描述文字中已經對進一步的操作進行了一定的描述則無需添加省略號, 例如 頁面內查找 或 選定日期。

其他

1. 保證術語是用戶能夠理解的；

2. 描述時間時應注意準確性；

3. 盡量少使用全大寫的辭彙；

4. 可以描述BUG的修復情況

8 確認和提示

有些情況下，對於用戶在應用中的操作，給出文字性的確認或提示會比較好。

確認和提示的案例如下：

確認是確保用戶的確想要做出指定的操作。有些情況下，確認是以警告或者重要信息對話框的形式出現的，用戶需要考慮再做出選擇。

提示通過顯示一些文字來告訴用戶剛才的操作完成了。這樣做可以避免後台操作帶來的不確定性。有些情況下，提示可以提供一個撤銷操作的選項。

使用確認和提示，可以避免用戶做出讓自己後悔的舉動，增強用戶操作的確定性。

那麼，對於是否有必要給出確認或者提示，建議使用下面的判斷邏輯指引你的設計：

9 設置

我們需要盡量避免讓用戶過多設置。那麼，如何判斷一個選項作為設置項是否合適呢？可以通過下面的方式進行判定。

一般的設置頁面，會包含下述類型的設置項：

1. 複選框

只有選中或者沒選中兩種選項可以設置；

2. 單項選擇

給了用戶一些離散的選擇，但同時只能選擇一項；

3. 滑塊

讓用戶在連續的值中間選一個；

4. 日期/時間

讓用戶選擇一個日期/時間的設置；

5. 子屏幕

進入一個更複雜的子屏幕，例如選擇頭像時進入的子屏幕——若只有一個子屏幕，應沿用進入該子屏幕按鈕同樣的標題；若進入的只是嚮導的第一頁，則使用第一步的名稱作為標題更合適；

6. 列表子屏幕

列出一個包含等價條目列表的一個設置類別，主標題展示名稱，副標題展示狀態，與該列表相關的按鈕展示在操作欄中；

7. 主開關

用來控制整個設置類別的開關，主開關應作為第一個條目展示在子屏幕的操作欄上——關閉主開關，條目列表消失，所有需要打開開關才能進行的操作全部展示為禁用狀態；

8. 獨立開關

當開關需要更詳細的描述，而不僅僅是一個開關的時候，使用獨立開關。點擊後進入詳細描述頁，並在該頁面進行操作。

9. 相互依賴

一個設置的可用狀態依賴於另一個設置的值。將設置放置在其依賴的設置下邊，並給出簡要的提示；若有多個設置依賴於同一個設置項，則使用子屏幕可能是更好的選擇。

配置默認值時需要仔細考慮，可遵循如下原則：

· 如果沒有默認值，用戶最傾向於選擇哪個值？

· 哪個值是中性的？

· 哪個值最沒有風險，最沒有爭議，最不過分？

· 哪個值消耗最少的電量和最少的數據流量？

10 幫助

10.1 謹慎使用新手引導

好的應用不需要新手引導~

如果一定要用的話，請注意一下幾個方面：

1. 只提供開始使用應用所必需的信息；

2. 使用交互動畫來吸引用戶，並讓用戶通過實際上手來學會如何使用；

3. 能夠簡單的取消、或跳過新手引導。

10.2 幫助

一般可以把「幫助」放在更多操作中，建議放在菜單的最下面，使其最容易被觸達。

對於幫助頁的展示樣式，有如下建議：

1、 假設用戶的每次請求都是緊急的，在用戶觸摸幫助時，不要彈出一堆選項讓用戶選擇

2、 在應用中設計一個幫助視圖，將其他選項隱藏在操作欄中。

對於幫助內容的撰寫，可以參照如下規則：

1、幫助是應用UI的擴展，而不是對UI的描述。無論是應用還是幫助，文案應參照術語和措辭中的指導，一以貫之。

2、僅展示重要的信息；

3、圖片比文字更容易理解——在描述關鍵UI或提供一步步指導時，請結合文字和圖標還有帶標註的截圖等，以便於用戶更快理解；

4、用戶可能更多的是瀏覽而不是閱讀，請在排版上更加友好，使用大字體的表格、列表、表格和留白。如有很多內容要顯示，請分隔成多個屏幕，讓用戶滾動瀏覽；

5、直接提供答案——比瀏覽更簡單的就是直接提供答案，可以考慮在每個可以導航到幫助的屏幕中，只展示和進入屏幕相關的信息（即所謂上下文幫助）

11 其他

不要太早讓用戶評價你的應用，最好在你的應用成功的幫助用戶完成某個任務或事情的時候再引導用戶評價；

一般建議按照屏幕默認的方向去啟動你的應用，遊戲類或視頻類可以有另外的考慮；

準備一張和應用首頁一樣的閃屏頁，會讓應用啟動的速度顯得快一點；

如果可能，不要讓用戶在初次啟動時閱讀免責聲明或同意用戶協議；

注意隨時保持用戶的輸入狀態以及應用的狀態，讓用戶在中斷後重新進入APP時可以繼續使用。

這份規範，一方面可以作為設計的參考，另一方面作為已成型APP的自檢清單。

相信能讀到這裡的你，會有所收穫~