delight

delight skill 概覽

delight 擅長做什麼

delight skill 可協助你在 UI 中加入恰到好處、讓人會心一笑的細節，而不會把產品做成花俏噱頭。它特別適合設計師、前端開發者，以及使用 AI 協作的產品團隊：當你已經有一個可用的介面，想再透過微互動、帶點趣味的文案、loading 狀態、空狀態、成功回饋與細膩的驚喜，提升整體情緒品質時，delight 就很有用。

delight 用於 UI Design 的最佳適用情境

當你的需求不是「把整個 app 重新設計」，而是「讓這段體驗更有記憶點、更溫暖、更精緻，或更有回報感」時，就很適合用 delight 做 UI Design。它最強的情境，是你已經知道想優化哪個畫面、流程或互動，只需要幫忙判斷哪些地方最適合自然地加入 delight。

delight skill 的差異在哪裡

和泛泛的「讓它更好看一點」這類 prompt 不同，delight skill 的核心在於「放在哪裡」以及「拿捏分寸」。原始指引強調的是：先找出自然適合加入 delight 的時機點，再檢查是否符合品牌與受眾，並確保這些設計是強化任務，而不是妨礙任務。也因此，相較於只提供靈感的泛用提示，它更適合真實產品工作。

導入前最重要的限制

delight 並不是獨立運作的設計大腦。它的說明明確要求先有來自 /frontend-design 的設計脈絡；如果連這個脈絡都還沒有，則必須先跑 /teach-impeccable。若跳過這些前置步驟，輸出會更像猜測，與你的產品語氣和情境也更容易失焦。

如何使用 delight skill

先補齊 context，再呼叫 delight

這個 GitHub skill 位於 pbakaus/impeccable 的 .claude/skills/delight。從目前提供的 repository 片段來看，SKILL.md 並沒有內建 delight install 這類安裝指令，因此比較合理的理解方式是：依照你自己的環境，把它當成 Claude skill 加入或複製到本機的 skills 設定中。實務上，重點不在套件安裝，而在呼叫順序：請先執行 /frontend-design 取得必要脈絡。

先讀這個檔案

請先從這個檔案開始：

• SKILL.md

因為這個 skill 資料夾目前只公開了 SKILL.md，沒有其他搭配的規則、參考文件或 scripts 可以補充邊界行為。這代表輸出品質會高度仰賴你提供的產品 context 是否完整、具體。

想把 delight 用好，先準備這些前置資訊

在使用 delight skill 之前，請先整理：

• 想優化的畫面或流程
• 產品所屬領域
• 品牌個性
• 受眾成熟度
• 這個時刻應該偏 playful、professional、quirky，還是 elegant
• 在 accessibility、performance 與 trust 上有哪些限制
• 這個 delight 應該明顯、低調，還是藏得更深

如果你目前完全沒有設計 context，請依照這個 skill 本身要求的前置路徑，先跑 /teach-impeccable，再跑 /frontend-design。

delight 需要什麼樣的輸入

好的 delight usage 都是從明確目標開始，而不是從模糊願景開始。高品質輸入通常會包含：

• 一個具體的 UI surface，例如：「settings save flow」、「empty project dashboard」、「file upload step」
• 目前的情緒問題，例如：「feels cold」、「waiting feels dead」、「success feels anticlimactic」
• 使用者情境，例如：「B2B finance admins」、「teens on mobile」、「creative pros on desktop」
• 語氣邊界，例如：「confident, not silly」
• 實作限制，例如：「CSS only」、「no sound」、「must support reduced motion」

把模糊目標改寫成可用的 delight prompt

較弱的寫法：

• “Make this app more delightful.”

較強的寫法：

• “Use the delight skill on the onboarding empty state for a project management app. Audience is busy startup teams. Brand tone is optimistic and competent, not quirky. Add 3 subtle delight opportunities in copy, motion, or interaction that improve first-use confidence without slowing setup.”

這樣會更好，因為它同時交代了位置、受眾、語氣上限，以及成功標準。

delight 通常最有價值的介入點

這個 skill 明確把焦點放在一些自然適合加入 delight 的時刻，例如：

• success states
• empty states
• loading states
• achievements
• interaction feedback
• frustrating error moments
• optional Easter eggs

如果你正在評估要不要安裝，這一點很關鍵：delight 最擅長的是強化使用旅程中的特定時刻，而不是替你生成完整 design system。

建議的 delight skill 工作流程

1. 先用 /frontend-design 蒐集產品與品牌脈絡。
2. 選定一個具體的目標體驗。
3. 請 delight 找出候選的 delight moments。
4. 依照領域適配度與使用者預期篩選想法。
5. 只保留能強化清晰度、信任感或回報感的點子。
6. 再把選中的想法轉成 UI copy、motion specs 或實作任務。

這個流程能避免 delight 產出隨機、像 gimmick 的點子。

如何幫 delight 縮小範圍，讓輸出更實用

常見錯誤是要求它處理「整個 app」的 delight。更好的做法是以單一時刻來定義範圍：

• after save
• first empty state
• while waiting for upload
• after streak completion
• on hover for a primary action
• when recovering from an error

這個 skill 的邏輯是以事件為驅動。事件定義得越窄，輸出就越可執行。

提升 delight 輸出品質的實用 prompt 結構

可以用這樣的結構：

• target surface
• user emotion now
• desired emotion after change
• brand tone
• audience
• risk tolerance
• implementation constraints
• examples to avoid

範例：
“Apply the delight skill to the publish success state in a creator tool. Users currently feel uncertain whether publish succeeded. We want relief plus a sense of accomplishment. Tone is polished and creative, not playful. Suggest microcopy, motion, and one optional surprise detail. Avoid confetti and cartoon language.”

這種寫法能讓 delight 更容易輸出可落地、可判斷的建議。

delight 不該做什麼

原始指引很明確：delight 應該是加分，而不是分心。實務上，遇到以下這些想法時應該直接淘汰：

• 拖慢任務完成
• 隱藏關鍵資訊
• 削弱專業可信度
• 讓使用者承受過多動態效果
• 造成 accessibility 問題
• 在嚴肅領域裡顯得不符合品牌

這條界線正是為什麼在這類工作上，delight skill 會比一般創意 prompt 更值得用。

delight skill FAQ

delight 只適合 playful 類型產品嗎？

不是。delight skill 同樣適用於較嚴肅的產品，只是呈現方式不同。在 finance、health 或 enterprise 的情境裡，delight 可能不是外放的俏皮感，而是令人安心的回饋、優雅的轉場、更有人味的空狀態，或平穩而有質感的成功訊息。

delight 對初學者友善嗎？

算友善，前提是你已經知道哪個畫面或流程需要調整。對初學者來說，最大的阻礙通常不是複雜度，而是 context 不足。若你沒有提供受眾、語氣或產品限制，這個 skill 還是會產生一些想法，但可信度會明顯下降，也更難直接採用。

delight 跟一般 prompting 有什麼不同？

一般 prompting 常常會產生停留在表面的修飾點子。delight 則更偏向決策導向：它會先問 delight 應該放在哪裡、是否符合品牌、以及如何避免造成干擾。這通常會導向數量較少，但更容易真正上線的想法。

什麼時候不該用 delight skill？

如果你還在處理核心 UX 結構、IA，或任務流程本身，就先不要用 delight。它是用來打磨與加分的 skill，不是拿來取代可用性問題的解法。如果使用者連任務都無法清楚完成，那還沒到加 delight 的時候。

delight 會幫到實作細節嗎？

會，但屬於間接幫助。這個 skill 以概念優先為主，但你可以要求它把想法表達成 UI copy、motion behavior、interaction notes 或 frontend tasks。若你需要真正的 components 或 code，建議在概念確認後，再把輸出接到你的 frontend workflow 中處理。

如何改進 delight skill 的使用效果

先餵給 delight 更完整的產品脈絡

想最快提升 delight 的結果品質，最有效的方法就是一開始就把情緒框架與品牌框架說清楚。請至少包含：

• 使用者正在做什麼
• 他們現在有什麼感受
• 你希望改成什麼感受
• 品牌能接受多少個性化表現
• 哪些事情絕對不能碰

少了這些資訊，這個 skill 很容易退回到泛泛的 polish 建議。

從單一時刻開始，不要一口氣包整段體驗

如果第一輪範圍開得太大，輸出通常會變得分散。想改善 delight guide 的使用流程，最有效的方式是先鎖定單一時刻，並要求它提出 3–5 個排序過的選項。這樣更容易評估，也能降低為了有趣而過度出招的風險。

先要求節制版選項

一個很實用的迭代模式是：

1. 先要求 subtle ideas
2. 再要求一個更大膽的 variant
3. 拿兩者和品牌適配度比較
4. 保留那個能明顯提升情緒、但改動最小的方案

這種做法特別適合用在專業型產品的 delight for UI Design。

避免 delight 的常見失敗模式

delight 常見的翻車方式包括：

• 動效太多
• 幽默感削弱了信任
• 文案聽起來太幼稚
• 把 polish 加在錯的時刻
• 所謂的「surprise」反而打斷任務完成

要避免這些問題，可以在 prompt 中明確寫出「amplify, never block」，並要求這個 skill 解釋每個點子為什麼有助於完成任務。

第一輪輸出後一定要再迭代

不要停在第一份概念清單。請繼續追問，例如：

• “Which option best fits a conservative enterprise tone?”
• “Reduce motion but keep the emotional payoff.”
• “Make this accessible for reduced-motion users.”
• “Turn the top idea into implementation-ready interaction notes.”

通常到了第二輪，delight usage 才會從「提供靈感」真正走到「可進入產品實作」。