・服務建議書與商業提案簡報（Pitch）技巧
🎯 單元學習目標
- 掌握商業提案（Pitch）與服務建議書精髓：學會將設計概念轉化為具備商業說服力的競標簡報與服務建議書（Proposal）。
- 建立評選攻防應變力：模擬真實競標現場，掌握評選委員在「預算、範疇、技術可行性」三大核心層面的提問應對策略。
- 落實工程交接（Hand-off）標準：建立符合開發規範的 Figma 設計稿標註、Design Tokens 體系與資產導出邏輯。
- 驗證設計稿的程式碼化結構完整度：完成高保真 RWD 設計稿審查，確保設計結構無縫對接下一階段的 AI 程式碼生成與實作。
・服務建議書（Proposal）的核心骨架
一份標準且具說服力的服務建議書，應包含以下四大核心結構與策略要素：
| 結構階段 | 核心說明與洞察 | 關鍵內容與交付要素 |
|---|---|---|
| 01 需求與痛點剖析 | 展示對業主產業、目標使用者與競爭對手的深刻洞察，說明現有瓶頸與轉型切入點。 | 產業市場趨勢 User Personas 競品對標分析 使用者核心痛點 |
| 02 核心解決方案與策略 | 說明設計與產品架構如何回應商業目標，提出具體的 UI/UX 策略與品牌風格定位。 | 商業指標 (KPIs) 資訊架構 (IA) UI/UX 設計策略 品牌視覺定位 |
| 03 時程與交付物 | 明確列出專案開發階段的里程碑、品質審查節點以及最終交付的設計與系統資產。 | 里程碑 (Milestones) 審查節點 Design System Figma Spec 標註 |
| 04 預算規劃與團隊優勢 | 提供清晰透明的項目計費拆解與付款時程，並展示團隊成員過往成功案例與資歷。 | Milestone Billing 項目計費拆解 團隊成員資歷 預估 ROI 效益 |
・商業提案簡報（Pitch Deck）高說服力架構
競標簡報的時間通常受到嚴格限制（10 ~ 15 分鐘），必須採用高張力的簡報故事線：
| 簡報階段 | 內容重點 | 簡報視覺策略 |
|---|---|---|
| 01. 爆點 Hook (1 min) | 拋出業界痛點或使用者核心矛盾 | 滿版大圖、數據卡片、極簡字體 |
| 02. 痛點分析 (2 mins) | 為什麼現有方案無效？業主損失了什麼？ | 競品對照表、User Journey Map |
| 03. 核心方案 (3 mins) | 我們提出的設計主張與品牌定位 | 動態原型（Prototype）、主視覺亮相 |
| 04. 設計展示 (5 mins) | 高保真 UI/UX 演示、RWD 適配與元件系統 | 實機 Mockup、互動動效流程演示 |
| 05. 落地保障 (2 mins) | 時程、開發交接邏輯、預算與預期 ROI | 甘特圖、組件化交付保證 |
💡 Pitch 簡報金律（10/20/30 法則）：簡報頁數不超過 10 頁，發表時間控制在 20 分鐘內，字體大小不小於 30pt，確保評選委員專注於演示內容而非閱讀繁雜文字。
・ 評選委員提問與攻防實戰(預算、範疇、可行性)
真實競標現場中，評選委員的提問往往直指「商業投資報酬率」與「專案風險」。
・三大核心攻防議題拆解
評選簡報現場針對預算、範疇與技術可行性之常見提問與應對策略對照表：
| 攻防議題軸線 | 評選委員常見提問 | 團隊攻防心法與應對策略 |
|---|---|---|
| 01 預算攻防 Budget & ROI |
「報價高於市場行情，額外預算價值在哪？」 |
不直接降價，而是展現「價值」與「階段性切分」：
|
| 02 範疇攻防 Scope Creep |
「若時程緊迫，如何確保所有功能按時上線？」 |
導入 MoSCoW 原則進行優先級切割與風險控管：
|
| 03 可行性攻防 Feasibility |
「複雜視覺與動效，工程團隊能實現嗎？」 |
提出「設計與工程交接標準」消除疑慮：
|
・ 評選現場回答萬能公式
面對評選委員的質疑與挑戰時，透過「肯定、機制、解答」三階段進行條理分明的應對：
💬 實戰情境提問：
評選委員：「這個 Bento Grid 佈局在行動端會不會太擠、開發成本過高？」
| 公式三階段拆解 | 溝通核心目的 | 團隊回答逐字稿示範 |
|---|---|---|
|
階段 01 肯定委員洞察 |
建立專業認同與溝通共鳴，避免對立與防禦性情緒。 | 「非常感謝委員精準的提問。我們在設計初期就考慮到了行動端適配問題。」 |
|
階段 02 提出機制 / 數據 |
用具體的 Design System 規範或 Auto Layout 架構化解疑慮。 |
「因此在 Auto Layout 架構中，我們已設定好 RWD Breakpoints：桌機端為 60:40 不對稱雙欄，行動端則會自動折疊（Collapse）為單欄直向堆疊。」 |
|
階段 03 邊界與解答 |
劃定開發範疇，並強調直接對應 CSS Flexbox 的技術可行性。 |
「這套邏輯已元件化，能直接轉化為 CSS Flexbox，不會產生額外的前端開發負擔。」 |
・設計稿的標註與工程交接（Hand-off）邏輯
設計與工程之間最常見的溝通障礙，源自於「設計稿缺乏系統化標註與代碼化邏輯」。
Figma Dev Mode 與工程標註三要素
涵蓋基礎建設、 Auto Layout 佈局、元件系統、圖層組織與 Dev Handoff 工程交付之實務標準與檢核指標。
- Design Tokens 全額綁定：畫面上 100% 的色彩、文字階層與間距，均需綁定 Figma Variables / Styles，嚴禁出現裸碼 Hex Code。
-
Auto Layout 對應 CSS Flexbox：
Horizontal / Vertical➔flex-direction: row / columnGap / Padding➔gap / paddingFill Container➔flex: 1（彈性延伸）Hug Contents➔width: fit-content（內容抱緊）
-
Icon 與圖像資產規範化：
- 所有 Icon 必須包裹在固定正方形 Frame 內（如 24x24px Bounding Box），防止工程匯出時尺寸偏移。
- 向量線條必須執行
Outline Stroke並進行Union / Flatten，確保轉為 SVG 時無描邊失真問題。
・前進 AI 實作！設計稿轉程式結構完整度審查
在進入下一階段利用 AI 工具（如 Cursor, Claude, Figma CodeGen）將設計稿自動轉化為前端程式碼（HTML/CSS/React）之前，必須完成 Figma 高保真 RWD 審查（Audit）。
高保真 RWD 設計稿審查清單 (Code-Readiness Audit)
| 審查構面 | Figma 設計稿檢核標準 | 前端程式碼對映與 AI 生成驗證 |
|---|---|---|
| 1. RWD 適配流體度 | 包含 Desktop (1440px)、Tablet (768px)、Mobile (375px) 三種完整 Breakpoints 設計。 | 縮放外層 Frame 時，卡片與內文自動推擠換行，無 Fixed Width 導致的溢出破版。 |
| 2. 元件變體完整性 | 所有 Interactive Components（按鈕、卡片、輸入框）具備完整 Default / Hover / Active / Disabled 變體。 |
AI 代碼能自動提取 :hover 與 :focus 虛擬類別 CSS 樣式。 |
| 3. 文案極限邊界 | 標題與內文欄位設定為 Fill Container，並測試過極長文案輸入狀況。 |
程式碼中會自動帶入 word-break 與彈性換行邏輯，不衝破容器。 |
| 4. 無障礙對比 (A11y) | 全站文字與背景色彩對比度經過 Stark / Contrast 檢測，達到 WCAG 2.1 AA (≥ 4.5:1)。 |
生成的 HTML 語意標籤（<h1>, <button>, <nav>）具備高品質可讀性。 |
・本單元期中提案與審查評分標準（Rubric）
審查評分標準
在期中提案現場，各組將進行 12 分鐘 Pitch 簡報 + 8 分鐘評選攻防，並由導師與評審進行以下四項指標打分：
| 評分指標 | 配分比例 | 具體審查與評分要點 |
|---|---|---|
| 1. 商業策略與簡報邏輯 | 30% | 提案是否精準擊中痛點？競標簡報故事線是否具備商業說服力與清楚的 ROI 預估？ |
| 2. 視覺質感與視傳美學 | 30% | 字體階層張力、色彩 Token、留白節奏與整體品牌風格的高保真視覺完成度。 |
| 3. Figma 結構規範度 | 20% | 100% 綁定 Design Tokens、Auto Layout 對應 Flexbox 無誤、圖層命名語意化。 |
| 4. 評選攻防與交接可行性 | 20% | 針對預算、範疇與技術提問的應變表現，以及 RWD 三端 Breakpoints 適配完整度。 |