對一份優秀的交互文檔來說，都要具備什麼樣的基本框架與基礎要素呢？如果你沒有一個明確的答案，那麼本文將爲你提供詳實的解答。

前言：整理文檔的過程中看到18年總結的一篇文章，這篇文章主要總結了在Web端後臺產品設計時輸出交互文檔應該考慮的9個方面，雖然現在看來結構簡單，考慮的覆蓋面也不全，但是在結構上還是值得借鑑。

不想看長篇大論的可以跳到文末看結構框架。

在交互設計上，規範的控件庫是“術”，達於術者，達下乘也，規範的控件庫是交互設計的技巧、是可以複用的技術；而統一的交互文檔指導方案是“法”，可以復以指導術之提高，達於法者，達中乘也；最後形成一套交互設計、用戶體驗、信息架構的知識庫是“道”，達於道者，達上乘也。

從“術法道”而言，隨着業務需求的增加，即使有了規範的控件庫可以進行復用，但在不同的場景下會有不同的交互規範。但交互文檔的結構是可以提煉總結的，交互設計師可以時常對交互文檔結構進行歸納總結，以便在今後的工作中針對不同的適用場景根據結構快速給出方案，將更多的時間用在業務邏輯和流程梳理上。

本篇文章，以XX後臺管理系統爲例，結合自己的經驗來聊一聊我總結的交互方案。包含以下9部分，有：限制條件、狀態、頁面切換、信息校驗、系統提示、界面、瀏覽器兼容、用戶角色、數據埋點等。

在輸出交互說明文檔的過程中需要考慮以上部分，當然並不是一定要包含以上，要視具體的產品需求、功能模塊與規格大小來確定。

Part1：限制條件

1.1 是與否

1.2 範圍值

指數值的取值範圍。如：列表頁展示多少數據記錄等。

通常在後臺管理系統，數據列表統一是展示10條數據，可以翻頁查看更多，或者自行選擇每頁展示的數據量，有“10、20、50、100”供選擇。

而物料商城的商品列表展示，適配不同分辨率瀏覽器，讓用戶使用主流的筆記本、電腦在瀏覽器可視區域瀏覽商品時不出現視覺誤導（假如每頁最多顯示商品數30個，若每行顯示7個商品的話，存在多頁的情況下，商品行數爲4行過2個，有5個商品空缺位，這樣看起來會誤認爲數據加載有問題）。

我們最終確定的商品展示方案是：每頁列表最多展示60個商品，適配不同瀏覽器分辨率，自動調整爲每行顯示4、5或6個商品，分辨率越大，每行展示商品數遞增。

1.3 極限值

指數據的顯示極限。如：文字最多顯示多少字，顯示不下怎麼辦；數字輸入框是否有上下限等。

分別舉兩個例子：

舉例一，在XX後臺管理系統表格中，單元格超過寬度即用“…”結尾，鼠標懸浮顯示全文。

而在設計列表、卡片、面板、彈窗等承載內容的載體時，都要考慮到內容的承載極限，比如在物料商城卡片和購物車卡片，商品的說明內容有多有少，而內容區寬度是固定的，所以需要進行視覺展示上行數的顯示。

圖1. （左）商城商品卡片說明內容限定 （右）購物車卡片說明內容限定

舉例二，在物料商城中，每個商品都有庫存數，那麼前端購買最大商品數對應的就是該商品的庫存數，按常識，商品最小購買量爲1。

在交互設計上，根據商品購買數的極限值，當購買數爲庫存數的時候，“+”按鈕置灰，表示用戶無法再增加，購買數爲1的時候，“-”按鈕置灰，表示用戶無法再減少。

同時，若用戶輸入大於庫存的數字，都將被處理爲最大庫存數，同理，輸入小於1的數字，都將被處理爲1。在輸入數字類型的限制上，只允許用戶輸入整數。

圖2. 商品加入購物車數量極限值限定（左：極小值、右：極大值）

Part2：狀態

2.1 默認狀態

默認狀態顯示的列表、文案、選項等。

舉一個例子，XX後臺管理系統中很多模塊是純列表展示，要考慮默認展示的列表數據量是否影響加載速度，加載速度長意味着增加了用戶的等待時間成本，在這種情況下，可以採取“初次打開不加載，提示用戶點擊搜索按鈕後加載”的方案，避免等待時間過長。

圖3. 列表輸入查詢條件示意

2.2 正常狀態

用戶正常使用時，會遇到的狀態。比如：商品上架/下架，數據存在動態更新情況。

以XX後臺管理系統物料商城爲例，商品背後有複雜的盤點庫存管理邏輯，商品盤點缺貨的話應及時下架。

那麼存在一種場景，某商品在加入購物車之前是正常在架狀態的，加入購物車之後該商品已被下架了，若將下架的商品從購物車從移走隱藏，這種粗暴處理的結果就是用戶會產生疑惑，“我的商品怎麼從購物車丟失了？是不是剛剛我沒有加入購物車呢？”。

根據易用性原則“有效的反饋信息”，我們可以將下架的商品標記爲失效商品，與上架的商品作區分供用戶快速識別。

圖4. 商品加入購物車不同狀態示例（左：上架、右：下架）

2.3 特殊狀態

特殊狀態往往在一些特殊場景下才出現的狀態，這種狀態有兩類：一是無數據情況（空白頁），二是數據異常情況，拆分數據異常的情況，又可能包含：數據加載失敗、網絡錯誤、系統更新等狀態。

以XX後臺管理系統的物料商城爲例，數據爲空的情況有：在商城某分類商品列表無上架商品、我的購物訂單列表爲空、我的購物車爲空這3種。

圖5. 物料商城數據爲空佔位圖示意

對於特殊狀態，在同屬相同功能模塊下，可以用一套樣式風格和文案風格一致的佔位圖進行佔位處理。

Part3：界面切換

界面切換分成兩塊，包含鏈接跳轉和彈窗。

3.1 鏈接跳轉

鏈接跳轉要考慮跳轉到新頁面之後是在本窗口打開鏈接還是在新窗口打開鏈接，在本窗口打開，若只有一個層級，可以加上“返回”，若層級較深，而用戶又需要快速切換到之前的瀏覽界面，那麼可以考慮加上“麪包屑”。

3.2 彈窗

XX後臺管理系統目前用到的內容彈窗有兩種形式，一種是彈出到瀏覽器窗口中上位置，另外一種是以側滑的形式彈出。

彈窗/側滑彈窗可以根據不同的瀏覽器分辨率選用不同尺寸的彈窗，若界面內容較多（高度超過瀏覽器可視高度），那麼選中側滑彈窗爲佳，通過垂直滾動條查看更多內容。

Part4：信息校驗

4.1 正常操作

指正常情況下的操作。如：必填數據框獲取焦點時是否進行提示。

4.2 錯誤操作

用戶操作錯誤時需要給出正確的糾正反饋。比如：重複密碼輸入有誤。

結合4.1和4.2，XX後臺管理系統中表單校驗的處理方案如下所示，下表中，提示文案可以進行重新調整，而校驗元素、與對應的場景、是否提示、提示樣式則相對來說比較統一。

表1. 表單元素校驗場景說明

4.3 特殊操作

指極端情況下的操作。比如：用戶輸入特殊字符，某些特殊字符傳入後臺會產生錯誤，可能導致sql注入。

所以後臺需要考慮是否有應對措施（特殊字符轉義），而前端是否需要做清空處理與相應的反饋提示等。

Part5：系統提示

結合場景，選擇適用的提醒，另外需要考慮提示的文案是否足夠情感化。

5.1 toast提醒

toast提醒屬於弱提醒，3秒後自動消失，不影響用戶當前的操作。

圖6. xx後臺管理系統全局toast提醒

5.2 提示對話框

適用用戶需要做二次確認，容易誤操作的、需要用戶明確知悉提示的內容一定是需要二次確認的。

圖7. xx後臺管理系統提示對話框

Part6：界面呈現

主要考慮交互方式和對齊方式兩種。

6.1 交互方式

Web端的產品交互方式比較單一，常用的操作是懸浮、點擊和鍵盤切換等。而手機端的產品交互方式會豐富些，動作有點擊、按、長按、滑動等。

Web產品，一方面要考慮不同動作下，控件的樣式會進行怎樣的改變，另一方面考慮是否支持鍵盤快捷方式。比如說：Tab鍵是否支持換行，Enter鍵是否支持提交操作，按backspace/delete鍵清除，下拉選項中用“↑”是否支持上移選項，用“↓”是否支持下移選項等。

6.2 對齊方式

列表中數據的對齊方式，主要視數據類型而定，XX後臺管理系統列表中常見的數據類型如下：

表2. 列表數據對齊

Part7：瀏覽器兼容

在Part1範圍值中有提到商品列表每頁商品展示數要結合瀏覽器兼容一起考慮。另一方面，碰到功能優化時，要考慮是否存在新老版本的兼容問題。

Part8：用戶角色

在後臺管理系統中，需要考慮的是不同角色對應的權限與不同用戶角色的權限級別。

在業務處理流程中涉及多種角色，不同角色的使用權限不同，且同種角色在不同環節中所做的操作也不同，比如：在電子合同簽約流程中，銷售顧問在合同擬稿狀態過程中，可以對其進行編輯和刪除處理；合同擬稿提交確認過程中，銷售顧問可以查看合同或撤回提交；待合同確認後，可以對合同發起簽約，而以上3個環節銷售助理只能進行查看。

因此處於不同狀態的合同，同種角色對應的操作是有區別的，處於同種狀態的合同，不同角色對應的操作也是有區別的。

圖8. 電子合同列表不同狀態對應操作示意圖（銷售顧問）

不同用戶角色的權限級別不同，例如某些功能按鈕，某些角色是“完全無權限”操作，沒有讓其知道有該功能的必要性，所以做隱藏處理比較合適。而某個角色具有“半權限”，那麼對應操作按鈕可以置灰處理，比如在業績管理-任務管理模塊中，數據運營屬於擁有“一半的權限”，只有銷售運營總監爲其開放了權限，他才能夠進行任務調整。

所以這裏對於數據運營角色，任務修改按鈕是置灰處理的，並給予一定的提示告知用戶若要獲得權限的後續操作如何，如下圖所示。

圖9. 按鈕置灰處理示意圖

Part9：數據埋點

C端的產品，產品上線後需要對用戶的行爲進行統計分析，往往會進行數據埋點，這裏不詳細展開。

結構框架

本文由 @辛小仲 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議