規格是什麼？#

要寫好規格文件，首先要區分兩種截然不同的規格類型，並掌握規格文件的關鍵組成元素。

功能規格 vs. 技術規格#

• 功能規格（Functional Spec）：從使用者的角度描述產品的行為——功能、畫面、選單、操作流程。關注的是「產品做什麼」
• 技術規格（Technical Spec）：描述內部實作細節——資料結構、演算法、API 介面。關注的是「產品怎麼做」

本章聚焦於功能規格，因為它是驅動產品設計的核心文件。

規格文件的組成元素#

概述#

以一個虛構的產品 WhatTimeIsIt.com 為範例，說明功能規格應包含的內容。概述讓讀者在幾秒鐘內就能理解這個產品是什麼、要解決什麼問題。

情境與虛構使用者#

使用虛構的使用者角色（如 Mike 和 Cindy）來描述真實的使用情境。這比抽象地列出功能清單更具說服力，也更容易讓讀者理解功能的實際用途。

非目標清單（Nongoals）#

明確列出本版本不打算實作的功能，與目標清單同樣重要。它能防止範圍蔓延（Scope Creep），讓團隊聚焦在真正重要的事情上。

流程圖與畫面描述#

• 使用流程圖呈現使用者在產品中的操作路徑
• 針對每個畫面撰寫詳細的描述，包括每個元素的行為、狀態與邊界條件

畫面描述應該詳細到開發者讀完就能實作，而不需要再回來問問題。描述每個按鈕按下去後會發生什麼、每個輸入欄位的驗證規則、每個錯誤狀態的處理方式。

撰寫規格的指導原則#

• 單一作者：每份規格文件應由一個人負責撰寫，以維持語調與邏輯的一致性
• 加入免責聲明：標明規格可能變更，降低讀者對文件的抗拒感
• 使用情境驅動：以使用者故事帶出功能，而非條列式地描述每個欄位
• 列出非目標：明確說明不做什麼，避免期望落差

開放議題與旁註#

• 開放議題（Open Issues）：尚未定案的設計決策，標示為待討論事項
• 旁註（Side Notes）：補充說明或技術備註，不影響主要閱讀流程

設計應從使用者體驗出發，而非從技術架構出發。先想像使用者會怎麼操作，再決定背後要怎麼實作。這個順序很重要——顛倒過來會產出對使用者不友善的產品。