手機上能順利找到聯絡入口嗎？測試窄螢幕頁面操作路徑

從窄螢幕尺寸開始，實際走訪首頁、聯絡表單、按鈕、捲動與放大文字，整理可重現的手機操作阻塞。

手機訪客可能在移動中開啟網站，聯絡入口若藏在折疊選單、頁尾或被浮動元件擋住，就可能在尚未閱讀服務資訊前離開。以下用一段可重做的窄螢幕檢查流程，從首頁一路走到送出前確認，記下入口是否看得到、手指是否點得到、表單是否能完成。測試目標是找出操作阻塞，不替換網站訊息或表單欄位策略。先用未放大的畫面走完一次，再調整文字大小重走；每輪只記一個卡點和重現步驟，方便和修正後的結果比較。這份紀錄可交給網站維護者重現，判斷入口、捲動或輸入哪一步需要處理。

選定手機測試尺寸

先固定測試畫面的寬度，否則同一頁在不同裝置上出現的換行和遮擋，很難分辨是版面問題還是操作差異。可用瀏覽器開發者工具的裝置模式，或手邊手機的直向畫面；記下視窗寬度、方向、瀏覽器縮放和是否登入。以下寬度是方便檢查的測試點，不是機型排名或市場占比。每個尺寸都從相同首頁開始，沿相同路徑走到聯絡區，便於重現差異。

從最窄尺寸開始，先觀察頁面有沒有整體橫向溢出，再確認文字、導覽與主要操作是否可用。若窄版失敗、寬版正常，先保留兩個尺寸的截圖和網址，不要立刻調整元件；後續要能重開相同尺寸，才看得出修正是否只移動問題。若只能用真機，記錄手機型號、直向或橫向和瀏覽器名稱即可。重點是每輪保持條件一致，不必蒐集所有市售機型。設定完成後，先截一張沒有捲動的首屏，並確認測試工具呈現的是頁面寬度而非整個桌面視窗寬度。若使用真機，可截圖後在相簿查看實際比例；若鍵盤或瀏覽器介面改變可見高度，另記當時是否有鍵盤開啟。每次回到入口前重新載入，避免選單狀態或表單殘值影響觀察。若網站依登入狀態顯示不同內容，把條件寫進紀錄，不要混合比較。每輪開始前清除舊的輸入內容，避免不同測試互相影響。

從首頁尋找入口

把自己當成第一次到站的訪客，從首頁頂端開始，不用搜尋網站內部連結，也不要先知道入口在哪。先看首屏能否辨認下一步；若聯絡入口在選單裡，點開後確認文字與目標清楚，再返回原頁繼續往下。若入口在頁尾，使用正常手勢捲動，留意是否因大量區塊而失去方向。每次只用頁面已呈現的導覽和連結，這樣測到的是一般訪客可走的路，而不是測試者的捷徑。

記下入口首次出現的位置：首屏、開啟導覽後、特定內容區，或頁尾；再記從首頁到該處需要幾次明確操作。操作次數本身不是通用好壞標準，應和任務是否容易理解一起看。若需要猜入口藏在何處，記下猜測過程；若看見入口卻不確定會到哪頁，也要記錄連結文字和實際目的地是否一致。一次測試只走一條自然路徑，避免同時點選多個入口，否則很難定位中途的迷失點。入口位置也要連續觀察兩次：一次直接從初始頁面尋找，一次在閱讀一段內容後返回頂端，再找相同入口。若位置改變或置頂列收合，描述畫面如何變化，不推定訪客一定會採用某種手勢。這能區分入口不明顯與頁面狀態變化造成的困惑。

可以請未參與網站製作的人做一次任務測試，口頭指示「找到可以提出需求的入口」，觀察對方是否停頓、返回或反覆開關選單。不要在旁邊提示按哪裡；完成後再問哪一段最不確定。若暫時只有自己測，就把畫面錄下來，隔一段時間重看停頓位置，避免熟悉頁面後自動忽略不明顯的入口。記錄實際看到的情況，不把個人偏好直接當成所有訪客的行為。

完成聯絡資料填寫

找到入口後，繼續完成頁面提供的聯絡流程，觀察輸入和校正是否順手。若頁面要求姓名、可回覆的聯絡方式或需求說明，逐項照頁面既有欄位填寫，不靠預填資料替訪客猜答案。測試文字可以使用清楚標記的虛構內容，例如「測試姓名」、「test@example.com」和一句不含個資的需求摘要；不要使用真實客戶資料，也不要真的送出正式諮詢。若表單有必填提示，確認提示在窄螢幕上仍看得見，並觀察錯誤訊息是否靠近需要修正的位置。

逐欄輸入時，注意鍵盤彈出後目前欄位有沒有被遮住，下一欄是否能滑到，輸入游標是否因觸碰其他區域而跳走。完成一段文字後先收起鍵盤，再檢查內容是否被截斷或仍留在欄位內；有自動格式或字數限制時，以頁面明示規則為準，不自行推測上限。可用複製貼上的方式檢查長文字，也要手動輸入一次，因為兩種方式可能帶來不同的游標和換行狀態。若瀏覽器提供不同輸入法，可用中文鍵盤填一次，再改用英文鍵盤填聯絡方式；觀察鍵盤的下一步或完成操作能否移到下一欄，若不能，記錄手動點選是否仍可用。重點是流程連續，不是輸入速度。

若流程需要驗證碼、附件或同意項目，只記錄實際顯示的步驟與阻塞，不把未知規則寫成網站功能。每次測完清除虛構資料，回到乾淨狀態再重走，避免前一輪的欄位內容掩蓋問題。成功標準是訪客能看懂每個欄位目前狀態、修正自己輸入的內容，並在送出前確認將提供的資料；測試者則停在送出按鈕之前，不製造真實名單或外部通知。

檢查按鈕與捲動

窄螢幕的按鈕不能只在截圖裡完整顯示，還要能被手指準確觸碰。沿路測試選單、聯絡連結、表單欄位、核取控制和送出前操作；每次點擊後確認發生的變化符合預期。若點到旁邊的文字、空白處或其他連結，記下誤觸位置和當時的畫面，不要只寫「按鈕太小」。按鈕彼此靠近時，可用不同手指位置重試幾次，確認邊界是否容易分辨。這是操作觀察，不替網站臆造固定的像素標準。

接著由上往下逐段捲動，看看固定在頂端或底部的導覽是否蓋住標題、提示與表單按鈕。捲到頁尾後再往回找聯絡區，確認使用者能否辨識目前位置；若頁面很長，可觀察回頂端控制是否清楚，但不要把它當成必要功能。橫向滑動若意外觸發，檢查是否有內容超出畫面；只在特定區塊需要橫向瀏覽的情況，則確認使用者看得出該區塊可滑動。再測一次返回上一頁後前進，確認位置和已輸入資料是否符合預期；若資料不保留或頁面回到頂端，照實記錄，不假設一定是錯誤。點外部連結後也確認返回路徑，並停在正式送出之前。

可以用下面的記錄方式，把模糊感受轉成可重現情境：

以上尺寸與情境只是示範記錄，不是實測結果。先確認問題在相同尺寸、相同步驟是否重現，再交給負責網站的人判斷原因，避免只憑一次滑動就改版。

放大文字再走一次

一般字級下完成路徑後，再調高手機系統文字大小或瀏覽器縮放，依序重做首頁尋找、進入聯絡區和表單檢查。縮放可能改變換行、區塊高度與固定導覽的位置，因此要特別看文字是否被裁切、按鈕是否被推到容器外，以及同一行文字是否擠壓旁邊控制。記下實際調整方式與檔位名稱，不把某個裝置的百分比當成通用門檻；若使用瀏覽器縮放，也要確認縮放後的視窗寬度和一般測試相同，避免把兩項變因混在一起。

逐一確認標題、說明文字、欄位提示、錯誤訊息和連結都能讀完。放大後若導覽改成多行，入口是否仍清楚；若按鈕文字換行，按鈕高度是否跟著完整展開；若表單變長，送出前檢查是否仍能回看已填內容。不要只檢查首頁，因為鍵盤、提示或較長表單可能讓後段才出現問題。放大測試也不是要求所有內容維持原本排版，而是確認閱讀與操作目的仍可達成。比對時固定同一個標題或按鈕作定位點，截取放大前後畫面，檢查首頁、中段和表單尾端，避免只看第一屏；長文字折行可能逐步推移後續控制位置。

發現問題時，先截下放大前後相同位置，並記下是閱讀受阻、操作受阻，還是單純視覺排列改變。若文字變大後需要多捲幾次，但沒有遮擋或失去方向，應記錄為版面變化，而非直接判定失敗；若重要說明被截掉、欄位無法聚焦或關鍵操作被蓋住，則標成阻塞並提供重現步驟。這樣能讓修正者分辨哪些是可接受的重新排版，哪些會讓訪客無法完成聯絡。

整理裝置與阻塞點

每輪結束後，把裝置條件和任務結果放在同一筆紀錄：測試日期、手機或模擬器、視窗寬度、方向、瀏覽器、文字大小、起點網址，以及走到哪一步。結果可以用「完成」、「需猜測」、「誤觸」、「被遮擋」、「無法繼續」等描述，但要附上具體畫面與操作，不用單一分數代替原因。若某一步因測試者不熟悉而停頓，重做一次確認；若只有特定寬度會卡住，也記下正常的對照寬度，讓問題範圍明確。

整理時先分清影響：入口難找、入口點不到、輸入中斷、內容讀不全、送出前不能核對。每項只寫一個主要阻塞，並附重現路徑，例如「直向、窄版、首頁開選單、點聯絡連結後返回時，入口不再明顯」。標註截圖檔名或錄影時間點，避免只留「手機版不好用」這類無法採取行動的結論。若問題無法重現，就記下測過的條件和結果，先不要把它定為已確認缺陷。交給修正者時，可用「條件、起點、操作、預期、實際」五項整理，不用先寫解法；例如直向窄版從首頁開始，展開選單後尋找入口，原本預期看清聯絡路徑，實際卻被浮層擋住。這只是示範情境，不是 ZhenheAI 的實測結果。完成修正後照同一條路徑重測，保留前後截圖，也檢查其他尺寸沒有新遮擋。

下一步可先挑最影響完成任務的一項，請網站負責人用相同裝置條件重現，再確認修正後是否仍能從首頁走到表單送出前。若你正要檢查自己的網站，現在就選一個最窄的測試寬度，從首頁親手走一次並留下第一張阻塞截圖；需要了解 ZhenheAI 的網站資訊，可從官方首頁開始。