「島嶼新浪潮：地方創生與數位觀光入口網」是 web02 課程教材裡示範的政府標案案例：預算新台幣 180 萬元，工期 120 天，目標是打造一個能帶動地方觀光與文化能見度的入口網站。RFP 明確要求 RWD 響應式設計、WCAG AA 無障礙、互動地圖與可篩選的景點／行程內容，交付項目包含提案文件、Figma 設計稿、已部署網站與無障礙檢測報告。這些條件會貫穿接下來每一個 Stage 的指令，不是做完精稿才回頭補。

※ 「設計與技術能力」單一構面就佔 40%，是四個構面裡權重最高的——這也是為什麼把架構、線框、精稿、無障礙每一步都做扎實，比臨時抱佛腳補一份漂亮的精稿更划算。

RFP 只寫了一句「對在地文化與生態旅遊有興趣的一般民眾」——這句話沒辦法直接拿去跟 Agent 討論架構，Agent 只會給出一個放諸四海皆準的通用網站。這一關要做的，是把這句話落地成三份可以直接被下一步引用的規格文件：核心 Persona 摘要（受眾痛點）、競品 SWOT 與突破點分析、前後台功能清單（標好 P0／P1）。這三份不是額外的紙上作業——Lv.3 討論網站架構、Lv.10 寫服務建議書的「UI/UX 規劃」與「代表性實績」，都會直接引用這裡整理出的內容，讓每一步的指令都有憑有據，而不是憑空想像。

不用寫成一份完整的人物誌報告，只要抓「會影響功能決策」的痛點與動機就夠——通常 2 個 Persona 就能涵蓋大部分決策，切角要夠具體，痛點要能直接對應到某個網站功能，而不是「希望介面好用」這種空泛描述。

1. 從 RFP 一句話拆出至少 2 個受眾切角：「對在地文化與生態旅遊有興趣的一般民眾」可以拆成行為模式不同的幾種人，例如習慣自己規劃行程的深度旅遊者，跟出發前一兩天才決定去哪的臨時起意遊客。
2. 請 Agent 幫每個 Persona 推導「核心痛點」與「造訪網站想完成的任務」：痛點要具體到能對應某個網站功能，講不出對應功能的痛點就不夠具體，要繼續追問。
3. 把痛點跟功能清單互相對照：每個痛點都應該能在下一步的功能清單裡找到對應的功能，對不到就代表這個痛點還沒被解決，或這個痛點其實不重要，可以刪掉。

找 2–3 個跟本案性質相近的既有網站（其他縣市文化觀光入口網、地方觀光局官網、大型旅遊平台的在地頻道），用 SWOT（優勢／劣勢／機會／威脅）逐一分析，最後收斂出「我們可以贏在哪裡」的突破點——這份分析會影響 Lv.10 服務建議書「代表性實績」怎麼寫定位，也會影響功能清單要不要多做「別人沒做好」的那個功能。

1. 列出 2–3 個競品／參考站：不用限定官方網站，觀光平台的在地頻道、鄰近縣市的類似入口網都算。
2. 針對每個競品做 SWOT 四象限分析：聚焦跟本案 RFP 需求相關的面向——互動地圖、篩選功能、RWD、無障礙，不是泛泛而談的品牌優劣。
3. 收斂出 2–3 個「突破點」：別人沒做到、但本案可以做到的具體項目，這些突破點會變成功能清單裡「主打」的 P0 功能，也是服務建議書代表性實績要強調的差異化賣點。

Lv.1 的功能清單只列到「頁面」層級（首頁、列表頁……），這裡要再往下拆一層，變成「功能規格」層級，而且要分「前台（使用者看到的）」與「後台（管理者使用的）」——很多 RFP 評分委員特別在意後台好不好管理、內容能不能自己維護，前台做得再漂亮，沒有後台就是半成品，直接對應評分表裡「專案管理能力」與「公司經驗與團隊」各 20% 的維運能力考量。

1. 從 Persona 痛點與 SWOT 突破點反推功能：例如「深度探路者」的痛點對應「地區／類型篩選」功能，SWOT 的突破點「互動地圖」對應首頁地圖入口。
2. 前台功能列出使用者能操作的完整清單：地圖、篩選、詳情、預約、在地故事等，每項標 P0（RFP 硬性要求或直接對應評分權重）或 P1（加分但非必要）。
3. 後台功能同樣列出並標優先度：內容管理（行程／景點資料的新增編輯下架）、預約管理（查看確認匯出名單）等，後台雖然 RFP 沒有明講介面長相，但能不能維運直接影響評分。
4. 產出後直接變成下一步的輸入：這張表做完，Lv.3 討論架構時要整段貼給 Agent，取代只有頁面名稱的功能清單，也是 Lv.10 服務建議書「UI/UX 規劃」那頁要引用的素材。

手動畫 Sitemap 通常是打開白板或 Word，自己一頁一頁想「要有哪些頁面」，架構合不合理全靠自己的經驗判斷；Figma Agent 的做法不同——是把 Lv.1 的 RFP 硬性需求，加上 Lv.2 整理好的 Persona 痛點與帶 P0／P1 優先度的功能規格清單交給它，用對話把架構談出來，過程中可以直接帶入評分標準、受眾痛點與功能優先度，而不是自己悶頭想完才發現漏了什麼。開一個新的 Agents 側邊欄聊天室，開始討論。

1. 先整理成一段完整敘述：把案例名稱、Lv.2 整理出的 Persona 痛點、RFP 硬性需求、帶 P0／P1 標籤的功能規格清單全部放進同一句話裡，不要分好幾句零散地講。
2. 要求它同時給「行銷或功能目的」：不是只要頁面清單，而是每頁「為什麼存在」、回應了哪個 Persona 的哪個痛點，方便你判斷架構合不合理。
3. 確認頁面之間的連結關係：哪一頁導向哪一頁，這會直接影響 Lv.4 線框稿裡按鈕與連結的位置。
4. 自己刪改一輪：Agent 給的是建議架構，不是定案——對照 Lv.2 的功能規格清單，確認所有 P0 功能都有出現在主要導覽裡，沒有被漏掉或降級。

延續 Lv.3 談出的架構，把四個 P0 頁面的線框全部畫完：首頁（承載互動地圖入口）、行程／景點列表（承載篩選功能）、行程詳情頁（單一行程完整介紹與預約入口）與線上預約（表單送出與確認）。線框階段只談「有哪些區塊、由上到下的順序」，完全不提顏色與風格，這是整個系列教學一貫的鐵律——手動畫線框時最容易犯的錯，就是邊排區塊邊忍不住開始選顏色，結果結構跟風格混在一起改，越改越亂。

Stage 2 灰階線框（示意）

→

Stage 4 精稿示意 — 由上面的線框指令搭配 Lv.6 的套色與內容指令產出，地圖區塊先用示意色塊表示「這裡未來是互動地圖」，篩選標籤與行程卡片都是線框階段就先保留好位置，精稿只是「上色＋填字」，完整精稿見 Lv.6。

web04 課程教材把這一步定位得很清楚：視覺設計不是憑空想像，而是把品牌的內涵與受眾心理，先轉換成一張「大家看了都同意這是什麼調性」的情緒板（Mood Board），再進到 Lv.6 把調性落地成真正的色票與字體規範。這一步手動做最容易被跳過——很多人線框畫完就直接開始套色，沒有先停下來對齊「大家講的是不是同一種調性」，Agent 至少會逼你先講清楚品牌關鍵字，才會產生色票建議。

依 web04 的定義，Mood Board 是把色彩、影像質感、字型氣質、UI 元件範例進行結構化拼貼的看板，核心目的有兩個：建立團隊視覺共識（避免大家對「現代感」「質感」這種形容詞理解不一致）、向業主／評審提案簡報（投入大量繪圖工時前，先取得視覺調性 Vibe 的認可）。對「島嶼新浪潮」這個標案來說，等於是在精稿開工前，先讓評審知道「我們理解的地方創生美感是這個樣子」。

1. 定義品牌視覺關鍵字：從 RFP 需求與受眾洞察提煉 3 個核心形容詞。「島嶼新浪潮」提煉出：海島慢遊（不是走馬看花的觀光，是慢下來體驗）、在地手作溫度（呼應織布工坊、潮間帶漁法等行程）、永續共生（地方創生的核心價值，不是消耗地方資源）。
2. 多管道圖像素材蒐集：依這 3 個關鍵字，到 Pinterest、Behance、Dribbble 蒐集攝影光影、建築線條、字體排版、配色組合的參考範例，或直接請 Figma Agent 依關鍵字生成示意色塊與質感描述。
3. 提取與歸納視覺元素：從蒐集的圖板中歸納出主色與輔色調性、圓角造型與版面留白率——這一步歸納出來的顏色，就是 Lv.6 要建立成變數的來源，不是憑空挑色票。

套用設計系統的前提，是你已經有一組可以被引用的顏色、字體與元件——同一個檔案裡建好即可，不用跨檔案發佈。web04 教材把這一步拆成「色彩 Token」「字體階層」「網格系統」三張規範表，再用「原子設計」把畫面拆成可重複使用的元件。這裡直接把 Lv.5 情緒板歸納出的調性，轉成「島嶼新浪潮」自己的一套 Style Guide——網站色彩最終以本案兩張參考服裝照為本，全面改成鮮明海洋藍綠＋鮮明日落橘。

只有 1 個主色、1 個輔色不夠應付真實介面——按鈕需要 Hover／Active 兩種互動狀態，內文也需要「次要文字」跟標題文字做出層級區隔。這 6 個延伸 Token 都是從主色、輔色調整明度算出來的，不是另外挑的新顏色：

字體家族刻意用兩套：標題（H1／H2）用 Noto Serif TC，襯線的收筆帶出「在地手作溫度」的人文質感，呼應 Lv.5 情緒板歸納出的品牌調性；H3 以下（卡片標題、內文、標籤、按鈕）一律用 Noto Sans TC，無襯線在小字級與介面元件上辨識度更高。層級靠字重（900／700／500／400）而不是另外挑字體去區分，維持系統的一致性與載入效能。

網格系統採業界標準的 12 欄網格：桌機 12 欄、Gutter 24px、最大寬度置中 1200px。元件則依原子設計理論拆解，方便 Agent 逐層建立、逐層重複使用：

這是讓精稿元件真的能「隨螢幕彈性伸縮」的關鍵設定，也是 Lv.8 談 RWD 轉化時，元件不會破版的基礎：

RFP 要求的「互動地圖」與「可篩選內容」，是 Figma Design 精稿無論做得多細都無法真正實現的——精稿裡的原型模式只能做畫面跳轉，沒有真正的地圖縮放或篩選邏輯。這正是 Figma Make 的用武之地：把精稿附加進去，讓它重新生成有真實互動的網頁，評審委員甚至可以直接點連結試用，不需要打開 Figma。除了 RFP 明講的硬性功能，底下也示範幾種讓網站更有質感的微互動——這些細節不是評分表逐項要求的，但正是評審委員判斷「這家公司有沒有用心」的地方。

1. 開一個新的 Figma Make 檔案，附加設計：在 AI 對話框點「＋」選「Attach a design」，貼上 Lv.6 精稿檔案的分享連結。
2. 用「元素＋觸發＋反應＋時長」公式描述互動：不是只講「做成可以互動」，下面示範地圖、篩選、預約表單、導覽捲動、卡片微互動、橫向手勢六種情境。
3. 逐一測試每個互動，微調 prompt：Make 重新生成程式碼，顏色與間距要對照精稿補充指令調整。
4. 發佈成專屬網址：可以直接附在提案文件裡，評審委員點開就能實際操作互動地圖與篩選功能。

六種微互動做完之後，網站給人的第一印象其實是「打開網址那一瞬間」——如果所有區塊都是生硬地直接出現，整體還是會顯得像半成品；加上有層次的進場動畫，是把「功能都能用」的網站，變成「看起來有質感」的網站最划算的一步。

RFP 把 WCAG AA 與 RWD 列為硬性規格，也是「設計與技術能力」40% 評分裡看得到、量得出來的部分。與其精稿做完才回頭補救，不如把這兩件事拆進 Lv.3–Lv.7 每一步的指令裡，下面整理成一張速查表。

不用 Figma Agent，純手動在 Figma 裡做完「島嶼新浪潮」整個流程，大致是這樣：自己開白板或 Word 條列頁面清單 → 一格一格手動拖元件畫線框 → 自己上網蒐集風格參考圖拼成情緒板 → 手動建立顏色與字體樣式，再一頁一頁手動套用 → 用 Figma 內建的 Prototype 模式串連畫面跳轉。這一頁走的是「Agent 架構討論 → 線框 → 情緒板 → Style Guide 與精稿 → Figma Make → RWD 轉化」六階段，每一步都用對話取代手動操作。兩者做出來的「東西」其實很接近，差別主要在花多少時間、細節會不會漏掉，以及能不能做出真正的互動。

值得說清楚的是：手動建置不是「做不到」，而是「每件事都要自己記得做」——熟悉 Figma 操作的設計師一樣能做出漂亮的精稿，只是比較花時間，而且規模一大（例如要讓四個 P0 頁面都維持一致），光靠人工稽核很容易漏掉一兩處。Figma Agent 省下來的主要是「記得做」跟「維持一致」這兩件事的心力，不是取代設計師的判斷。

web01 課程總覽單元提出一套分析任何網站的方法：拆成企劃力（UX）、設計力（UI）、技術力（AI/Code）三個維度分別評估。套用到「島嶼新浪潮」這個案例，剛好可以把手動建置與 Figma Agent 兩種做法的產出結果，用同一把尺量出差異在哪裡，而不是只憑印象說「用 Agent 比較好」。

三個維度加總來看，手動建置在「設計力」這個維度不一定輸——如果設計師本身功力夠紮實，照樣能做出精緻的成果；但「技術力」幾乎注定拿不到高分，除非另外找工程資源支援。這剛好呼應 Lv.1 提過的 RFP 評分表：「設計與技術能力」單一構面就佔 40% 權重，這正是 Figma Agent 接上 Figma Make 這條路徑最明顯的優勢所在。

Lv.1 那張評分權重表其實已經把整份投標文件該長什麼樣子講得很清楚：「設計與技術能力」40% 是 Lv.3–Lv.8 的核心戰場，「價格」20% 屬於報價單、不在本頁範圍，剩下的「專案管理能力」20% 與「公司經驗與團隊」20%——加起來也是 40%，跟設計技術能力同樣重——過去九個關卡都還沒處理。服務建議書（Service Proposal）就是把 Lv.3–Lv.9 做出來的設計成果，跟公司資訊、過往實績、時程規劃與團隊分工放進同一份文件，評審看的不是你 Figma 檔案裡有多少張畫框，而是這份文件能不能讓人相信「這家公司做得出來、也管得動 120 天的工期」。RFP 案例文件明講的服務建議書內容，可以拆成四個部分，下面逐一示範怎麼用 Figma Agent（設計頁面類）與 FigJam AI（圖表類）把每一部分實際做出來，並附上完整 20 頁服務建議書與 15 頁提案簡報的實際產出。

這一節的目的不是寫作文，而是把幾個「一眼可信」的基本事實排版清楚：公司名稱與定位、成立年份、團隊規模、核心服務項目、相關專業認證或獲獎紀錄、聯絡窗口。用 Figma Agent 直接在提案文件的畫布上做一頁設計稿，之後可以匯出成 PDF 或投影片使用的頁面。

1. 先把事實條列出來：不用等資料齊全才開始，公司名稱、成立年份、團隊規模、3–5 項核心服務可以先用暫定資料佔位，之後再換成真實內容。
2. 請 Agent 設計一頁「公司簡介」版面：版面邏輯是「品牌識別＋一句話定位」在最上方，中間是關鍵數字（成立年份、團隊人數、服務過的專案數），下方是核心服務項目與認證標章。
3. 套用 Lv.6 建立的品牌變數：顏色、字體都沿用「島嶼新浪潮」精稿同一套設計系統，讓提案文件跟網站設計稿是同一個視覺調性，而不是兩套風格拼在一起。

評審最怕看到「我們做過很多案子」這種沒有佐證的空話——這一節的重點是挑跟本案性質相近的案例、用數字說話：地方創生、觀光、政府標案、互動地圖或 RWD 網站，任何一項相關都值得放，每個案例至少附一個可量化的成效指標（流量成長、轉換率、得獎紀錄），而不是只有案名跟一張截圖。

這一節不用重新設計——內容就是 Lv.3 到 Lv.8 已經做出來的東西，這一節的任務只是「摘要與排版」：把散落在 Sitemap、線框、情緒板、精稿、Figma Make 原型、無障礙檢核裡的成果，濃縮成幾頁讓評審快速翻閱的提案頁面，而不是把整個 Figma 檔案原封不動塞進去。

這一節要證明的是「這家公司管得動 120 天」，具體拆成兩張圖：甘特圖（工作項目怎麼分配到 120 天裡）與組織圖（誰負責什麼）。這兩種都是 FigJam AI 官方文件明確列出能一鍵生成的圖表類型（流程圖、組織圖、甘特圖、心智圖），跟 FigJam 範本庫裡人物誌、同理心地圖這類「社群範本」不同——那些是版面樣板、不是 FigJam AI 官方列出的一鍵生成圖表類型（Lv.2 做 Persona 摘要卡用的是 Figma Agent 直接設計版面，也不是套用這類範本）；甘特圖與組織圖可以直接請 FigJam AI 生成，穩定度更高。

※ 8 個項目天數加總剛好等於 RFP 要求的 120 天——甘特圖排太鬆會讓評審懷疑工期抓不準，排太滿又沒留緩衝會顯得不切實際，這張表已經把兩者平衡過。

前面四個部分做出來的是書面文件——評審委員會私下逐頁翻閱、比對評分表打分數；但大多數政府標案還有一場現場簡報（通常 15–20 分鐘＋Q&A），評審是坐在台下聽你講，不是自己翻文件。這兩種情境需要的版面邏輯不一樣：書面文件可以資訊密集、附完整表格；簡報投影片則要「一頁一個重點、字級夠大、遠看也看得清楚」。直接把四個部分的提案頁面原封不動塞進投影片，會變成台下的人在瞇眼睛讀小字——這一段示範怎麼把整份服務建議書，重新編排成一份真正拿來站上台講的簡報。

※ 第 14 頁的「現場互動示範」最容易出狀況——會場網路不穩、QR code 掃不到都可能發生，準備一份操作過程的截圖或短影片當備案，不要讓整場簡報卡在等網路連線。

下面是完整 20 頁服務建議書實際產出的縮圖，點擊任一頁可放大並依序翻閱全稿。

同一份服務建議書濃縮改編成的 16:9 現場簡報，字級更大、一頁一個重點，供站上台講解使用。