響應式網頁設計檢查：手機版選單、表格與表單怎樣才易用

響應式網頁設計檢查：一隻手填表時先遇到甚麼

拿著手機步行的客人，想在公司網站查服務並留下聯絡資料；他用拇指打開選單，找到表格，輸入一半時鍵盤遮住確認按鈕。這份響應式網頁設計檢查以操作觀察為起點：頁面在窄螢幕沒有橫向捲動，只能算初步合格；能否讀清、選對、輸入、改錯及完成，才決定手機版是否真的易用。

這是一段假設使用情境，不是對 Black Media 現有網站或客戶的測試結果。老闆可以用自己熟悉的手機先做一輪，再邀請未看過設計稿的同事重做同樣任務。記錄每一步花在哪裏、發生甚麼錯誤及他怎樣理解畫面，比只問一句「覺得靚唔靚」更容易找到可修正的問題。

響應式設計會因螢幕寬度、字體設定、內容長短與操作方式改變呈現。Google 的流動裝置索引指引提醒網站保持手機與桌面內容和搜尋資訊一致；網站管理者仍應自行驗證重要內容是否真的可讀，不能只憑程式碼標示已支援手機。

觀察記錄一：選單能找到工作入口嗎

選單的名稱應讓第一次來的人辨認

請一位不熟悉網站內容的同事，拿手機做一個具體任務，例如找到服務範圍、查詢付款方法或打開聯絡方式；只告訴他任務，不提示選單位置。記下他是否看得懂項目名稱、展開第二層後能否返回上一層、打開聯絡頁會否突然關閉選單。如果網站把相近功能拆成幾個不清楚的縮寫，改大圖示也不能解決找不到入口的問題。

橫放手機、放大系統字體或打開螢幕閱讀工具時，選單可能比平時長，應檢查最後一項仍可點到、頁面不被遮住，且鍵盤操作能走到選單與退出。若暫時做不到全部情境，也要優先修正阻斷下單和聯絡的情況，並把餘下問題記入改善清單。

先看導覽名稱，再看按下去的結果

手機選單通常比桌面窄，使用者不一定看到完整層級。請以「找最新服務資料」「聯絡公司」「查看產品分類」三項任務測試，觀察是否能用選單文字預期下一頁內容。若所有項目都叫「了解更多」，客人可能要逐頁試；若分類只靠公司內部術語命名，新客戶未必理解。

遇到多層選單，應區分展開子項與前往分類頁的動作。點分類文字後若直接跳頁，使用者可能永遠找不到第二層；若全部只能展開，也可能難以到達分類介紹。請實際用手指操作，不要只在桌面以滑鼠移過導覽便判斷手機可用。

關閉、返回與目前位置同樣重要

展開選單後，客人應知道如何關閉並返回剛才閱讀的位置。若選單覆蓋全頁，關閉後卻回到頂部，他可能要重找內容。若手機瀏覽器的返回鍵令選單狀態混亂，也應記錄。測試時讓同事從搜尋或分享連結直接進入內頁，不要每次都由首頁開始，因為真實訪客未必按公司預期的起點閱讀。

對內容較多的網站，搜尋框或分類入口可以協助定位，但不應掩蓋選單命名混亂的問題。先觀察客戶最常找的幾件事，調整項目次序與用詞，再考慮是否需要額外快捷入口。若每頁都放過多固定按鈕，手機可閱讀的空間反而減少。

• 記下從哪一頁開始、點過甚麼及是否找到目的地。
• 觀察選單展開後能否關閉，及按返回鍵的結果。
• 由不同內容入口試一次，避免只測首頁。

觀察記錄二：長頁與小字會否迫人放大

標題、段落與重點資料的視覺次序

網站可在手機上縮到剛好放進畫面，字卻細到要放大才能讀，便未真正照顧手機使用。選一段較長服務說明，觀察字級、行距和段落寬度是否令讀者能逐行跟上。重要限制應在附近說清楚，而非藏在只有放大後才看見的圖片文字。讓真實內容測試，不能只用兩句示意文。

若有中英混合、產品型號或長電郵地址，應檢查換行方式。不能為了讓頁面看似整齊，把資料強行切斷或遮住尾段。若某張版面只在設計示範文字下正常，一換真實資料就出現重疊，問題應在內容與版面規則一併處理，而非叫使用者自行轉橫向再看。

固定橫幅不應搶走主要內容

手機畫面高度有限，頁首、優惠橫幅、私隱提示與即時聊天按鈕若同時固定，可能只剩一小截可讀內容。測試頁面在未登入、首次打開及關閉提示後的狀態；任何必需提示都要可以理解與操作，但不應令客戶找不到產品或表格。若每項都「一定要固定」，便需要按任務重新排優先次序。

有些內容在桌面以左右兩欄對照，到了手機變成先顯示全部左欄再全部右欄，讀者便無法理解兩者如何配對。可改為逐項交錯呈現或使用清楚的小標題。這種問題要用一段實際資料測試，單靠視覺稿中的佔位方塊很難發現。

觀察記錄三：列表與表格收窄後資料還在嗎

表格改成卡片時，別丟掉欄位間的關係

價格、規格與服務條件若原本以表格呈現，手機顯示為一張張卡片時，要在每個值旁寫清欄位名稱。只留下幾行數字而把表頭藏起來，讀者無從知道哪個數值對應哪個產品。比較類資料也可保留橫向捲動，但須讓人察覺仍有內容在右邊，並檢查放大字體後第一欄沒有把其他欄推得無法閱讀。不要只靠縮小字體把所有欄硬塞在一屏。

測試者可指定兩項服務，找出差異並向旁人講解。若他必須不斷左右來回記住數字，便可考慮提供逐項比較的摘要。這個任務檢查的是資訊能否理解，而不只是截圖是否沒有跑版；桌面版也要保留同等重要的條件，避免手機內容被刪得太簡單。

表格不能因為裝不下便刪掉重要欄位

公司服務常有規格比較表，手機一行容不下全部欄位時，可以考慮橫向捲動並有明確提示，或把每一列轉成清楚標籤與值。重點是保留決策所需資料，並讓讀者知道如何看。若手機版只顯示名稱，價格、限制或差異全部消失，客人便無法完成桌面版原本能做的比較。

測試時挑最長的欄位名稱、最多文字的一列，以及需要放大的情況。看看表頭是否仍可對應數據、連結能否按到、橫向捲動會否連整個頁面一起飄走。可參考網店平台比較文章內的決策資料，想像讀者在手機上怎樣逐欄閱讀，才知道應用甚麼呈現方式。

列表逐項操作要有足夠間距

商品清單的分類選項、篩選條件和表格內連結，如果貼得太近，容易選錯。W3C 的操作目標尺寸指引提供可參考的準則，實際設計亦要留意相鄰按鈕之間的距離。讓不同同事在實際手機上按選項，記錄誤觸，較能判斷哪些位置需要改善。

觀察記錄四：表單每個欄位都讓人知道要填甚麼

鍵盤種類與欄位順序要配合真實輸入

填電郵時，裝置最好能提供適合電郵地址的鍵盤；填電話時則用方便輸入數字的方式，並容許按商戶實際需要輸入區號。欄位說明不要全放在會隨輸入消失的提示字，否則客人回頭修改時已忘記要求。先問清楚完成聯絡或落單最少需要甚麼資料，避免一頁塞入太多非必要欄位。若有同意條款，連結和說明應在客人提交前可讀。

用沒有預先填好資料的手機走一次表單，再用自動填寫走一次，檢查稱謂、公司名、電郵和地址有無填錯位置。若客人貼上帶空格的電話號碼或較長的電郵地址，系統應在合理情況下明確提示，不應無聲截斷。測試時同時問：收到成功訊息後，後台能否找到完整內容？

提示文字不能只放在會消失的位置

表格內的灰色示意文字，使用者開始輸入後可能消失；若他忘記欄位用途，便難以判斷資料是否填對。欄位應有清楚可見的名稱，必要格式另作說明。W3C 的表單標籤指引提供設計參考；技術實作由開發人員處理，商戶則核對用語是否符合真實收件流程。

例如查詢表格問「公司名稱」和「聯絡人」，應分清哪些必填、哪些可選，以及收集原因。若客戶只是問一項服務，要求填太多不相關資料會增加負擔；若需要填產品型號才能安排跟進，便在輸入前說明。欄位規劃與日後如何回覆客人有直接關係，應由使用資料的同事一起決定。

鍵盤、選項與自動填寫要照顧真實手機

電郵欄位應方便輸入電郵，電話欄位要能處理香港常用號碼形式，地址則不宜強迫使用不適合香港的郵遞區號格式。測試手機鍵盤彈出時，焦點有否落在正在編輯的欄位，頁面是否突然跳動。表單若有自動填寫，也要確認填入後欄位標籤及內容仍清楚可讀。

輸入法同樣重要。以中文輸入姓名或地址時，候選字列表可能遮住下一步；選日期的控制在不同裝置也可能呈現不同。測試者可嘗試正常、較長及留空的資料，觀察是否有明確回應。這些操作問題，不應只靠桌面模擬器推斷，最好由真實手機確認。

觀察記錄五：錯誤提示能幫人改對嗎

不要只在最上方寫「資料不正確」

送出表格後若有問題，使用者要知道是哪一格、錯在哪裏及如何修正。只有紅色外框，對部分人不夠明確；只有頁首一段籠統提示，若表格很長也容易找不到目標。W3C 的表單驗證教學可供設計及程式人員參考，測試時應用真實情境檢查語句是否可理解。

假設客人電郵打錯，應能在該欄附近得知要檢查格式，修正後不應失去已填的其他欄位。若檔案上傳超出限制，亦應寫清楚可用的類型或大小，而非只回覆一串技術代碼。使用者能繼續完成任務，才算錯誤處理有效。

成功畫面與內部收件也要對上

表格顯示提交成功，客人會預期公司已取得資料。內部需核對資料有否真正保存、通知有否送到應接手的人，以及重複按提交時如何處理。手機版測試不只是表面操作，還包括最後工作的結果。若未收到通知，應清楚記錄測試時間及內容，交由負責人排查。

若查詢改為直接聯絡 WhatsApp，仍需確認開啟後對象是否正確，預填訊息不應含有其他客戶資料。按了連結不等於已發出訊息，網站若有追蹤，亦須在報告中分清兩者。商戶不必在首輪手機檢查建構複雜分析，但必須知道客人嘗試聯絡後誰會回覆。

觀察記錄六：商品頁到結帳的細節

購物籃的決策資訊不能被固定按鈕蓋住

手機上的「加入購物籃」按鈕若固定在畫面底部，應留意它會否遮住規格、送貨限制、同意選項或表單錯誤。若按鈕點完後購物籃數量變了，亦要用文字確認加入的是哪件商品和數量，避免重複落單。選擇產品變體時，庫存或價格如有變化應同步展示；若資訊尚未確認，不能讓人以為上一個選項的價錢仍有效。

結帳前的摘要要讓客人容易返回修改，但不應一返回便失去剛填的地址與送貨選擇。測試可故意在最後一步刪一件商品，再回到確認頁核對總額。這類操作與寄存速度不同：即使頁面載入很快，資訊或狀態不同步，客人仍然會對結帳失去信心。

選項與存貨狀態要清楚可辨

手機網店常見尺寸、顏色和數量選項。選取後應能看清目前是哪個組合、對應價格與可售狀態，不能把顏色差異當作唯一提示。若客人改選另一個規格，商品圖片、說明與落單按鈕的狀態也應一致。從網上商店開發角度看，這些是交易資訊，不只是按鈕外觀。

讓測試者故意選缺貨與可售組合，再從購物籃返回頁面，觀察選項是否仍保留及是否能清楚更改。若一個按鈕寫「加入」，使用者卻不知道加入哪個規格，便要改善選項摘要。不要只用一款沒有變體的示例商品驗收整個手機購物流程。

付款、送貨資料在縮小畫面後仍須完整

結帳時的收貨地址、付款方法與最後確認可能分散多個步驟，應有清晰進度與返回方法。手機使用者切換到銀行或付款應用程式再返回，網站也要合理呈現目前訂單狀態。這些功能需要技術與營運一同測試，單靠設計稿不能證明付款真的完成。

若公司正進行網站改版及舊頁交接，手機商品頁亦要核對原有內容是否被縮成難以找到的標籤。新版可以重新安排段落，但應保留影響購買決定的資訊及正確網址路徑。手機訪客和桌面訪客都應看到一致的核心內容。

觀察記錄七：不同裝置與設定下，網站仍可用嗎

縮放與橫向顯示不應破壞操作

有人會放大字體，亦有人把手機轉成橫向。測試時可調整瀏覽器字體或頁面縮放，再核對導覽、表格和固定按鈕是否互相遮擋。設計並非要求每一種可能裝置都完全一樣，而是重要功能在常見變化下仍有路可走。若某個畫面只容許按極小圖示才能關閉提示，便值得優先修正。

公司內部有較舊或較新裝置時，可挑不同尺寸與瀏覽器做代表性測試，保留裝置、版本與重現步驟。單一截圖未必能說明問題是在網頁、瀏覽器還是輸入方式。不要只告訴開發人員「手機版唔好用」，應記下從哪頁開始、點甚麼及實際出現甚麼。

網絡較慢時，按鈕需有可理解回應

客人按提交後若畫面沒有任何變化，可能再次按下，形成重複查詢或訂單。應測試較慢連線下的等候提示及最終結果，讓使用者知道工作仍在進行還是需要重試。這篇重點在互動而非效能分數；如果只是某頁載入特別慢，技術人員還需另行追查圖片、程式或主機原因。

假設用戶在填寫中途網絡中斷，恢復後是否會失去整份內容，要看網站如何設計。公司可按表格重要程度提出合理期望，並讓技術人員評估可行方法。最基本的是不要把模糊的空白畫面當成已提交，也不要在可能已完成的情況下單叫客人再按一次而沒有核實。

把觀察寫成修正優先次序，而非印象評語

用同一張記錄表交代裝置、步驟與結果

一條可交付給設計及開發同事的記錄，應包含測試日期、裝置與瀏覽器、字體或輔助設定、原定任務、實際點擊次序、出錯畫面及預期結果。寫「手機版不好用」不足以讓人重現；寫「填完送貨地區，按返回購物車再進結帳，地區欄位清空」才可檢查。把重現方法寫清楚，也有助分辨是個別裝置、特定資料，還是所有用戶都會遇上的流程錯誤。

先修阻礙付款、提交查詢、找到聯絡資訊的問題，再修閱讀上的嚴重障礙，最後調整細微的視覺不一致。網站改動後，用同樣任務重測，特別留意修改手機選單會否影響桌面導覽。若計劃同時調整導覽文字、網址與頁面內容，可參考香港網站設計項目流程先把驗收和負責人列好，避免設計完成才發現核心任務未測。

記錄每項問題時，用「任務、起點、操作、實際結果、預期結果」五欄。假設手機使用者從服務頁點聯絡，表格欄位被鍵盤遮住而不能送出，這比「手機版排版一般」更能協助修正。可拍攝不含個人資料的畫面供對照，並記下裝置及畫面寬度；敏感查詢內容應用虛構資料重現。

排序先看會否阻止客人完成任務、是否影響重要訊息、出現範圍有多大，再看視覺細節。若錯誤集中在某個共用表格元件，修正後需抽查所有使用該元件的頁面。若只出現在一個很長的服務名稱，也要確認其他長內容是否會重現。這種分類能令團隊修正規則，而非每個截圖都做一次局部補丁。

1. 選擇三項最重要的手機任務，逐項寫下起點與成功結果。
2. 請未參與設計的同事操作並口述看見的資訊。
3. 記錄卡住位置、必要資料及可重現步驟。
4. 修正後重做同一情境，再抽查相近頁面。

驗收時要由真正使用任務作決定

手機版設計評審時，可以請同事各自完成三件事情：從首頁找服務範圍、由文章找對應服務、填妥聯絡表單。只需觀察完成與否、停在哪一個畫面、他如何理解按鈕文字，便能找出導覽與表單的主要阻礙。若只給測試者看樣板圖片，他無法體驗載入後的互動、鍵盤遮擋或提交後的錯誤。要把任務連到實際頁面，而非單張精美設計圖。

另一種驗收是由網店同事挑一件含不同規格的商品，故意選錯選項、返回修改、進入結帳後再改數量。從商品資訊、運費到確認頁，每個步驟都要核對狀態是否一致。請負責客戶服務的人看一次錯誤訊息：他能否根據畫面告訴客人怎樣修正？若不能，錯誤文案仍有改進空間。測試記錄交到設計團隊後，要指定覆核人和重測日期，才不會讓已解決的問題只停留在討論。

設計完成後仍須注意新增內容。日後加入一個更長的產品名稱或多一個導覽項目，可能令原本剛好放得下的手機版再次擠壓。交付時保存一組長標題、較大字體與多項商品的測試資料，供往後改版沿用；內容編輯亦應知道哪些資訊不能被手機版自動隱藏。

常見問題

手機上能縮小整個桌面頁，算不算響應式設計？

未必。若讀者仍要放大、左右拖動或用極小按鈕操作，實際體驗可能不合用。應測試閱讀、選單、表格及完成聯絡等核心任務，而不只看截圖能否完整放進畫面。尤其要確認重要內容在手機上沒有被隱藏。

網站有手機版，是否每個裝置都要一模一樣？

不需要。版面可以因畫面寬度而改變，但核心資訊與操作結果要保持一致。可以挑代表性裝置與不同字體設定做測試，記錄遇到的具體障礙，再按業務影響處理。若某些限制與實際功能有關，應讓使用者在操作前知道。

手機表格欄位愈少愈好嗎？

應只收集完成服務所需資料，同時提供足夠資訊讓公司接手。過多欄位會增加輸入負擔，過少又可能令同事無法回覆。先問每欄由誰使用、為甚麼需要，再測試錯誤提示及提交結果，比單純比較欄位數更有意義。

手機版測試可否只用瀏覽器縮窄視窗？

縮窄視窗可快速找出橫向溢出及版面問題，但觸控、虛擬鍵盤、瀏覽器返回與裝置設定仍應在真實手機核對。先用模擬方式篩出明顯錯誤，再由日常使用者實際走一遍核心路線，便能發現單靠桌面滑鼠較難察覺的障礙。

若公司準備設計或調整公司網站，可先用手機走一次客人最常做的工作，把卡住的位置與虛構測試資料帶來，與 Black Media 討論手機版操作改善。以實際任務排定修正，會比只憑外觀印象決定哪個畫面要改更清楚。