把頁面分工寫成一張路線表
| 頁面角色 | 主要問題 | 下一步 |
|---|---|---|
| 首頁 | 公司幫邊類客戶處理甚麼？ | 進入合適服務、案例或公司資料。 |
| 服務頁 | 範圍、交付物及合作條件係甚麼？ | 查詢、比較相關方案或閱讀必要說明。 |
| 文章／指南 | 具體問題應該點判斷或處理？ | 相關指南、對應服務或有上下文嘅查詢入口。 |
| 案例 | 某個情境用咗甚麼做法？ | 相關服務及方法限制，避免只見到作品圖。 |
| 公司與聯絡資料 | 由誰提供服務，點樣聯絡？ | 可用聯絡渠道及需要嘅網站資料。 |
示範：把內部分工改成訪客睇得明嘅名稱
虛構 B2B 技術公司若只用「Solutions、Innovation、Synergy」，新客未必知道邊度有保養範圍。可以先比較「設備保養」、「故障維修」、「項目案例」等服務或任務名稱，再由頁面內文解釋技術能力。唔係所有網站都要用同一組標籤，應以實際服務同使用測試決定。
連結文字要講清楚目的地
Google 一般可透過帶有 href 嘅 a 連結發現頁面。製作時要同時檢查訪客是否可以操作、連結是否真係去到相關內容，以及文字是否足以理解目的地。唔好把不同服務全部連返首頁，亦唔好用一長串重複關鍵字代替有意義嘅名稱。
文章中嘅「服務頁報價應交代哪些條件」有具體上下文；一堆冇說明嘅「更多」就要靠訪客估。重要而公開嘅頁面亦應有合理來源入口，避免只存在 sitemap 或要依賴網站搜尋先搵到。
手機選單同鍵盤都要實測
- 選單控制項有清楚名稱；展開同收合狀態可以辨認。
- 子選單可以用點擊與鍵盤操作，唔只依賴滑鼠 hover。
- 焦點次序同視覺順序合理，訪客可以離開選單而唔被困住。
- 目前所在頁面或分類有適當提示；麵包屑反映頁面關係，而非假裝係使用歷程。
- 放大文字或使用窄畫面時，名稱仍可讀，內容唔會被切走。
改導覽之前，先保留網址對照
改選單名稱未必需要改網址。若確實要合併或移動頁面，先記錄舊網址、相關新目的地、內部來源連結同需要保留嘅參數；逐項測試轉址結果。將所有舊頁轉去首頁，會失去原有內容上下文，亦唔等於完成遷移。
導覽交收檢查
- 列出重要服務、案例、指南與公司資料，確認各自有清楚頁面角色。
- 由首頁、相關文章及服務頁出發，實測能否完成指定任務。
- 檢查全部選單、麵包屑與內文連結，確認目的地、狀態及內容相符。
- 找出冇合理內部入口嘅重要頁面，補上相關位置嘅連結；唔以到處塞連結處理。
- 用手機及鍵盤展開、選擇、返回與收合選單。
- 改版後再抓取網站，核對失效連結、轉址及原有重要頁面是否仍可到達。
常見問題
所有頁面都要三次點擊內到達嗎？
唔應只靠固定次數判斷。先看任務是否清楚、標籤是否可預期及途中是否出現死路；重要服務可以較直接，複雜資料則需要合理分類。
麵包屑可唔可以取代主選單？
兩者用途不同。麵包屑協助理解所在層級，主選單則提供主要路徑；實際設計要按內容規模及訪客任務測試。
下一步與延伸閱讀
官方參考與更新說明
本文嘅規劃表、測試步驟及示範情境由 ITOB Group 編輯團隊整理；示例並非客戶成效紀錄。最後實質更新：2026 年 10 月 25 日。
