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

前言：整理文檔的過程中看到18年總結(jié)的一篇文章，這篇文章主要總結(jié)了在Web端后臺產(chǎn)品設(shè)計時輸出交互文檔應(yīng)該考慮的9個方面，雖然現(xiàn)在看來結(jié)構(gòu)簡單，考慮的覆蓋面也不全，但是在結(jié)構(gòu)上還是值得借鑒。

不想看長篇大論的可以跳到文末看結(jié)構(gòu)框架。

在交互設(shè)計上，規(guī)范的控件庫是“術(shù)”，達(dá)于術(shù)者，達(dá)下乘也，規(guī)范的控件庫是交互設(shè)計的技巧、是可以復(fù)用的技術(shù)；而統(tǒng)一的交互文檔指導(dǎo)方案是“法”，可以復(fù)以指導(dǎo)術(shù)之提高，達(dá)于法者，達(dá)中乘也；最后形成一套交互設(shè)計、用戶體驗、信息架構(gòu)的知識庫是“道”，達(dá)于道者，達(dá)上乘也。

從“術(shù)法道”而言，隨著業(yè)務(wù)需求的增加，即使有了規(guī)范的控件庫可以進(jìn)行復(fù)用，但在不同的場景下會有不同的交互規(guī)范。但交互文檔的結(jié)構(gòu)是可以提煉總結(jié)的，交互設(shè)計師可以時常對交互文檔結(jié)構(gòu)進(jìn)行歸納總結(jié)，以便在今后的工作中針對不同的適用場景根據(jù)結(jié)構(gòu)快速給出方案，將更多的時間用在業(yè)務(wù)邏輯和流程梳理上。

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

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

Part1：限制條件

1.1 是與否

是與否，非0即1，允許或不允許，比如：內(nèi)容的復(fù)制粘貼，分私密信息和非私密信息，私密信息不支持復(fù)制粘貼，常見的為密碼，非私密信息則支持用戶復(fù)制粘貼。

1.2 范圍值

指數(shù)值的取值范圍。如：列表頁展示多少數(shù)據(jù)記錄等。

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

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

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

1.3 極限值

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

分別舉兩個例子：

舉例一，在XX后臺管理系統(tǒng)表格中，單元格超過寬度即用“…”結(jié)尾，鼠標(biāo)懸浮顯示全文。

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

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

舉例二，在物料商城中，每個商品都有庫存數(shù)，那么前端購買最大商品數(shù)對應(yīng)的就是該商品的庫存數(shù)，按常識，商品最小購買量為1。

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

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

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

Part2：狀態(tài)

2.1 默認(rèn)狀態(tài)

默認(rèn)狀態(tài)顯示的列表、文案、選項等。

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

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

2.2 正常狀態(tài)

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

以XX后臺管理系統(tǒng)物料商城為例，商品背后有復(fù)雜的盤點庫存管理邏輯，商品盤點缺貨的話應(yīng)及時下架。

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

根據(jù)易用性原則“有效的反饋信息”，我們可以將下架的商品標(biāo)記為失效商品，與上架的商品作區(qū)分供用戶快速識別。

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

2.3 特殊狀態(tài)

特殊狀態(tài)往往在一些特殊場景下才出現(xiàn)的狀態(tài)，這種狀態(tài)有兩類：一是無數(shù)據(jù)情況（空白頁），二是數(shù)據(jù)異常情況，拆分?jǐn)?shù)據(jù)異常的情況，又可能包含：數(shù)據(jù)加載失敗、網(wǎng)絡(luò)錯誤、系統(tǒng)更新等狀態(tài)。

以XX后臺管理系統(tǒng)的物料商城為例，數(shù)據(jù)為空的情況有：在商城某分類商品列表無上架商品、我的購物訂單列表為空、我的購物車為空這3種。

圖5. 物料商城數(shù)據(jù)為空占位圖示意

對于特殊狀態(tài)，在同屬相同功能模塊下，可以用一套樣式風(fēng)格和文案風(fēng)格一致的占位圖進(jìn)行占位處理。

Part3：界面切換

界面切換分成兩塊，包含鏈接跳轉(zhuǎn)和彈窗。

3.1 鏈接跳轉(zhuǎn)

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

3.2?彈窗

XX后臺管理系統(tǒng)目前用到的內(nèi)容彈窗有兩種形式，一種是彈出到瀏覽器窗口中上位置，另外一種是以側(cè)滑的形式彈出。

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

Part4：信息校驗

4.1 正常操作

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

4.2 錯誤操作

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

結(jié)合4.1和4.2，XX后臺管理系統(tǒng)中表單校驗的處理方案如下所示，下表中，提示文案可以進(jìn)行重新調(diào)整，而校驗元素、與對應(yīng)的場景、是否提示、提示樣式則相對來說比較統(tǒng)一。

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

4.3 特殊操作

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

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

Part5：系統(tǒng)提示

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

5.1 toast提醒

toast提醒屬于弱提醒，3秒后自動消失，不影響用戶當(dāng)前的操作。

圖6. xx后臺管理系統(tǒng)全局toast提醒

5.2 提示對話框

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

圖7. xx后臺管理系統(tǒng)提示對話框

Part6：界面呈現(xiàn)

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

6.1 交互方式

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

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

6.2 對齊方式

列表中數(shù)據(jù)的對齊方式，主要視數(shù)據(jù)類型而定，XX后臺管理系統(tǒng)列表中常見的數(shù)據(jù)類型如下：

表2. 列表數(shù)據(jù)對齊

Part7：瀏覽器兼容

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

Part8：用戶角色

在后臺管理系統(tǒng)中，需要考慮的是不同角色對應(yīng)的權(quán)限與不同用戶角色的權(quán)限級別。

在業(yè)務(wù)處理流程中涉及多種角色，不同角色的使用權(quán)限不同，且同種角色在不同環(huán)節(jié)中所做的操作也不同，比如：在電子合同簽約流程中，銷售顧問在合同擬稿狀態(tài)過程中，可以對其進(jìn)行編輯和刪除處理；合同擬稿提交確認(rèn)過程中，銷售顧問可以查看合同或撤回提交；待合同確認(rèn)后，可以對合同發(fā)起簽約，而以上3個環(huán)節(jié)銷售助理只能進(jìn)行查看。

因此處于不同狀態(tài)的合同，同種角色對應(yīng)的操作是有區(qū)別的，處于同種狀態(tài)的合同，不同角色對應(yīng)的操作也是有區(qū)別的。

圖8. 電子合同列表不同狀態(tài)對應(yīng)操作示意圖（銷售顧問）

不同用戶角色的權(quán)限級別不同，例如某些功能按鈕，某些角色是“完全無權(quán)限”操作，沒有讓其知道有該功能的必要性，所以做隱藏處理比較合適。而某個角色具有“半權(quán)限”，那么對應(yīng)操作按鈕可以置灰處理，比如在業(yè)績管理-任務(wù)管理模塊中，數(shù)據(jù)運(yùn)營屬于擁有“一半的權(quán)限”，只有銷售運(yùn)營總監(jiān)為其開放了權(quán)限，他才能夠進(jìn)行任務(wù)調(diào)整。

所以這里對于數(shù)據(jù)運(yùn)營角色，任務(wù)修改按鈕是置灰處理的，并給予一定的提示告知用戶若要獲得權(quán)限的后續(xù)操作如何，如下圖所示。

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

Part9：數(shù)據(jù)埋點

C端的產(chǎn)品，產(chǎn)品上線后需要對用戶的行為進(jìn)行統(tǒng)計分析，往往會進(jìn)行數(shù)據(jù)埋點，這里不詳細(xì)展開。

結(jié)構(gòu)框架

作者：辛小仲；一名正在成長的交互設(shè)計師，公眾號：辛小仲。

本文由 @辛小仲 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議