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