微信小程式設計規範（2） 清晰明確
二、清晰明確
作為一個負責任的開發者，一旦用戶進入我們的小程式頁面，就有責任和義務清晰明確告知用戶身在何處、又可以往何處去，確保使用者在頁面中游刃有餘地穿梭而不迷路，這樣才能提供使用者安全的愉悅的使用體驗。
1. 導航明確，來去自如
導航是確保使用者在網頁中瀏覽跳轉時不迷路的最關鍵因素。導航需要告訴用戶，我在哪，我可以去哪，如何回去等問題。首先在微信系統內的所有小程式的全部頁面，都會自備微信提供的導覽欄，統一統一解決我在哪，如何回去的問題。在微信層級導航保持體驗一致，有益使用者在微信內形成較統一的體驗和互動認知，無需在各小程式和微信切換中新增學習成本或使用習慣。
微信導覽列
微信導覽列，直接繼承於客戶端，除導覽列顏色之外，開發者無需亦不可以對其中的內容進行自定義。但開發者需要規定小程式各頁面的跳轉關係，讓導航系統能以合理的方式運作。
微信導覽列分為導覽區域、標題區域以及操作區域。其中導航區控製程序頁面進程。目前導覽列分深淺兩種基本配色，在iOS和Android展示有所不同，如下圖所示：
導覽區（iOS）
#導覽區通常只有一個操作，即返回上一級介面。開發者可定義其內容，且不可對樣式進行修改。
導航區（Android）
通常情況下，系統導航左側唯一的操作為「離開小程序，回到微信，程式後台運行」。
當使用者進入小程式次級頁面後，我們建議小程式本身可以設計回傳操作，同事使用者也可以透過安卓系統自帶的硬體返回按鈕回到上一層。
微信導覽列自訂顏色規則（iOS和Android）
小程式導覽列支援基本的背景顏色自訂功能，選擇的顏色需要在滿足可用性前提下，和諧搭配微信提供的兩套主導航列圖示。建議參考以下選色效果：
選色方案範例：
#頁內導覽
開發者可依自身功能合計需要在頁面內新增自有導航。並保持不同頁間導航一致。但受限於手機螢幕尺寸的限制，小程式頁面的導覽應盡量簡單，若僅為一般線性瀏覽的頁面建議僅使用微信導航列即可。
微信控制項庫提供tab導覽供開發者選擇。 tab欄可固定在頁面頂部或底部，方便使用者在不同的tab頁間作切換。為確保點擊區域，tab項不得超過4項。一個頁面也不應出現一組以上的tab欄。
2. 減少等待，反饋及時
頁面的過長時間的等待會引起用戶的不良情緒，使用微信小程式專案提供的技術已能很大程度縮短等待時間。即便如此，當不可避免的出現了加載和等待的時候，需要予以及時的反饋以舒緩用戶等待的不良情緒。
啟動頁設計
小程式啟動也是小程式在微信內容一定程度上展現品牌特徵的頁面之一。
本頁面將突出顯示小程式品牌特徵和載入狀態。
啟動頁除LOGO品牌展示外，頁面上的其他所有元素如載入進度指示，由微信統一提供且無法變更。無需開發者開發。
下拉標示區
微信類別所有小程式頁面，都會再下拉時出現微信為其統一設計的標示區。品牌展示區由品牌名稱和微信小程式提示組成。目的是強化品牌和使用者對小程式的產品感知。
下拉標示（iOS深淺兩色方案）
微信提供深淺兩組配色方案，如此處標示所示，文字顏色不可自訂，開發者在自訂背景色時，應注意確保下拉標示的辨識度。
下拉標示（Android深淺兩色方案）
微信下拉提示用於給使用者明確的小程式歸屬者，防止造假與作弊。此處標示提供深淺兩組方案，文字顏色不可自訂，開發者在自訂背景色時，應注意確保下拉標示的辨識度。
頁面刷新互動（iOS）
開發者可自訂需要透過下拉互動完成刷新的頁面，此類互動微信將提供標準能力和樣式。在樣式上，刷新圖示與下拉標示配色已捆綁，分為深淺兩套方案，開發者在使用時，應注意頭部文字、下拉標示與刷新圖示的和諧統一。但使用者在該類別頁面做出下拉互動時，出現微信小程式頁面標準載入動畫。開發者無需自行開發樣式。
在開發者沒有在頁面頂部設計tab的情況下，若定義該頁面可透過下拉動作刷新，則刷新後加載狀態提示語小程式品牌展示區出現在標題欄之下，頁面頂部。
開發者暫無法執行定義此載入效果。
在開發者定義了頁面頂部tab並定義該Tab下的內容頁面可透過下拉動作刷新，則刷新後載入狀態提示語小程式品牌展示區出現在頂部Tab之下，且僅刷新目前頁面內容。開發者暫無法自行定義此載入效果。
頁面刷新互動（Android）
#與iOS相同，在樣式上，Android下重新整理圖示與下拉標示配色已捆綁，分為深淺兩組方案，開發者在使用時，應注意頭部文字、下拉標識與刷新圖示的和諧統一。
微信下拉標示錯誤使用案例
請避免下列錯誤使用情況，確保資訊的可見性和頁面的可用性。
頁內導覽
微信控制項庫提供深淺tab導覽方案供開發者選擇。 tab欄需固定在頁面頂部，方便使用者在不同的tab頁間作切換。為確保點擊區域，tab項不得超過4項。一個頁面也不應出現一組以上的tab欄。
Tab欄選取態預設為100%實色，未選取態帶有60%，其中選取態顏色可自訂。在自訂顏色選擇中，務必保持Tab的可用性、可視性和可操作性。
頁面內載入回饋
開發者可在小程式裡自訂頁面內容的載入樣式。建議不管是使用在局部還是全體，自訂載入樣式都應該盡可能簡潔，並使用簡單動畫告知使用者載入過程。開發者也可以使用微信提供的，統一的頁面載入樣式，如圖中例所示。
模態載入
模態的載入樣式將覆蓋整個頁面的，由於無法明確告知具體載入的位置或內哦讓那個將可能引起使用者的焦慮感，因此應謹慎使用。除了在某些全局性操作下不要使用模態的菊花。
局部載入回饋
即旨在觸發載入的頁面局部進行回饋，這樣的回饋機制更有針對性，頁面改動小，是微信推薦的回饋方式。例如：
載入回饋注意事項
- #若載入時間較長，應提供取消操作，並使用進度條顯示載入的進度。
- 載入過程中，應保持動畫效果；無動畫效果的載入很容易讓人產生該介面已經卡死的錯覺。
- 不要再同一個頁面使用超過1個載入動畫。
結果回饋
除了在使用者等待的過程中需予以及時回饋外，對操作的結果也需要明確回饋。根據實際情況看，可選擇不同的結果回饋樣式。對於頁面局部的操作，可在操作區域直接回饋，對於頁面層級操作結果，可使用toast、彈跳窗或結果頁面展示。
頁面局部操作結果回饋
對於頁面局部的操作，可在操作區域直接回饋，例如點擊多選控制項前後如下圖。對於常用控件，微信設計中心已提供控件庫及WeUI控件庫，其中的控件都已設計有完整的操作回饋。
頁面全域操作結果－toast
其中toast適用於輕量級的成功提示，1.5秒後自動消失，不打斷流程，對使用者影響較小，適用於不需要強調成功專題的操作提醒。特別注意toast形式不適用於任何錯誤提醒。
頁面全域操作結果－彈框
對於需要使用者明確知曉的操作結果狀態可透過彈框來提示，並可附帶下一步操作指引。
頁面全域操作結果－結果頁
對於操作結果已經是目前流程的終結的情況，可使用操作結果頁來回饋。這種方式最強烈且明確的告知使用者操作已經完成，並可根據實際情況給予下一步操作的指引。
3. 異常可控，有路可退
在設計任何的任務和流程時，異常狀態和流程往往容易被忽略，而這些異常場景往往是使用者最為沮喪和需要幫助的時候，因此需要格外注意異常狀態的設計，在出現異常時予以用戶必要的狀態提示，並告知解決方案，使其有路可退。
要杜絕異常狀態下，用戶莫名其妙又無處可去，卡在某一個頁面的情況。 2.2中所提到的彈跳窗和結果頁都可作為異常狀態的提醒方式。除此之外，在表單頁面中尤其是表單項目較多的頁面中，也應明確指出出錯項目，以便使用者修改。
異常狀態－表單出錯
表單報錯，在表單頂部告知錯誤原因，並識別錯誤欄位提示使用者修改。
