LESSON-23｜專案規劃與設計

先理解：這堂課解決什麼問題？

在開始寫四頁網站前，先把目標商家、訪客角色、頁面責任、主要任務與驗收證據寫成一份不需要猜測的規劃檔；本堂只做規劃，不連外部服務、不部署。

本堂要完成：完成一份 planning-only project brief：列出首頁、服務、關於、聯絡四頁，為每頁寫出責任，建立四個 user tasks，分配 P0/P1/P2，並留下至少四項可重現驗收證據。

學習邊界：先完成「把服務型商家需求整理成可執行的 project brief」，不提前引入尚未教過的框架或建置工具。

先備知識與操作環境

本堂不要求先會 HTML、CSS、JavaScript、框架或部署。只要會用編輯器建立與儲存純文字檔案、用瀏覽器開啟 HTML、按右鍵開啟 DevTools，並能閱讀頁面、Elements、Console 與鍵盤 focus。先開啟 examples/minimal.html，再進入 Starter；本堂只做 planning-only 規劃，不建立真正四頁、不連外部服務、不部署。

檔案位置：先找到 examples/minimal.html、project-brief.md、index.html、style.css、main.js、evidence.md，再從本頁的最小實驗開始。
瀏覽器：開啟最小實驗與階段頁；每次修改後儲存並重新整理。
DevTools：依本堂內容使用 Elements、Styles、Computed、Console 或 Network，記下第一個可觀察證據。
操作習慣：每次只修改一個檔案或一個責任，先預測、再操作、最後驗收。

先做最小實驗：先看見結果

這不是期末網站，而是一個可以直接看到本堂核心結果的最小實驗。先完成一次操作，再回到檔案和名詞卡對照。

開啟本堂最小實驗

入口：開啟 examples/minimal.html。
操作：開啟 examples/minimal.html，先數四個頁面項目，再按『檢查清單數量』，最後只用 Tab 走到按鈕並按 Enter。
預期：畫面保留四個規劃項目；status 顯示實際項目數，Console 顯示同一個 count；沒有外部請求或正式資料寫入。
重設：重新整理 examples/minimal.html；它是只讀最小實驗，不要在這裡加入自己的商家內容。

第一個檢查位置：先確認目前 URL 是 examples/minimal.html，再在 Elements 找 #page-plan、#status 與 #check-plan。
成功證據：畫面保留四個規劃項目；status 顯示實際項目數，Console 顯示同一個 count；沒有外部請求或正式資料寫入。若不同，先檢查：先確認目前 URL 是 examples/minimal.html，再在 Elements 找 #page-plan、#status 與 #check-plan。

學生練習流程

依序完成每一張卡；目前只聚焦一個步驟，先操作，再用可觀察證據確認結果。

1
最小實驗

先閱讀本頁的問題、檔案地圖、名詞卡與最小例子。
2
Step 2

自己回答互動問答 4 題，再展開解析。
3
最小實驗 2

開啟最小實驗，實際操作一次並記下證據。
4
Starter

把 Starter 複製到自己的工作資料夾，照 4 張微步驟卡逐一完成；每一步都要看到結果再繼續。
5
Checkpoint

前往 Checkpoint，只處理 1 個本堂核心缺口；先預測，再用指定證據驗收。
6
Solution

前往 Solution，先看逐檔差異與修改原因，再決定要不要把完整內容帶回自己的檔案。
7
變體驗收

完成情境變體與獨立挑戰，留下檔案位置、操作、結果與驗收證據，並閱讀下一堂銜接：首頁與共用外框：下一堂會依照這份規劃先完成多頁網站的共同骨架。

檔案地圖：每個位置負責什麼？

先不要急著背檔名；請把檔案位置和責任連起來。你在階段頁會看到同一份檔案的可執行版本。

examples/minimal.html只讀最小實驗：先觀察四頁規劃清單與實際 li 數量。
starter/files/project-brief.mdStarter 規劃檔：依序補上角色目標、Sitemap、user tasks 與 priority。
starter/files/index.htmlStarter 預覽入口：把規劃結果呈現成可觀察的四頁清單。
checkpoint/files/project-brief.mdCheckpoint 規劃檔：故意只留一項 checklist，供學生找出驗收契約缺口。
solution/files/project-brief.mdSolution 規劃檔：完整列出四頁、四個任務、優先級與五項驗收條件。
solution/files/evidence.mdSolution 證據紀錄：示範如何寫修改檔案、操作、預期、實際與結果。

先學會這些詞

先從名詞、英文與白話意思開始；每次只展開一張名詞卡，再對照正式定義、範例與驗收證據。專業術語、語法、檔案路徑會使用不同樣式。第一次遇到術語時，先回到這裡，不要靠猜。

本堂 8 個詞先選一組，再展開需要的名詞卡；每次只保留目前的學習焦點。

project briefproject brief 白話意思：開始製作前用來對齊目標、範圍與驗收方式的規劃文件。展開查看正式定義、範例與驗收證據

正式定義: 以商家目標、訪客角色、頁面責任、使用者任務與驗收條件描述專案邊界的文件。
什麼時候用: 還沒有開始建立四頁網站，需要先讓設計、開發與商家對同一份結果有共識時。
最小範例: project-brief.md 先寫目標商家、四頁 Sitemap、四個 user tasks 與 Acceptance checklist。
可觀察證據: 讀者能從檔案說出誰要完成什麼、在哪一頁完成，以及如何確認完成。
容易混淆: 和完整網站混淆；brief 是規劃契約，不代表 HTML、表單或部署已完成。

sitemapsitemap 白話意思：把網站有哪些頁面、檔名與彼此入口列出來的地圖。展開查看正式定義、範例與驗收證據

正式定義: 描述網站頁面節點、URL 與導覽關係的規劃模型。
什麼時候用: 要從需求決定頁面範圍，或要避免漏頁、重複頁時。
最小範例: index.html、services.html、about.html、contact.html 四列表格。
可觀察證據: Sitemap 每列都有 URL、頁面責任與主要 CTA，四個檔名可被逐一對照。
容易混淆: 和內容大綱混淆；sitemap 先說頁面與路徑，內容大綱才深入頁面內文。

page responsibilitypage responsibility 白話意思：每一頁主要負責回答一個問題或推動一個下一步。展開查看正式定義、範例與驗收證據

正式定義: 以頁面 URL、核心內容、主要行動與不負責事項界定頁面邊界的方法。
什麼時候用: 四頁以上開始互相重複，或不知道一段內容應放在哪一頁時。
最小範例: services.html 負責比較方案；about.html 負責建立背景信任。
可觀察證據: Sitemap 的四列各自有不同責任與 CTA，沒有四頁都寫同一句話。
容易混淆: 和頁面上有多少區塊混淆；責任是訪客結果，不是區塊數量。

user taskuser task 白話意思：用訪客角度描述他要完成的操作與結果。展開查看正式定義、範例與驗收證據

正式定義: 以角色、情境、行動與目的描述可觀察使用者行為的需求句子。
什麼時候用: 要判斷頁面或功能是不是必要，或要把抽象需求變成驗收案例時。
最小範例: 當我是第一次訪客，我想理解服務並前往服務頁，以便判斷是否適合。
可觀察證據: 句子包含訪客、動作與結果，可以在頁面或流程中指出驗證位置。
容易混淆: 和功能清單混淆；user task 從訪客結果出發，不是只列『有按鈕』。

prioritypriority 白話意思：決定先完成哪一件事的排序標記。展開查看正式定義、範例與驗收證據

正式定義: 用 P0、P1、P2 等層級表達需求在核心流程中的相對優先順序。
什麼時候用: 時間有限，需要先保護主要轉換或先分辨必要與加分項目時。
最小範例: P0：理解服務並送出諮詢；P2：快速回到服務頁。
可觀察證據: 每個 user task 有優先級，學生能說明為什麼 P0 比 P2 先驗收。
容易混淆: 和重要性形容詞混淆；priority 要能導向具體的取捨順序。

acceptance checklistacceptance checklist 白話意思：完成前逐項打勾的檢查清單。展開查看正式定義、範例與驗收證據

正式定義: 將需求轉成可重現的條件、操作、預期結果與證據位置的驗收規格。
什麼時候用: 要交付、請別人接手，或需要判斷『完成』不是憑感覺時。
最小範例: 四頁檔名、P0 任務結果、390px 與純 Tab 操作各有一項 checklist。
可觀察證據: 每一項都能指出檔案、操作、預期與實際證據，而不是只寫『做好了』。
容易混淆: 和待辦清單混淆；待辦描述要做什麼，驗收清單描述怎麼證明完成。

CTAcall to action 白話意思：頁面希望訪客下一步採取的主要行動。展開查看正式定義、範例與驗收證據

正式定義: 依頁面責任選出的主要操作入口，例如前往服務頁或開始諮詢。
什麼時候用: 頁面內容已經說明背景，需要安排訪客下一步時。
最小範例: 首頁 CTA：查看服務方案；聯絡頁 CTA：送出諮詢。
可觀察證據: Sitemap 每列有主要 CTA，user task 能對應到這個行動與結果。
容易混淆: 和所有連結混淆；CTA 是主要下一步，不是頁面上每一個可點擊文字。

planning-onlyplanning-only scope 白話意思：這堂課只完成規劃，不假裝已完成真正網站整合。展開查看正式定義、範例與驗收證據

正式定義: 明確限制教材只處理需求、頁面、任務、優先級與驗收契約，不建立正式頁面、外部服務或部署。
什麼時候用: 技術範圍容易膨脹，或學生想提前加入尚未教過的框架、後端與上線設定時。
最小範例: 本堂用離線預覽列出四頁，但不建立四個正式 HTML，也不送出任何外部資料。
可觀察證據: README、project-brief.md、stage files 都能找到相同的範圍邊界。
容易混淆: 和完整網站完成混淆；規劃可以先被驗收，不等於任何實作已上線。

最小例子：先看懂，再複製

這段只保留本堂第一個微成果。先預測結果，再逐行讀；完整檔案請開啟下方最小實驗。

目標商家：安心到府服務
訪客：第一次尋找居家維護的屋主
目標：理解方案後送出諮詢

Live Lab：逐段讀碼與驗證

每一步只回答五件事：為什麼做、改哪裡、會看到什麼、用什麼證據確認、卡住先查什麼。

Step 1
先寫出目標商家與訪客

目的
讓學生先知道規劃不是列喜好，而是先說清楚誰要使用網站、要完成什麼結果。

修改位置
project-brief.md 的角色與目標
寫出目標商家、訪客角色與一句話目標，保留『誰、做什麼、得到什麼』三個資訊。

預期結果
讀者可以用一句話說出網站服務誰，以及訪客完成什麼結果。

驗收證據
project-brief.md 的角色與目標區塊；學生口頭重述誰、做什麼、得到什麼。

卡住先查
只檢查角色與目標三行，不先修改 sitemap 或 HTML。
Step 2
把四頁責任放進 Sitemap

目的
讓每個頁面有單一主要責任，後續建立 HTML 時不必猜內容要放哪裡。

修改位置
project-brief.md 的 Sitemap table
建立 index.html、services.html、about.html、contact.html 四列，為每列寫頁面責任與主要 CTA。

預期結果
四個檔名、四個責任與四個 CTA 可以逐列對照，沒有把四頁混成一頁。

驗收證據
Sitemap table 四列；每列可指出檔名、唯一責任與主要 CTA。

卡住先查
只先核對四個檔名是否完全等於四個實際規劃 URL。
Step 3
把需求寫成 User tasks 與優先級

目的
把抽象需求變成訪客動作，再用 P0/P1/P2 決定先完成哪一類結果。

修改位置
project-brief.md 的 User tasks 與 Priority
用『當……我想……以便……』寫四個任務，並分配 P0、P1、P2。

預期結果
每個任務都有角色、動作與結果；P0 是本次最先保護的核心路徑。

驗收證據
User tasks 表格、Priority 區塊與學生能說明 P0/P1/P2 的理由。

卡住先查
只圈一個任務，檢查是否同時有訪客、動作與以便後的結果。
Step 4
用離線預覽看見規劃結果

目的
讓 Markdown 規劃先有一個可以在瀏覽器觀察的最小入口，但不誤認成已完成真正網站。

修改位置
index.html 的 #page-plan、#baseline-status 與 button
在 #page-plan 放入四個規劃項目，保留狀態文字與可操作按鈕，讓 main.js 讀取實際 li 數量。

預期結果
瀏覽器看見四個頁面項目；按鈕後 status 與 Console 顯示實際數量，Tab 可聚焦按鈕。

驗收證據
畫面四個 li、#baseline-status 的實際文字、Console 的數量與鍵盤 focus。

卡住先查
只檢查 #page-plan 是否存在，以及 main.js 是否用 querySelector 讀到它。
Step 5
把 Acceptance checklist 補成可重現條件

目的
把完成標準從一句模糊描述變成之後可以逐項檢查的交付契約。

修改位置
project-brief.md 的 Acceptance checklist
補上四頁檔名、P0 任務、390px／Tab 與 evidence.md 格式三項條件。

預期結果
checklist 有四項，而且每項都能指出檔案、操作或可觀察證據。

驗收證據
project-brief.md 的四項清單、evidence.md 的紀錄欄位與一次實際填寫。

卡住先查
只數 checklist 項目是否為四項，再對照每項是否包含可觀察位置。
Step 6
用變體檢查規劃是否可移植

目的
確認學生學到的是規劃方法，而不是只會複製安心到府服務的文字。

修改位置
project-brief.md 與 evidence.md
把商家改成到府清潔，保留四頁、四個 user tasks、P0/P1/P2 與驗收欄位，只替換內容。

預期結果
變體能說明哪些結構不變、哪些商家內容改變，且沒有新增外部服務、框架、部署或正式資料。

驗收證據
變體 brief、原始與變體差異紀錄，以及一次重新檢查四頁與四個任務。

卡住先查
先只列『保留』與『替換』兩欄，不先改 HTML 或 JavaScript。

操作層級Live Lab 段落導覽：切換六個實驗步驟

讀碼順序：先找入口，再找被引用的檔案，最後用畫面、DOM、Console、Network 或資料結果驗證。

互動問答

先回答目前這一題，再展開解析；完成後按下一題，讓每一次回答都回到檔案或瀏覽器完成驗證。

Q1概念理解「project brief」在本堂要解決什麼問題？本題線索：project brief；回到名詞卡與讀者能從檔案說出誰要完成什麼、在哪一頁完成，以及如何確認完成。展開解析收合解析

白話解析：

開始製作前用來對齊目標、範圍與驗收方式的規劃文件。正式來說，以商家目標、訪客角色、頁面責任、使用者任務與驗收條件描述專案邊界的文件。

對照位置：

回到名詞卡「project brief」，再看讀者能從檔案說出誰要完成什麼、在哪一頁完成，以及如何確認完成。

預期觀察：

你應該能用自己的話說出：還沒有開始建立四頁網站，需要先讓設計、開發與商家對同一份結果有共識時。

常見錯誤：

不要只回答「它是project brief」；那是重複名詞，不是說明責任。

立即驗證：

開啟 examples/minimal.html，依序做「開啟 examples/minimal.html，先數四個頁面項目，再按『檢查清單數量』，最後只用 Tab 走到按鈕並按 Enter。」並記下畫面或工具證據。

Q2程式碼閱讀修改指定規則後，你預測畫面會看到什麼？本題線索：project-brief.md 的角色與目標；要修改：寫出目標商家、訪客角色與一句話目標，保留『誰、做什麼、得到什麼』三個資訊。；觀察：project-brief.md 的角色與目標區塊；學生口頭重述誰、做什麼、得到什麼。展開解析收合解析

白話解析：

先看檔案責任，再預測結果。這一步的目的：讓學生先知道規劃不是列喜好，而是先說清楚誰要使用網站、要完成什麼結果。

對照位置：

對照 Live Lab Step 1，位置是 project-brief.md 的角色與目標；範例內容：目標商家：安心到府服務訪客：第一次尋找居家維護的屋主目標：理解方案後送出諮詢

預期觀察：

讀者可以用一句話說出網站服務誰，以及訪客完成什麼結果。

常見錯誤：

如果只改了檔案但沒有結果，先不要重寫全部；只檢查角色與目標三行，不先修改 sitemap 或 HTML。

立即驗證：

實際操作後檢查 project-brief.md 的角色與目標區塊；學生口頭重述誰、做什麼、得到什麼。。

Q3概念比較「project brief」和「sitemap」在本堂的責任有什麼不同？本題線索：比較 project brief 與 sitemap；操作位置：project-brief.md 的 Sitemap table 展開解析收合解析

白話解析：

project brief：開始製作前用來對齊目標、範圍與驗收方式的規劃文件。；sitemap：把網站有哪些頁面、檔名與彼此入口列出來的地圖。

對照位置：

對照兩張名詞卡的正式定義：以商家目標、訪客角色、頁面責任、使用者任務與驗收條件描述專案邊界的文件。／描述網站頁面節點、URL 與導覽關係的規劃模型。

預期觀察：

你應該能指出兩者分別出現在哪個檔案或工具，以及哪一個結果會改變。

常見錯誤：

不要把「改變畫面」當成所有技術的責任；先說清楚誰負責結構、呈現、行為或驗收。

立即驗證：

在 project-brief.md 的 Sitemap table 做「建立 index.html、services.html、about.html、contact.html 四列，為每列寫頁面責任與主要 CTA。」，再用 Sitemap table 四列；每列可指出檔名、唯一責任與主要 CTA。比較前後差異。

Q4除錯驗收如果完成操作後結果不對，你會先從哪一個證據開始查？本題線索：project-brief.md 與 evidence.md；第一個檢查位置：變體 brief、原始與變體差異紀錄，以及一次重新檢查四頁與四個任務。展開解析收合解析

白話解析：

先描述症狀，再提出一個最小假設。本堂常見錯誤是：順手加入新的框架、外部服務或真正送出資料，讓本堂範圍失控。

對照位置：

對照最後一段 Live Lab：project-brief.md 與 evidence.md；檢查方式：先只列『保留』與『替換』兩欄，不先改 HTML 或 JavaScript。

預期觀察：

你要能指出一個具體位置，而不是一次修改很多檔案。

常見錯誤：

不要先清快取、重裝工具或複製 Solution；先查看第一個可觀察錯誤。

立即驗證：

重新操作並留下「症狀、證據、假設、單一修正、結果」五項紀錄。

常見誤解

看到畫面沒有變化，不代表程式沒執行；先確認檔案、路徑、元素與狀態證據。
能複製 Solution 不代表理解；請先說出修改哪個檔案、預期哪個結果、用什麼證據確認。
本堂只使用 Markdown、HTML、CSS、JavaScript 與瀏覽器 DevTools；不建立真正四頁、不連外部服務、不加入框架或部署工具，先完成 planning-only project brief。

本堂任務與驗收

完成一份 planning-only project brief：列出首頁、服務、關於、聯絡四頁，為每頁寫出責任，建立四個 user tasks，分配 P0/P1/P2，並留下至少四項可重現驗收證據。

能用四頁 sitemap 留下可重現證據。
能用四個 user tasks 留下可重現證據。
能用 P0/P1/P2 優先級留下可重現證據。
能用驗收 checklist 留下可重現證據。
Starter、Checkpoint、Solution 的入口都能開啟並知道三者差異。
遇到問題時能先寫出症狀，再檢查一個最小假設。

情境變體：把同一份規劃改成到府清潔服務，保留四頁與任務格式，只替換商家內容、服務名稱與一項主要 CTA；不新增框架、外部服務、部署或表單串接。
獨立挑戰：不看 Solution，替另一個服務型商家完成 planning-only brief；保留四頁 Sitemap、四個 user tasks、P0/P1/P2 與 Acceptance checklist，只替換商家內容與主要 CTA，並提交 evidence.md。

專案規劃與設計

先理解：這堂課解決什麼問題？

先備知識與操作環境

先做最小實驗：先看見結果

學生練習流程

最小實驗

Step 2

最小實驗 2

Starter

Checkpoint

Solution

變體驗收

檔案地圖：每個位置負責什麼？

先學會這些詞

最小例子：先看懂，再複製

Live Lab：逐段讀碼與驗證

先寫出目標商家與訪客

把四頁責任放進 Sitemap

把需求寫成 User tasks 與優先級

用離線預覽看見規劃結果

把 Acceptance checklist 補成可重現條件

用變體檢查規劃是否可移植

互動問答

白話解析：

對照位置：

預期觀察：

常見錯誤：

立即驗證：

白話解析：

對照位置：

預期觀察：

常見錯誤：

立即驗證：

白話解析：

對照位置：

預期觀察：

常見錯誤：

立即驗證：

白話解析：

對照位置：

預期觀察：

常見錯誤：

立即驗證：

常見誤解

本堂任務與驗收

官方延伸閱讀