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

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

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

在今年所做的公司項目、獨立承接的項目以及一些個人構思的概念性設計項目中，我逐漸積累形成了一份自己比較熟悉的交互設計自查表。這一過程中也參考過很多同行、前輩們的相關經驗，例如網易UEDC飛靈的《如何建立交互設計自查表》、阿里鴻影的《交互設計方案衡量標準的五層總結》等等。

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

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

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

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

第一部分 信息架構與流程

1. 信息架構

1.1 信息架構是否容易理解

整體的信息架構、導航、模塊入口的設計，是否符合用戶既定的使用習慣和理解？

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

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

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

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

1.2 信息層級是否清晰

信息區域間的層級關系、元素控件間的關系是否符合親密性、對比性和重復性等設計原則，能否正確地體現與頁面信息架構相符的邏輯關系？

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

1.3 信息分類是否合理

對龐雜信息進行組織、篩選、歸類時，有沒有遵循用戶熟悉的分類標準？對企業應用來說，分類有沒有符合企業內部習慣和行業慣例？

項目案例：

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

1.4 信息視覺流是否流暢

視覺流是否存在反復和繞行現象？同一任務內的主要操作和閱讀區域應盡量確保視覺流流暢。

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

(1)確定當前階段 → (2)閱讀設備、數量、所屬項目、請購人員、發起時間等基本信息 → (3)確定自己在本流程中的身份（因為部分場景下，當前用戶的身份可能有多種可能性，需要用戶再做確認）→ (4)在列表區閱讀此前的流程歷史，必要時可上下滑動或點擊查看附件 → (5)確定當前步驟等待自己完成的是什么任務 → (6)執行該任務。

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

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

2. 流程設計

2.1 用戶體驗路徑是否一致

在具有相似度的任務中，用戶體驗路徑的設計是否清晰，并具有一致性？具有相似度的任務是指雖然在具體步驟和任務目標上有所差別，但流程上有較大部分是類似或共通的流程。

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

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

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

1. 共通的流程節點：都由發起、審核（確認或拒絕）、信息提交（含上傳附件）、關閉、完成這些節點構成，只是節點的順序、數目、對應角色和需要執行的具體操作不同。
2. 共通的呈現元素（頁面、信息和控件）：都包括流程歷史記錄列表、詳情頁、確認表單、拒絕表單、流程關閉表單、附件上傳控件、執行按鈕等元素。

那么，這些具有相似度的共通部分在設計時，要盡量采用完全相同的節點和呈現元素去實現，確保體驗路徑一致。不要讓用戶在采購流程中看到的是一個樣子，在報賬流程對應的頁面又看到的是另一個樣子。

2.2 返回和出口是否符合用戶預期

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

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

2.3 逆向流程的設計是否考慮周全

這里的逆向主要指業務邏輯上，而不是2.2中簡單的返回、退出操作。正向流程比較容易理解，例如電商應用中的“查看商品→填寫收貨信息→下單→付款”，或者企業管理應用中的逐級審批，都是典型的正向流程。而實際上逆向流程也同樣不可忽視，同樣用剛才的例子，電商應用中的取消訂單，企業管理應用中審核人員打回一個申請、使審批流程返回上一步甚至關閉這個流程，都是在實際使用場景中普遍存在的逆向流程。一般來說，呈現在流程圖上都是正向的流程，正因為此，逆向流程才更需要自查以避免遺漏。

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

2.4 跳轉名稱與目的是否一致

檢查每個跳轉入口的鏈接名稱與目的頁面名稱之間的一致性。

項目案例：確認一遍每個可能因為畫稿子時想當然導致不一致的鏈接名稱，例如不要出現鏈接是”個人資料“、而跳轉到的頁面標題是”修改資料“的情況。

2.5 是否充分考慮了操作的容錯性

2.5.1 危險操作的二次確認

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

2.5.2 提供必要的撤銷功能

執行一個操作后是否允許用戶撤銷？

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

2.5.3 操作失敗的解釋與建議

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

項目案例：新建項目流程中的第2步是在地圖中對項目所在地進行定位，而當定位位置讀取結果出現異常時，可以通過toast對定位失敗進行解釋，并建議用戶檢查網絡及GPS設置。交互文檔中可以在交互說明中寫明toast的文案。

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

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

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

第二部分 界面呈現

3. 控件呈現

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

3.1 控件是否符合用戶認知

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

而實際上，控件不符合認知的情況更多來源于設計師有意為之的盲目創新。這里還是建議，在交互習慣已經逐漸沉淀的今天，在產品本身不需要在界面上標新立異的情況下盡量采用通用的組件。

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

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

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

項目案例：消息模塊的消息列表中，根據消息的類別不同，標簽顏色共設計了藍、黃、灰、紅四種（根據客戶的需求，現階段的版本中實際上只用到了紅色和藍色兩種），紅色代表待辦類，藍色代表通知類。消息列表項可以通過組件化，在整個項目的設計中格式保持完全一致，有需要修改時，也可以統一修改和優化。

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

相同控件的操作反饋也要相同，簡單地說，長得一樣的控件操作起來也是一樣的。交互行為的一致性和樣式的一致性是相形而生的。對外要符合整個平臺的產品設計規范，對內要與同一產品內”兄弟姐妹“們的行為一致，這樣才能更好地降低交互模式的學習成本。

項目案例：整個項目中涉及上傳的操作有很多，上傳設計文件、上傳報價單、上傳合同等，對所有涉及上傳的操作控件，交互行為也應該統一進行設計，以保證一致性。在交互文檔的通用交互說明中，有專門的一張交互稿用于規定全平臺中的文件上傳、更新、下載操作的交互反饋。

3.4 控件的不可用狀態如何呈現

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

項目案例：發起工資核算流程中，填報工資構成的界面有兩處涉及不可用狀態的地方，“下一步”按鈕僅當全部金額信息填寫后可用，“導入上月數據”按鈕僅當該員工存在上個月工資數據時可用，在交互說明中對這兩個控件的可用條件以及不可用時的樣式（30%透明度淡顯）進行了明確的規定。

4. 數據呈現

4.1 空態如何呈現

空態是設計中必須考慮，卻又容易疏漏的點。不但數據完全空缺時會產生空態，在所有涉及篩選控件的數據列表中，都有可能因為篩選的結果為空產生空態。

項目案例：在全局交互說明中，有專門的一節“14.4 空狀態”用于規定可能涉及空態的頁面的空態顯示。

4.2 字數有限制時超限如何處理

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

項目案例：項目關閉原因的多行文本輸入框字數限制為200字，在交互說明中將其超限的處理方式確定為“自動刪除”。

4.3 無法完整顯示的數據如何處理

移動端界面的寬度有限，數據量較大、無法在指定行數內完整顯示的情況很多，尤其在未對字數進行限制的情況下。那么此時是截斷并用”…”提示未顯示完全，還是讓信息塊的高度與內容自適應、多行顯示，或者其他方法？一般而言，如果有另一個頁面可供用戶查看完整的信息時，可以使用前者，從而讓頁面更規整也更簡潔；而對唯一性的顯示，或者這已經是信息顯示最完整的頁面了的話，顯然必須全部顯示以保證信息的完整性。同樣的，無論采用哪種處理方式，都要在交互說明中讓視覺設計和開發同學清楚你的想法。

項目案例：供應商名錄模塊中，供應商列表中會顯示供應商名稱和供貨范圍，而供貨范圍由用戶按需要任意填寫，可能很短也可能非常長。而由于在詳情頁中可以（也必須）讓用戶查看完整的信息，列表頁中為了避免視覺上的混亂，可以采用“…”在行末截斷。而這些要求需要在交互說明中寫明，一種簡單的做法是默認在行末用“…”截斷，而需要多行顯示完整信息時特別指出即可，畢竟后者只占少數。

4.4 數據過期如何提示用戶

來自網絡的數據過期時如何友好地提示用戶？

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

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

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

4.5 數據按什么規則排序

涉及數據排序的列表，無論有沒有可以調整排序方式的控件，都要在交互說明中注明默認的排序方式。這點還是比較容易漏的，畫原型時可能只是隨意設置了一些虛擬的數據，不會太考慮它們的排序方式，而這恰恰是開發同學最關心的問題之一。

項目案例：設計文件庫中的文件列表，按更新時間倒序排列，未上傳文件排在最上方，有多個未上傳文件時按文件名倒序排列。

4.6 數值是否要按特定的格式的顯示

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

4.7 數據是否存在極值

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

項目案例：新建任務時，”開始時間“和”計劃結束時間“選擇器都有相應的極值限制，允許范圍以外的日期不可選：”開始時間“只有今天后的日期可選，”計劃結束時間“只有開始時間后的日期可選。

5. 文案呈現

5.1 句式是否一致

相似場景中，頁面標題和頁面標題之間的句式結構要保持一致，文案與文案之間的句式結構也要保持一致，總之，相應位置的文字句式要始終一致。

項目案例：所有流程的成功提示頁中，頁面標題都是“動詞+對象”（標題為動詞、動詞短語也是iOS設計規范建議的方式），而主提示語都是“賓語+動詞+成功”的句式。避免有時因為“好像這樣讀起來更順一點”就寫成了“賓語+成功+動詞”（如：采購流程成功關閉）或者其他句式，哪種句式更好是語文問題，這里不做探討，我們要做的只是保持一致。

5.2 用詞是否一致、準確

操作、稱謂、反饋中的用詞同樣要保持一致，并且應當在準確、不引起歧義的基礎上盡可能簡練。

項目案例：涉及表單提交的操作都用“提交”而不是混用”確定“、”確認“，涉及新建的操作都稱為“新建”而不是混用“創建”、“添加”，涉及對當前用戶的稱謂都用“您”而不是混用“你”，涉及成功提示的反饋都用”成功“而不是混用”完成“、“結束”，諸如此類的細節往往是反映一個設計師是否足夠專業和細心的重要指標之一。

5.3 文案是否有溫度感

文案需要讓用戶感覺到產品的溫度，對C端應用而言很好理解。而即使是B端應用，在必要的場景下，文案內容也應當在不影響表達的準確性和效率的前提下，避免冰冷的機械感，應結合場景和用戶角色融入恰當的情感。

項目案例：在一個項目各專業驗收完成，項目經理執行“完成項目”操作時，附言提供了具有溫度感的默認文案，相比冷冰冰的“本項目已全部完成”，即使收到通知的員工知道這是系統提供的默認文案，也多少會心頭一暖吧。

6. 輸入與選擇

6.1 是否為用戶提供了默認值

是否為選擇控件提供了默認項？輸入框內容為空時如何顯示？輸入框獲得焦點時，默認文字是消失（即僅作為提示文字或占位符）還是保留（即作為可編輯的默認文案）？

項目案例：這一點其實在前面一些例子里已經提到過了，像5.3節案例中提到的默認文案。這里還是用4.7節里講過的“新建任務”頁面的例子吧，因為確實比較典型。項目經理在項目中新建一個階段任務時，需要選擇專業、階段、開始時間、計劃結束時間，并填寫任務描述，如果不提供默認值的話，創建多個專業的多個任務對項目經理是一件非常繁重的工作。因此，設計中為每項都考慮了默認值。

其中，有一部分是用戶可能可以直接使用的，例如“階段”的默認值為當前最新進度的下一階段，“任務描述”的默認值是“階段+（專業）”的字段組合，“開始時間“的默認值為今天。

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

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

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

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

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

6.3 是否存在不必要的輸入

是否存在以下不必要、甚至會引起邏輯錯誤的輸入（這里的輸入包括鍵盤輸入和選擇等多種輸入形式）：

（1）如果某個數據是對應整個流程全局的，那么在這個流程內部，顯然這個數據不需要再重復輸入，每多一次輸入就多一次錯誤的可能。

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

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

項目案例：初版方案中，因為請購階段已經指定了設備數量，那么自然地會想到單價和總價應該是關聯的一對數據，在輸入單價后，總價應該是自動輸出的只讀數據，不應當允許重復輸入總價。但在自查中，結合自己在設計院工作的經驗，我忽然意識到這里有問題，設備采購中的單價和總價確切地說是“設備單價”和“合同總價”，兩者之間的關系并不是乘一個數量那么簡單，而應該是”合同總價=設備單價×數量+其他費用“，其他費用可能包括配件價格、稅費等五花八門的類目。而設備的單價和整個合同的總價對客戶來說都是重要的信息，因此在此兩個數據都應該是允許輸入的。因此，自查后，將總價由一個只讀的cell改成了一個數值輸入框。

6.4 是否指定了鍵盤類型和鍵盤引起的頁面滾動

當需要通過鍵盤進入輸入時，需要在交互稿中標注調出鍵盤的布局類型。否則，開發同學如果將所有未標注的鍵盤都寫成了默認鍵盤，會讓用戶不得不手動切換鍵盤類型、大大影響用戶的輸入體驗。以iOS鍵盤為例，常用的主要是以下11種：

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

項目案例：登錄頁的手機號碼和密碼輸入框，分別調出的應該是默認鍵盤和密碼鍵盤，同時，輸入框獲得焦點、調出鍵盤后，頁面相應地向上滾動相應的高度，以保證輸入框、登錄按鈕、“忘記密碼”鏈接可見。這些都需要在交互說明中向開發同學注明。

第三部分 過程與特殊情形

7. 交互過程與反饋

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

操作成功后如何跳轉？如何提示用戶？通過toast還是設置專門的成功提示頁？

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

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

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

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

因網絡環境差、無網、后臺故障等原因導致操作失敗時如何提示用戶？跳轉至專門的失敗提示頁，還是阻斷跳轉、停留在當前頁面并通過toast提示？

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

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

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

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

7.4 是否設計了必要且合理的動效

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

項目案例：這篇文章主要講交互自查，就不方便放動效的具體案例了，因為具體做起來會涉及比較多和開發的溝通。對本項目這樣一個B端的管理類應用而言，常規的動效庫足矣，除了信息列表的下拉刷新、頁面的載入等待、文件上傳下載的等待等場景外，基本上不需要額外的動效設計。這種情況下，實際工作中，對動效的考量和開發團隊的組件積淀是有很大關系的。在這類項目的交互設計的自查階段，我們更多地需要做的是考慮需要動效的場景（無論你起初是不是這樣想，最后會發現，需要動效的地方通常都比你想象得少），以及動效的必要性和合理性。

8. 特殊情形

8.1 角色權限與狀態不同造成會造成哪些差異

對允許未登錄狀態使用部分功能的C端應用而言，需要考慮的主要是游客狀態轉登錄狀態、登錄狀態轉游客狀態時，體驗路徑中的差異。對B端應用而言，需要分析的則主要是根據用戶在流程中的角色不同、根據用戶在公司內的部門和職務不同、根據用戶在同一流程中的權限不同，會在任務流程、界面呈現（例如：部分控件和入口的顯示與否）文案等方面產生哪些區別。

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

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

8.2 是否提供特殊模式

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

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

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

案例項目介紹：http://qinsman.com/1612_epmp/

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

本文由 @ Qinsman 原創發布于人人都是產品經理。未經許可，禁止轉載。