# 第 1 節：Introduction
## 1. Introduction
### 課程開場與課程目標

* 介紹本訓練將分享設計思考（Design Thinking）的原則與方法論（methodologies）
* 透過具體案例（concrete application cases）理解概念並學會應用
* 目標是提升創造力（creativity），並學會以設計思考的步驟推進專案（project）

### 講師背景介紹

* 講師為 Jim Elazar，作者（author）與講者（speaker）
* 工程背景（engineering background），在 IT（I.T.）領域超過 10 年經驗
* 曾任職能分析師（functional analyst）與產品經理（product manager）
* 工作地點包含法國與澳洲

### 設計思考（Design Thinking）在課程中的學習內容

* 依設計思考方法探索客戶需求（customer needs）
* 透過問卷（questionnaires）或建立角色模型（avatar）理解使用者
* 學習用結構化方式找點子（structured ideation）
* 學習製作原型（prototype）並進行測試（test）

### 設計思考的定位與核心精神

* 設計思考是創新管理（managing innovation）的方法
* 用於打造更符合終端使用者（end users）需求的產品或服務
* 核心特色是以使用者/客戶為中心（user-centered / customer at the center）

### 起源與普及脈絡

* 提到設計思考在 1980 年代由美國史丹佛大學（Stanford University）發展
* 提到 Jim Brown 在 1990 年代透過 IDEO 推廣此方法
* 強調設計思考有多種切入方式，會依需求組合不同方法

### 適用範圍：不只給設計師

* 釐清設計思考不是只給設計師使用
* 可用於產品設計，也可用於顧問（consulting）、管理（management）、客服（customer support）等領域的創新
* 提到 Google、Facebook、Amazon 等公司使用設計思考

### 案例：Airbnb 的設計思考實踐

* 2009 年 Airbnb 早期經營困難，流量少、每週營收約 200 美元，三位共同創辦人分攤後不足以支撐生活
* 團隊聚焦分析紐約約 40 個房源（listings），探究為何訪客不預訂
* 發現關鍵問題在於房源照片不好看，無法促使訪客下訂
* 採取行動：親自到紐約用專業相機拍攝更好的照片，更新後幾天內每週營收從 200 美元提升到 400 美元

### 與「可擴展」信條（Scalable Dogma）的對比

* 當時矽谷強調可擴展（scalable），也就是能大規模成長且不需人力介入的產品
* 創辦人沒有盲從信條，而是依直覺與分析結果採取「人力介入」的做法
* 結果證明以使用者體驗為中心的調整能帶來明顯成效

### 讓員工站在使用者角度：同理與沉浸

* 制定內部做法：新進員工在入職前兩週內親自入住 Airbnb 房源
* 要求新進員工記錄旅程與體驗，形成可分享的觀察
* 目的在於讓員工站在旅客與終端使用者（end users）的角度，理解挑戰、挫折（frustrations）與需求

### 課程形式與學習建議（課內要求）

* 課程以影片（videos）形式呈現，且有固定順序（specific order），建議依序觀看
* 強調務必做練習（exercises），只知道技術但不應用，無法得到想要的結果
* 指出設計思考的主要挑戰在於「落地應用」（apply），而不只是理解理論
* 講師表示可在需要時提供協助並回答問題

# 第 2 節：Why is Design Thinking important?

## 2. The origins of Design Thinking
### 背景脈絡：公司如何在眾多專案中做選擇

* 每家公司同時存在多個競爭中的專案（projects），但大型專案組合（portfolio）中只有少數會真正落地
* 過去高層（executive committee / directors）在挑選專案時，主要看兩個面向：可行性（feasibility）與商業可行性（viability）
* 商業可行性（viability）：是否財務上有吸引力、是否值得投資
* 可行性（feasibility）：技術上是否做得到、是否具備能力與資源

### 傳統開發方式：瀑布式（Waterfall Approach）

* 專案選定後常採瀑布式（waterfall approach）流程
* 依序進行：規格（specifications）、設計（design）、開發（development）、測試（testing）、部署（deployment）
* 特徵是階段線性推進，通常在前期就做大量定義與規劃

### 設計思考的關鍵差異：以使用者為中心（Design Thinking / Human-centered）

* 設計思考（design thinking）把終端使用者（end users）放回開發核心
* 先理解客戶與使用者需求（needs），釐清他們的問題，再開始找解法
* 新產品或服務的開發以解決使用者問題或挑戰為出發點，而非先想解法再找問題對應

### 同理心是核心：同理心（Empathy）

* 同理心（empathy）是設計思考的核心
* 定義：把自己放在他人立場，理解對方正在經歷什麼、感受什麼
* 強調從使用者視角看世界，理解他們的恐懼、挫折與痛點（fears / frustrations）

### 三個面向的整合：可行性、商業可行性、渴望性（Feasibility / Viability / Desirability）

* 商業可行性（viability）：商業模式是否能長期獲利、是否能創造利潤
* 可行性（feasibility）：技術與資源是否足以實作、是否真的做得到
* 渴望性（desirability）：使用者是否會喜歡、是否符合需求、是否願意使用
* 設計思考強調以渴望性（desirability）作為思考起點，但並不忽略另外兩個面向，而是三者一起納入評估

### 跨領域支撐：多學科方法（Multidisciplinary Approach）

* 設計思考推動人本且跨領域（multidisciplinary）的合作
* 常結合學科包含：民族誌（ethnography）、心理學（psychology）、行銷（marketing）、工程（engineering）、管理（management）
* 目的是用多元視角理解使用者行為與情境，找出更貼近人與需求的創新解法

## 3. The Design Thinking mindset
### 成功心態：好奇心（Curiosity）與像孩子一樣提問

* 要做好設計思考（Design Thinking），需要保持好奇心（curious）
* 要「像孩子一樣」重新質疑習以為常的做法與流程
* 避免預設立場（presuppositions），並持續檢視與質疑自己的假設（assumptions）

### 避免用自己代替使用者：假設的風險

* 有時終端使用者（end user）與我們相似，可能會用自己的偏好、慾望、挫折（frustrations）與恐懼（fears）作為參考
* 但多數情況下，產品或服務是為「和我們不同的人」設計
* 因此更要避免把自身經驗當成通用答案，預設（presuppositions）要盡量避免

### 假設必須被驗證：持續試驗與迭代（Iteration）

* 過程中難免需要做假設，但必須記住它們只是「假設」，可能對也可能錯
* 設計思考的力量在於以結構化（structured）方式建立解法並持續精煉（refine）
* 透過反覆嘗試與修正，逐步逼近真正符合需求的方案

### 設計思考五步驟（Five Steps）

* 同理（Empathy）：走向使用者、站在對方立場理解需求
* 定義（Define）：辨識問題並定義要解的挑戰（challenge / problem）
* 發想（Ideate）：產生多個可能的解法與點子
* 原型（Prototype）：做出原型以回應需求
* 測試（Test）：測試並收集回饋（feedback），再回到前面步驟重複改善

### 核心流程邏輯：先釐清需求，再思考解法

* 強調應先清楚定義要解的問題，而不是先急著想解決方案
* 由客戶需求（customer needs）引導創造（creation），而不是先有解法再硬找需求
* 後續會逐步拆解五個步驟並用案例說明每一步的做法

# 第 3 節：Empathy

## 4. Empathy in Design Thinking
### 設計思考第一步：同理（Empathy）與同情（Sympathy）

* 以同理（empathy）為起點，把自己放在使用者（user）角度理解他們的挑戰、問題與實際體驗
* 觀察與理解使用者在與產品/服務互動時「想什麼、感受什麼、做什麼」
* 進行時的三個關鍵原則：不評判（without judgment）、尊重（respect）、好奇（curiosity）
* 訪談使用者時不批評其反應或困難，目標是學習並蒐集真實資訊

### 訪談示例：相機產品的使用情境探查

* 角色：相機公司產品經理（product manager）訪談用相機拍攝課程的講師（trainer）
* 訪談重點：需求、使用方式、喜歡的功能（features）、遇到的問題、缺少的東西
* 情境問題：請對方描述一次實際使用流程（scenario），包含架設設備步驟、先按哪個按鈕、介面理解、如何匯出影片、如何收音與麥克風操作
* 補充探問：購買動機（motivations）、決策因素、對品牌（brand）的認知、為何選這台而非其他產品
* 原則：不引導受訪者說特定答案，不用「影響式提問」，而是還原互動過程

### 無法接觸理想客戶時：先假設再驗證

* 若暫時接觸不到理想客戶（ideal client），不要卡住，先做合理假設並開始
* 例：要做個人理財 App，可先假設典型使用者的職業、年齡、教育背景、習慣、常讀媒體、常去的地方、財務痛點、收入來源、每月最大支出等
* 強調：初始假設可能被市場推翻，實際使用者族群可能與原先預想不同
* 例：某作者寫書原意是教一般人防止被操控，上市後卻發現行銷人（marketers）更熱衷學來影響他人購買，目標受眾出現落差

### 工具：同理心地圖（Empathy Map）

* 目的：用結構化方式描述「典型使用者」（typical user），聚焦需求、情緒、行為與語句
* 特點：不追求完整人物傳記，而是提取能影響設計決策的關鍵資訊
* 基本結構：中間圓圈放角色名稱；四象限分別是想（Thinks）、感受（Feels）、做（Does）、說（Says）
* 角色名稱可稱作角色（persona）或替身（avatar），本質都是「典型使用者」的具象化
* 做法：先以假設建立 persona，之後再透過資料與訪談驗證是否正確

### 團隊共創方式：同步貼便條的工作法

* 建議以團隊方式建立同理心地圖，能集思廣益，產生更多角度
* 每個人分別代入 persona，寫下他會對自己說什麼、對別人說什麼、在做什麼、在想什麼、在感受什麼
* 偏好實體工作坊：在會議室用白板與便利貼（Post-its）同步書寫，比線上工具更直覺
* 同步進行的好處：所有人同時輸入想法，節省時間並提高參與度

### Persona 範例：John Sportsman 與健身房 App 購物體驗

* Persona：John Sportsman，目標是改善他在健身房 App 內購買營養補給品（nutritional supplements）的體驗
* 背景：機械公司資深技術員（senior technician），30 多歲，單身，固定健身且注重飲食
* 現況：常在健身房現場買補給品，但不在 App 上購買
* 行為特徵：手機操作熟練，但不信任線上購物（online shopping）
* 使用者目標：讓他更願意在 App 內下單，降低阻力並提升信任
* 商業價值：健身房可提前掌握訂單、預先備貨並更好管理庫存（stock）；使用者可減少櫃台等待時間，加快取貨流程

## 5. An example of an empathy map
### 更深入了解典型使用者的方法

* 可用訪談（interview）與一或多位相似客戶對談，詢問購買流程、期待、阻礙等
* 可用線上問卷（online questionnaire）讓社團成員填寫以蒐集資訊
* 蒐集後再整理分類，或先以假設（assumptions）開始，之後再驗證
* 不知道從哪開始時，可上網研究同類型應用程式或競品的使用者評論與回饋

### 透過評論找改進點：以課程評論為例

* 參考同主題訓練或產品的評論（reviews）來找可改善之處
* 特別關注三星評論（three-star reviews），因為通常最具建設性（constructive feedback）
* 一到二星評論常較情緒化、主觀（subjective）成分高
* 五星評論多是肯定，較少指出具體可改進點

### 同理心地圖（Empathy Map）的四象限

* 同理心地圖（empathy map）包含四象限：說（says）、做（does）、想（thinks）、感受（feels）
* 左側兩象限「說、做」偏向可觀察（observed）的外顯行為
* 右側兩象限「想、感受」偏向推論（inferred）的內在狀態

### 說（Says）：使用者會對外說什麼

* 目標是寫出使用者可能對他人說的典型句子，像是「我很愛運動」「蛋白質就是生命」「不痛不成長（No pain no gain）」
* 也可能與購買蛋白粉相關：「要聰明花錢」「網路很多詐騙」
* 也可能對產品/系統的感受：「健康無價」「只有火箭科學才搞得定」或覺得系統很複雜、像「工廠化流程（gas factory）」與「浪費時間」
* 允許重複或相似內容，後續再整理

### 做（Does）：使用者的日常行為與習慣

* 觀察或想像使用者在公共情境與日常生活中的行為模式
* 例子：週日一次煮好一週餐、再忙也安排運動、時間多在工作/通勤/運動之間
* 例子：上網搜尋資訊、看運動賽事影片、線上買雜貨、購買前比價
* 用來判斷他是否常找便宜、是否習慣線上購物等行為特徵

### 想（Thinks）：使用者心裡真正相信什麼

* 聚焦使用者腦中的自我對話與信念，這些想法未必會說出口
* 例子：對支出要小心、網路充滿駭客（hackers）、線上交易不安全
* 例子：行動應用程式很容易被駭（hack），因此對資安有疑慮

### 感受（Feels）：使用者的情緒狀態

* 使用情緒詞彙描述使用者的感受，而非理性判斷
* 例子：對運動感到自豪、對維持體態感到開心
* 例子：對長期工作與運動的高強度節奏感到疲累
* 例子：害怕價格被坑、害怕信用卡被盜刷或被駭

### 工作坊進行方式：同步書寫、限時完成

* 建議以團隊方式進行，每人拿便利貼（Post-its）先各自寫想法再貼到板上
* 初期不討論不交換，確保每個人都能輸出自己的觀點
* 建議設定 10 分鐘計時（timer），用限時促進直覺輸出並提升效率
* 若某個象限貼得較少也沒關係，後續會再處理與整理這些便利貼

## 6. [Exercise] The Empathy Map

# 第 4 節：The definition phase

## 7. Organize your ideas
### 從發散到收斂：定義階段（Define Phase）

* 同理心地圖（empathy map）階段是在發散（diverging），盡可能蒐集大量資訊
* 定義階段（definition phase）目標是收斂（converge），把想法整理、分群並找出主題（themes）
* 依同理（empathy）階段蒐集到的資訊，辨識使用者/客戶的需求（needs）

### 需求（Needs）的定義：用動詞而不是名詞

* 需求可以是生理或情緒上的必要（physical / emotional necessities），反映使用者目標與動機（goals / motivations）
* 表達需求時應用動詞（verbs），避免用名詞（nouns）把解法先鎖死
* 用名詞會把某個方案當成唯一答案，降低發想空間；用動詞能保持開放，後續再找多種解法

### 「更快的馬」例子：避免把解法當需求

* 引用汽車產業早期觀點：如果問人想要什麼，可能只會說「更快的馬」
* 「更快的馬」是名詞導向，代表一個解法（solution）
* 若改用動詞「更快移動／更快到達（go faster）」就回到需求本身
* 以需求為核心時，解法可以是更快的馬、汽車或其他方式，變成「機會（opportunities）」而不是先定解法

### 定義階段的焦點：先釐清需求與機會

* 此階段不急著選解法，而是把需求說清楚
* 目的是找出「機會（opportunity）」與真正想解的問題，解法會在後面階段再決定

### 整理同理心地圖：先把相似便利貼分群

* 先把相似或重複的便利貼（Post-it notes）合併或分組
* 重複的便利貼不要丟掉，可疊在一起或聚在同一組，反映該主題出現頻率較高
* 例子：關於健康的重要性（例如「投資健康」「健康無價」）可視為同一概念並分到同組

### 例子：從句子抽出主題並命名分類

* 例子：把「只有火箭科學才搞得定」「這是瓦斯工廠」歸到「應用程式太複雜（complexity）」的主題
* 分類名稱由團隊決定，重點是要能幫助理解使用者，而不是追求唯一正確命名
* 透過分類把零散的句子轉為可用的洞察（insights）

### 可能得到的主題：說（Says）象限的整理結果

* 可整理出主題如：複雜度（complexity）、價格（price）、健康（health）
* 這些主題反映使用者在意的方向，例如在意健康價值、關注價格、反感系統複雜

### 可能得到的主題：做（Does）象限的整理結果

* 可能出現主題如：組織能力（organization）、線上活動（online activities）
* 反映使用者很有規劃、日常時間緊、常使用網路與線上購物
* 個別且不易歸類的便利貼可保留成單一項目，例如「購買前會比價」

### 可能得到的主題：感受（Feels）象限的整理結果

* 可能形成「運動自豪（pride）」等主題，顯示他對運動與體態感到正向情緒
* 無法合併的想法可保留原樣，不需要硬分組

### 可能得到的主題：想（Thinks）象限的整理結果

* 可整理出主題如：價格（price）、複雜度（complexity）、安全（security）
* 顯示使用者對被駭（hacked）有擔憂，需要被安撫與建立信任（reassurance）

### 限時收斂與整理原則

* 建議設定 5 分鐘計時（timer）完成分群整理
* 強調這不是精密科學（not an exact science），分類的目的是快速產出可用結構來理解人物誌（persona）

### 收斂後得到的使用者輪廓

* 使用者很有條理（organized），也不想浪費時間
* 覺得應用程式使用很複雜（complex）
* 對資安（security）有疑慮，擔心被駭（hacked）
* 後續會進一步看使用者旅程（user’s journey）以理解為何在行動應用程式上購買會覺得困難

## 8. The user journey
### 目的：分析使用者旅程找阻礙點（User Journey）

* 進一步貼近使用者與 App 的互動，真正「站在使用者鞋子裡」體驗流程
* 目標是找出阻礙點（blocking points）、動機（motivation）、困惑點、惱人點（irritation）
* 輸出可用來挖掘改善機會與新增功能方向，提升整體體驗（user experience）

### 分析方法：每一步拆成「做、想、感受」（Does / Thinks / Feels）

* 將旅程每個步驟用三個維度描述：做（does）、想（thinks）、感受（feels）
* 要求具體到操作行為、腦中疑問與情緒反應，避免只寫籠統敘述

### 使用者旅程四階段：補給品購買流程（Journey Phases）

* 產品搜尋（Product search）
* 加入購物車（Add to cart）
* 付款（Payment）
* 取得訂單編號（Receipt of order number）

### 階段一：產品搜尋（Product Search）

* 做（Does）：點選補給品分類、用品牌或價格篩選、點更多資訊查看商品細節
* 想（Thinks）：想知道每公斤價格以便比較但找不到、想確認是否有庫存但沒有可用性指標、選擇太多不清楚差異
* 感受（Feels）：面對選項感到迷失（lost），但也覺得好處是不用等配送可到健身房直接取貨

### 階段二：加入購物車（Add to Cart）

* 做（Does）：點加入購物車、確認要加入購物車
* 想（Thinks）：為什麼這頁不能調整數量、剛剛操作是否成功、沒有進度提示（progress indicator）不知道要不要再點一次
* 感受（Feels）：覺得流程不清楚、因為複雜而挫折（frustrated）

### 階段三：付款（Payment）

* 做（Does）：點付款、確認訂單明細、輸入信用卡資訊並付款
* 想（Thinks）：看不到鎖頭等安全標示（padlock / security indicator）、不確定交易是否正在處理
* 感受（Feels）：擔心被駭（hacked）、怕重複點擊導致被扣款兩次

### 階段四：取得訂單編號（Receipt of Order Number）

* 做（Does）：等待系統寄出確認信與訂單編號
* 想（Thinks）：不確定操作是否成功、不知道要等多久才會收到確認信、確認頁面沒有說明寄信時間或規則
* 感受（Feels）：壓力（stress）與不耐（impatience）

### 目前揭露的主要問題類型（Blocking Points Themes）

* 資訊缺口：缺少單位價格、庫存可用性、商品差異說明等關鍵資訊
* 狀態不透明：缺少進度提示與交易狀態回饋，導致不確定與重複操作風險
* 信任不足：付款安全感不足（缺安全標示與明確確認），引發被盜刷與重複扣款焦慮
* 等待不確定：訂單確認流程缺少時程與回饋，造成焦躁與不信任

## 9. [Exercise] The user journey

## 10. Identify opportunities
### 從使用者旅程找機會：先分群再談機會

* 已掌握人物誌（avatar）並辨識他與應用程式互動時遇到的挑戰
* 接下來要更細看使用者旅程（user journey），找出改善機會（opportunities for improvement）或新產品/服務機會
* 在進入「找機會」之前，先像整理同理心地圖（empathy map）一樣，把旅程中的觀察分群整理

### 旅程分群後的三大類問題

* 資安（security）相關問題反覆出現
* 清晰度不足（clarity），導致操作理解困難
* 缺少進度指示（progress indicators），讓人不確定操作是否成功

### 視覺化整理方式：用色碼標示分類

* 用顏色代碼（color code）在白板上標示不同分類
* 可用不同顏色小圓點貼紙對應每張便利貼（Post-it）
* 範例配色：紅色代表資安、綠色代表清晰度、橘色代表進度指示

### 資安（Security）類問題：缺乏安全感與信任訊號

* 付款流程缺少「付款安全」的提示或指標，讓使用者缺乏安心感
* 使用者受媒體駭客事件影響，擔心信用卡被盜刷與帳戶被清空
* 結果是使用者不敢往下完成付款

### 清晰度（Clarity）類問題：操作文字與流程不直覺

* 按鈕命名不清楚，造成理解負擔
* 使用者想快速完成購買以節省時間，但反而需要花時間猜測如何下單
* 產生挫折與不耐（frustration / loses patience），降低完成率

### 進度指示（Progress Indicators）類問題：不確定是否成功、害怕重複扣款

* 點擊按鈕後缺少「正在處理」或「已完成」的提示
* 使用者不知道操作是否生效，不敢再按第二次
* 主要擔憂是重複點擊導致被扣款兩次
* 這類問題幾乎在每個步驟都可能出現，成為反覆性阻礙

### 分類整理的目的：讓優先排序更容易

* 先把問題依類別分組，有助於後續做優先級排序（prioritization）
* 讓團隊能以主題為單位集中討論與提出解法
* 接下來的重點會進入「如何解決這些問題」的階段

## 11. Solve the problem
### 為何要先做優先順序（Prioritization）

* 組織資源有限，必須聚焦在最重要、最值得投入的改善項目
* 在提出解法前先排序，才能避免把力氣分散在影響小或成本過高的問題上

### 排序的兩個指標：可行性與重要性（Feasibility / Importance）

* 可行性（feasibility）或複雜度（complexity）：評估要投入多少資源才能做出來
* 重要性（importance）：評估這個改善對使用者體驗或目標成果的影響程度
* 目標是做相對排序：在多個挑戰之間找出第一、第二、第三優先

### 以投票方式排序（Voting）

* 常用做法是投票，讓團隊成員依各自判斷分配分數，形成共識
* 可用多種方法，講者提供的是最簡單的 1～3 分評分法

### 1～3 分評分法：規則（Scoring 1–3）

* 可行性（feasibility）：3 分代表最容易、1 分代表最不容易
* 重要性（importance）：3 分代表最重要、1 分代表最不重要
* 這是相對競爭（relative ranking），分數用於在同一組項目中拉開優先順序

### 範例：三個改善項目如何被排序

* 已辨識的三個挑戰：安全感（security）、流程清晰度（clarity）、進度指示（progress indicator）
* 安全感（security）：可行性 2、重要性 1，代表團隊認為偏複雜且相對較不優先
* 流程清晰度（clarity）：可行性 1、重要性 2，代表團隊認為最難做但重要性中等偏上
* 進度指示（progress indicator）：可行性 3、重要性 3，代表容易做且最重要，因此成為首要聚焦項目

### 本訓練的聚焦方向：進度指示（Progress Indicator）

* 以進度指示（progress indicator）為主要改善目標
* 用來讓使用者清楚知道自己在購買流程中的位置與進行狀態（where he stands in the purchasing process）
* 目的在降低不確定感，避免重複點擊與焦慮感

### 定義階段常用句型：How might we（HMW）

* How might we（HMW）用於把挑戰改寫成可解的問題句，讓思考自然導向解法
* How：讓焦點放在「怎麼做」而不是停留在問題描述
* Might：傳達「可行且值得嘗試」，避免一開始就否定
* We：強化團隊責任感與自主性（responsibility / autonomy）
* 建議每個挑戰各寫一句 HMW，作為後續發想（brainstorming）時的共同目標

### HMW 句型範例（Examples）

* 如何我們能加入進度指示，顯示購物流程的進展？（How might we show the progress of the shopping process?）
* 如何我們能提升購買流程中的安全感？（How might we increase the feeling of security during the buying process?）
* 如何我們能讓購買流程更清楚、更明確？（How might we make the buying process clearer / more explicit?）

### 階段銜接：從定義到發想（Definition → Ideation）

* 透過排序與 HMW 句型完成定義階段（definition phase）
* 接著進入發想階段（ideation phase），用 HMW 聚焦團隊產出解法方向

## 12. [Exercise] Solve the problem
### 練習目的與時機

* 已釐清理想客戶（ideal client）面臨的挑戰後，進入協助客戶克服挑戰的階段
* 強調在思考解決方案前，必須先做挑戰的優先排序（prioritization）

### 優先排序的評估標準：可行性（Feasibility）

* 針對列出的各項挑戰評估可行性（feasibility）
* 以 3～1 分表示難易度
* 3 代表最容易執行的三項
* 1 代表最難執行的一項

### 優先排序的評估標準：重要性（Importance）

* 針對列出的各項挑戰評估重要性（importance）
* 以 1～3 分表示重要程度
* 1 代表最不重要
* 3 代表最重要

### 需求定義句型：我們如何才能…（How Might We）

* 每個挑戰都要轉成「我們如何才能…？」的提問句型（How Might We, HMW）
* 目的在於以問題導向的方式界定改善方向，而非直接跳到解法

### 題目提供的 HMW 範例

* 我們如何加入進度指標（progress indicators）？
* 我們如何展示購買流程（purchase process）的進展？
* 我們如何增強消費者在購買過程中的安全感（feeling of security）？
* 我們如何讓購買流程更清晰（clarity）？
* 我們如何讓購買流程更清晰明確（more explicit）？

# 第 5 節：Ideation

## 13. The mindset to find ideas
### 發想階段（Ideation Phase）的目的

* 在發想階段（ideation phase）要盡可能提出大量點子與解法，協助使用者克服挑戰
* 依專案性質，也可能在此階段發現新產品（new products）的機會
* 發想流程不只屬於設計思考（design thinking），也常見於其他需要產生解法的方法論

### 發想需要的心態：保持開放心態（Open-minded）

* 保持開放心態（open-minded）是第一要點
* 面對看似怪異或天馬行空的點子時，人容易排斥
* 但往往是這些奇怪點子能引出最佳解法或新方向

### 發想規則：暫停評價（Suspend Judgment）

* 在過程中先暫停評價（suspend the judgment）
* 不批判、不攻擊他人的想法
* 避免審查他人想法，也要避免自我審查（self-censorship）

### 發想規則：信任自己（Trust Yourself）

* 鼓勵信任自己（trust yourself），即使想法暫時不可行也要說出來
* 不可行的想法可能成為他人延伸新點子的觸發點

### 發想規則：先求量再求質（Quantity over Quality）

* 初期追求數量（quantity），不急著評估品質（quality）
* 後續再整理、篩選與收斂
* 允許更瘋狂或更新的點子，以擴大探索範圍

### 發想規則：讓每個人都被聽見（Listen to Everyone）

* 每個人的聲音都重要（every voice counts）
* 需顧及內向者（introverts）不易在團體中發言，但可能提出很好的點子
* 需要鼓勵內向者表達，同時引導外向者（extroverts）避免壟斷討論

### 常見的發想方法：心智圖（Mind Map）

* 心智圖（mind map）從中心概念出發畫分支，用來拆解主題與擴展想法
* 作為產生點子或整理想法的結構化工具

### 常見的發想方法：腦力激盪（Brainstorming）

* 腦力激盪（brainstorming）是常見的點子產生方式
* 文中提到會在後續內容進一步說明

### 常見的發想方法：分鏡（Storyboarding）

* 分鏡（storyboarding）作為產生或呈現解法的方式
* 文中提到會在下一段落詳細介紹

### 常見的發想方法：最糟點子（Worst Idea）與反向腦力激盪（Reverse Brainstorming）

* 最糟點子（worst idea）屬於反向腦力激盪（reverse brainstorming），要求參與者先想出最差的解法
* 優點是降低拘束與自我審查（self-censorship），因為目標就是「想最糟」
* 也能先排除明顯壞點子，進而騰出空間找更創新解法

### 重要但常被忽略的方法：直接問使用者（Ask the User）

* 直接向使用者/客戶徵求點子（ask our user/customer for ideas）常被忽略
* 終端使用者（end customer / end user）可能反而最懂問題，能提出最貼近需求的想法
* 這是不可忽視的點子來源

### 經驗案例：與典型使用者共創（Co-creation）

* 在軟體專案中，團隊直接拜訪典型使用者，展示想法並讓對方協助改進
* 在做出原型（prototype）之前就先討論，確保方案貼近需求並獲得新點子

### 經驗案例：受訪者視角揭露同理困難

* 新創請作者試用並評估線上教練（online trainer）應用程式
* 每個流程節點暫停收集回饋（feedback）與新點子
* 因團隊成員不是線上教練，反而更難站在使用者立場，凸顯同理（empathy）不足的挑戰

## 14. Brainstorming
### 腦力激盪的目的（Brainstorming）

* 腦力激盪（brainstorming）是把一群人聚在一起，針對問題或挑戰大量產生點子
* 若沒有方法與規則，討論容易變成輪流發言、互相評論、離題插話，最後沒有結論甚至更混亂

### 建議人數與會議特性

* 小團體最理想：4～6 人
* 採時間盒（time-limited）形式，有助保持專注與效率
* 小團體更容易圍繞同一目標前進，降低討論發散失控

### 需要明確目標：HMW（How might we）

* 會議必須有清楚目標，最好用 How might we（HMW）句子描述要解的挑戰
* 目標需在會議中清楚宣布並維持可見（寫在白板或投影），用來防止偏題

### 必備材料與工作方式

* 每人準備便利貼（Post-it）與筆（markers）
* 先個人發想再共享：每位成員先用固定時間（例如 5 分鐘）盡量寫出多點子在便利貼上
* 再把便利貼貼到板上，由每個人逐一說明自己的點子
* 將相似點子分群（group together similar ideas），便於後續整理與選擇

### 腦力激盪的核心規則（Rules）

* 暫停批判與評斷（suspend judgment）
* 鼓勵瘋狂點子（crazy ideas are encouraged）
* 在他人點子上加建（build on the ideas of others）
* 一次一人說話（one person speaks at a time）
* 視覺優先（prioritize visuals）
* 建立安全且合作的空間，讓所有人能無懼分享而不怕被否定或嘲笑

### 心理安全的重要性（Psychological Safety）

* 若團隊包含主管層（managers / supervisors / directors），成員可能更容易防衛或自我審查
* 先立規則並強調「所有點子都先接住」，才能讓創意被釋放並節省討論成本

### 以 John Sportsman 為例：進度顯示的發想方向

* 可在 App 底部加入進度條（progress bar）顯示購買進度
* 可顯示「第 1/4 步」等步驟指示（step indicator）：商品選擇、訂單確認、付款、取得訂單編號
* 可在每次切換頁面時顯示提示視窗（pop-up），提醒剩餘步驟與目前位置
* 可提出更跳躍的方案如語音互動（interactive voice system），結合圖形介面與語音完成購買
* 在此階段不評斷好壞，目標是產出最大量想法以擴大解題空間

### 後續流程：從發想到選擇（Selection Phase）

* 腦力激盪完成後進入篩選與選擇階段（selection phase）
* 建議由團隊共同完成，讓決策更一致並提高認同感

### 會議安排與引導者角色（Facilitator）

* 建議早上進行，精神較清醒；避免午餐後容易疲倦的時段
* 最好有引導者（facilitator）負責說明規則、控場、必要時重新框定（reframe）
* 引導者也要主動讓較內向者有發言機會，避免討論被少數人主導

## 15. The 6-3-5 method
### 技巧名稱與目的：六三五法（6-3-5 Method）

* 六三五法（6-3-5 method）是一種高效率、也很有趣的發想技巧，用最短時間產生大量點子
* 強調以結構化（structured）方式快速產生「很多很多」想法

### 命名邏輯：6、3、5 代表什麼

* 6 代表 6 位參與者（可彈性調整為 4～5 人也能做）
* 3 代表每一輪每人要寫 3 個點子
* 5 代表連續進行 5 輪（rounds）

### 重要原則：全程限時（Time-boxing）

* 六三五法需要嚴格限時（time-boxing），才能在短時間內產出高密度點子
* 每一輪寫點子的時間上限建議 5 分鐘，不要超過

### 事前準備：表格與題目要先清楚

* 每位參與者拿到一張表格，包含 6 列（rows）與 3 欄（columns）
* 三欄用來填「點子1、點子2、點子3」
* 一開始就要公告要解的問題（problem statement），並清楚寫下目標
* 可沿用「我們如何才能…？」（How Might We, HMW）作為題目描述

### 操作流程：第一輪各自寫 3 個點子

* 六位參與者各自獨立在第一列寫下 3 個點子
* 倒數計時 5 分鐘完成，期間不需要討論

### 操作流程：換紙接力並延伸他人點子

* 5 分鐘結束後，每人把紙傳給右邊的人
* 先花一點時間閱讀前一位留下的內容，再開始下一輪倒數
* 每一輪都要再寫 3 個新點子
* 新點子可以延續既有方向，也可以完全不同，不強制一定要沿用前人的想法

### 延伸示例：用他人點子加細節

* 看到前人寫「每一步跳出提示（pop-up）」「顯示剩餘步驟數」等想法
* 可以在此基礎上補充「加入完成付款的預估時間（time estimate）」等細節
* 反映六三五法的核心：在他人點子上疊加（build on ideas）與擴展

### 產出規模：一小時內大量點子

* 完成 5 輪後，6 列會被填滿
* 每張表共有 18 個點子（6 列 × 3 欄）
* 6 張表合計 108 個點子（6 × 18），可在不到一小時內完成

### 空間調整：需要畫圖時的做法

* 若題目需要繪圖或更大書寫空間，可放大表格
* 可用 A3 紙張（A3 format）提供更多空間

### 收斂與下一步：分群與再投票

* 活動結束後先把相似點子分組（group similar ideas）
* 接著可進行新一輪投票（vote）來做優先排序（prioritize）
* 用於決定接下來專案要聚焦與落地的解法方向

# 第 6 節：The prototype

## 16. Create a prototype
### 進入原型階段（Prototype）

* 當方案優先順序（prioritized solution）確定後，就進入原型（prototype）製作
* 目標是以最快速度做出可測試的版本，用來蒐集使用者回饋（feedback）

### 為何先做原型而不是直接做完整產品

* 直接開發完整產品（complete product）成本高、時間長，且結果不確定
* 尚未確認終端客戶（end customers）是否喜歡或是否真的需要該功能
* 原型能在早期降低風險、節省時間與金錢（save time and money）

### 原型形式依領域而定（Prototype Formats）

* 行動應用（mobile application）可用線框工具（wireframing / prototyping tool）快速做互動示意
* 也可用紙本原型（paper prototype）：把購買流程每一步畫在不同紙張上，模擬頁面切換與操作

### 紙本原型的操作方式（Paper Prototype Walkthrough）

* 逐步向使用者解釋流程與介面：按鈕、頁面、進度指示（progress indicators）、安全指示（security indicators）等
* 用情境引導方式模擬操作：「你點這裡會到下一頁」「點這裡會跳出提示視窗（pop-up）」等
* 一邊展示圖稿一邊詢問使用者感受與理解程度：「你覺得如何？」「你會知道下一步要做什麼嗎？」

### 原型的核心優勢：修改成本極低

* 對紙稿或低保真原型（low-fidelity prototype）做修改幾乎沒有成本
* 能快速迭代（iterate）與修正方向，而不必承擔完整開發的代價

### 回饋目標：真實且誠實的使用者意見

* 重點是盡快推出原型並獲得真實、直接、誠實的回饋（real / honest / sincere feedback）
* 回饋用來驗證設計是否解決痛點、是否提升理解與信任感，而不是用來證明團隊原本想法一定正確

## 17. [Article] Online tool to create mockups
### 文章主題：線上建立原型工具清單

* 用於建立原型（prototype）的線上工具，適用於行動應用程式（mobile applications）與網站（websites）

### 原型工具（Prototype Tools）

* MockFlow（mockflow.com）：影片中使用的工具
* Balsamiq Cloud（balsamiq.cloud）
* Moqups（moqups.com）
* Figma（figma.com/design）
* Wireframe.cc（wireframe.cc）：偏線框稿（wireframe）快速製作

### 協作與客戶展示工具（Collaboration & Demo）

* Zeplin（zeplin.io）：用於協作（collaboration）與客戶展示（demo），可與 Figma、Sketch、Adobe XD 整合（integrate）

## 18. Storyboarding
### 低成本原型法：故事板（Storyboarding）

* 故事板（storyboarding）是一種低成本原型（prototype）方法，用繪圖呈現使用者與產品/服務互動的路徑與步驟
* 源自電影分鏡（cinema storyboard），用一格格畫面描述重要場景
* 目的：重建使用者旅程（user journey），凸顯關鍵行為、重要時刻與情緒

### 使用時機：原型階段或發想階段（Prototype / Ideation）

* 常放在原型階段用來快速呈現解法
* 也可在發想階段（ideation phase）使用，用視覺化方式推進概念與情境

### 故事板用途：對外溝通與對內對齊

* 給客戶看：展示設計的使用步驟與體驗流程
* 給高層看：向高層決策者（executive committee）說明方案以取得核准
* 給技術團隊看：產品經理（product manager）用來向工程團隊（technical team）說明預期流程與互動

### 製作方式：6～8 格縮圖（Thumbnails）

* 用白紙或白板畫 6～8 格縮圖（thumbnails），格數依專案需要調整
* 每一格傳達一個重點：情境、行動、想法、情緒或關鍵訊息
* 只畫必要元素，不影響敘事的細節可以省略，避免陷入枝節

### 規則與心態：重點是傳達，不是畫功

* 沒有固定規則，需依產品特性彈性調整
* 不必是專業畫家，畫得粗糙也能有效溝通概念
* 可用文字放在格內或描述欄，呈現角色當下想法或情境內容

### 範例：John Sportsman 購買蛋白粉的 8 格故事板

* 場景 1：在廚房發現蛋白粉用完，不想等配送，情緒不爽
* 場景 2：在客廳看球賽前想快速下單，狀態急迫，不想花太多時間
* 場景 3：進入挑選頁，商品資訊與進度指示讓他知道自己在第 1 步，覺得清楚
* 場景 4：點選商品後跳出提示視窗（pop-up），用勾勾確認操作成功，並顯示剩餘時間（沙漏），感覺流程很快
* 場景 5：選擇數量，只先買 1 份測試是否順利，然後送出驗證
* 場景 6：付款頁顯示第 3 步的進度，輸入信用卡資料，看到鎖頭（padlock）提升安全感，覺得放心
* 場景 7：最後確認頁直接顯示訂單摘要與可取貨日期時間，不必等確認信，立即得到確定感
* 場景 8：到健身房拿到蛋白粉，情緒滿意，回到目標「增肌」

### 一次解太多問題的取捨：聚焦與分期（Scope / Phasing）

* 故事板可以同時呈現多個改善點，例如進度指示（progress indicators）與安全指示（padlock）
* 也可以只聚焦單一面向，因為實際開發往往需要分期（phases）進行，無法一次做完
* 需要同時保留最終願景（end result），並規劃中間階段的落地步驟

### 執行建議：時間盒避免陷入細節（Time-boxing）

* 這個練習應採時間盒（time-limited），避免過度雕琢介面細節而偏離目標
* 以「讓旅程與關鍵訊息可被理解」為完成標準，而不是把每個畫面畫到完整 UI 規格

## 19. [Exercise] Storyboarding
### 練習主題：故事板（Storyboarding）

* 進行故事板（storyboard）練習，輪到你開始動手做

### 製作方式

* 可以手繪故事板（draw your storyboard）
* 也可以使用線上工具（online tool）製作

### 參考工具

* 影片示範使用 Storyboard That（storyboardthat.com）

## 20. MVP (Minimum Viable Product)
### 概念介紹：最小可行產品（MVP, Minimum Viable Product）

* MVP（Minimum Viable Product）是「最小可行產品」的概念，本身不是新概念
* 由 Eric Ries 在《精實創業（The Lean Startup）》中普及
* 常被用於產品管理（product management）訓練，因為能帶來良好成果

### MVP 的核心做法：用最小功能快速上線驗證

* 新產品在做過基本市場研究後，先推出第一版 MVP
* 以最少功能（minimum functionalities）上線測試市場反應
* 直接向終端使用者（end users）收集資料（data）與回饋（feedback）
* 衡量產品是否成功，吸取教訓（learn lessons），再規劃改進並推出新版本
* 持續迭代（iteration）循環，直到產品逐步成熟

### MVP 的主要優點：降低長期投入後失敗的風險

* 避免花數月或數年開發後才發現市場不喜歡或沒有需求
* 以更快節奏驗證方向，降低時間與成本的浪費
* 在軟體（computing / software）領域，產品即使上線後也會持續演進

### 與設計思考（Design Thinking）與精實（Lean）邏輯的關係

* MVP 的邏輯與設計思考（design thinking）非常相近，皆符合精實哲學（lean philosophy）
* 設計思考流程：找需求、定義問題、發想解法、做原型（prototype）、測試、收集結果、再循環
* 文中提到設計思考常見於設計領域（design），而精實（lean）常見於產品經理（product managers），但本質原則相通

### 應用情境：電商（E-commerce）銷售下滑時的做法

* 若電商主力商品（flagship products）銷售下滑，可考慮用精實創業（Lean Startup）方式推出新品
* 快速推出 MVP 蒐集客戶回饋，再決定是否持續改進進入下一輪循環

### 關鍵決策：持續迭代或轉向（Pivot）

* 根據回饋決定：改進 MVP 繼續循環，或改變方向（pivot）
* 轉向（pivoting）可能包含改變目標客群（target audience）或調整功能方向（features）

### 例子：Instagram 的轉向（Pivot）

* Instagram 初期概念偏向拍照並地理標記（geolocation），強調「我在這裡拍了這張照片」
* 團隊發現濾鏡（filters）功能更受歡迎，於是轉向成為以分享照片與濾鏡為核心的產品
* 成功關鍵來自後續轉向，而非一開始的原始構想

### 收尾重點：需要量測系統（Measurement System）

* 在做原型（prototype）與推 MVP 的同時，必須建立能量測進度的系統（system to measure progress）
* 以可衡量的方式追蹤成果，支撐後續迭代或轉向決策

## 21. Prioritize your tasks-The MoSCoW method
### 為何需要再做一次任務優先順序（Task Prioritization）

* 原型方向確定後，仍無法同時開發所有功能，必須把待辦事項（tasks / to-do list）依優先順序排列
* 受時間與預算限制（time / budget constraints），需要用可落地的方法把需求分類，避免全部都「看起來很重要」

### 設計思考到落地開發：角色分工與責任（Roles & Responsibilities）

* 以軟體專案視角，產品經理（Product Manager）通常負責定義專案待辦清單（to-do list）
* 在 Scrum（Scrum）中，產品負責人（Product Owner）是負責優先排序待辦事項的人
* 待辦事項不是單人決定，而是由產品團隊與客戶共同討論、逐步形成

### 實務運作方式：設計思考工作坊（Design Thinking Workshops）

* 產品經理負責組織設計思考工作坊，邀請產品/專案相關角色共同參與
* 參與角色可包含：開發者（developers）、功能分析師（functional analysts）、使用者體驗（UX, user experience）相關人員
* 工作坊中會針對定義（definition）、發想（ideation）、原型（prototype）等階段一起代入使用者視角
* 產品經理再與客戶直接溝通，取得回饋並整合成後續開發方向

### 與敏捷開發結合：Scrum 與迭代回饋（Agile / Scrum）

* 設計思考用來產出與驗證方向，後續用 Scrum（Scrum methodology）進行開發
* 以衝刺（sprints）方式交付，例如每 3 週一個 sprint
* 每個 sprint 結束向客戶展示（demo）並收集回饋，再進入下一個 sprint
* 因為無法把所有點子一次做完，才需要一套簡單且一致的排序機制

### 優先排序方法：MoSCoW（MoSCoW Method）

* MoSCoW（MoSCoW method）是一種容易記、易操作的需求分類法
* 重點是大寫字母 M / S / C / W；中間的 “o” 只是為了好念、好記的助詞，不影響分類概念

### Must have：必須有（Must Have）

* 定義：產品不可缺少的核心項目，屬於「非做不可」（non-negotiable）
* 這一類通常對應最小可行產品（MVP, minimum viable product）的必要功能
* 目標：用最小努力做出可上線測試的版本，盡快取得客戶回饋（feedback）

### Should have：應該有（Should Have）

* 定義：很重要、應該做，但不是「缺了就不能用」
* 原則：通常在 Must have 完成後再做，若資源允許就納入

### Could have：可以有（Could Have）

* 定義：有會更好，但沒有也不影響核心任務
* 常屬於「舒適功能」（comfort features）或加分項
* 原則：只有在不影響其他任務、資源充裕時才做

### Won’t have：暫時不做（Won’t Have）

* 定義：本期不做，未來有時間再考慮的功能
* 用途：把「想要但不急」的需求先放到未來版本（future version），避免拖累當期交付

### 建議做法：用工作坊完成分類（Workshop-based Categorization）

* 建議在專門工作坊中，由利害關係人（stakeholders）一起討論並分類每個需求
* 過程中一定會有分歧與辯論，但這是必要的對齊工作
* 好處：讓各方對需求重新取捨、促進建設性討論，也更容易形成共同承諾
* 特別適用在需求量很大、難以排序時，能快速降低混亂並提升決策效率

# 第 7 節：The test phase

## 22. The purpose of the test phase
### 最後階段：測試（Testing Phase）

* 設計思考（Design Thinking）的最後階段是測試（testing phase）
* 目標是測試使用者/客戶與產品或服務的互動（interaction）
* 被視為「關鍵時刻」（moment of truth），用來驗證方向是否正確

### 測試目的：蒐集回饋與驗證假設（Feedback & Assumptions）

* 核心目的是向使用者蒐集回饋（feedback）
* 用來檢查先前在個人或團隊階段提出的假設（assumptions）是否正確
* 同時回頭檢驗先前定義的使用者挑戰是否成立

### 要驗證的挑戰範圍：從使用性到介面細節

* 檢查是否真的存在你認為的痛點，例如安全性（security）、可近用性（accessibility）、進度指示（progress indicator）
* 也可能包含：選項數量限制、按鈕尺寸、配色（color）等介面設計因素
* 目標是在接近真實使用情境（real conditions）的條件下驗證

### 迭代（Iteration）觀念：測試不是終點

* 設計思考流程不會在測試後結束
* 測試階段完成的是第一輪迭代（first iteration）
* 測試後會蒐集更多資訊，再啟動下一輪迭代以改進產品

### 對「不完美」的接受：逐輪逼近最佳解

* 很少能在第一輪迭代就做出完美成果
* 需要接受「嘗試—假設—驗證—修正」的循環
* 有時假設正確，有時需要吸取教訓（learn lessons）並重來
* 每完成一次迭代，產品就更接近最符合使用者需求的版本

### 測試執行的態度：像科學家一樣觀察與記錄

* 測試階段必須謹慎進行，因為它直接影響後續改進方向
* 要以科學家（scientists）的心態：文件化（document）、量測（measure）、觀察（observe）
* 重視細節、問題設計的精確性、以及觀察力，才能找出可改進點

### 測試的產出：改善點與新機會

* 透過細緻觀察與提問，能得到具體的改進靈感
* 也可能延伸出新產品的想法或新機會
* 後續內容會延伸介紹如何把測試結果轉成下一步行動與改良方向

## 23. Collect feedback
### 測試需事前規劃：場景（Scenario）與假設（Hypothesis）

* 測試階段必須事先規劃（planned in advance），不能臨場隨意進行
* 需要保持開放心態（open minded），但同時要有明確指引
* 先準備要驗證的測試場景（scenarios），用來確認或否定假設（hypotheses）
* 可針對特定功能（features）或產品/應用程式的特定面向做測試

### 設定驗證標準：主觀與客觀指標（Subjective / Objective Criteria）

* 事先定義用來確認或推翻假設的判準（criteria）
* 可用主觀標準（subjective criteria）例如使用感受、困惑程度
* 也可用客觀標準（objective criteria）例如完成下單所需時間、完成操作所需點擊次數

### 心態提醒：不要愛上自己的產品

* 不要對自己的應用程式/產品產生過度投入（fall in love with your product）
* 使用者不喜歡某功能，不代表使用者「不行」，而可能是設計需要修正的訊號
* 使用者卡住可能代表介面設計需調整、目標客群（target audience）不對、測試流程不佳，或功能應改進甚至移除
* 重點是提出假設、測試、再測試（test and retest），並從結果學習

### 測試執行方式：觀察、紀錄與限時（Observation / Notes / Time-boxing）

* 測試時至少需要一位使用者/客戶與一套筆記工具（take notes）
* 可選擇錄影（film）以利回看細節
* 建議限制測試時間（time-boxing）以提升效率
* 若可行，兩人一組進行：一人做紀錄，另一人專注觀察使用者行為

### 測試紀錄表：用四象限結構化整理

* 可準備測試紀錄表（test sheet），內容可依專案需求調整
* 先描述測試時採用的心態與要測的場景（scenario）
* 使用四象限整理觀察與產出，讓測試更有結構並避免遺漏

### 原型形式：可用可運作版本或紙上原型（Prototype）

* 測試可用可運作的原型（working prototype），例如應用程式第一版
* 也可用繪圖原型（prototype in the form of drawings）
* 若使用繪圖原型，要先向使用者說明每張圖對應的步驟與情境，並解釋點擊後的流程轉換

### 象限一：做得好（What Went Well）

* 記錄使用者哪些地方操作順、理解快、流程自然
* 例子：使用者能在頁面間順利導覽、能輕鬆挑選想要的補充品（supplements）

### 象限二：可改進處（What Can Be Improved）

* 記錄使用者卡住、困惑、操作不順或明顯摩擦點
* 例子：加入購物車（add to cart）按鈕太小，導致難以點選，需要放大

### 象限三：問題清單（Questions）

* 記錄測試過程中出現但當下無法回答的問題，避免遺漏
* 例子：是否同時在 Android 與 iOS 上線、信用卡使用何種加密（encryption）、下單後能否取消訂單等

### 象限四：想法與建議（Ideas / Suggestions）

* 收集使用者的建議與測試過程中浮現的新點子
* 可直接詢問使用者希望新增或改善哪些內容
* 例子：顯示庫存數量（stock level）以避免等待、加入社群分享（social media sharing）換取折扣等

### 重要技巧：請使用者大聲說出心裡想法（Think Aloud）

* 要求使用者進行大聲思考（think aloud），描述腦中正在想什麼
* 目標是掌握使用者看到什麼、怎麼想、感受如何（what they see / think / feel），避免靠猜測
* 同時釐清喜歡與不喜歡的點，找出應該移除或調整的部分

### 重複測試：多位使用者帶來更可靠洞察

* 若資源允許，應與不同使用者重複測試
* 透過多次測試比對，能更清楚辨識共通問題與真正優先的改進點

## 24. [Exercise] Collect feedback

## 25. A/B testing
### 方法目的：用 A/B 測試（A/B Testing）驗證假設

* 當在兩個或以上選項之間猶豫時，可用 A/B 測試（A/B testing）驗證假設
* 同時測兩個版本並量測結果，找出表現較好的版本
* 核心是用數據確認「哪個更有效」，而不是靠直覺選擇

### 適用範圍：可測的變因都能做（Variants）

* 可測廣告顏色（ad color）或加入購物車按鈕（add to cart button）的顏色，觀察轉換率（conversion rate）
* 可測商品圖片尺寸（product image size）對轉換率的影響
* 部落格可測文章預覽長度（excerpt length），例如先顯示 2 行、3 行、4 行，量測點擊「了解更多」（learn more）的比例以提升互動（engagement）

### 與原型測試的關係：可搭配也可分開

* A/B 測試可與原型測試（prototype testing）同時進行或分開進行，取決於產品型態與測試目標
* 例：一邊觀察使用者整體體驗流程，一邊針對「購買按鈕顏色」做 A/B 測試比較轉換率
* 兩者可互補：原型測試偏質性體驗與阻礙點，A/B 測試偏量化指標比較

### 前提條件：需要可比較的版本（Version A / Version B）

* A/B 測試通常需要有第一版產品或可操作的版本
* 理論上可用紙本（paper prototype）做，但更常見是讓不同使用者只看到版本 A 或版本 B，以便比較行為差異

### 基本流程：建立兩版本、隨機分組、量測比較

* 從原始原型出發，建立兩個變體（variations）
* 聚焦單一變因，避免同時改太多導致結果難解讀
* 將樣本隨機分配（random sample）成兩組，一組只看版本 A，另一組只看版本 B
* 樣本越大，結果越可靠（more reliable）與更具意義（more meaningful）
* 量測並比較兩組的轉換率（conversion rates），選出表現更好的版本

### 迭代找最優：勝者再對戰下一個版本

* 先比較兩個顏色：例如橘色 vs 黃色，若橘色轉換率較高就保留橘色
* 再用橘色去對比下一個候選：例如橘色 vs 紅色
* 反覆比較直到找到能帶來最佳轉換率的顏色或設計選項

## 26. Sailboat retrospective
### 主題：定期回顧以持續改進（Continuous Improvement）

* 強調要定期盤點（take stock）以改善工作方式並即時修正方向
* 敏捷（Agile）與設計思考（Design Thinking）都重視持續改進（continuous improvement）的精神
* 透過固定回顧會議檢視哪些做得好、哪些需要改善、哪些應停止

### 會議名稱：帆船回顧（Sailboat Retrospective）

* 帆船回顧（sailboat retrospective）是敏捷（agile）世界常見的回顧會議，也可用在設計思考流程
* 相較於單純列清單（做得好／可改進／要停止），帆船回顧更視覺化（visual），更容易看出改進重點
* 常見節奏是每三週或每月進行一次回顧

### 視覺隱喻：船、島、風、錨、礁石

* 船代表團隊（team）與專案運作
* 天堂島代表目標（objectives）或要達成的目的地
* 順風（favourable winds / tailwinds）代表推動前進的正向因素與成果（accomplishments）
* 錨（anchors）代表拖慢進度的阻礙與障礙（barriers）
* 礁石（rocks）代表風險（risks），需要提前辨識以避免翻船（shipwreck）

### 順風（Tailwinds）：保留並持續的有效作法

* 順風是讓團隊更接近目標的行動與成果，代表「要繼續做」的事情
* 每位成員用便利貼（Post-it）寫下在最近一個週期（sprint）中團隊做得好的事
* 目的包含提升動機（motivation）與獲得肯定（recognition）
* 最後由每位成員朗讀自己的便利貼內容，讓正向行為被看見

### 錨（Anchors）：拖慢進度的障礙來源

* 錨是阻礙成功、降低進度的因素，需要被移除以讓團隊更快前進
* 例子：客戶不回信、測試環境不穩（unstable test environment）、設備或電腦狀況不佳
* 也可能是組織或人際問題，例如同事衝突、部門不合作、決策者缺席

### 礁石（Rocks）：需要避開的風險（Risks）

* 礁石象徵可能造成重大損害的風險，需要被看見並提前規避
* 目標是讓團隊能更安全地推進，避免專案遭受重創

### 會議進行方式：分段聚焦＋便利貼輸出

* 建議一次專注一個分類，例如先做順風，再做錨，再做礁石
* 每個分類給固定時間讓每個人先安靜書寫，再進行分享與討論
* 透過便利貼機制確保所有人都能表達，不會只剩少數人主導討論

### 參與公平性：避免外向者壟斷（Extroverts）與內向者沉默（Introverts）

* 傳統群體討論容易由外向者（extroverted）主導，內向者（introverted）較少發言
* 帆船回顧要求每人先寫下想法再分享，提升多元觀點的覆蓋率

### 可選加項：太陽（Sun）紀錄團隊樂趣

* 可加入太陽（sun）分類，記錄近期有趣或溫暖的小事
* 例子：有人主動幫忙、發生有趣事件、同事帶蛋糕或點心
* 用意是提醒團隊努力之餘也要保留樂趣與正向氛圍

### 產出與落地：聚焦障礙與風險並形成行動方案（Action Plan）

* 所有便利貼貼上後，主要聚焦在障礙（anchors）與風險（rocks）
* 討論可行的解法來移除障礙並降低風險（mitigate risks）
* 團隊共同制定可立即執行的行動計畫（action plan），提升效率（efficiency）與生產力（productivity）

# 第 8 節：Quiz

## 測驗 1：Quiz

# 第 9 節：Conclusion

## 27. A final word

## 28. Contact

## 29. Bonus

## 30. Your certificate

---

# Terminology
* 設計思維（Design Thinking）：以人為本的創新方法，透過理解使用者需求來設計產品與服務
* 人本設計（Human-Centered Design）：以使用者情境、行為與需求作為設計決策核心的設計取向
* 同理心（Empathy）：換位理解他人感受與處境的能力，用於洞察真實需求與痛點
* 同理階段（Empathize）：設計思維流程中蒐集使用者洞察的步驟，包含訪談、觀察與情境研究
* 問題定義（Define）：將洞察轉化為清晰問題陳述，對齊目標、範圍與成功準則
* 構想發散（Ideate）：大量產生解法與點子，先求量與多樣性以打開解題空間
* 原型製作（Prototype）：快速做出可被體驗的雛形，用於驗證概念與降低不確定性
* 測試驗證（Test）：讓使用者體驗原型並蒐集反饋，迭代修正以逼近需求
* 可行性（Feasibility）：從技術與資源角度評估能否實作與交付的面向
* 可獲利性（Viability）：從商業模式與財務永續角度評估是否能長期成立的面向
* 期望性（Desirability）：從使用者價值與採用意願角度評估是否「想要」的面向
* 多學科整合（Multidisciplinary Approach）：結合工程、心理、行銷、管理等專業以提升解題品質的方法
* 民族誌研究（Ethnography）：以田野觀察與深入訪談理解文化與生活型態的研究方法
* 使用者研究（User Research）：系統性蒐集使用者資料以支持產品決策的研究活動總稱
* 情境訪談（Contextual Interview）：在使用情境中訪談並觀察行為，以捕捉真實工作流程與摩擦點
* 問卷調查（Survey Research）：以結構化題目蒐集大量樣本意見，用於量化趨勢與分群
* 競品分析（Competitive Analysis）：分析競爭對手產品策略、體驗與定位以找出差異與機會
* 使用者評論分析（Review Mining）：從評論與回饋中萃取常見痛點、需求與情緒訊號的分析方法
* 三星評論策略（Three-Star Review Heuristic）：優先研究中等評價以獲取具體改進建議的取樣方法
* 角色模型（Persona）：以資料與洞察建立的典型使用者原型，用於對齊設計決策
* 使用者化身（Avatar）：以具體人物設定承載需求與情境的代表性角色描述
* 同理心地圖（Empathy Map）：以「說、做、想、感」結構化整理使用者洞察的工具
* 說（Says）：同理心地圖中可被引用的使用者語句與外顯表述
* 做（Does）：同理心地圖中可觀察的行為、步驟與操作習慣
* 想（Thinks）：同理心地圖中推論的信念、顧慮與內在對話
* 感（Feels）：同理心地圖中推論的情緒狀態，如焦慮、挫折、期待等
* 可觀察行為（Observable Behaviors）：能以觀察驗證的外顯行為資料，降低主觀猜測
* 推論洞察（Inferred Insights）：由觀察與訪談推導的內隱想法與感受，需要後續驗證
* 假設驅動（Assumption-Driven）：先以假設啟動設計再用研究驗證與修正的工作方式
* 設計假設（Design Assumption）：對使用者、情境、需求或解法的暫定判斷，需透過測試確認
* 使用者旅程（User Journey）：描述使用者完成目標時的端到端步驟與情緒起伏的模型
* 痛點（Pain Point）：造成困擾、延遲或成本的摩擦點，常是優先改善目標
* 需求洞察（User Insight）：對使用者動機與行為原因的可行解釋，用於指引設計方向
* 機會點（Opportunity Area）：從痛點與洞察延伸出的改進或新服務可能性
* 主題分群（Affinity Clustering）：將大量便條內容按相似性歸類以找出模式與主題的方法
* 視覺標記（Color Coding）：用顏色區分主題或類別以提升整理與溝通效率的手法
* 資訊架構（Information Architecture）：內容與功能的結構設計，影響可找性與理解成本
* 介面清晰度（UI Clarity）：介面文字與操作提示的可理解程度，直接影響任務完成率
* 進度指示器（Progress Indicator）：顯示任務流程進度的元件，降低不確定感與重複操作
* 步驟流程（Step-by-Step Flow）：將任務拆成明確步驟的流程設計，提升可預期性
* 任務完成率（Task Completion Rate）：使用者能成功完成指定任務的比例指標
* 使用者信任（User Trust）：使用者對系統安全性與可靠性的主觀判斷，影響採用與付費
* 安全感知（Perceived Security）：使用者「覺得安全」的感受，需以訊號與透明度強化
* 支付信任訊號（Trust Signals）：如加密標章、第三方驗證與提示文案，用於提升付款信心
* 可擴展性（Scalability）：系統或流程在成本可控下支援成長與擴張的能力
* 可擴展性迷思（Scalability Dogma）：過度迷信自動化與規模化而忽略使用者價值的思維偏誤
* 實地體驗（Dogfooding）：團隊親自使用產品以感受痛點、驗證假設並提升同理
* 服務藍圖（Service Blueprint）：將前台體驗與後台支援流程對齊的可視化設計工具
* 構想規則（Ideation Rules）：如暫停批判、鼓勵瘋狂點子、先量後質等促進發想的規範
* 六三五法（6-3-5 Method）：6 人每輪各寫 3 個點子、共 5 輪快速產生大量構想的結構化發想法
* 腦寫法（Brainwriting）：以書寫取代口頭發想，降低搶話與從眾，提升輸出量的方法
* 輪轉發想（Round-Robin Ideation）：按順序輪流補充他人點子以延伸與擴散的協作機制
* 時限發想（Time-Boxed Ideation）：以固定時間限制促進直覺輸出與提高效率的做法
* 主持人（Facilitator）：負責規則說明、節奏掌控與促進參與的引導角色
* 團隊心理安全（Psychological Safety）：成員敢表達與嘗試而不怕被羞辱的工作氛圍
* 自我審查（Self-Censorship）：因害怕評價而壓抑點子的內在限制，會降低創意產量
* 暫停批判（Defer Judgment）：在發想階段延後評價以保護新點子生長的原則
* 先量後質（Quantity First）：先追求大量點子再進行篩選評估的發想策略
* 建立在他人點子上（Build on Ideas）：以聯想與延伸方式把既有點子推進成更成熟方案的技巧
* 瘋狂點子鼓勵（Encourage Wild Ideas）：刻意允許超常規點子以突破框架限制的發想規則
* 方案選擇階段（Selection Phase）：把大量點子收斂為可行方案並排優先序的階段
* 點子分群（Affinity Grouping）：將相似點子聚類以找出主題與方向的整理方法
* 投票優先排序（Dot Voting）：用點貼投票快速決定最受支持點子的群體決策法
* 加權投票（Weighted Voting）：以分配分數表達偏好強度的優先級決策方式
* 原型（Prototype）：用低成本方式做出可體驗雛形以驗證假設的產物
* 低保真原型（Low-Fidelity Prototype）：以草圖或紙本呈現流程與介面概念的粗略原型
* 高保真原型（High-Fidelity Prototype）：接近成品外觀與互動的原型，用於更真實測試
* 紙本原型（Paper Prototype）：用紙張繪製介面並模擬互動以快速迭代的原型法
* 線框圖（Wireframe）：以簡化布局呈現資訊架構與流程的介面設計圖
* 互動原型（Interactive Prototype）：可點擊或可操作的原型，用於驗證操作流程與可用性
* 快速迭代（Rapid Iteration）：以短週期反覆修改原型並驗證的開發節奏
* 使用者回饋（User Feedback）：由目標使用者提供的體驗意見與痛點資訊
* 情境測試（Scenario-Based Testing）：以任務情境引導使用者操作以觀察行為的測試方法
* 可用性測試（Usability Testing）：觀察使用者完成任務的效率與錯誤以找出體驗問題的測試
* 口述思考法（Think-Aloud Protocol）：要求使用者說出腦中想法以揭露認知歷程的研究技術
* 測試紀錄表（Test Notes Sheet）：以結構化欄位記錄觀察、問題與想法的測試文件
* 改進點（Improvement Opportunities）：測試中發現可提升體驗或降低摩擦的具體項目
* 觀察紀錄（Observation Log）：系統化記錄行為、停頓、誤操作等現象的資料
* 指標化驗收（Success Metrics）：以可量測指標判定假設是否成立的驗證方式
* 完成時間（Time on Task）：使用者完成任務所需時間，用於衡量效率與摩擦
* 點擊次數（Number of Clicks）：完成任務的互動步數指標，用於評估流程簡潔度
* 轉換率（Conversion Rate）：從瀏覽到完成行動的比例，用於衡量設計成效
* A/B 測試（A/B Testing）：同時比較兩個版本並以數據決定優勝者的實驗方法
* 隨機分派（Random Assignment）：將受試者隨機分到不同版本以降低偏差的實驗設計
* 樣本數（Sample Size）：參與測試的人數規模，影響結論的穩定性與可信度
* 統計顯著性（Statistical Significance）：判斷差異是否可能非偶然的統計準則
* 多變量測試（Multivariate Testing）：同時測多個元素組合以找出最佳配置的實驗方法
* 最小可行產品（MVP, Minimum Viable Product）：以最少功能快速驗證市場與假設的產品版本
* 精實創業（Lean Startup）：以「建造-衡量-學習」循環快速驗證與迭代的創業方法論
* 建造-衡量-學習（Build-Measure-Learn）：以迭代閉環持續修正產品方向的學習框架
* 轉向（Pivot）：根據學習結果調整目標客群、價值主張或功能方向的策略決策
* 故事板（Storyboarding）：用連續畫格描繪使用者旅程與關鍵情緒節點的可視化工具
* 使用者旅程圖（User Journey Map）：端到端描繪步驟、痛點與情緒曲線以找改善點的圖表
* 服務藍圖（Service Blueprint）：串聯前台體驗與後台流程以找斷點與責任分工的工具
* 敏捷回顧（Retrospective）：定期檢視合作方式並制定改進行動的團隊反思會議
* 帆船回顧（Sailing Boat Retrospective）：以船、島、風、錨、礁石隱喻結構化回顧的技巧
* 順風（Tailwinds）：推進目標的正向因素與做得好的行為，在回顧中用來強化延續
* 錨（Anchors）：拖慢進度的障礙與阻力，在回顧中用來制定移除計畫
* 礁石（Rocks）：潛在風險與隱患，在回顧中用來預防與降低衝擊