ux-design-for-architects
提供架構師設計與審查非 UI 使用者接觸點（API / 設定 / 擴充功能）之 UX 的指導方針。不包含 UI 畫面設計（如配色、版面配置）。
UX 不僅涵蓋 UI，更包含系統與使用者的所有接觸點。這些接觸點的 UX 若不佳，後續將難以修改（因使用者會產生依賴），進而降低系統整體的成功機率。因此，應優先於實作進行設計。
進行方式
- 識別接觸點: 對象為 API / 設定 / 擴充功能（可為多種）。
- 識別使用者（原則 1）: 誰、為了什麼目的、以何種技術程度使用。
- 閱讀對應接觸點的詳細指南:
- 設定 →
references/configuration.md - API →
references/api.md - 擴充功能 →
references/extensions.md
- 設定 →
- 依據六大原則進行檢查（如下）: 若提出設計方案，請簡述符合原則的依據。
- 若為審查，請依照
references/review-checklist.md的格式提出指正。 - 意見分歧時，向使用者提出假設並請求確認（AskUserQuestion）。
UX 六大原則
| # | 原則 | 要點 | 原因 |
|---|---|---|---|
| 1 | 了解使用者 | 掌握目標、技術程度、心智模型與典型工作流程，使其如預期運作（最小驚奇原則） | 使用者行為常與預期不同，觀察與測量比提問更有效 |
| 2 | 只做必要的事 | 僅提供必要的功能。若有廣泛使用的標準（如 OAuth、OpenID 等）應優先採用 | 已提供的功能將成為負債；一旦推出，使用者會習慣且難以修改 |
| 3 | 讓操作無需手冊 | 使操作方式一目了然，並透過建議或提示引導 | 使用者不閱讀手冊；若無法解決問題，會歸咎於產品 |
| 4 | 從資訊交換角度思考 | 不需詢問 > 減少詢問 > 以容易回答的方式詢問。不要重複詢問相同事項 | 輸入資訊是一種負擔；應透過推測、記憶或推導來減少 |
| 5 | 讓簡單的東西保持簡單 | 消除最初幾個操作步驟的障礙。提供預先設定好的用戶端或範例 | 初學者最容易流失；初次體驗決定留存率 |
| 6 | 先設計 UX 再實作 | 先於架構設計 UX，並透過反饋循環逐步完善 | 實作後修改 UX 成本極高；應延後實作、深入設計 |
資訊詢問時機的判斷（原則 4 的具體化）
依優先順序思考：
- 不詢問: 適當的預設值、從環境自動偵測、記憶過去輸入、從已知資訊推導
- 減少詢問: 僅詢問真正必要的項目
- 以容易回答的方式詢問: 使用使用者不需在腦中計算即可回答的形式，而非內部實作用語（例如：以「快取使用的記憶體上限」取代「最大快取條目數」；甚至透過模式選擇如「伺服器或用戶端」來推導詳細設定）
輸出與回應的場合（原則 4）
若無效能問題，應以使用者可理解的形式提供充足資訊，使其能預測後續動作。若需將某次呼叫的結果傳遞至下一次呼叫，應盡量減少加工後傳遞。
各接觸點摘要
- 設定: 「不安裝」設定最佳，其次為自動決定，最後才是在附帶適當預設值的情況下引入。判斷標準為：「使用者是否比我們擁有更好的脈絡？」——只有在回答「是」時才應設為設定。未知金鑰或應用失敗不應被忽略，應回報錯誤。有效的設定值應能在啟動時等時機確認。
- API: 使用者為開發者。應易於學習、不易誤用，且下一步行動永遠清晰明確。專注做好一件事。避免讓使用者編寫樣板程式碼。遵循標準。一開始就進行版本管理。延後公開直到有必要，並先在內部使用。
- 擴充功能: 在充分了解使用案例之前，應延後新增（可透過後續重構加入）。專注做好一件事。定義輸入輸出，不暴露內部結構。一旦公開便難以修改。
常見錯誤（設計或審查時應注意）
- UX 專業知識不足 / 太晚邀請專家
- 只關注 UI，輕視 API、設定與擴充功能的 UX
- 由技術主管決定 UX，僅讓專家調整 UI 細節
- 忽略專家的建議
- 在兩個方案間猶豫不決，便以設定方式將問題推給使用者
若無專家在場，應明確指出此情況，並建議及早引入 UX 專家。不過，不應因拒絕建議而停止設計，應依本指南提出暫行方案。
與迭代開發流程的連接
- 從使用者旅程推導設計 → 將本指南應用於旅程中的各個接觸點
- 迭代切分 → 僅在最初的切分中建立必要的接觸點（公開 API 或擴充功能通常可在 MVP 之後再導入）
- 難以變更的部分應深入設計、緩慢實作 → UX 為典型代表。透過實際使用觀察來學習
輸出格式
設計提案: 依「對象接觸點 → 使用者形象 → 提案 → 對應原則與理由 → 未決定事項」的順序簡潔呈現。
審查: 採用 references/review-checklist.md 的格式。