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

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

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

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

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

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

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

Part1：限制條件

1.1 是與否

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

1.2 范圍值

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

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

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

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

1.3 極限值

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

分別舉兩個(gè)例子：

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

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

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

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

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

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

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

Part2：狀態(tài)

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

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

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

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

2.2 正常狀態(tài)

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

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

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

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

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

2.3 特殊狀態(tài)

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

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

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

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

Part3：界面切換

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

3.1 鏈接跳轉(zhuǎn)

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

3.2?彈窗

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

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

Part4：信息校驗(yàn)

4.1 正常操作

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

4.2 錯(cuò)誤操作

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

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

表1. 表單元素校驗(yàn)場(chǎng)景說(shuō)明

4.3 特殊操作

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

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

Part5：系統(tǒng)提示

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

5.1 toast提醒

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

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

5.2 提示對(duì)話框

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

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

Part6：界面呈現(xiàn)

主要考慮交互方式和對(duì)齊方式兩種。

6.1 交互方式

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

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

6.2 對(duì)齊方式

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

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

Part7：瀏覽器兼容

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

Part8：用戶角色

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

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

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

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

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

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

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

Part9：數(shù)據(jù)埋點(diǎn)

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

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

作者：辛小仲；一名正在成長(zhǎng)的交互設(shè)計(jì)師，公眾號(hào)：辛小仲。

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

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