delight

delight skill 概覽

delight 是做什麼的

delight skill 協助代理在 UI 工作中加入有品味的愉悅感、個性與細微打磨，不會把介面做成嘩眾取寵的 gimmick。它真正的任務不是抽象地「讓它更有趣」，而是找出哪些細小的情緒觸點能改善體驗，特別是在成功狀態、空白狀態、載入時刻、onboarding，以及輕量互動中。

誰適合使用 delight

這個 delight skill 很適合做產品 UI、onboarding、dashboard、消費型 app、創作工具，以及重視情緒調性的品牌體驗的人。對於常收到「再精緻一點」、「更有個性一點」或「讓這個更有記憶點」這類需求，但又必須維持可用性與品牌一致性的團隊，尤其有幫助。

最適合用於 UI Design 的情境

如果你想把 delight 用在 UI Design，這個 skill 會比泛泛的「加點動畫」提示更強，因為它重視的是放置位置、是否恰當，以及節制。它會把方向推向能襯托產品的 delight，而不是妨礙任務完成。

最大差異點

這個 skill 最關鍵的差異在於判斷力：它會明確尋找自然適合加入 delight 的時機，並且追問當前產品情境是否適合 playful、elegant、quirky 或 professional 的表現方式。也因此，它比一體適用的視覺潤飾建議更實用。

導入前的重要注意事項

delight skill 並不是完全可獨立使用的。它本身的指示要求先具備設計脈絡，包括先呼叫 /frontend-design；如果目前還沒有任何設計脈絡，則要先執行 /teach-impeccable。如果跳過這些前置設定，輸出品質會明顯下降，因為 delight 高度依賴品牌語氣、目標受眾，以及產品本身的嚴肅程度。

如何使用 delight skill

在 skills 環境中安裝 delight

在典型的 GitHub skills 設定中，可用以下方式安裝：

npx skills add pbakaus/impeccable --skill delight

如果你的環境已經有同步 pbakaus/impeccable repository，請確認 skill 存在於 .agents/skills/delight。

先看這個檔案

請先從這個檔案開始：

• SKILL.md

這個 repository snapshot 針對此 skill 只暴露出一個真正有參考價值的檔案，所以你的大部分理解都會來自那份文件，而不是 helper scripts 或其他參考資料。

呼叫 delight 前，先搞懂必要前置設定

在使用 delight 之前，先把設計脈絡準備好：

1. 呼叫 /frontend-design
2. 依照它的 Context Gathering Protocol 進行
3. 如果目前還沒有設計脈絡，先執行 /teach-impeccable
4. 蒐集領域語氣：例如 playful、professional、quirky、elegant 等

這些不是可有可無的前置流程。delight skill 會對「是否合適」做價值判斷，因此它需要產品與受眾脈絡，才能避免輸出流於表面的「加點閃亮效果」。

了解 delight 需要什麼輸入

當你提供以下資訊時，delight skill 的效果最好：

• 目標畫面、流程或元件
• 產品類型與受眾
• 品牌個性
• 任務的嚴肅程度
• 任何動效、無障礙或效能限制
• 目前的問題，例如「感覺太冷」、「成功狀態太平」

較弱的輸入：

• 「讓這個畫面更有 delight。」

更好的輸入：

• 「Use delight on our invoicing app’s payment success screen. Audience is small-business owners, tone is calm and trustworthy, not playful. We want a brief rewarding moment after payment confirmation without slowing users who need the receipt immediately. Avoid heavy animation.」

delight 通常最有用的落點

依照 skill 指引，適合加入 delight 的機會通常包括：

• 成功狀態
• 空白狀態
• 載入狀態
• 成就與里程碑
• hover、click、drag 互動
• 錯誤復原時刻
• 可選的 Easter eggs

這點很實用，因為它能幫你把注意力放在「讓人覺得這份 delight 是有道理的」時機，而不是把效果灑滿整個介面。

delight 不適合的情境

如果某個介面主要處理的是急迫性、安全性、合規要求，或高密度任務吞吐，就不該先從 delight 下手。例子包括：

• 關鍵醫療或金融操作
• 高壓的營運控制台
• 安全性確認流程
• 速度與清晰度比個性更重要的工作流程

在這些情況下，即使要用 delight，也應該非常節制，並優先考慮平靜、讓人安心的回饋，而不是新奇感。

把模糊目標變成有效的 delight prompt

一個好的 delight 使用 prompt 應該包含五個元素：

1. 目標介面
2. 使用者前後情緒
3. 品牌語氣
4. 限制條件
5. 輸出格式

範例：

Apply the delight skill to our empty dashboard state for first-time users.
Context: B2B analytics product, audience is marketers, tone is smart and optimistic.
Goal: reduce the cold, intimidating feel of an empty workspace.
Constraints: keep copy concise, no cartoon tone, minimal motion, accessible by default.
Output: propose 5 delight opportunities ranked by impact, then rewrite the empty state copy and describe one subtle interaction.

這種結構能提供足夠資訊，讓 skill 做出恰當的 delight 判斷，而不是直接退回到通用的微互動建議。

請它給你排序後的選項，而不是單一點子

在實務上使用 delight 時，建議請代理依下列標準替點子排序：

• 對使用者情緒的影響
• 實作複雜度
• 與品牌的契合度
• 分散注意力的風險

這很重要，因為 delight 本來就帶有主觀性。有排序的選項比較容易審查，也能降低第一個概念太可愛、太昂貴，或太不符合品牌的風險。

先讓基礎 UX 成立，再用 delight

delight skill 在核心流程已經容易理解的前提下最有效。如果你的畫面仍然有 IA、文案或可用性問題，delight 可能只是在掩蓋問題，而不是解決問題。較穩妥的 workflow 是：

1. 先建立基礎 UX
2. 蒐集設計脈絡
3. 執行 delight
4. 針對語氣與無障礙做檢查
5. 先實作最小但高價值的觸點

好的 delight 輸出應該包含什麼

這個 skill 產出的實用 delight 指南，不應只有「加動畫」這種層次。你應該期待輸出明確說明：

• 要強化的確切 UI 時刻
• 為什麼那個時刻值得加入 delight
• 表現強度應該到什麼程度
• 如何保留清晰度與操作速度
• 在該領域中有哪些東西應該避免

如果輸出太散，請要求代理把範圍收斂到單一畫面與單一情緒結果。

先用 delight 做概念發想，再收斂到可上線版本

一個實用的 workflow 是：先讓 delight 產出幾個高層次概念，接著再做一輪更嚴格的 production pass：

• 降低動效
• 縮短文案
• 拿掉裝飾性的額外元素
• 驗證無障礙
• 檢查效能成本

這種兩階段做法，能保留 delight 的創意價值，又不會把不必要的華麗感直接送上線。

delight skill 常見問題

delight 只適合用在 playful 的產品嗎

不是。delight skill 同樣適用於 professional 類產品，只是表現方式不同。在較嚴肅的產品中，delight 往往代表的是舒緩、流暢、溫度感與細緻回饋，而不是幽默或顯眼的動畫。

為什麼 delight 會比一般 prompt 更好

一般 prompt 往往會直接跳到效果層面。delight skill 的結構更完整，重點放在脈絡與機會判斷：哪裡適合放 delight、哪裡不適合，以及對這個受眾與品牌來說，表現強度應該多明顯。

delight 對新手友善嗎

是的，前提是你已經知道想改善的是哪個畫面或流程。新手最常漏掉的是脈絡。如果你沒有提供產品語氣、受眾或限制條件，delight skill 可能會產出聽起來不錯、但很難真正落地的點子。

我需要先用其他 impeccable skills 嗎

通常需要，至少要走完設計脈絡那條路徑。delight skill 明確依賴 /frontend-design，而在尚未建立脈絡時，也可能需要 /teach-impeccable。請把 delight 視為建立在設計理解之上的專門加值層，而不是第一步的設計工具。

delight 能幫忙處理文案、動效和互動嗎

可以。來源指引明確指向像是空白狀態、成功回饋、載入、成就，以及互動等時刻。這表示 delight 不只會影響視覺，也能介入 microcopy、節奏、回應方式，以及小型 UI 行為。

什麼時候不該使用 delight

如果主要問題是導覽不清、層級混亂、產品策略缺失，或 UX 基礎本身有問題，就先不要用 delight。另外，當領域要求中性表達，或 playful 的表現可能損害信任感時，也應避免使用。

如何改進 delight skill 的使用效果

給 delight 更明確的情緒目標

影響效果最大的槓桿，是情緒描述要夠具體。不要只說「讓它更有 delight」，而是直接說希望改變成什麼：

• 從焦慮變成安心
• 從空蕩變成有邀請感
• 從例行公事變成有回報感
• 從等待變成不無聊

這能幫助 delight 更準確地選擇時機與語氣。

一開始就講清楚品牌邊界

當你明確說出哪些東西不能碰時，delight skill 的品質會大幅提升：

• 不要 mascots
• 不要彈跳動畫
• 不要笑話
• 不要 gamification
• 成功後不要額外增加等待時間

這些限制可以避免最常見的失敗模式：表現過度，最後跟產品信任感衝突。

指定嚴肅程度與領域風險

因為 delight 很容易做過頭，所以要明白告訴代理可接受的情緒強度。例如：

• 「fintech, medium trust sensitivity」
• 「admin tool, low need for whimsy」
• 「creative app, high tolerance for playful interaction」

這會讓產出的 delight 指南更貼近真實情境。

請 delight 區分 must-have 與 nice-to-have

常見問題是拿到一串混雜的點子，但每個點子的實作成本差很多。要改善輸出，可以直接要求：

• 1 個高影響、低成本的點子
• 1 個中等成本的 signature moment
• 2 個可選的延伸想法

這樣更方便真實的產品團隊採用。

要求每個點子都說明理由

請代理針對每個 delight 建議都解釋：

• 為什麼這個時刻值得加入 delight
• 它支撐的是哪一種使用者感受
• 為什麼不會干擾任務進行

這能過濾掉純裝飾性的 filler，讓 delight 回到 UX 價值本身。

修正常見失敗模式：delight 太多

如果第一版輸出顯得太吵，可以要求第二輪用更緊的限制重做：

Revise the delight proposals to be 40% more restrained.
Keep only ideas that improve clarity, reward completion, or soften friction.
Remove anything that adds cognitive load, delay, or cartoonish tone.

這通常是把 delight 快速收斂到可上線品質的最快方法。

用單一畫面範圍提升實作品質

不要一開始就讓 delight 試圖改造整個產品。先只選一個介面，例如：

• signup success
• first empty dashboard
• file upload loading state
• saved confirmation
• drag-and-drop feedback

範圍越窄，得到的建議通常越可執行，審查也更簡單。

從概念一路迭代到可出貨細節

在拿到第一版 delight 輸出後，接著追問更具體的問題：

• 「Which idea has the best value-to-effort ratio?」
• 「Rewrite this for an enterprise audience.」
• 「Make the interaction accessible with reduced-motion fallback.」
• 「Remove anything that could slow expert users.」

這正是 delight skill 真正變得有用、而不只是提供靈感的地方。

將 delight 與無障礙、效能審查一起做

適合 UI Design 的好 delight，仍然必須尊重 reduced motion、響應速度，以及快速完成任務的需求。若一個點子看起來很精緻，卻傷害了無障礙或速度，那就不能算成功的 delight。請要求代理一併提供 fallback 行為，並標示任何有風險的動效或時間設定假設。

為團隊建立可重用的 delight brief

如果你預期會反覆使用 delight，建議建立一份簡短、可重用的 brief，內容包括：

• 品牌語氣
• 受眾
• 領域敏感度
• 動效限制
• 文案風格
• 可接受與不可接受的 delight 範例

每次都沿用同一份 brief，能讓 delight skill 的輸出更一致，也能減少反覆修改。