2019-9-12 資深UI設計者
有理有據(jù)，有面有料，是一個設計作品的專業(yè)體現(xiàn)。之前花了四篇小文（鏈接在文末），講述如何提升設計師設計作品的內(nèi)在含金量和外在形式感，今天，我們將用最后的篇幅，聊聊如何給設計作品創(chuàng)造一個盡可能完美的終局——交互文檔的細節(jié)。
千里之堤毀于蟻穴，再專業(yè)的交互設計，如果在后期交付時頻繁出現(xiàn)細節(jié)的缺失和補充，其實還是很容易遭受研發(fā)和測試同學diss的。甚至有可能因為一個細節(jié)的疏忽，導致整體交互方案的崩盤，不得不從頭再來。
如果研發(fā)過程中發(fā)生這樣的設計事故，其實是非常影響團隊士氣和個人專業(yè)影響力的。
設計細節(jié)篇，分兩個維度來闡述，一個是文檔外,一個是文檔內(nèi)。
文檔外，其實是要回歸設計的初衷，很多設計師包括我自己，設計久了，總愿意把自己當作是用戶的代言人，盡可能的為用戶體驗著想，絞盡腦汁的尋求最佳體驗的設計，并以此為傲。
這如果是在產(chǎn)品發(fā)展的成熟期，功能相對穩(wěn)定，體驗同質(zhì)化嚴重，這個時候追求的體驗，尋求體驗的突破是非常有意義的，可以讓產(chǎn)品獲得更多的口碑，從而帶來更多的用戶和收益。
但是如果是在探索期和成長期，過度的追求單一維度的體驗，可能反而會成為一種產(chǎn)品發(fā)展的桎梏，阻礙產(chǎn)品的成長，而在衰退期追求的體驗，則完全背離了公司作為商業(yè)組織的利益點，會顯得和整個項目組格格不入。
產(chǎn)品生命周期與用戶體驗要求
所以對于探索期和衰退期的產(chǎn)品來說，設計師要盡可能考慮商業(yè)性和技術(shù)可行性。用最小的設計代價，快速的迭代，完成產(chǎn)品的目標（驗證價值或解決問題）。
如果設計師在這兩個階段太揪細節(jié)，可能會因為得不到項目的支持而心灰意冷。
技術(shù)可行性和商業(yè)收益，不是我們所擅長的領域，通過前面的設計法則和用戶埋點也不能準確推算，所以還需及時向技術(shù)及商務同學確認，別人家能做的產(chǎn)品形態(tài)，咱們家技術(shù)框架不一定支持。別人家能做的精簡，可能會損害咱們家的主營業(yè)務。
涉及到這兩點，除非有自上而下的旨意，否則單憑設計之力無異于蚍蜉撼樹，很容易讓自己費力不討好。
文檔內(nèi)的交互細節(jié)，主要在于文檔的完整性和閱讀體驗，既要面面俱到，又要清晰簡潔。
面面俱到是指要盡量包含所有流程、頁面及狀態(tài)，避免遺漏。它體現(xiàn)了一個交互設計師設計思維的嚴謹性和設計態(tài)度。
網(wǎng)上有很多關于交互走查表的模板，非常的全面，但就是因為太過全面，反而讓很多新人設計師望而生畏，避而遠之，這就失去了交互走查表本身的意義。
我認為，交互走查表其實就是提供給設計師的一份幫助文檔，大家都知道在設計的時候，提示要盡可能的簡短，要適時出現(xiàn)，要清晰簡潔，遺憾的是我看到的交互走查表往往都不滿足這一條。
冗長的交互走查表，就像是冗長的幫助文檔一樣，把責任都推給了設計師，仿佛在說：誰讓你不按照我逐條檢查呢？
如果出現(xiàn)細節(jié)的遺漏，就變成了設計師自己的錯。
誰都不想遺漏，但是后期設計時間往往真的就很緊迫，設計師除了細節(jié)的補充，可能還有其他很多任務需要做，大家只是想確認一下而已，哪有時間和精力去看那么冗長的“幫助文檔”。
所以發(fā)揮一下設計師的同理心，根據(jù)二八原則，80%設計師可能遺漏的問題都只是認知走查表里20%的內(nèi)容，這20%的內(nèi)容也真正意義上影響我們80%的用戶和體驗，是設計者最為關心的。
那么，我們是不是先把這20%的設計解決好呢？這才是真正急設計師之所急，站在設計師的角度考慮問題。
所以本文精心篩選出最容易被大家所忽略，且大多數(shù)設計又必須要考慮的異常分支，為大家整理了一份《設計細節(jié)check表》，以確保主體流程的主要設計“面面俱到”。（流程設計、布局設計，以及互動設計，如果大家在前期有遵守對應的設計原則，再加上數(shù)據(jù)的支持，應該大方向都是正確的。我也希望大家盡量通過前期的理論和數(shù)據(jù)，去保證流程和整體設計的正確性，而不是要等到最后細節(jié)確認的時候，才來審視檢驗整體，讓細節(jié)篇，真的是在完善細節(jié)。）
設計細節(jié)Check表
我把這份《設計細節(jié)check表》按照從整體到局部進行了歸類：
最大的單元是指每個任務流程的檢查，然后是頁面單元，因為頁面涉及到加載的異常分支比較多，所以單獨拆出來和頁面狀態(tài)并列分別闡述。最后是組塊單元，主要包括輸入類和非輸入類的組件操作及反饋。
下面我們逐一來看：
流程檢查主要包括三點：
秉承一致性原則，同一個產(chǎn)品，能保持一致的地方，要盡可能保持一致。
在實際項目中，同一個產(chǎn)品，往往有多個設計師，每個設計師都負責相對獨立的一大模塊，偶爾就會涉及到相似功能的設計，因為是不同人在進行，所以設計出來的形態(tài)就可能不一致；
但對于用戶來說，使用相似功能的人，往往可能是同一撥人，設計的不一致，體驗就會有差異，不僅對于用戶來說學習成本高，而且對于項目組來說同時維系兩套不同的設計，成本也比較高。
如果一個流程的正向流程和逆向流程是完全一致的，一般無需特別說明，但是如果返回時需要跳過某些頁面或者狀態(tài)快速返回，則需要進行特殊標注，否則可能會被研發(fā)同學遺漏。
當遇到特殊情況，程序崩潰，后臺殺死，斷電等，進度是否能夠能自動保存并恢復，如果需要，就需要考慮恢復的時機和形式。
說完流程，再來說單獨的頁面。談到頁面時，首先要談的是加載狀態(tài)，畢竟頁面不是憑空就有的。
加載狀態(tài)主要要考慮以下幾點：
預加載的時機是什么時候，預加載的內(nèi)容有多少？（對于用戶會長時瀏覽的內(nèi)容，一般建議預加載，預加載的內(nèi)容一般會結(jié)合內(nèi)容大小、瀏覽時長、甚至網(wǎng)絡狀態(tài)綜合決定）
在信息未加載出來前，界面是顯示空白引導，還是默認占位符，還是顯示上一次的緩存內(nèi)容？（一般有緩存優(yōu)先顯示緩存，無緩存先顯示默認占位符，等內(nèi)容加載完成后再進行替換）
是否顯示加載圖標，進度條，是否可以取消加載？（一般情況下等待超過0.1s，就能夠被用戶感知到，就建議顯示加載圖標，以便用戶知道程序已經(jīng)接收到并在響應用戶的操作指令。如果等待超過1秒，就建議顯示進度條，并提供取消操作，便于用戶自主控制）
是全部加載，還是分布加載顯示？（一般情況下，在2~3屏內(nèi)的有限內(nèi)容，或者完全非同類的內(nèi)容，是可以一次性全部加載的，因為用戶可能就是沖著某一類內(nèi)容進來的，很可能會快速滑動到目標內(nèi)容。
而對于同類型的圖文信息，而且是內(nèi)容比較多時，一般都會采取分布加載的形式，避免浪費多數(shù)用戶的流量。
視頻播放機制、廣告圖片加載等，一般還要考慮網(wǎng)絡情況，一般WIFI情況下，因為對流量及網(wǎng)速的要求低，所以采用自動播放視頻，自動顯示圖片、播放廣告等，更容易被用戶所接收）
是否自動重試加載，何時進行超時提示等。（很多產(chǎn)品在設計時，如果不是完全無網(wǎng)絡，僅僅是網(wǎng)絡信息不穩(wěn)定，會嘗試自動加載，以避免用戶手動操作。如果自動加載超過上限，才會提示讓用戶稍后再試）
頁面加載出來后，就要要考頁面本身的狀態(tài)了。
需要考慮的異常頁面狀態(tài)主要有以下幾種：
考慮完整體頁面后，最后再來考慮一下頁面內(nèi)的組件狀態(tài)。先來看一下輸入類。
輸入框/文本框要考慮的主要有三點：
最后看一下非輸入類的操作組件。
“文本/圖標按鈕、鏈接、可操作的卡片/列表”要考慮一下幾點：
如果設計完成后，初步檢查以上五項內(nèi)容，基本上可以確定主題流程的主要設計內(nèi)容已經(jīng)面面俱到了。
文章來源：人人都是產(chǎn)品經(jīng)理