申請人能否清楚知道自己在多步驟表格的哪一階段？

先判斷分階段是否真的有幫助

長申請表可按資料性質分成數個階段，讓顧客每次處理一組相關問題。W3C 的多頁表格指引建議按邏輯分組、在每頁重述整體說明、清楚標示可選階段，並交代目前進度。這是設計起點，不代表所有表格都應拆開。只有三道問題的查詢表，通常一頁更清楚；需要身份、資格、證明文件及覆核的服務申請，則可能適合分階段。先列出每階段要求的資料及用戶完成後能做到甚麼。「資料」這種步驟名稱含糊；「聯絡資料」或「證明文件」更能建立預期。

進度提示不應只是裝飾性的編號圓點。它應回答三個實際問題：我在哪裏、還剩甚麼、返回較早階段會否遺失目前輸入？顧客可能需要找文件、暫停或改正地址，這些問題便很重要。若階段數目已知，開始時可說明總數；若後續答案會改變路徑，則避免作出虛假的精確承諾。可說明部分申請人會多一個文件階段，或使用會一致更新的約略數目。畫面顯示「四步之三」後卻突然冒出第五步，即使最終可以提交，也會令用戶失去信心。

讓目前位置可看見亦可讀出

W3C 建議在網頁標題和主要標題加入進度：屏幕閱讀器使用者通常很早便聽到頁面標題，而其他人可快速掃視主標題。例如英文可寫「Step 2 of 4: Supporting documents」，中文可寫「證明文件，四步之二」。不同頁面與語言版本應使用一致次序和名稱。視覺化步驟列可以補充，但不能只靠顏色區分。已完成、目前及尚未開始的階段應有文字說明。若手機版為節省位置而隱藏可見文字，須確認手機用戶仍能理解符號，輔助技術亦能讀出相同狀態。

對已知順序，W3C 的例子使用有序清單呈現步驟，並建議在能保存資料時讓已完成階段成為連結。這同時交代次序及返回方法。若流程長度可變，HTML progress 元素可用來表示約略完成情況，但百分比可能暗示流程具有實際上不存在的精確度。呈現方法應反映真實狀態。進度條只是指示，不應看起來可點擊卻完全不能導航；相反，若已完成階段可按，便要具備正常連結行為、可見焦點及清楚的目前階段標記。語意必須符合實際操作。

返回較早階段要連同資料保存設計

返回已完成階段的連結，只有在系統保留已輸入資料時才真正有用。團隊應決定在甚麼時刻保存：按「繼續」、主動按「儲存」，或其他已清楚說明的時點。若顧客返回修改早前答案，後續資料可能不再適用。例如改變申請人類別，可能取消原本需要的文件階段。系統應說明哪些後續輸入受影響，保留不受影響的資料，並在丟棄大量工作前徵求確認。答案已失效的階段，不應仍顯示令人安心的「已完成」。W3C 的返回已完成階段例子，也明確以保存目前資料為前提。

表格內的「上一步」與瀏覽器的返回按鈕並不相同，兩條路都要測試，因為顧客會兩者都用。若系統建立申請草稿，還須避免另一分頁或恢復的工作階段悄悄覆蓋較新的答案。應說明是否有草稿、如何繼續，以及正式提交後還能否安全查看先前頁面。到達最終確認頁時，進度列不應令人以為按回舊步驟可修改已提交紀錄，實際卻會開出另一宗申請。進度提示須反映資料生命週期，而不只是前端畫面的排列。

以服務申請作例子

設想本地服務申請預計有四階段：聯絡資料、服務需要、證明文件及覆核。第一頁列明名稱，並解釋尚未備齊文件的人可儲存草稿後再回來。第二頁的網頁標題和主標題均顯示「四步之二」；進度提示把第一階段標為已完成，後兩階段標為尚未開始。文件頁應按照先前答案說明此階段是否必須，若屬可選，便提供清楚的略過方法。覆核頁則摘要已輸入資料，讓用戶返回相應階段修正，同時保持其他資料完整。

再測試顧客在第二階段把「個人」改為「公司」。若因此必須提交公司文件，畫面與可讀出的階段狀態都應更新，並解釋變更原因；若某個可選階段消失，進度列不應繼續計算無法到達的頁面。英文和繁體中文名稱要各自驗收：直譯可能無法準確說明需要甚麼文件，較長的中文文字在窄屏也可能換行。以純鍵盤及屏幕閱讀器完成流程，再在小型手機重試。記錄按「繼續」或「上一步」後焦點落在哪裏，以及新頁標題是否能被察覺。

把進度提示變成可驗收要求

驗收時應包括第一次申請的人、返回已儲存草稿的人，以及答案會改變階段數目的人。請他們在沒有提示下指出目前階段、餘下工作，及如何安全地修改早前答案。要觀察實際回答，而非只數點擊次數。檢查可選階段有否標明，網頁標題、主標題和視覺清單有否互相矛盾。W3C 的標籤與說明指引支持清楚交代輸入預期，因此階段標題也應讓顧客知道本頁需要甚麼。若用戶仍不知道是否快到提交，應先修正資訊設計，再美化圖形。

把已測試的狀態模型寫進產品規格：甚麼算目前、已完成、已略過、被阻擋及已提交；各狀態何時轉換；返回時哪些資料會保留。這樣設計、開發、翻譯及測試人員才有共同依據。每當新資格分支或文件種類改變旅程，都要重看這套規則。真正的進度提示，是向顧客承諾服務會怎樣一步步進行；路線改變，承諾也要同步更新。這是中小企判斷多步驟申請是否真的有幫助，而非只看起來有條理的實際標準。

如實處理分支及中斷

分支會改變「已完成」的意思。申請人起初表示沒有代表人，代表人階段可以不出現；若其後改變答案，新階段應顯示為必填而未完成，總階段數亦須更新，同時不應暗示其他資料已流失。相反，移除一個階段時，百分比突然上升也不應讓人摸不著頭腦。可用階段名稱及目前任務解釋變化。狀態模型應根據當下必須提供的資料，而非顧客曾經看過多少畫面。服務重新設計、資格規則變動時，這點尤其重要。

中斷後再回來，也要有清楚的入口。申請人透過電郵或帳戶頁返回時，應到下一個未完成階段，並看到已儲存內容的摘要。若早前答案改變，系統無法安全推斷下一步，應先要求覆核受影響答案，而非猜測。進度顯示要把草稿狀態與正式提交狀態分開。「四個階段都完成」不等於「申請已提交」；後者取決於明確的最終動作及可查證的確認紀錄。分清狀態，才不會令顧客以為草稿已正式送達。

上線前應同時把進度提示當作內容及互動來測。測試員只聽每頁標題而不看視覺元件，也應知道所處階段；另一位在最窄的支援屏幕檢查文字有否被截斷或換行混亂。鍵盤使用者應能返回及再向前而不流失輸入；屏幕閱讀器使用者要能聽出目前位置，並分辨可按的已完成階段。最後比較正式提交確認與之前的進度狀態。這些測試比只看圓點顏色更有意義。記錄實際失敗，並在用戶無法預測下一步時修訂階段模型或文案；同時確認雙語版本的階段名稱所指的工作相同，沒有一種語言把可選事項說成必填。