> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 設計衝刺

> 設計衝刺是一種在 5 天內完成問題聚焦、原型製作與使用者驗證的方法，協助團隊在大規模投入前先用證據做決策。

<Info>
  **類別**: 方法<br />
  **類型**: 快速產品驗證與決策方法<br />
  **來源**: Jake Knapp 在 Google 與 Google Ventures 的實務，約 2010 年形成，2016 年系統化出版<br />
  **別名**: GV 衝刺、五天衝刺
</Info>

<Note>
  **快速回答** — **設計衝刺**（Design Sprint）是一套在一週內把關鍵問題轉成可測試原型，並用真實使用者回饋快速做決策的方法。它由 Jake Knapp 在 Google 與 Google Ventures 情境中發展，並在 2016 年《Sprint》一書中被完整方法化。核心價值是用 5 天取得決策級證據，取代長週期但低驗證度的討論。
</Note>

## 什麼是設計衝刺？

設計衝刺是一種「五天閉環」流程：圍繞一個高風險問題，依序完成問題地圖、方案發散、決策收斂、原型製作與使用者測試。

> 設計衝刺不是加速開會，而是加速取得可行動的決策證據。

它強調先驗證再投入，通常在週五以 5 位目標使用者測試高擬真原型。面對高不確定決策時，可與 `/zh-hant/methods/hypothesis-driven-thinking`、`/zh-hant/methods/scientific-method`、`/zh-hant/methods/pre-mortem-analysis` 搭配使用。

### 設計衝刺的三層理解

* **入門**：當團隊要做高成本決定卻缺乏使用者證據時，先用衝刺做小規模驗證。
* **實踐者**：嚴格執行五天節奏，明確決策者、衝刺問題與招募條件。
* **進階**：把衝刺納入投資組合管理，優先資源配置給證據更強的方向。

## 起源

設計衝刺起源於 Jake Knapp 在 Google 產品工作中的實務探索，約 2010 年開始形成雛形。之後在 Google Ventures 與新創團隊協作中，逐步被打磨成可重用流程。

2016 年，Jake Knapp、John Zeratsky 與 Braden Kowitz 在 *Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days* 中完整公開此方法。GV 對外說明的節奏也一致：週一定方向、週二畫方案、週三做決策、週四搭原型、週五測使用者。

## 核心要點

設計衝刺的成效取決於「問題清晰度、決策紀律、使用者回饋品質」三者同時成立。

<Steps>
  <Step title="聚焦一個最高風險問題">
    把問題寫成可驗證假設，例如「新使用者是否願意在首次使用時授權關鍵權限」。問題越具體，證據越可用。
  </Step>

  <Step title="先發散再收斂">
    分開「想法生成」與「方案決策」階段，可降低過早否決，保留高潛力方案。
  </Step>

  <Step title="只製作用於驗證的原型">
    原型目標是觀察行為，不是達到上線品質。重點是以最小成本獲得可信回饋。
  </Step>

  <Step title="把回饋轉成投入決策">
    衝刺結束需形成「繼續、修正、暫停」的明確結論，讓證據直接影響資源分配。
  </Step>
</Steps>

## 應用場景

當決策時間短、錯誤成本高時，設計衝刺特別有價值。

<CardGroup cols={2}>
  <Card title="新功能方向驗證">
    在投入研發前先確認使用者是否願意採用，降低錯配風險。
  </Card>

  <Card title="關鍵互動改版">
    對高影響流程先做原型測試，避免只憑團隊偏好推進大改。
  </Card>

  <Card title="服務流程創新">
    先模擬服務觸點與體驗路徑，再決定是否做組織級調整。
  </Card>

  <Card title="跨部門共識建立">
    讓產品、設計、研發與業務在同一週內基於同一份證據對齊。
  </Card>
</CardGroup>

## 經典案例

Blue Bottle Coffee 與 Google Ventures 的合作常被引用為設計衝刺案例。公開內容指出，衝刺前 Blue Bottle 的線上銷售占比約為 **10%**，團隊希望改善網站對購買決策的支撐能力。

團隊依標準流程完成 **5 天衝刺**，並在週五對高擬真原型進行 **5 位目標使用者** 測試。可衡量成果不只是「討論更多」，而是用一週取得可行動證據，為後續網站改版提供更清楚的轉化優化方向。

## 邊界與失效場景

若把設計衝刺當成形式化工作坊，它很容易失效。沒有明確決策者、問題定義過寬、使用者樣本不匹配，都會導致結論不可用。

兩個邊界條件要留意：第一，設計衝刺擅長處理「方案不確定」問題，不適合已明確的執行排程問題；第二，5 次訪談屬方向性證據，不代表市場規模結論。常見誤用是把衝刺結果視為上線充分條件。

## 常見誤區

多數誤區來自把衝刺當成「快速做完產品」而非「快速驗證決策」。

<AccordionGroup>
  <Accordion title="設計衝刺只適合新創公司">
    大型組織同樣適用，尤其在跨團隊協作成本高時更具價值。
  </Accordion>

  <Accordion title="做一次衝刺就完成需求探索">
    衝刺是一次高密度驗證循環，不能取代持續性的使用者研究。
  </Accordion>

  <Accordion title="5 位使用者就能得出統計結論">
    衝刺測試主要用於早期發現重大可用性與價值風險，屬質性訊號。
  </Accordion>
</AccordionGroup>

## 相關概念

把設計衝刺與以下方法搭配，可形成「假設提出、證據驗證、實施落地」的連續鏈路。

<CardGroup cols={3}>
  <Card title="假設驅動思維" href="/zh-hant/methods/hypothesis-driven-thinking">
    把衝刺目標轉為可驗證假設與判定標準。
  </Card>

  <Card title="科學方法" href="/zh-hant/methods/scientific-method">
    讓原型測試具備實驗邏輯與可重複性。
  </Card>

  <Card title="最小可行產品" href="/zh-hant/methods/mvp">
    將衝刺學習結果轉化為最小上線範圍。
  </Card>

  <Card title="預先驗屍分析" href="/zh-hant/methods/pre-mortem-analysis">
    在擴大投入前先辨識高機率失敗路徑。
  </Card>
</CardGroup>

## 一句話總結

<Tip>
  設計衝刺的本質，是用一週把「意見衝突」轉成「使用者證據驅動的投入決策」。
</Tip>