更新：@今天的日期（MM/DD/YY）
問題脈絡
用一句可執行且簡潔的問題陳述段落，描述該議題背後的核心問題與動機，清楚說明此功能旨在解決的核心問題，或建構此功能所釋放的機會。 此功能的市場宣導語是什麼？我們為何現在要建構它？我們憑什麼能靠此功能取勝？ 此問題陳述必須足夠詳細且可執行，無需額外背景資訊就能獨立傳達所有關鍵要點，但限制在最多3句簡潔句子。 以最相關的客戶角色開頭（例如：「企業主需要……」），但切勿在概述段落中使用確切的個人或公司名稱。
解決方案設計
在確定方向前，先探索解決方案空間。 考慮多種候選方案，並根據策略和體驗的鏡頭進行評估。
識別哪些策略槓桿對此解決方案最重要，並深入探討：
- 優先考慮能透過規模經濟最大化成本優勢的功能，隨著用戶採用或營運量增加，降低單位成本。
- 選擇能放大網路效應的功能，隨著參與者數量增加，提升用戶價值。
- 偏好能創造反定位機會的功能，引入競爭對手無法輕易複製，否則會嚴重干擾其自身策略的能力或體驗。
- 強調能提高客戶轉換成本的功能，讓用戶更難或不願離開生態系統。
- 專注於能強化品牌的功能，鞏固其獨特身份，並與用戶建立持久的情感連結。
- 利用能佔據封閉資源的功能，例如專有資料、獨家合作夥伴關係或競爭對手無法輕易取得或模仿的獨特能力。
- 實施能展現優越流程或專有工作流程的功能，創造可持續的營運優勢，超越競爭對手。
在設計簡單且令人愉悅的用戶體驗時，請嘗試在設計用戶流程時運用以下原則：
-
持續簡化——移除不必要的步驟或功能，提供直覺、極簡的體驗。每個元素都必須證明其存在的價值。
-
維持無縫連貫——以最少的認知負荷引導用戶從頭到尾，無死胡同。
-
注重細節——字體排版、轉場、間距和文案都應反映精心的工藝。在每個接觸點上，平衡功能與美感，保持統一且一致的品牌感受。
-
用體貼的巧思帶來驚喜——添加微小但令人難忘的細節，提升體驗超越純功能性。
-
如果不確定如何設計 SaaS 元件，請模仿 Linear 的設計或元件運作方式。
在討論解決方案時，不要明確提及這些原則，只需在探索、決定並解釋最佳解決方案時，將其融入你的論證中。
在探索解決方案空間並確立最佳策略後，簡潔地說明此功能的作用、如何解決用戶的痛點，以及如何讓用戶感到愉悅——寫得緊湊，避免不必要的開場白。
- 非常具體地詳細說明用戶與產品互動和體驗的理想方式。聚焦於介面設計、用戶旅程的每一步，以及如何改善解決方案的整體可用性和簡潔性。
- 呈現我們預期推出此功能後會發生的真實使用敘事。
- 將此錨定在真實用戶的真實時刻。例如：「當 Frank 在舊金山拜訪不同新創公司時，他使用[功能 X]記錄抱怨，並在[功能 Y]中追蹤需求，隨著他了解這些資訊……」
- 強調我們可以採用的獨特策略，或使此解決方案與市場上替代方案不同的方面，並將我們的產品與競爭對手進行反定位。
請記住：最佳解決方案能最大化 ICE：影響力（Impact）、信心（Confidence）和努力（Effort）。影響力越高、信心越高、努力越低——解決方案越好。
將解決方案的說明分成聚焦且簡潔的段落，段落之間用換行分隔——每個段落涵蓋體驗的一個方面。
驗收標準
每個標準必須描述一個特定的、可測試的條件，並包含明確的預期結果。標準描述預期的結果，而非實作選擇。標準應符合 MECE 原則——互斥且 collectively exhaustive——涵蓋完成工作所需的所有條件。
功能性：
- [可觀察的用戶行為 → 預期的系統回應或結果]
邊界案例與錯誤處理：
- [當輸入無效、服務失敗、資料遺失或用戶遇到非預期狀態時，會發生什麼]
不包含在內：
- [此工作明確不包含的內容——設定明確界限以防止過度建構]
<強驗收標準範例>
- 當用戶在搜尋列中輸入時，結果會在 300 毫秒的去抖動後即時更新，以排名列表顯示產品名稱、圖片和價格。
- 用戶可以導航至「設定」>「編輯個人資料」，並更新名字、姓氏、電子郵件和電話號碼。變更會立即儲存，並在應用程式中反映，無需重新整理。
- 如果儲存請求失敗（逾時或 5xx），則顯示行內錯誤：「發生錯誤，請重試。」表單會保留用戶未儲存的輸入。
- 提交空的搜尋查詢會返回預設結果列表，而非錯誤或空狀態。
- 這不包括批次個人資料編輯、CSV 匯出或管理員級別的權限變更。 </強驗收標準範例>