線框圖與原型怎麼用：先驗證流程再修視覺

一張完成度很高的預約頁，看起來已經可以上線，點進去卻只有一條能走完的路徑：不能返回、不能改日期，也沒有額滿狀態。這樣的畫面可以用來討論視覺，但若想知道使用者能不能完成預約，就需要不同的準備。

本文以原創到府植栽照護預約為練習，方法參考 2026 年 9 月 14 日查閱的 NN/g 與 GOV.UK 資料。服務、畫面狀態和測試任務均自行設計，沒有真實預約或受測者結果；原型的角色是協助學習與決策，不代表已完成可營運系統。

先說明要驗證什麼，再選交付形式

線框圖主要表達畫面結構、內容順序與操作位置；視覺稿進一步呈現字型、色彩及細節；原型則用來模擬某些互動或服務行為。團隊對這些名稱可能有不同用法，交付前最好直接說明哪些部分可操作、哪些只是示意。

如果要討論植栽照護頁應先介紹服務範圍還是價格，簡單線框圖就能開始對話。如果要看使用者是否能更換時段，則需呈現點擊、返回和資料保留的反應。把多張畫面連成帶有操作箭頭的流程，也能幫助大家理解畫面間的關係。

不要只用高保真或低保真概括所有細節。NN/g 說明保真度可以分別表現在互動、視覺與內容上：畫面雖然只有灰階，仍可使用接近正式的文字；視覺稿很精緻，也可能完全不能互動。選擇時應以研究問題決定需要逼真到哪裡。

為任務準備足夠的內容與狀態

原創預約練習可設定服務只到特定區域，需要選日期、時段與填寫聯絡方式。先列出任務開始在哪裡、完成時會看到什麼，以及返回修改時哪些資訊應保留。這份範圍表能避免只畫成功頁，卻沒有通往它的完整操作。

依本次要驗證的問題，補上重要分支，例如地址不在服務範圍、時段額滿、必填欄位未填與送出後的確認。並非每次都要模擬所有後端狀況；但若某個分支會影響研究任務，就不能在參與者碰到時才臨時說這一頁不重要。

文字長度和內容也會影響判斷。用全部相同的假日期或無意義文字，可能掩蓋資訊難找的問題。可以使用合理的虛構服務資料，清楚標示不會成立預約；需要真實資料才能驗證的情境則另外規劃，不在簡單原型中收取住址或付款資訊。

讓測試任務有情境，但不要提供操作答案

先寫下想觀察的使用目標，再轉成參與者能理解的活動。例如你週六下午在家，希望安排一次植栽照護，請找出符合需求的時段並完成這份練習預約。這提供選擇條件，卻沒有直接告訴他應點哪個選單或按鈕。

如果要測返回修改，可在適當階段加入新條件：原先的時段臨時不方便，請改選另一個可配合的時間。不要把任務寫成按上一頁再點右側下拉選單，否則測到的主要是能否遵照指令，而不是能否自己找到操作方式。

先定義可觀察的完成條件，例如確認頁顯示預期日期與時段，再決定要記錄哪些困難。偏好詢問可放在操作之後，用來了解理由；單純問你會不會使用，和真正觀察一次練習任務，能提供的證據不同。不要只收滿意度就宣稱流程已經順暢。

排演原型，避免把製作缺陷當成設計問題

正式邀請參與者前，自己走過預計測試的路徑，核對起始畫面、點擊區、返回、捲動與連結。若採紙本原型，先整理畫面順序並約定誰負責切換。這是檢查研究工具能否運作，不是替真正的使用者測試預先寫出成功結果。

進行時先取得研究同意，解釋這是尚未完成的原型，以及哪些操作不會真的執行。請參與者盡量說出當下想法，主持人以觀察與聆聽為主。需要協助繼續時，記錄何時介入、提供什麼提示，方便之後判讀資料。

如果按鈕沒有設定連結，導致參與者停住，先分清是原型故障還是設計不清楚。可詢問他原本預期會發生什麼，但不要把這次停頓直接列為正式服務的缺陷。修好原型後再確認；若版本在測試間變動，也要留下版本與時間。

1. 寫出研究問題及完成條件，決定需要的內容、視覺與互動程度。
2. 整理任務流程、例外狀態和測試資料，製作範圍明確的原型。
3. 排演連結與切換，準備中性任務並取得參與者同意。
4. 記錄操作、提示與版本差異，選擇要修改的問題再安排驗證。

把觀察轉成可追查的修改紀錄

建議用任務、畫面、觀察、影響與下一步整理每個問題。若參與者返回後發現日期被清空，先記錄發生在哪一版、是否影響完成，以及有沒有尋求協助。再討論是否保留日期、補上提示，或重新安排修改流程。

問題優先順序可以綜合是否阻止任務、是否造成錯誤選擇，以及影響哪些情境來判斷。不要只按大家提到的次數排序；一個出現較少但可能導致錯誤預約的問題，也值得先查明。少量質性資料的次數不等於整體使用者的發生率。

修改後保留前後版本和判斷理由，讓團隊知道是哪個觀察促成變更。如果要比較兩版，注意先前看過的內容可能影響後續操作，不能把第二次較快完成直接歸因於新版。需要量化比較時，應另外設計一致條件及合適的研究方式。

原型完成後，還有正式產品的驗收

可點擊原型能檢查特定理解與流程，通常不能驗證真實付款、資料儲存、權限、效能或所有輔助科技行為。GOV.UK 的 alpha 指引也將早期原型與正式品質程式分開。把原型交給開發時，要一併交代哪些內容仍是假設或模擬。

植栽照護示例即使能完成預約演示，正式服務仍需處理時段是否同步、多人同時預約、通知寄送及取消規則。這些問題可以在原型階段提早提出，但不能因為畫面演示成功，就宣稱後端和營運流程也已經通過測試。

完成交接時附上流程圖、狀態說明、測試發現與未處理問題，並安排實際產品階段的驗證。原型不一定要保留為程式碼，也不必無限精修。當它已提供足夠資訊支持下一個決定，就可以整理證據，進入相應的設計、開發或研究工作。

從生活問題開始練習設計思考

補齊網站專案的正式驗收

理解響應式畫面與實際裝置檢查

• 教學
• 軟體與 App
• 架站與電商
• 網域、主機與前端