前言
在設計領域，提案是設計師與客戶溝通的橋樑，將想法轉化為實際產品或服務的關鍵，也是設計師最頭痛的部分…「如何在有限的時間內，將自己的設計理念和想法清楚且有說服力地傳達給客戶？」
回顧提案歷程，我發現不同的設計提案，儘管流程或展示成果有所差異，面對的核心原則卻是相同。這些看似模糊的原則和特點，在經過腦內解構大戰後，似乎跟敏捷方法有一定的關聯… 🤔 ➡️ 💡
本篇內容將說明提案時運用的心法，以及敏捷提案的特點。
文章大綱
- 什麼是敏捷提案
- 敏捷提案特點與案例
- 確認清單：設計你的「設計提案」
- 參考資料
1︎. 什麼是敏捷提案 💬
在軟體開發流程中，常使用敏捷開發方法，著重於靈活的迭代開發，以適應不斷變化的需求和環境。「敏捷提案」是敏捷方法的一種實踐，它不拘泥於標準的框架或方法論的約束，它是一種思維、心態、心法，不論你的團隊是否採用敏捷開發，都可以應用於提案過程。
敏捷提案目的是 — 即時了解並適應客戶（利害關係人）的需求與變化。在提案中保持靈活性，以交付有價值的產品或功能，推動專案前進。
雖然「敏捷提案」被視為一種心法，實踐它仍有具體的方法可供參考。我們可以從敏捷方法的特點切入：
- 清楚簡潔的目標
- 客戶參與
- 反饋和迭代
- 優先級別
接下來的內容將詳細探討這些特點的具體實踐方式。
本文不會詳述敏捷方法，主旨放在幫助設計師有效提案。以下案例請依個人情境斟酌，不見得適用每個專案，你也可以依照個人經驗，調整成自己的具體做法。2︎. 敏捷提案特點與案例 🌰
敏捷提案是一種心法，可將敏捷方法的特點貫穿其中，「清楚簡潔的目標」將會是提案的核心 ;「客戶參與」在最外層，涵蓋整個提案的各個環節 ; 而「反饋和迭代」以及「優先級別」則形成了一個相互循環的迴圈。
聽起來是不是有點抽象？下面將一一解釋各特點的內容 👇
背景概要
（此篇章將以產品配色提案舉例）在提案期間，客戶同時進行了 LOGO 迭代，新的 LOGO 強調了漸層元素。然而，在 SaaS 平台，特別是以表格操作為主的產品中，漸層元素較少使用，因為過多的漸層可能降低易用性。若僅簡化問題，使用純色系統，又缺少品牌識別延伸至數位產品的脈絡。因此，在品牌識別和易用性之間取得平衡，會是此提案的考量之一。
2–1 清楚簡潔的目標
著手提案前，必須清楚提案預期達到的目標，並貼齊專案的基本條件，這將是提案最核心主軸，接下來的提案過程，都將圍繞著這個核心角度出發。以此次提案舉例：
➤ 目標
產品為 SaaS 平台，已有基礎架構佈局（Layout），配色提案需應用於四個產品線（色彩系統的擴展性）。
➤ 基本條件
* 對齊品牌色與產品數位色：產品數位色應用在元件需清晰可視
* 色彩計畫符合前端 Chakra UI 框架（👉 了解更多 -如何通過 Chakra UI 打造一致的 Design System）
確認目標跟基本條件後，不同類型的提案會發展出不同的步驟。整體而言，不論是哪種提案，都會經歷資料搜集（發散）到方案淬鍊的過程（收斂）。
以產品配色提案舉例 🌰，在製作簡報前，我執行了以下四個步驟：
Step1. 大量搜集素材 （發散）｜ 海量搜集後台介面樣式，以及 REF 其他多產品線的公司怎麼做。前置作業一定要做足功課，天馬行空，多多嘗試設計的可能性。
Step2. 幫素材分類（收斂）｜ 盤點搜集的素材，依照解決問題的邏輯分類。（舉例：依照配色邏輯分類素材，純色系統？漸層運用在哪些部分？）
Step3. 套入實際畫面（發散）｜ 將可能的解法方案套用在實際畫面（如下圖每一行都是實際介面套入解法的畫面），盡可能擬真，更好評估設計效果。
Step4. 淬鍊方案（收斂）｜ 盤點現有的資源及限制，綜評後選擇最平衡的方案，並釐清取捨點。收斂後的方案盡量在 3 個以內，提案不是越多越好，太多選擇可能導致決策困難和討論分散。
2–2 客戶參與
敏捷開發極度注重客戶參與，因此，敏捷提案也鼓勵客戶或最終用戶參與需求的定義和驗收，是獲得客戶需求的同理心機制。
設計的方案未必有完美的正解，在提案的過程，我們需讓客戶理解，目標不是強迫客戶選擇其中一個方案，而是彼此激盪出更適合的解法。
✭ 創造開放討論的空間
提案的過程，適時地停頓，創造客戶可發問或互動的機會，或是主動徵詢客戶的意見，不要讓客戶壓抑自己的想法，也不必逼客戶立即擠出想法。
✭ 善於傾聽和觀察
觀察客戶的表達慣性，談論到什麼「關鍵詞」，語氣的起伏會變得明顯？這些變化可能是「客戶關心卻沒有表達的事項」，同時也觀察，哪些部分客戶會直接忽視，以減少不必要的討論時間。珍惜每次面對面談論的機會，這些都是觀察的時機。
舉例來說 🌰：本次專案是遠端執行，然而，當提案的層級重要（同時影響其他產品）且需要更多的互動時，設計師應該儘可能面對面提案，並邀請主管參加，提高客戶的參與度，以獲得更準確的需求關鍵點。
2–3 反饋和迭代
這裡強調的是「迭代」，而不是單純地「調整」，意味著每次的變動都是更優化、更貼近需求，並非漫無目的的改變。
復盤和迭代是敏捷方法重要的一環，創造反饋機制，讓團隊和利害相關者能夠不斷討論更貼近真正的需求，根據反饋和變化調整設計提案。有些意見在會議當下沒被提出，不代表事後不會浮出水面，建議保留一點點彈性空間，理解「迭代」是設計的日常。
在迭代的歷程中，如何平衡需求變化、時程壓力、資源分配之間的比例，需要設計師發揮溝通和協調的能力。
設計師的工作不是閉門造車，專業是基本，提升溝通協調能力才能發揮更多影響力，傳遞設計的價值。
即使提案已確定，也不一定是最終版本。以此次提案為例 🌰：其他產品線進行實際規劃時，我們發現主色與示警色重疊，影響了整體畫面的識別性，因此，隨後進行了配色的細節調整，持續迭代以達到目標需求。
2–4 優先級別
優先級別，需要與利害關係人、產品經理、開發團隊達到相同的共識。
優先級別與迭代息息相關，敏捷方法在進行開發週期（Sprint）的時候，會依照優先級別安排任務（Task），以確保團隊持續產出最高價值。這個概念也可以應用在提案上，面對每一個新的需求，設計師可透過幾個面向判斷處理的優先順序，例如：用戶需求、產品目標、技術可行性、緊急程度、資源可用性、成本（時間、人力和技術資源）等等。
用意是在提案時，能明確強調設計項目的重要性，指出它們如何與用戶需求、產品目標或公司戰略相關聯，有助於客戶更容易做出決策。
優先順序沒有絕對標準，主要是依靠設計師的經驗，以及專案情境來通盤考量，以產品配色提案來說 🌰：我會先確定技術可行性（符合 UI 框架），再進一步思考用戶需求（易用性）、產品目標（配色可用於跨平台）、成本（需要花多少時間），並將這幾點融入提案簡報，在同一頁比較各個方案的特點。
小結
不同類型的提案，雖然步驟不同，實際上共享相似的思維模式。因為無論是哪種提案，設計師都處於雷同的環境 — 那就是「不斷變化的客戶需求和市場」，這正是敏捷方法的核心所在。
簡言之，敏捷提案是一種以客戶需求為中心、保持靈活性的方法。它開始於「定義目標需求」，然後通過自身經驗找到對應的「解決方法」來實現。
在提案過程，設計師需要與客戶密切合作，了解需求，並不斷迭代和反饋，以確保提案能夠提供最大價值。
以上是我個人提案的經驗，下個段落將按照提案的時間軸，舉一些可確認的大方向，
不論是什麼類型的提案都可套入，你也可以建立自己的 Checklist，在提案的各個階段審視。3︎. 確認清單：設計你的「提案舞台」🎬
3–1 事前準備
想像你是一個編劇家兼表演家，即將上演一場互動式劇場演出。你需要設計角色登場方式、舞台佈置、表演內容，並且領導劇情走向。
❏ 提案簡報（舞台）
簡報架構基本：封面封底、議程目錄、專案概覽、需求目標、解決方案、QA等等，先確認簡報的骨架，再逐步填好內容的細節，最後思考如何視覺化呈現設計成果。
與其直接進入設計成果或解決方案，讓參與者像是欣賞戲劇一般，一同走過設計的流程與邏輯，豐富呈現設計的層次。
❏ 講稿（台詞）
將提案過程中要表達的內容寫下來，不要只條列項目，也不要忽略轉場詞。人在緊張壓力的情況下，會不斷重複慣用詞（例如：然後、那），事先準備好講稿，可以幫助克服這個問題。接下來，不斷演練，直到講稿非常熟悉可以自然流暢地表達為止。
3–2 會議進行
在這場表演，你一人分飾多角，是提案人同時也是主持人，掌握會議的節奏、氛圍 ，打破劇場的第四面牆（Fourth Wall），讓觀眾參與成為作品的一部份，觀眾對作品更有共感。
❏ 開場介紹（登場）
這是屬於你的舞台！開場時「有意識地」慢慢說話，藉由點開簡報、走上台，或是暖場的空擋，深層的呼吸讓身體放鬆（記得不要明顯到被人發現XD）。開場時，清楚表達提案的背景資訊，以及 Highlight 本次提案目標。
❏ 回饋討論（觀眾互動）
如果你是分享會，開場時可以先提醒大家最後 QA 時間，中間視情況回答問題 ; 如果你是提案會議，可在每個段落的中間穿插討論，不需要限制討論的時間點，任何想法和點子都可以隨時提出，重要的是激起火花，了解案主的想法。
❏ 確認定案（謝幕）
提案會議接近尾聲，提案的方向有近一步的決策後，務必重複一次本次會議的重點和下一步（When/Who/What — 什麼時候 提供給誰 什麼東西）。
3–3 後續行動
❏ 會議記錄（節目回顧）
完成會議記錄，並主動回報案主進度，好的會議記錄提供明確的下一步，也幫助大家回顧提案的關鍵內容和討論。
實際經驗 👉 記錄每個重要決策，可在關鍵時刻保護自己。（職場經驗談 - 會議記錄很重要，這句話請默念3遍）
