ux-design-thinking
用同理、定義、發想、原型、測試五階段解決以使用者為中心的問題
中文翻譯
---
name: "ux-design-thinking"
description: "運用設計思考的五個階段：同理、定義、發想、原型、測試，來解決以使用者為中心的問題。當使用者需要解決模糊的問題、重新設計使用者體驗、主持創新工作坊，或從零開始發展新的產品概念時使用這個 skill，就算他們說的是「我們不知道要做什麼」、「我們該怎麼創新」或「使用者不滿意但我們不確定原因」也一樣。"
metadata:
category: "WP-21 設計/資訊/傳播/公衛"
tags: ["design", "design-thinking", "innovation", "ux"]
---
# 設計思考
## 概述
設計思考是一種以人為本的創新方法，整合使用者需求、技術可行性和商業可行性。它的五個階段是迭代的，不是線性的，隨著理解加深，預期會回頭重做。
## 框架
```
IRON LAW: Empathize BEFORE Define, Define BEFORE Ideate
（鐵律：先同理再定義，先定義再發想）
還沒搞懂問題（Define）就跳到解法（Ideate），
會把力氣浪費在解錯的問題上。沒有同理使用者就去定義問題，
只會產出以內部為中心的問題陳述。
順序很重要：先理解人，再框出問題，
然後才產生解法。
```
### 五個階段
**1. 同理（Empathize）**：了解使用者的世界
- 觀察、訪談，沉浸在使用者的情境中
- 目標：理解需求、痛點和動機（不只是他們說了什麼，還有他們做了什麼、感受到什麼）
**2. 定義（Define）**：框出對的問題
- 把同理的發現綜合成一句觀點（POV）陳述：
`[User] needs to [need] because [insight]`
- 定義得好的問題，等於已經解決一半。需要的話就重新框架。
**3. 發想（Ideate）**：產生很多解法
- 發散：量比質重要。先延後評斷。
- 技巧：腦力激盪、How Might We 問題、SCAMPER、最糟糕的點子
- 然後收斂：投票、分群、選出 2-3 個概念去做原型
**4. 原型（Prototype）**：讓點子變得具體
- 快速、便宜、可丟棄的原型，用來學習
- 擬真度要配合問題：流程用紙本草圖、互動用可點擊的 mock、技術可行性用程式碼
- 目標：測試假設，不是讓利害關係人驚艷
**5. 測試（Test）**：向真實使用者學習
- 把原型放到真實使用者面前
- 觀察行為，不要只問意見
- 什麼有效？什麼失敗？什麼讓你意外？
- 如果核心假設錯了，就回到同理或定義
## 輸出格式
```markdown
# Design Thinking Sprint: {Challenge}
## Empathize
- User: {who}
- Key insights from research: ...
- Surprises: ...
## Define
- POV: [User] needs to [need] because [insight]
- How Might We: {3-5 HMW questions}
## Ideate
- Ideas generated: {count}
- Top 3 concepts: ...
## Prototype
- Prototype type: {paper / digital / physical}
- What it tests: {specific assumption}
## Test
- User feedback: ...
- Validated: {what was confirmed}
- Invalidated: {what was wrong}
- Next iteration: {what to change}
```
## 範例
### 正確的應用
**情境：** 重新設計醫院候診室的體驗
- **同理**：觀察病人 3 天。關鍵洞察：焦慮的高峰不是來自等待時間，而是來自對等待時間的「不確定」。
- **定義**：「病人需要感覺自己知道等候狀態，因為不確定性放大的焦慮，超過實際等待所造成的。」
- **發想**：40 多個點子 → 前 3 名：即時排隊顯示、簡訊位置更新、預估時間自助機
- **原型**：簡訊更新流程的紙本原型（5 分鐘做完）
- **測試**：測了 8 位病人 → 6 位表示感覺「焦慮少很多」，雖然實際等待時間沒變 ✓
### 錯誤的應用
- 跳過同理，一開頭就說「我們需要一個新的 app 功能」 → 沒搞懂問題就先想解法。違反鐵律。
## 常見陷阱
- **「快速失敗」需要心理安全感**：如果失敗會被處罰，團隊就不會去實驗。要讓大家知道，原型本來就是用來失敗的，那就是學習。
- **HMW 問題會決定解法空間**：「我們如何縮短等待時間？」和「我們如何降低等待時的焦慮？」會導向不同的解法。框架要小心。
- **原型 ≠ MVP**：原型是用便宜的方式測試假設。MVP 是可行的產品。不要把原型做過頭。
- **設計思考不只是給設計師用的**：它適用於服務、流程、政策、商業模式，任何涉及人類需求的問題。
- **迭代不是選項**：如果五個階段只跑一遍而沒有回頭，你做的是「貼滿便利貼的瀑布式開發」，不是設計思考。
## 參考資料
- 各階段的引導練習，見 `references/dt-exercises.md`英文原文
---
name: "ux-design-thinking"
description: "Apply Design Thinking's five stages — Empathize, Define, Ideate, Prototype, Test — to solve user-centered problems. Use this skill when the user needs to solve an ambiguous problem, redesign a user experience, facilitate an innovation workshop, or develop a new product concept from scratch — even if they say 'we don't know what to build', 'how do we innovate', or 'the users aren't happy but we're not sure why'."
metadata:
category: "WP-21 設計/資訊/傳播/公衛"
tags: ["design", "design-thinking", "innovation", "ux"]
---
# Design Thinking
## Overview
Design Thinking is a human-centered approach to innovation that integrates user needs, technological feasibility, and business viability. Its five stages are iterative, not linear — expect to loop back as understanding deepens.
## Framework
```
IRON LAW: Empathize BEFORE Define, Define BEFORE Ideate
Jumping to solutions (Ideate) without understanding the problem (Define)
wastes effort solving the wrong problem. Defining the problem without
empathizing with users produces internally-focused problem statements.
The sequence matters: understand the human first, then frame the problem,
then generate solutions.
```
### The Five Stages
**1. Empathize** — Understand the user's world
- Observe, interview, immerse in the user's context
- Goal: understand needs, pain points, and motivations (not just what they say, but what they do and feel)
**2. Define** — Frame the right problem
- Synthesize empathy findings into a Point of View (POV) statement:
`[User] needs to [need] because [insight]`
- A well-defined problem is half-solved. Reframe if needed.
**3. Ideate** — Generate many solutions
- Diverge: quantity over quality. Defer judgment.
- Techniques: brainstorming, How Might We questions, SCAMPER, worst possible idea
- Then converge: vote, cluster, select 2-3 concepts to prototype
**4. Prototype** — Make ideas tangible
- Build quick, cheap, disposable prototypes to learn
- Fidelity should match the question: paper sketches for flow, clickable mocks for interaction, code for technical feasibility
- Goal: test assumptions, not impress stakeholders
**5. Test** — Learn from real users
- Put the prototype in front of real users
- Observe behavior, don't just ask opinions
- What worked? What failed? What surprised you?
- Loop back to Empathize or Define if core assumptions were wrong
## Output Format
```markdown
# Design Thinking Sprint: {Challenge}
## Empathize
- User: {who}
- Key insights from research: ...
- Surprises: ...
## Define
- POV: [User] needs to [need] because [insight]
- How Might We: {3-5 HMW questions}
## Ideate
- Ideas generated: {count}
- Top 3 concepts: ...
## Prototype
- Prototype type: {paper / digital / physical}
- What it tests: {specific assumption}
## Test
- User feedback: ...
- Validated: {what was confirmed}
- Invalidated: {what was wrong}
- Next iteration: {what to change}
```
## Examples
### Correct Application
**Scenario:** Redesigning hospital waiting room experience
- **Empathize**: Observed patients for 3 days. Key insight: anxiety peaks not from wait time but from UNCERTAINTY about wait time.
- **Define**: "Patients need to feel informed about their wait status because uncertainty amplifies anxiety beyond what the actual wait causes."
- **Ideate**: 40+ ideas → top 3: real-time queue display, SMS position updates, estimated-time kiosk
- **Prototype**: Paper prototype of SMS update flow (5 min to build)
- **Test**: 8 patients tested → 6 reported feeling "much less anxious" even though actual wait didn't change ✓
### Incorrect Application
- Skipped Empathize, started with "we need a new app feature" → Solutioning without understanding the problem. Violates Iron Law.
## Gotchas
- **"Fail fast" requires psychological safety**: Teams won't experiment if failure is punished. Establish that prototypes are meant to fail — that's learning.
- **HMW questions set the solution space**: "How might we reduce wait time?" leads to different solutions than "How might we reduce anxiety during waits?" Frame carefully.
- **Prototype ≠ MVP**: A prototype tests a hypothesis cheaply. An MVP is a viable product. Don't over-build prototypes.
- **Design Thinking is not just for designers**: It applies to services, processes, policies, business models — any problem involving human needs.
- **Iteration is not optional**: If you run through all 5 stages once without looping back, you've done waterfall with sticky notes, not Design Thinking.
## References
- For facilitation exercises per stage, see `references/dt-exercises.md`