principle-experience-first | 先決定值得交付的體驗

本頁以 pstack-claude 0.9.126 為基準。原文標示 user-invocable: false，通常由 poteto-mode 按需讀取。以下透過自然語言套用原則，不是獨立命令的用法。

定位與適用情境

使用者體驗（User Experience，UX）與實作便利衝突時，應優先選擇對使用者有價值的結果。每個功能、控制項與選項都必須能說明存在理由。少量完整功能，比堆滿未打磨功能更符合這個原則。

例如團隊要推出匯入設定介面。直接暴露所有解析器選項最容易實作，卻讓第一次使用的人不知道如何完成工作。真正的核心循環是選檔、預覽、理解錯誤，再確認匯入，而不是展示底層所有能力。

這裡的使用者不只終端使用者。程式庫的匯入者、內部介面的呼叫者與下一位維護工程師，也應被納入同等權衡。

準備

描述一個具體使用者與任務，例如第一次把既有設定匯入工具。
列出目前擬加的控制項、選項及其服務的實際需求。
準備合法、格式錯誤、空白等模擬輸入，避免只做成功畫面。
確認可使用的拋棄式原型環境，以及不能改動的正式服務邊界。

操作步驟

把目標寫成使用者能完成的事。 先要求使用者能辨認檔案、預覽結果、修正輸入並確認匯入，不以「提供完整解析器設定」當成體驗目標。
逐項審查範圍。 每個選項都回答它解決哪個核心任務問題。不能說明用途的功能先移出本次範圍。必要但次要的能力，也不能遮蔽主要操作。
先以低成本原型走完流程。 在可拋棄的 HTML 或其他既有原型環境呈現選檔、預覽、確認與取消。正式實作前先調整互動決策，不讓既有程式碼成本綁住選擇。
補齊使用過程的細節。 檢查對齊、間距、轉場、處理中回饋、錯誤狀態與修正入口。格式錯誤時，使用者應知道發生什麼事，以及接下來能做什麼。
同時審視消費與維護成本。 請另一位讀者依任務試走，並檢查介面是否迫使維護者加入難懂的特例。說明留下哪些功能、延後哪些功能，以及對兩種使用者的影響。

可直接使用的提示詞

套用 principle-experience-first。
我們正在設計匯入設定介面，現有草案直接暴露全部解析器選項。
先以第一次匯入的使用者為對象，定義選檔、預覽、修正錯誤與確認的核心流程。
逐一說明控制項的理由，移出不能服務本次核心任務的功能。
先在核准目錄做拋棄式原型，涵蓋合法、錯誤與空白輸入，不接正式服務。
檢查回饋、對齊、間距、轉場與錯誤恢復，再推薦最小可交付範圍。
回報終端使用者與下一位維護者各自會感受到什麼改變。
沒有實際觀察的體驗判斷請標成待驗證，不宣稱使用者一定喜歡。

預期結果與驗收

預期得到一個能走完核心流程的原型、一份功能取捨紀錄，以及具體的錯誤與回復設計。範圍應由任務需要決定，而不是由最容易接上的底層選項決定。

驗收時，讀者應能從錯誤輸入找到修正方向，再回到匯入流程，而非只能關閉重來。維護者則應看得懂每個保留功能的理由，知道哪些需求刻意未納入。

常見誤用是把「體驗優先」理解成只美化成功畫面，或只追求第一眼好看而增加維護負擔。刪減功能也不是目的，刪到無法完成核心任務並不符合原則。

限制與權限

原則決定的是目標，不是宣稱基礎工作可以省略。基礎設計仍應服務目標，實作順序則是另一個問題。原型觀察也不能取代正式系統的可靠性與安全驗證。

教學不授權更動產品承諾或直接對外發布。涉及既有使用者的功能移除、不可逆資料操作與部署，仍須依專案規則確認。沒有使用者研究時，應區分觀察、推論與尚未驗證的偏好。

延伸閱讀與來源

匯入介面是本頁教學情境，不是上游產品功能或已完成的使用者測試。