我習(xí)慣從層級的角度由高至低地排查各個(gè)交互層面可能存在的問題——首先是信息架構(gòu)與流程這一最高層級，然后是界面的具體呈現(xiàn)，以及基于界面呈現(xiàn)的交互過程，最后才是以上自查中均未涵括的其他特殊情形。

交互設(shè)計(jì)自查，是設(shè)計(jì)師完成一個(gè)項(xiàng)目的交互稿后，在提交給團(tuán)隊(duì)內(nèi)部、外部或者客戶進(jìn)行評審前非常重要的一個(gè)查漏補(bǔ)缺的環(huán)節(jié)。及時(shí)自己發(fā)現(xiàn)手誤、考慮細(xì)節(jié)不完善之處、異常狀態(tài)的遺漏，不但避免了Review時(shí)的尷尬場面，也有利于設(shè)計(jì)師自己形成更為縝密的思考方式，在往后經(jīng)手的其他項(xiàng)目中，能在設(shè)計(jì)之中就有意識(shí)地融入這些思考，從而讓自己的設(shè)計(jì)質(zhì)量得到快速的提高。但交互設(shè)計(jì)自查應(yīng)該從哪些角度入手，怎樣才算一次比較全面和完整的自查？我想這是很多朋友關(guān)心的，也是我們每個(gè)人都在孜孜不倦地去探索和積累的。

那么作為今年工作小結(jié)的第三篇，就通過本文和大家一起聊一聊這個(gè)問題。

在今年所做的公司項(xiàng)目、獨(dú)立承接的項(xiàng)目以及一些個(gè)人構(gòu)思的概念性設(shè)計(jì)項(xiàng)目中，我逐漸積累形成了一份自己比較熟悉的交互設(shè)計(jì)自查表。這一過程中也參考過很多同行、前輩們的相關(guān)經(jīng)驗(yàn)，例如網(wǎng)易UEDC飛靈的《如何建立交互設(shè)計(jì)自查表》、阿里鴻影的《交互設(shè)計(jì)方案衡量標(biāo)準(zhǔn)的五層總結(jié)》等等。

但關(guān)于自查的角度仍然是眾說紛紜、沒有形成太多公認(rèn)的定論，有的偏重全面的異常流程處理，有的偏重UI細(xì)節(jié)的斟酌，有的則更關(guān)注平臺(tái)、設(shè)備方面可能出現(xiàn)的問題，畢竟交互設(shè)計(jì)本身就是一個(gè)交叉性很強(qiáng)的位置，上有產(chǎn)品級別的模塊設(shè)置，下有UI級別的元素樣式位置，內(nèi)有組件的交互規(guī)范，外有多平臺(tái)多機(jī)型的適配，在不同層面可能遇到的問題太多、太雜。而每個(gè)人在不同團(tuán)隊(duì)中所接觸的項(xiàng)目特點(diǎn)不同，對自查中最常出現(xiàn)問題的類型也可能不同，即使是資深設(shè)計(jì)師也很難說能考慮周全所有的自查點(diǎn)。舉個(gè)自己的例子，可能因?yàn)槟壳八鲞^的項(xiàng)目幾乎都是要么iOS要么安卓的單平臺(tái)應(yīng)用，同時(shí)也很少涉及橫屏場景，所以本著做過的項(xiàng)目才有發(fā)言權(quán)的原則，我自己整理的這份自查表中不涉及多平臺(tái)和屏幕方向切換引起的問題。當(dāng)然，也希望隨著自己接觸的項(xiàng)目類型越來越廣，也能在這些方面有所思考和積淀。

這樣的困惑也讓我意識(shí)到了作為交互設(shè)計(jì)師，建立一套適合自己的交互設(shè)計(jì)自查表的重要性。其實(shí)，雖然叫做自查表，呈現(xiàn)的方式也是一份checklist，但更重要的并不是這個(gè)表格本身，而是自查時(shí)的思路和角度。只有思路清晰、角度能遵循一定的步驟，才能避免東打一棒西打一耙，做到心里有數(shù)，至少在能意識(shí)到的問題上避免遺漏。而自查表的編制也不是一蹴而就的過程，結(jié)合自己在項(xiàng)目踩坑的經(jīng)驗(yàn)不斷補(bǔ)充新的自查點(diǎn)，才能形成較為完善的自查邏輯。下圖是我現(xiàn)在工作中習(xí)慣使用的自查表：

個(gè)人覺得，無論把自查表定義成一份任務(wù)走查腳本、一份異常情形匯總，還是一份交互和UI細(xì)節(jié)的檢查清單，都不完全合理。在自查階段如果設(shè)計(jì)師嚴(yán)格按測試階段的步驟，逐個(gè)流程任務(wù)進(jìn)行走查會(huì)耗費(fèi)大量的時(shí)間。而無論是異常情形，還是主流程中的易錯(cuò)點(diǎn)，都是自查中不可忽視的一部分，單純以其中一者為主總會(huì)不可避免地出現(xiàn)遺漏。因此，我更習(xí)慣從層級的角度由高至低地排查各個(gè)交互層面可能存在的問題——首先是信息架構(gòu)與流程這一最高層級，然后是界面的具體呈現(xiàn)，以及基于界面呈現(xiàn)的交互過程，最后才是以上自查中均未涵括的其他特殊情形。

下面，我將以最近在做的一個(gè)實(shí)際項(xiàng)目——一家中小型工程公司的工程項(xiàng)目管理平臺(tái)APP為例（查看項(xiàng)目介紹，查看完整交互稿），逐一通過實(shí)例介紹各個(gè)層級的共計(jì)33個(gè)自查點(diǎn)，和大家一起看看在同一個(gè)項(xiàng)目中如何由上到下逐級地進(jìn)行自查。很高興這次分享得到了用戶的允許，界面中涉及的數(shù)據(jù)和名稱均為化名。不過由于案例的范圍限于同一個(gè)項(xiàng)目內(nèi)，可能有部分自查點(diǎn)的案例并不是同類問題里最有代表性的，但只要熟悉了這些自查思路，在看到或者設(shè)計(jì)其他項(xiàng)目類似的例子時(shí)，能夠觸類旁通就好。

第一部分 信息架構(gòu)與流程

1. 信息架構(gòu)

1.1 信息架構(gòu)是否容易理解

整體的信息架構(gòu)、導(dǎo)航、模塊入口的設(shè)計(jì)，是否符合用戶既定的使用習(xí)慣和理解？

項(xiàng)目案例：雖然在信息架構(gòu)設(shè)計(jì)階段，我們已經(jīng)通過卡片分類法初步選取并驗(yàn)證了符合用戶心智模型的名稱，但在交互設(shè)計(jì)的初步方案完成后，自查中首先應(yīng)當(dāng)注意的仍然是這些最上層的信息架構(gòu)設(shè)計(jì)，是否符合用戶既定的使用習(xí)慣和理解，必要時(shí)可以拿輸出的頁面找朋友或同事幫忙進(jìn)行一些非常簡短的測試，看看是否存在這方面的問題。

APP的一級頁面使用了iOS用戶最為熟悉的底Bar標(biāo)簽導(dǎo)航結(jié)構(gòu)，4個(gè)標(biāo)簽頁的名稱和對應(yīng)功能都符合用戶使用其他產(chǎn)品時(shí)培養(yǎng)出的既定習(xí)慣：“開始”提供最重要的信息提醒和模塊的快捷入口，“消息”收納了各類的通知和待辦提醒，“項(xiàng)目”作為核心模塊提供項(xiàng)目管理的入口，“我”則是在各類應(yīng)用中都已為用戶所熟知的個(gè)人頁面，提供用戶個(gè)人的資料、統(tǒng)計(jì)和設(shè)置等輔助功能。在自查和測試中這些方面都表現(xiàn)很好，沒有出現(xiàn)問題，但在“開始”頁8個(gè)模塊入口和“我”頁面的4個(gè)快捷入口上，在自查中還是發(fā)現(xiàn)了一些問題。下面舉兩個(gè)例子，因?yàn)樯婕耙恍┖茈y一言兩語講清楚的需求背景，如果覺得理解起來有困難的朋友可以略過。

例如，”發(fā)送通知“原先名為”發(fā)送消息“，這可能會(huì)導(dǎo)致部分用戶據(jù)此認(rèn)為這是一個(gè)雙向的、類似聊天的功能（如微信、QQ），而實(shí)際上，根據(jù)客戶的需求，這只是一個(gè)單向信息傳遞的功能（更類似于郵件），因此自查后將其改為”發(fā)送通知“，更符合用戶對這兩個(gè)詞的認(rèn)知。

再比如，”我“頁面中的一個(gè)便捷入口”我的請購“原先名為”我的采購“，該便捷入口的功能定義是直達(dá)該用戶發(fā)起的采購申請，而“我的采購”會(huì)讓用戶誤認(rèn)為這是采購人員查看自己經(jīng)手的采購申請的入口，改為“我的請購”后則有效解決了這一理解問題。

1.2 信息層級是否清晰

信息區(qū)域間的層級關(guān)系、元素控件間的關(guān)系是否符合親密性、對比性和重復(fù)性等設(shè)計(jì)原則，能否正確地體現(xiàn)與頁面信息架構(gòu)相符的邏輯關(guān)系？

項(xiàng)目案例：在項(xiàng)目管理模塊的項(xiàng)目人員架構(gòu)調(diào)整頁面中，項(xiàng)目頭圖（包括項(xiàng)目號、項(xiàng)目名稱、所在地、地圖背景）是在項(xiàng)目頁面中貫穿始終的全局性元素，層級較高，與下方的人員列表之間通過間距這一簡單的方式體現(xiàn)了層級的不同。而人員列表中，有邏輯聯(lián)系的元素（同專業(yè)的人員）和無邏輯聯(lián)系的元素（項(xiàng)目經(jīng)理、工藝、電氣等不同專業(yè)之間）的設(shè)計(jì)也符合了親密性、對比性、重復(fù)性等原則的要求，頭像列表方式避免了大量人員信息的過載和混亂。但也不是沒有問題——原先”專業(yè)負(fù)責(zé)人“和”設(shè)計(jì)人“字樣使用了同樣的灰色，沒有體現(xiàn)出兩類角色之間的差別，將”專業(yè)負(fù)責(zé)人“字段改為紅色后每個(gè)專業(yè)負(fù)責(zé)人和普通設(shè)計(jì)人的配備更加清晰和一目了然。

1.3 信息分類是否合理

對龐雜信息進(jìn)行組織、篩選、歸類時(shí)，有沒有遵循用戶熟悉的分類標(biāo)準(zhǔn)？對企業(yè)應(yīng)用來說，分類有沒有符合企業(yè)內(nèi)部習(xí)慣和行業(yè)慣例？

項(xiàng)目案例：

本項(xiàng)目作為一個(gè)面向化工設(shè)備制造企業(yè)的管理應(yīng)用，信息的分類和用語自然要貼合行業(yè)人員熟悉的習(xí)慣。例如，人員的分類上，工程部內(nèi)部的人員按照行業(yè)習(xí)慣，根據(jù)項(xiàng)目經(jīng)理和工藝、電氣、儀表、設(shè)備等不同專業(yè)進(jìn)行分類（見1.2附圖，此處不再贅述），而公司層面的通訊錄模塊中，二級導(dǎo)航則按照客戶的部門架構(gòu)進(jìn)行劃分。任務(wù)進(jìn)度頁面的篩選控件也需要注意這點(diǎn)，例如”專業(yè)“分為工藝/電氣/儀表/設(shè)備共4種，”階段“則按客戶企業(yè)的項(xiàng)目運(yùn)營流程分為投標(biāo)（方案）/設(shè)計(jì)/采購/安裝/調(diào)試/驗(yàn)收共6種，”狀態(tài)“則同樣根據(jù)客戶熟悉的標(biāo)準(zhǔn)分為進(jìn)行中/延期中/已完成共3種。自查中注意再根據(jù)與客戶確認(rèn)過的需求仔細(xì)篩查一遍，避免想當(dāng)然地采用了不符合用戶實(shí)際使用習(xí)慣的分類。

1.4 信息視覺流是否流暢

視覺流是否存在反復(fù)和繞行現(xiàn)象？同一任務(wù)內(nèi)的主要操作和閱讀區(qū)域應(yīng)盡量確保視覺流流暢。

項(xiàng)目案例：各個(gè)管理模塊的進(jìn)度頁面中，如果當(dāng)前用戶是當(dāng)前流程的執(zhí)行人，則頁面上需要有一個(gè)”執(zhí)行“控件，讓當(dāng)前用戶去執(zhí)行下一步操作。例如在采購流程的發(fā)票確認(rèn)階段，如果當(dāng)前用戶是采購人，則采購人需要通過”執(zhí)行“控件去進(jìn)行驗(yàn)收成果的確認(rèn)（或拒絕）。而在設(shè)計(jì)這個(gè)控件的位置時(shí)，原本為了遵循充分利用導(dǎo)航欄空間的原則，自然會(huì)想到把它放在導(dǎo)航欄右端作為文字按鈕，這在普通的頁面中并無不妥，但在這個(gè)頁面中，采購人員的閱讀順序是：

(1)確定當(dāng)前階段 → (2)閱讀設(shè)備、數(shù)量、所屬項(xiàng)目、請購人員、發(fā)起時(shí)間等基本信息 → (3)確定自己在本流程中的身份（因?yàn)椴糠謭鼍跋?，?dāng)前用戶的身份可能有多種可能性，需要用戶再做確認(rèn)）→ (4)在列表區(qū)閱讀此前的流程歷史，必要時(shí)可上下滑動(dòng)或點(diǎn)擊查看附件 → (5)確定當(dāng)前步驟等待自己完成的是什么任務(wù) → (6)執(zhí)行該任務(wù)。

而在1~5步中，閱讀順序幾乎是嚴(yán)格由上而下的，并且用戶會(huì)在閱讀過程中認(rèn)真地確認(rèn)各項(xiàng)信息，也就是閱讀的專注程度比較高。那么第6步的”執(zhí)行“控件如果放在右上角，雖然簡化了頁面的元素、節(jié)省了空間，但會(huì)造成視覺流的大折返。

所以，在最終交付的版本中，我將”執(zhí)行“按鈕設(shè)置在了頁面底部，并且始終處于流程歷史列表的上方，從而確保了不打斷用戶在專注閱讀過程中的視覺流。

2. 流程設(shè)計(jì)

2.1 用戶體驗(yàn)路徑是否一致

在具有相似度的任務(wù)中，用戶體驗(yàn)路徑的設(shè)計(jì)是否清晰，并具有一致性？具有相似度的任務(wù)是指雖然在具體步驟和任務(wù)目標(biāo)上有所差別，但流程上有較大部分是類似或共通的流程。

例如，C端產(chǎn)品中非常常見的3類密碼重設(shè)流程——因忘記密碼需要重置密碼、因賬號被盜需要重設(shè)密碼、以及用戶主動(dòng)希望修改密碼，就很大程度上存在相似度，那么這3類流程在用戶體驗(yàn)路徑上，在共通部分就需要保持一致性。

B端產(chǎn)品中這類情況則更為普遍，例如下面的例子中要講到的審批流程。這些具有相似度的流程在設(shè)計(jì)時(shí)要注意共通部分的一致性，其中包括流程節(jié)點(diǎn)本身的一致性，以及流程涉及的呈現(xiàn)元素（頁面、信息和控件）的一致性，簡而言之，不能在A流程中是這樣、在B流程中又是那樣。

項(xiàng)目案例：本項(xiàng)目中共有3個(gè)涉及逐級審批的流程——采購流程、報(bào)賬流程和工資核算流程，具體的需求背景和設(shè)計(jì)細(xì)節(jié)就不在這里展開講了。簡而言之，3個(gè)流程的具體步驟和執(zhí)行角色等細(xì)節(jié)自然是迥然相異的，但當(dāng)這些步驟分解到最小元素時(shí)，可以發(fā)現(xiàn)有很多：

1. 共通的流程節(jié)點(diǎn)：都由發(fā)起、審核（確認(rèn)或拒絕）、信息提交（含上傳附件）、關(guān)閉、完成這些節(jié)點(diǎn)構(gòu)成，只是節(jié)點(diǎn)的順序、數(shù)目、對應(yīng)角色和需要執(zhí)行的具體操作不同。
2. 共通的呈現(xiàn)元素（頁面、信息和控件）：都包括流程歷史記錄列表、詳情頁、確認(rèn)表單、拒絕表單、流程關(guān)閉表單、附件上傳控件、執(zhí)行按鈕等元素。

那么，這些具有相似度的共通部分在設(shè)計(jì)時(shí)，要盡量采用完全相同的節(jié)點(diǎn)和呈現(xiàn)元素去實(shí)現(xiàn)，確保體驗(yàn)路徑一致。不要讓用戶在采購流程中看到的是一個(gè)樣子，在報(bào)賬流程對應(yīng)的頁面又看到的是另一個(gè)樣子。

2.2 返回和出口是否符合用戶預(yù)期

正常來講，任何流程都應(yīng)當(dāng)允許用戶返回上一步，以及快速（或至少在較少、步驟內(nèi)）退出當(dāng)前流程，而返回和取消操作的跳轉(zhuǎn)目的應(yīng)當(dāng)符合用戶期望，讓用戶返回其認(rèn)為最合理的位置。

項(xiàng)目案例：現(xiàn)場圖庫模塊的上傳現(xiàn)場照片流程中，用戶可能希望直接退出照片流程，也可能只是希望返回上一步重新選擇要上傳的照片。

2.3 逆向流程的設(shè)計(jì)是否考慮周全

這里的逆向主要指業(yè)務(wù)邏輯上，而不是2.2中簡單的返回、退出操作。正向流程比較容易理解，例如電商應(yīng)用中的“查看商品→填寫收貨信息→下單→付款”，或者企業(yè)管理應(yīng)用中的逐級審批，都是典型的正向流程。而實(shí)際上逆向流程也同樣不可忽視，同樣用剛才的例子，電商應(yīng)用中的取消訂單，企業(yè)管理應(yīng)用中審核人員打回一個(gè)申請、使審批流程返回上一步甚至關(guān)閉這個(gè)流程，都是在實(shí)際使用場景中普遍存在的逆向流程。一般來說，呈現(xiàn)在流程圖上都是正向的流程，正因?yàn)榇耍嫦蛄鞒滩鸥枰圆橐员苊膺z漏。

項(xiàng)目案例：采購管理模塊中，采購流程中各階段的執(zhí)行人可以拒絕確認(rèn)上一階段的結(jié)果，將流程打回上一步。對這類逆向流程的反饋形式，我在交互說明中指定了被“打回”的流程記錄的顯示形式。

2.4 跳轉(zhuǎn)名稱與目的是否一致

檢查每個(gè)跳轉(zhuǎn)入口的鏈接名稱與目的頁面名稱之間的一致性。

項(xiàng)目案例：確認(rèn)一遍每個(gè)可能因?yàn)楫嫺遄訒r(shí)想當(dāng)然導(dǎo)致不一致的鏈接名稱，例如不要出現(xiàn)鏈接是”個(gè)人資料“、而跳轉(zhuǎn)到的頁面標(biāo)題是”修改資料“的情況。

2.5 是否充分考慮了操作的容錯(cuò)性

2.5.1 危險(xiǎn)操作的二次確認(rèn)

在刪除、返回和取消（進(jìn)行大量表單輸入后）等危險(xiǎn)操作執(zhí)行時(shí)，是否為用戶提供了二次確認(rèn)的機(jī)會(huì)？
項(xiàng)目案例：添加供應(yīng)商時(shí)，當(dāng)用戶有填寫信息的情況下（視為可能進(jìn)行了大量的輸入），”返回“操作就是一個(gè)危險(xiǎn)操作，因此在進(jìn)行返回時(shí)需要彈出Alert窗口（標(biāo)題”放棄添加？“、副標(biāo)題：”將放棄已填寫的供應(yīng)商信息“、以及”確認(rèn)“、”取消“兩個(gè)按鈕）讓用戶進(jìn)行二次確認(rèn)。二次確認(rèn)框的標(biāo)題和副標(biāo)題文案、按鈕文字，以及確認(rèn)后的返回去向，都在交互說明中進(jìn)行了闡述。

2.5.2 提供必要的撤銷功能

執(zhí)行一個(gè)操作后是否允許用戶撤銷？

項(xiàng)目案例：采購流程、報(bào)賬流程、工資核算流程中，在任意一步，流程的發(fā)起人如果發(fā)現(xiàn)自己提請的信息有誤，都可以通過全局性存在的”關(guān)閉“按鈕撤銷其發(fā)起的流程。

2.5.3 操作失敗的解釋與建議

在操作失敗后是否提供了必要的解釋或其他可行的建議？

項(xiàng)目案例：新建項(xiàng)目流程中的第2步是在地圖中對項(xiàng)目所在地進(jìn)行定位，而當(dāng)定位位置讀取結(jié)果出現(xiàn)異常時(shí)，可以通過toast對定位失敗進(jìn)行解釋，并建議用戶檢查網(wǎng)絡(luò)及GPS設(shè)置。交互文檔中可以在交互說明中寫明toast的文案。

需要強(qiáng)調(diào)的是，這里只是建議大家在自查中確認(rèn)這幾個(gè)問題。而不是說一定要在全部流程中強(qiáng)行加入容錯(cuò)性的考量，無論是二次確認(rèn)、撤銷還是操作失敗提示，都要視情況而定是否有必要：

• 過多不必要的二次確認(rèn)會(huì)大大降低體驗(yàn)的流暢性
• 所有操作都可撤銷會(huì)讓后臺(tái)數(shù)據(jù)交互和消息推送的負(fù)荷都極大地增加，即使是必要的撤銷也可以放在后臺(tái)、并不一定要作為移動(dòng)端的功能
• 在用戶熟知如何處理的、顯而易見的操作失敗后，給予過于詳細(xì)的提示會(huì)讓用戶產(chǎn)生被當(dāng)成傻子的感覺

對第三點(diǎn)，插一句現(xiàn)實(shí)生活中的例子。在麥當(dāng)勞用自助點(diǎn)餐機(jī)點(diǎn)餐時(shí)，被工作人員用關(guān)愛的眼神緊緊盯著是一個(gè)挺不舒服的體驗(yàn)（和同事朋友聊過后發(fā)現(xiàn)自己不是一個(gè)人），生怕自己一個(gè)操作慢了工作人員就急切地伸手過來指指點(diǎn)點(diǎn)。其實(shí)我們都明白，在自助點(diǎn)餐機(jī)旁配備工作人員是一番好意也是絕對必要的，快餐店面對的用戶群體是龐大的，即使讓熟悉觸屏硬件操作、掃碼支付的年輕人產(chǎn)生這樣不愉快的體驗(yàn)，也要力保不熟悉這些操作的用戶能及時(shí)獲得足夠的協(xié)助去迅速完成點(diǎn)餐流程。這實(shí)際上就是新手用戶和中高級用戶的問題，在目標(biāo)用戶群體較為確定的產(chǎn)品設(shè)計(jì)中，我們可沒有麥當(dāng)勞這樣“用戶群體龐大而不確定”的借口，“沒有人愿意永遠(yuǎn)當(dāng)個(gè)新手，新手和專家隨著時(shí)間推移都會(huì)傾向于成為中級用戶。因此應(yīng)當(dāng)為中級用戶而優(yōu)化設(shè)計(jì)。新手一旦成為中級用戶，額外幫助會(huì)反過來妨礙用戶”。因此，我們要做的不是永遠(yuǎn)把用戶當(dāng)新手，去提供我們自以為詳盡而貼心的提示，而是站在中級用戶的立場，仔細(xì)衡量每個(gè)場景下失敗提示是否必要。

第二部分 界面呈現(xiàn)

3. 控件呈現(xiàn)

這里自查的范圍主要是與交互體驗(yàn)關(guān)系最緊密的控件，但實(shí)際上在自查過程中可以同時(shí)檢查非操作性的普通頁面元素（圖片、icon、信息列表、分隔元素等），沒有必要分兩遍來檢查。不過為了敘述方便本節(jié)還是簡稱為控件為主。

3.1 控件是否符合用戶認(rèn)知

控件的選用和設(shè)計(jì)是否合理、符合用戶成型的認(rèn)知習(xí)慣。合理包括形狀、文字、用色、尺寸、位置、分組等方面。舉極端點(diǎn)的小例子，“拒絕”按鈕設(shè)計(jì)成綠色而“確認(rèn)”按鈕設(shè)計(jì)成紅色、復(fù)選項(xiàng)用圓形而單選項(xiàng)用方形、過于口語化的控件文字、位置過于隱蔽、分組不符合用戶習(xí)慣等等，都是不合理的例子。這點(diǎn)相信熟悉平臺(tái)規(guī)范和業(yè)務(wù)背景的設(shè)計(jì)師都不會(huì)輕易犯這么明顯錯(cuò)誤，只是有時(shí)改稿很倉促時(shí)有可能會(huì)隨手留下一些類似的小問題，在自查中還是要過一遍以防這些低級錯(cuò)誤貽笑大方。

而實(shí)際上，控件不符合認(rèn)知的情況更多來源于設(shè)計(jì)師有意為之的盲目創(chuàng)新。這里還是建議，在交互習(xí)慣已經(jīng)逐漸沉淀的今天，在產(chǎn)品本身不需要在界面上標(biāo)新立異的情況下盡量采用通用的組件。

項(xiàng)目案例：設(shè)計(jì)管理模塊中，項(xiàng)目的文件庫是一個(gè)控件比較密集的界面，二級Tab欄、上傳按鈕、下載按鈕、右滑調(diào)出的更新和刪除按鈕，都能較好地符合用戶的認(rèn)知，功能點(diǎn)具有顯而易見性。其中，更新按鈕的icon設(shè)計(jì)原本是用了一個(gè)類似于“刷新”的圖標(biāo)，但經(jīng)過仔細(xì)考慮，在工程行業(yè)設(shè)計(jì)文件管理的場景下，文件“更新”的本質(zhì)應(yīng)該是重新上傳、覆蓋原有文件，而不是與字面更為相近的“刷新”，因此最終修改為與上傳的含義更為接近的icon，更加符合用戶的理解。

3.2 控件樣式是否具有一致性

即使是再細(xì)心的設(shè)計(jì)師，先后畫的兩個(gè)button也很難保證完全一致，因此充分通過組件化，在不斷的復(fù)用中積淀自己的一套常用組件庫是非常必要的。導(dǎo)航欄、底Bar、信息Cell（包括Cell的標(biāo)題或尾注）、圖片輪播或泳道等等，都可以通過組件化保證在同一產(chǎn)品中的呈現(xiàn)是完全一致的，后續(xù)即使有修改也可以統(tǒng)一修改、統(tǒng)籌優(yōu)化。這樣在后續(xù)視覺設(shè)計(jì)階段中同樣可以大大降低標(biāo)注的工作量。還是那句話，設(shè)計(jì)規(guī)范形成得越早，后期效率就越高，所以個(gè)人更習(xí)慣在交互設(shè)計(jì)階段就進(jìn)行組件化的工作，而不是留到視覺設(shè)計(jì)階段才進(jìn)行。

項(xiàng)目案例：消息模塊的消息列表中，根據(jù)消息的類別不同，標(biāo)簽顏色共設(shè)計(jì)了藍(lán)、黃、灰、紅四種（根據(jù)客戶的需求，現(xiàn)階段的版本中實(shí)際上只用到了紅色和藍(lán)色兩種），紅色代表待辦類，藍(lán)色代表通知類。消息列表項(xiàng)可以通過組件化，在整個(gè)項(xiàng)目的設(shè)計(jì)中格式保持完全一致，有需要修改時(shí)，也可以統(tǒng)一修改和優(yōu)化。

3.3 控件交互行為是否具有一致性

相同控件的操作反饋也要相同，簡單地說，長得一樣的控件操作起來也是一樣的。交互行為的一致性和樣式的一致性是相形而生的。對外要符合整個(gè)平臺(tái)的產(chǎn)品設(shè)計(jì)規(guī)范，對內(nèi)要與同一產(chǎn)品內(nèi)”兄弟姐妹“們的行為一致，這樣才能更好地降低交互模式的學(xué)習(xí)成本。

項(xiàng)目案例：整個(gè)項(xiàng)目中涉及上傳的操作有很多，上傳設(shè)計(jì)文件、上傳報(bào)價(jià)單、上傳合同等，對所有涉及上傳的操作控件，交互行為也應(yīng)該統(tǒng)一進(jìn)行設(shè)計(jì)，以保證一致性。在交互文檔的通用交互說明中，有專門的一張交互稿用于規(guī)定全平臺(tái)中的文件上傳、更新、下載操作的交互反饋。

3.4 控件的不可用狀態(tài)如何呈現(xiàn)

控件常常需要一定的條件觸發(fā)才變得可用，例如表單頁中只有在必要信息全部填寫得符合要求的情況下，”提交“按鈕才可用。那么，在不可用時(shí)，是直接將控件顯示為不可用，還是在點(diǎn)擊后提供反饋提示用戶需要完成哪些條件才可用？兩者各有優(yōu)缺點(diǎn)，前者讓行動(dòng)點(diǎn)的不可用狀態(tài)外化，讓用戶直觀地理解自己的狀態(tài)，但假如用戶不熟悉當(dāng)前場景，會(huì)難以知道是缺了哪些條件導(dǎo)致不可用；后者在點(diǎn)擊后可以通過toast清晰地告知用戶需要哪些條件才能觸發(fā)可用，但這需要增多一步點(diǎn)擊操作。因此，兩者都是可行的做法，但無論采用哪種做法，都需要在交互說明中寫明，前者需要寫明可用條件，后者需要寫明toast的提示文案。

項(xiàng)目案例：發(fā)起工資核算流程中，填報(bào)工資構(gòu)成的界面有兩處涉及不可用狀態(tài)的地方，“下一步”按鈕僅當(dāng)全部金額信息填寫后可用，“導(dǎo)入上月數(shù)據(jù)”按鈕僅當(dāng)該員工存在上個(gè)月工資數(shù)據(jù)時(shí)可用，在交互說明中對這兩個(gè)控件的可用條件以及不可用時(shí)的樣式（30%透明度淡顯）進(jìn)行了明確的規(guī)定。

4. 數(shù)據(jù)呈現(xiàn)

4.1 空態(tài)如何呈現(xiàn)

空態(tài)是設(shè)計(jì)中必須考慮，卻又容易疏漏的點(diǎn)。不但數(shù)據(jù)完全空缺時(shí)會(huì)產(chǎn)生空態(tài)，在所有涉及篩選控件的數(shù)據(jù)列表中，都有可能因?yàn)楹Y選的結(jié)果為空產(chǎn)生空態(tài)。

項(xiàng)目案例：在全局交互說明中，有專門的一節(jié)“14.4 空狀態(tài)”用于規(guī)定可能涉及空態(tài)的頁面的空態(tài)顯示。

4.2 字?jǐn)?shù)有限制時(shí)超限如何處理

表單對字?jǐn)?shù)有限制時(shí)，超限時(shí)是直接自動(dòng)刪除超出部分，還是保留超出部分但通過合理的反饋提示用戶刪減，或其他更巧妙的反饋手段。無論選用哪種，都需要在交互說明中寫明處理方式。

項(xiàng)目案例：項(xiàng)目關(guān)閉原因的多行文本輸入框字?jǐn)?shù)限制為200字，在交互說明中將其超限的處理方式確定為“自動(dòng)刪除”。

4.3 無法完整顯示的數(shù)據(jù)如何處理

移動(dòng)端界面的寬度有限，數(shù)據(jù)量較大、無法在指定行數(shù)內(nèi)完整顯示的情況很多，尤其在未對字?jǐn)?shù)進(jìn)行限制的情況下。那么此時(shí)是截?cái)嗖⒂谩薄碧崾疚达@示完全，還是讓信息塊的高度與內(nèi)容自適應(yīng)、多行顯示，或者其他方法？一般而言，如果有另一個(gè)頁面可供用戶查看完整的信息時(shí)，可以使用前者，從而讓頁面更規(guī)整也更簡潔；而對唯一性的顯示，或者這已經(jīng)是信息顯示最完整的頁面了的話，顯然必須全部顯示以保證信息的完整性。同樣的，無論采用哪種處理方式，都要在交互說明中讓視覺設(shè)計(jì)和開發(fā)同學(xué)清楚你的想法。

項(xiàng)目案例：供應(yīng)商名錄模塊中，供應(yīng)商列表中會(huì)顯示供應(yīng)商名稱和供貨范圍，而供貨范圍由用戶按需要任意填寫，可能很短也可能非常長。而由于在詳情頁中可以（也必須）讓用戶查看完整的信息，列表頁中為了避免視覺上的混亂，可以采用“…”在行末截?cái)?。而這些要求需要在交互說明中寫明，一種簡單的做法是默認(rèn)在行末用“…”截?cái)啵枰嘈酗@示完整信息時(shí)特別指出即可，畢竟后者只占少數(shù)。

4.4 數(shù)據(jù)過期如何提示用戶

來自網(wǎng)絡(luò)的數(shù)據(jù)過期時(shí)如何友好地提示用戶？

這點(diǎn)在無論C端還是B端應(yīng)用中的收藏功能中比較集中，例如C端電商應(yīng)用中，用戶收藏的商品已下架，或者用戶正在查看的活動(dòng)已過期的情況，音樂應(yīng)用中用戶已收藏的音樂下架的情況等等。B端應(yīng)用也有類似的設(shè)備、隱患點(diǎn)、現(xiàn)場圖片之類信息的收藏功能，如果用戶收藏的信息對象已失效（例如被上傳者或管理員刪除），在用戶通過收藏頁訪問時(shí)該如何提示？

先舉個(gè)我們都很熟悉的例子，在用戶體驗(yàn)方面的口碑有目共睹的網(wǎng)易云音樂，唯獨(dú)在歌曲因版權(quán)問題下架的處理上，采用了沒有任何提示、直接從用戶的收藏列表里悄無聲息地刪除的做法（最近我沒有收藏的歌曲出現(xiàn)下架的情況，不太清楚后續(xù)版本中有沒有改掉這一點(diǎn)，這里的吐槽只針對當(dāng)時(shí)的版本）。這導(dǎo)致用戶經(jīng)常都在歌單里找了半天才發(fā)現(xiàn)某首歌消失了。在版權(quán)越來越受重視的時(shí)代，曲庫版權(quán)的規(guī)范化是用戶都能理解的，但對歌曲下架的處理，個(gè)人覺得完全有更合適的方式，例如仍然將其保留在用戶的收藏列表中，并以一個(gè)特殊的樣式呈現(xiàn)，雙擊時(shí)彈出toast提示用戶”該歌曲已因版權(quán)問題下架“。所以，直到現(xiàn)在我也不知道云音樂這樣做是出于怎樣的考慮。

項(xiàng)目案例：項(xiàng)目現(xiàn)場圖庫中，用戶可以將自己經(jīng)常查看的照片加入“我的收藏”，而根據(jù)客戶的需求，項(xiàng)目圖庫只是方便員工進(jìn)行現(xiàn)場圖片的暫存和分享，并不是一個(gè)權(quán)限級別非常高的資源庫，因此，基本上項(xiàng)目成員都有權(quán)限在現(xiàn)場圖庫中刪除認(rèn)為沒有用的照片。而如果A用戶收藏的照片被B用戶刪除時(shí)，在列表中將如何顯示？點(diǎn)擊后又如何處理？這些都是要在交互說明中明確的方案。

4.5 數(shù)據(jù)按什么規(guī)則排序

涉及數(shù)據(jù)排序的列表，無論有沒有可以調(diào)整排序方式的控件，都要在交互說明中注明默認(rèn)的排序方式。這點(diǎn)還是比較容易漏的，畫原型時(shí)可能只是隨意設(shè)置了一些虛擬的數(shù)據(jù)，不會(huì)太考慮它們的排序方式，而這恰恰是開發(fā)同學(xué)最關(guān)心的問題之一。

項(xiàng)目案例：設(shè)計(jì)文件庫中的文件列表，按更新時(shí)間倒序排列，未上傳文件排在最上方，有多個(gè)未上傳文件時(shí)按文件名倒序排列。

4.6 數(shù)值是否要按特定的格式的顯示

數(shù)值的展示和輸入，都需要確定的呈現(xiàn)格式，小數(shù)可能需要確定的位數(shù)，大數(shù)值可能需要每隔千位用逗號分隔，這些同樣是需要在交互說明中體現(xiàn)的。
項(xiàng)目案例：工資核算流程中，確認(rèn)工資信息的信息列表中，所有金額都采用兩位小數(shù)格式顯示。

4.7 數(shù)據(jù)是否存在極值

涉及數(shù)值（或日期等）輸入和選擇的控件，有沒有設(shè)置極值以幫助用戶防錯(cuò)？如果有，在輸入值超過極值時(shí)如何提示用戶？

項(xiàng)目案例：新建任務(wù)時(shí)，”開始時(shí)間“和”計(jì)劃結(jié)束時(shí)間“選擇器都有相應(yīng)的極值限制，允許范圍以外的日期不可選：”開始時(shí)間“只有今天后的日期可選，”計(jì)劃結(jié)束時(shí)間“只有開始時(shí)間后的日期可選。

5. 文案呈現(xiàn)

5.1 句式是否一致

相似場景中，頁面標(biāo)題和頁面標(biāo)題之間的句式結(jié)構(gòu)要保持一致，文案與文案之間的句式結(jié)構(gòu)也要保持一致，總之，相應(yīng)位置的文字句式要始終一致。

項(xiàng)目案例：所有流程的成功提示頁中，頁面標(biāo)題都是“動(dòng)詞+對象”（標(biāo)題為動(dòng)詞、動(dòng)詞短語也是iOS設(shè)計(jì)規(guī)范建議的方式），而主提示語都是“賓語+動(dòng)詞+成功”的句式。避免有時(shí)因?yàn)椤昂孟襁@樣讀起來更順一點(diǎn)”就寫成了“賓語+成功+動(dòng)詞”（如：采購流程成功關(guān)閉）或者其他句式，哪種句式更好是語文問題，這里不做探討，我們要做的只是保持一致。

5.2 用詞是否一致、準(zhǔn)確

操作、稱謂、反饋中的用詞同樣要保持一致，并且應(yīng)當(dāng)在準(zhǔn)確、不引起歧義的基礎(chǔ)上盡可能簡練。

項(xiàng)目案例：涉及表單提交的操作都用“提交”而不是混用”確定“、”確認(rèn)“，涉及新建的操作都稱為“新建”而不是混用“創(chuàng)建”、“添加”，涉及對當(dāng)前用戶的稱謂都用“您”而不是混用“你”，涉及成功提示的反饋都用”成功“而不是混用”完成“、“結(jié)束”，諸如此類的細(xì)節(jié)往往是反映一個(gè)設(shè)計(jì)師是否足夠?qū)I(yè)和細(xì)心的重要指標(biāo)之一。

5.3 文案是否有溫度感

文案需要讓用戶感覺到產(chǎn)品的溫度，對C端應(yīng)用而言很好理解。而即使是B端應(yīng)用，在必要的場景下，文案內(nèi)容也應(yīng)當(dāng)在不影響表達(dá)的準(zhǔn)確性和效率的前提下，避免冰冷的機(jī)械感，應(yīng)結(jié)合場景和用戶角色融入恰當(dāng)?shù)那楦小?/p>

項(xiàng)目案例：在一個(gè)項(xiàng)目各專業(yè)驗(yàn)收完成，項(xiàng)目經(jīng)理執(zhí)行“完成項(xiàng)目”操作時(shí)，附言提供了具有溫度感的默認(rèn)文案，相比冷冰冰的“本項(xiàng)目已全部完成”，即使收到通知的員工知道這是系統(tǒng)提供的默認(rèn)文案，也多少會(huì)心頭一暖吧。

6. 輸入與選擇

6.1 是否為用戶提供了默認(rèn)值

是否為選擇控件提供了默認(rèn)項(xiàng)？輸入框內(nèi)容為空時(shí)如何顯示？輸入框獲得焦點(diǎn)時(shí)，默認(rèn)文字是消失（即僅作為提示文字或占位符）還是保留（即作為可編輯的默認(rèn)文案）？

項(xiàng)目案例：這一點(diǎn)其實(shí)在前面一些例子里已經(jīng)提到過了，像5.3節(jié)案例中提到的默認(rèn)文案。這里還是用4.7節(jié)里講過的“新建任務(wù)”頁面的例子吧，因?yàn)榇_實(shí)比較典型。項(xiàng)目經(jīng)理在項(xiàng)目中新建一個(gè)階段任務(wù)時(shí)，需要選擇專業(yè)、階段、開始時(shí)間、計(jì)劃結(jié)束時(shí)間，并填寫任務(wù)描述，如果不提供默認(rèn)值的話，創(chuàng)建多個(gè)專業(yè)的多個(gè)任務(wù)對項(xiàng)目經(jīng)理是一件非常繁重的工作。因此，設(shè)計(jì)中為每項(xiàng)都考慮了默認(rèn)值。

其中，有一部分是用戶可能可以直接使用的，例如“階段”的默認(rèn)值為當(dāng)前最新進(jìn)度的下一階段，“任務(wù)描述”的默認(rèn)值是“階段+（專業(yè)）”的字段組合，“開始時(shí)間“的默認(rèn)值為今天。

有一部分是便于用戶的選擇，例如“計(jì)劃結(jié)束時(shí)間”的默認(rèn)值等于“開始時(shí)間”，雖然用戶肯定要重新選擇一次，但基于“開始時(shí)間”點(diǎn)去選擇一段時(shí)間（比如半個(gè)月）后的日期，至少比基于一個(gè)“1900年1月1日”之類的點(diǎn)去選擇要方便很多。

而還有一部分是無從預(yù)計(jì)默認(rèn)值的，這不代表可以隨便用一個(gè)選項(xiàng)作為默認(rèn)值，而必須提供一個(gè)“未選擇”選項(xiàng)，例如“專業(yè)”，如果很隨意地默認(rèn)“工藝”為默認(rèn)值的話，用戶很容易稍一疏忽就提交了一個(gè)專業(yè)隸屬錯(cuò)誤的任務(wù)，而默認(rèn)項(xiàng)為“未選擇”，則可以讓“提交”按鈕在這一情況下不可用，從而起到防錯(cuò)的作用。

6.2 輸入過程是否提供提示和判斷

是否在輸入過程中為用戶提供提示？是否執(zhí)行輸入判斷，是在輸入過程中執(zhí)行、失焦后執(zhí)行還是提交后執(zhí)行？經(jīng)判斷輸入不符要求時(shí)如何提示？

項(xiàng)目案例：“忘記密碼”流程中要求用戶輸入自己用于登錄的手機(jī)號，這里對手機(jī)號格式的判斷就是一個(gè)典型“提交后執(zhí)行”的處理。無論采用哪種方式，都要在交互說明中寫清楚。

6.3 是否存在不必要的輸入

是否存在以下不必要、甚至?xí)疬壿嬪e(cuò)誤的輸入（這里的輸入包括鍵盤輸入和選擇等多種輸入形式）：

（1）如果某個(gè)數(shù)據(jù)是對應(yīng)整個(gè)流程全局的，那么在這個(gè)流程內(nèi)部，顯然這個(gè)數(shù)據(jù)不需要再重復(fù)輸入，每多一次輸入就多一次錯(cuò)誤的可能。

項(xiàng)目案例：按照客戶公司的設(shè)計(jì)文件編號規(guī)定，完整編號的格式是”項(xiàng)目號（6位數(shù)字/字母）-專業(yè)縮寫（2個(gè)字母）-文件類型縮寫（2個(gè)字母）-流水號（4位數(shù)字）“。在新建或編輯設(shè)計(jì)文件目錄時(shí)，需要輸入文件編號，此時(shí)如果要求用戶輸入完整的編號，不但增加了大量的重復(fù)輸入操作，還容易填錯(cuò)?？紤]到這點(diǎn)，輸入時(shí)鎖定了項(xiàng)目號和專業(yè)縮寫兩個(gè)字段，用戶只要根據(jù)自己要上傳的文件具體是什么，填寫文件類型縮寫和流水號即可。這樣不但避免了重復(fù)輸入，也確保了至少不會(huì)出現(xiàn)項(xiàng)目號和專業(yè)錯(cuò)漏的現(xiàn)象。

（2）A和B兩個(gè)數(shù)據(jù)成對存在時(shí)，顯然也不應(yīng)該允許同時(shí)允許輸入A和B。這個(gè)比較容易理解，比如商品單價(jià)和總價(jià)、項(xiàng)目名稱和項(xiàng)目號、部門和部門負(fù)責(zé)人之間都是成對的關(guān)系，允許同時(shí)輸入兩者不但不必要也不合理。但要注意的是，設(shè)計(jì)師不要按照自己的生活經(jīng)驗(yàn)想當(dāng)然地判斷這種邏輯聯(lián)系，例如上面的商品單價(jià)和總價(jià)，在某種情況下并沒有直接的邏輯關(guān)聯(lián)，下面要舉的也是一個(gè)這樣的反例（正面的例子很容易理解，就不贅述了）。

項(xiàng)目案例：初版方案中，因?yàn)檎堎忞A段已經(jīng)指定了設(shè)備數(shù)量，那么自然地會(huì)想到單價(jià)和總價(jià)應(yīng)該是關(guān)聯(lián)的一對數(shù)據(jù)，在輸入單價(jià)后，總價(jià)應(yīng)該是自動(dòng)輸出的只讀數(shù)據(jù)，不應(yīng)當(dāng)允許重復(fù)輸入總價(jià)。但在自查中，結(jié)合自己在設(shè)計(jì)院工作的經(jīng)驗(yàn)，我忽然意識(shí)到這里有問題，設(shè)備采購中的單價(jià)和總價(jià)確切地說是“設(shè)備單價(jià)”和“合同總價(jià)”，兩者之間的關(guān)系并不是乘一個(gè)數(shù)量那么簡單，而應(yīng)該是”合同總價(jià)=設(shè)備單價(jià)×數(shù)量+其他費(fèi)用“，其他費(fèi)用可能包括配件價(jià)格、稅費(fèi)等五花八門的類目。而設(shè)備的單價(jià)和整個(gè)合同的總價(jià)對客戶來說都是重要的信息，因此在此兩個(gè)數(shù)據(jù)都應(yīng)該是允許輸入的。因此，自查后，將總價(jià)由一個(gè)只讀的cell改成了一個(gè)數(shù)值輸入框。

6.4 是否指定了鍵盤類型和鍵盤引起的頁面滾動(dòng)

當(dāng)需要通過鍵盤進(jìn)入輸入時(shí)，需要在交互稿中標(biāo)注調(diào)出鍵盤的布局類型。否則，開發(fā)同學(xué)如果將所有未標(biāo)注的鍵盤都寫成了默認(rèn)鍵盤，會(huì)讓用戶不得不手動(dòng)切換鍵盤類型、大大影響用戶的輸入體驗(yàn)。以iOS鍵盤為例，常用的主要是以下11種：

• 默認(rèn)鍵盤（UIKeyboardTypeDefault）：用于文本輸入
• 密碼鍵盤（UIKeyboardTypeASCIICapable）：用于密碼輸入
• URL鍵盤（UIKeyboardTypeURL）：用于網(wǎng)址輸入
• 郵箱鍵盤（UIKeyboardTypeEmailAddress）：用于Email輸入
• 數(shù)字鍵盤（UIKeyboardTypeNumberPad）：只有數(shù)字的數(shù)字鍵盤
• 數(shù)字符號鍵盤（UIKeyboardTypeNumbersAndPunctuation）：數(shù)字符號鍵盤，用于數(shù)字符號（主鍵盤）和字母（次鍵盤）同時(shí)輸入的情況
• 電話鍵盤（UIKeyboardTypePhonePad）：用于電話撥號的數(shù)字鍵盤（比數(shù)字鍵盤在左下角多了”+*#”鍵）
• 文本數(shù)字鍵盤（UIKeyboardTypeNamePhonePad）：用于文本（主鍵盤）和數(shù)字（次鍵盤）同時(shí)輸入的情況
• 小數(shù)鍵盤（UIKeyboardTypeDecimalPad）：比數(shù)字鍵盤多一個(gè)“.”，用于需要輸入小數(shù)的情況
• 推特鍵盤（UIKeyboardTypeTwitter）：用于發(fā)布推文，右下角是一個(gè)“#”號，便于插入標(biāo)簽
• 搜索鍵盤（UIKeyboardTypeWebSearch）：用于網(wǎng)頁搜索
  此外，如果鍵盤調(diào)出后會(huì)引起屏幕滾動(dòng)（為保證部分重要控件或信息可見），也要在交互說明中注明。

項(xiàng)目案例：登錄頁的手機(jī)號碼和密碼輸入框，分別調(diào)出的應(yīng)該是默認(rèn)鍵盤和密碼鍵盤，同時(shí)，輸入框獲得焦點(diǎn)、調(diào)出鍵盤后，頁面相應(yīng)地向上滾動(dòng)相應(yīng)的高度，以保證輸入框、登錄按鈕、“忘記密碼”鏈接可見。這些都需要在交互說明中向開發(fā)同學(xué)注明。

第三部分 過程與特殊情形

7. 交互過程與反饋

7.1 是否周全地考慮了所有操作成功的反饋

操作成功后如何跳轉(zhuǎn)？如何提示用戶？通過toast還是設(shè)置專門的成功提示頁？

項(xiàng)目案例：本項(xiàng)目中按照情景不同，兩種反饋方式都有采用。

（1）對流程較短、重要性級別較低、信息量較小的操作，不設(shè)置專門的成功提示頁，直接在頁面頂部彈出非模態(tài)的toast進(jìn)行反饋。交互文檔中，在通用交互說明的章節(jié)指定了toast（成功型）的顯示方式，而在正文部分，需要對操作成功進(jìn)行反饋時(shí)，只要寫明反饋文案即可。

（2）反過來，對流程較長、重要性級別較高、信息量較大的操作，則設(shè)置了專門的成功提示頁，并在全部的成功提示頁設(shè)置返回開始頁的按鈕，方便用戶快速退出流程并進(jìn)行其他操作。

7.2 是否周全地考慮了所有操作失敗的反饋

因網(wǎng)絡(luò)環(huán)境差、無網(wǎng)、后臺(tái)故障等原因?qū)е虏僮魇r(shí)如何提示用戶？跳轉(zhuǎn)至專門的失敗提示頁，還是阻斷跳轉(zhuǎn)、停留在當(dāng)前頁面并通過toast提示？

項(xiàng)目案例：本項(xiàng)目中對異常流程全部采用非模態(tài)的toast進(jìn)行反饋，和操作成功的反饋一樣，交互文檔中在通用交互說明的章節(jié)指定了toast（失敗型）的顯示方式，而在正文部分，需要對操作成功進(jìn)行反饋時(shí)，只要寫明反饋文案即可。

7.3 操作過程中是否允許取消

表單提交過程中是否允許取消？文件上傳、下載過程中是否允許取消操作？

項(xiàng)目案例：項(xiàng)目中對表單提交過程不允許取消，而在文件上傳、更新（重上傳）、下載過程中，則在進(jìn)度提示控件中提供了取消按鈕，允許用戶中斷正在進(jìn)行的操作過程。允許取消時(shí)，應(yīng)該在交互稿中體現(xiàn)出取消后的反饋或者跳轉(zhuǎn)。

7.4 是否設(shè)計(jì)了必要且合理的動(dòng)效

是否有必要添加動(dòng)效？載入時(shí)間是否適合添加這樣的動(dòng)效效果？如果長時(shí)間等待后操作失敗，如何提示用戶？

項(xiàng)目案例：這篇文章主要講交互自查，就不方便放動(dòng)效的具體案例了，因?yàn)榫唧w做起來會(huì)涉及比較多和開發(fā)的溝通。對本項(xiàng)目這樣一個(gè)B端的管理類應(yīng)用而言，常規(guī)的動(dòng)效庫足矣，除了信息列表的下拉刷新、頁面的載入等待、文件上傳下載的等待等場景外，基本上不需要額外的動(dòng)效設(shè)計(jì)。這種情況下，實(shí)際工作中，對動(dòng)效的考量和開發(fā)團(tuán)隊(duì)的組件積淀是有很大關(guān)系的。在這類項(xiàng)目的交互設(shè)計(jì)的自查階段，我們更多地需要做的是考慮需要?jiǎng)有У膱鼍埃o論你起初是不是這樣想，最后會(huì)發(fā)現(xiàn)，需要?jiǎng)有У牡胤酵ǔ６急饶阆胂蟮蒙伲?，以及?dòng)效的必要性和合理性。

8. 特殊情形

8.1 角色權(quán)限與狀態(tài)不同造成會(huì)造成哪些差異

對允許未登錄狀態(tài)使用部分功能的C端應(yīng)用而言，需要考慮的主要是游客狀態(tài)轉(zhuǎn)登錄狀態(tài)、登錄狀態(tài)轉(zhuǎn)游客狀態(tài)時(shí)，體驗(yàn)路徑中的差異。對B端應(yīng)用而言，需要分析的則主要是根據(jù)用戶在流程中的角色不同、根據(jù)用戶在公司內(nèi)的部門和職務(wù)不同、根據(jù)用戶在同一流程中的權(quán)限不同，會(huì)在任務(wù)流程、界面呈現(xiàn)（例如：部分控件和入口的顯示與否）文案等方面產(chǎn)生哪些區(qū)別。

項(xiàng)目案例：在2.5.2節(jié)的例子中我們講過，采購流程、報(bào)賬流程、工資核算流程中，在任意一步，流程的發(fā)起人如果發(fā)現(xiàn)自己提請的信息有誤，都可以通過全局性存在的”關(guān)閉“按鈕撤銷其發(fā)起的流程，而“關(guān)閉”按鈕顯然就是只對流程發(fā)起人顯示的。

另一個(gè)例子是關(guān)于文案的差異，根據(jù)流程所屬模塊不同、用戶在流程中所承擔(dān)的角色不同，流程各步驟發(fā)送的待辦事項(xiàng)或者通知的文案也有非常多種可能性。這時(shí)用例表就是交互文檔中一個(gè)非常直觀清晰的表達(dá)方式，例如本項(xiàng)目消息模塊的通知類就有23種不同的用例。

8.2 是否提供特殊模式

是否提供無圖模式、夜間模式、編輯模式，如果有的情況下，如何呈現(xiàn)？

項(xiàng)目案例：本項(xiàng)目沒有提供無圖模式和夜間模式，但在項(xiàng)目的人員架構(gòu)選擇、以及供應(yīng)商名錄的管理等功能中，都有瀏覽模式與編輯模式之分。兩種模式間控件方面的差異可能會(huì)比較大，最好是通過單獨(dú)的頁面繪制呈現(xiàn)出來。

原文鏈接：http://qinsman.com/1612_selfcheck/

案例項(xiàng)目介紹：http://qinsman.com/1612_epmp/

案例項(xiàng)目的完整交互稿：http://qinsman.com/resources/empm_iddoc.html

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