行動無障礙操作:放大、讀屏與觸控次序檢查
無障礙的時間成本常在最後一刻才被看見:一個彈窗、圖片按鈕或自訂選單可以令讀屏焦點走失,之後每次修改都要回頭補測。把它列為早期規則,反而較容易控制返工。 本文整理放大、讀屏、鍵盤與觸控次序的資料準備、前後台規則、技術取捨、例外處理、驗收與移交,讓團隊可在動工前定出可核實的範圍與責任。
閱讀全文 →無障礙的時間成本常在最後一刻才被看見:一個彈窗、圖片按鈕或自訂選單可以令讀屏焦點走失,之後每次修改都要回頭補測。把它列為早期規則,反而較容易控制返工。 本文整理放大、讀屏、鍵盤與觸控次序的資料準備、前後台規則、技術取捨、例外處理、驗收與移交,讓團隊可在動工前定出可核實的範圍與責任。
閱讀全文 →專業服務團隊在聯絡頁常收到「想了解服務」這類資料不足的查詢;不是要堆更多欄位,而是要讓訪客理解每一欄需要甚麼、哪些必填,以及提交後會發生甚麼。 本文整理表單標籤、輸入提示與錯誤語意的資料準備、前後台規則、技術取捨、例外處理、驗收與移交,讓團隊可在動工前定出可核實的範圍與責任。
閱讀全文 →平台規則或內部政策一改,外判項目最容易出現「大家以為已改」的空檔。若修改只在聊天訊息流轉,設計稿、測試項目和最後上線版本往往已經不同步。 本文整理修改提出、決策、重測與簽核紀錄的資料準備、前後台規則、技術取捨、例外處理、驗收與移交,讓團隊可在動工前定出可核實的範圍與責任。
閱讀全文 →支付審批一拖延,客人已習慣在聯絡頁追問進度;若按鈕只有平常狀態,大家無法知道提交中、成功、失敗或暫不能使用時應看見甚麼,前線亦難以判斷問題在哪一段。按鈕狀態需要對應真實系統狀態。提交中不是單純變灰,而是要避免重覆請求;失敗後不是只恢復原狀,而是保留資料並指出可修正或可改用的下一步。 本文從資料欄位、選型、串接、手機與搜
閱讀全文 →「字體放大就會容易讀」是一個常見誤解。聯絡頁的標題能否被看懂,還取決於訪客知道自己身在何處、要提供甚麼資料,以及錯誤後怎樣回到正確步驟。真正可讀的標題要和後面的表單、按鈕與說明互相支持。若首屏叫人「開始對話」,表單卻沒有說明應提供哪些項目,訪客仍會停在不知道怎樣開始的狀態。 本文從資料欄位、選型、串接、手機與搜尋品質、
閱讀全文 →聯絡頁首屏信息層級不是單靠加入一項功能或調整一個畫面便能處理。本文以查詢類型、聯絡入口、表單、回覆安排與手機首屏為主線,整理香港團隊需預備的資料、PHP 與 MySQL 的實作分工、測試情境、例外處理和移交紀錄,並指出哪些常見做法會令前台、後台與日常跟進出現不同答案。
閱讀全文 →