interaction-design

interaction-design スキルの概要

interaction-design スキルでできること

interaction-design スキルは、UI のモーション、マイクロインタラクション、画面遷移、フィードバック状態を設計・実装する際に役立ちます。インターフェースをより分かりやすく、反応が伝わるものにしたいときに向いています。単に「アニメーションを付ける」のではなく、「動きによって状態・意図・変化を伝える」ことが目的の場面で特に有効です。

どんな人にこのスキルが向いているか

この interaction-design skill は、UI デザイナー、フロントエンドエンジニア、そして完成度の高いプロダクト UI を作るプロダクトチームに適しています。たとえば、ボタン、ローディング状態、モーダル、トースト、スクロール時の表示演出、ドラッグ＆ドロップ、ホバー状態、ページ遷移などです。作りたい機能自体は決まっているものの、タイミング、easing、インタラクションの組み立てをより整理したい場合に特に使いやすいです。

実際に解決したいジョブ

多くのユーザーが interaction-design を導入するのは、実務上の明確な課題があるからです。汎用的なプロンプトだと、派手ではあっても根拠の薄いアニメーションが出がちです。このスキルは、フィードバック、現在位置の把握、注意の誘導、状態変化の連続性といった目的に沿ったモーションへとエージェントを導きます。そのため、「楽しいアニメーションを追加して」といった曖昧な依頼より、実運用の UI Design にずっと向いています。

一般的な UI プロンプトとの違い

最大の価値は、制約が入ることです。このスキルはモデル任せの即興にせず、タイミングの目安、easing パターン、実装に落とし込みやすい具体的な参照情報を与えます。さらに、アニメーションライブラリ、マイクロインタラクションのパターン、スクロールアニメーションに関する参照ファイルが例ベースで用意されているため、実装時の手探りを大きく減らせます。

インストール前に確認したいこと

実装にそのままつなげやすいガイダンスや、使えるパターン例が欲しいなら、このスキルを入れる価値があります。一方で、より広いビジュアルデザイン戦略、デザインシステムのガバナンス、包括的なアクセシビリティ監査が目的なら適していません。このリポジトリは、インタラクションの振る舞いとフロントエンド実装パターン、特に React 寄りの例に強みがあります。

interaction-design スキルの使い方

interaction-design のインストールとセットアップの前提

上流の SKILL.md には CLI のインストールコマンドは記載されていないため、wshobson/agents リポジトリに対する通常の skills 導入フローを使い、その後 plugins/ui-design/skills/interaction-design から interaction-design を有効化してください。初回利用前に、最低でも次を読んでおくのがおすすめです。

• SKILL.md
• references/animation-libraries.md
• references/microinteraction-patterns.md
• references/scroll-animations.md

補助ファイルを 1 つだけ拾い読みするなら、一般的なプロダクト UI の仕事に最も近い references/microinteraction-patterns.md から入るのが効率的です。

interaction-design を呼び出すべきタイミング

interaction-design は、次のような場面で使うと効果的です。

• loading、success、error、disabled の状態を追加するとき
• dropdown、modal、tabs、drawer の挙動をより分かりやすくしたいとき
• hover、focus、press、gesture のフィードバックを磨きたいとき
• ページ遷移やコンポーネント遷移を実装するとき
• スクロール連動の reveal や progress indicator を追加するとき
• CSS transitions と JS アニメーションライブラリのどちらを使うか判断したいとき

逆に、静的なワイヤーフレームや、純粋に見た目のブランド表現を探る用途では、そこまで相性は良くありません。

このスキルに必要な入力情報

interaction-design usage の品質は、入力の具体性に大きく左右されます。少なくとも次は渡してください。

• コンポーネント名またはフロー名
• インタラクションを開始するユーザー操作
• 変化前と変化後の状態
• プラットフォームまたはフレームワーク
• モーション、パフォーマンス、アクセシビリティ上の制約
• コンセプトだけ欲しいのか、コードだけ欲しいのか、両方欲しいのか

弱い入力の例:

• “Add nice animations to this dashboard.”

より強い入力の例:

• “Use the interaction-design skill to improve a React settings panel. I need hover, pressed, saving, success, and error states for a save button; a 250ms drawer transition; and motion that feels calm, not playful. Prefer CSS or Framer Motion. Respect reduced motion.”

曖昧な要望を強いプロンプトに変える方法

良い interaction-design guide のプロンプトは、だいたい次の 4 要素で構成されます。

1. UI surface: どのコンポーネントや画面が変化するのか
2. Intent: そのモーションで何を伝えたいのか
3. Constraints: タイミング、技術スタック、アクセシビリティ、パフォーマンス
4. Output shape: パターンの理由、コード、エッジケースまで欲しいのか

例:

• “Apply the interaction-design skill for UI Design on a checkout form. Design loading and validation feedback for submit, inline field errors, and a success transition after payment. Use React and Tailwind. Include durations, easing choices, reduced-motion handling, and sample implementation.”

実プロジェクトでのおすすめワークフロー

実務では、次の流れが扱いやすいです。

1. ユーザー操作と状態変化を定義する
2. まずは振る舞いの理由をスキルに聞く
3. その後で自分のスタック向けの実装を依頼する
4. 出力を参照ファイルと照らし合わせる
5. フィードバックや位置把握の改善に寄与しないモーションは削る
6. reduced motion と低速デバイスでテストする

最初からフルコードを求めるより、この順番のほうがうまくいきます。interaction-design の一番大きな価値は、書き始める前に適切なモーションの仕組みを選べることにあるからです。

インストール判断に役立つリポジトリの読み順

導入するかを見極めたいなら、次の順番で読むと時間を無駄にしません。

1. 原則とタイミングの指針を確認するための SKILL.md
2. よくある UI 状態を見るための references/microinteraction-patterns.md
3. ライブラリ選定が必要なら references/animation-libraries.md
4. ビューポート連動のケースなら references/scroll-animations.md

この順で読むと、このスキルの本当の強みが見えてきます。理論だけでなく、パターンに裏打ちされた実装に強い点です。

ライブラリ選定と実装の方向性

参照内容は React パターンにかなり寄っており、Framer Motion の例や、IntersectionObserver のようなブラウザネイティブな方法も含まれています。つまり、この interaction-design skill は次のどちらを求める場合にも相性が良いです。

• 軽量な CSS やブラウザネイティブのインタラクション
• React における、より表現力の高い宣言的アニメーション

React 以外の環境でも原則自体は十分流用できますが、一部のコード例は自分のスタック向けに読み替える必要があります。

実用的な timing と easing の目安

このスキルの中でも特に使い勝手が良いのが、タイミング設計のモデルです。

• hover や click フィードバックには 100-150ms
• 小さなコンポーネント遷移には 200-300ms
• modal や大きめの状態変化には 300-500ms
• 500ms+ は、より演出的な連続動作に限る

これはあくまで出発点であって、盲目的に守る固定ルールではありません。出力の質を最短で上げるには、それぞれの duration が何のためか――フィードバック、位置把握、注目、連続性――をエージェントに説明させるのが効果的です。

interaction-design が得意な典型パターン

この interaction-design usage が特に強いのは、次のようなケースです。

• loading button と非同期フィードバック
• tab 遷移や shared layout transitions
• hover や tap の affordance
• skeleton と progress indicator
• scroll reveal セクション
• notification と toast のモーション
• drag-and-drop の視覚フィードバック

こうした箇所は、通常のプロンプトだと状態変化の指定が甘くなりやすく、壊れやすい UI 挙動になりがちです。

明示しておきたい制約条件

安定した出力を得たいなら、次の条件は明言してください。

• prefers-reduced-motion をサポートする
• layout shift を避ける
• アニメーションは割り込み可能にする
• 必要な場合を除いて、遷移中にユーザー入力をブロックしない
• コストの高いレイアウト変更より、GPU に乗りやすい transform を優先する
• calm、crisp、playful、enterprise-neutral など、求めるインタラクションのトーンを指定する

こうした制約がないと、単体では見栄えがしても、プロダクト文脈ではしっくりこないモーションに寄ることがあります。

interaction-design スキル FAQ

普通のプロンプトより interaction-design を使う価値はある？

あります。特に、実装品質とモーションの目的を重視するなら有用です。普通のプロンプトだと装飾的なアニメーションに寄ることがあります。interaction-design skill は、状態に応じた振る舞い、タイミングの指針、実例に裏打ちされたパターンが必要で、そのまま実装につなげたい場面でより役立ちます。

この interaction-design スキルは初心者向き？

中程度です。原則そのものは追いやすい一方で、例の多くはフロントエンド実装に慣れている前提、特に React やアニメーションライブラリの利用を前提にしています。それでも初心者が使えないわけではなく、CSS transitions、状態図、実装手順のようなシンプルな出力を求めれば十分活用できます。

interaction-design は React 専用？

いいえ。ただし、参照ファイルでは React が最も手厚く、特に Framer Motion と組み合わせた説明が明快です。Vue、Svelte、素の JavaScript を使っている場合は、タイミング、easing、状態ロジックを保ったまま、自分のスタック向けにパターンを翻訳するよう依頼するとよいです。

interaction-design を使わないほうがいいのはどんなとき？

より大きな課題が情報設計、ビジュアルブランディング、プロダクト戦略にあるなら、interaction-design は適切ではありません。また、使いやすさのためのフィードバックより、映像的な演出やシネマティックな表現が重要なアニメーション中心のマーケティング用途にも向いていません。

interaction-design は UI Design systems の用途でも使える？

はい。特に、motion tokens、タイミングのレンジ、hover/press の振る舞い、loading 状態、コンポーネント間での遷移ルールを標準化したい場面で有効です。フルの design token 設計全体よりも、インタラクションのルール整備に強みがあります。

アクセシビリティは自動で担保される？

完全ではありません。このスキルはより良いモーション判断を支援しますが、reduced motion の挙動、focus の視認性、キーボード操作時の扱い、重要な状態変化に対する非モーションのフィードバックについては、引き続き明示的に依頼する必要があります。

interaction-design スキルを改善する方法

状態ごとに入力を分けて渡す

interaction-design の出力を改善する最も確実な方法は、コンポーネント名だけでなく、各状態を明示することです。たとえば:

• idle
• hover
• pressed
• loading
• success
• error
• disabled

こうしておくと、エージェントは孤立した演出を作るのではなく、実際の状態変化をつなぐ遷移として設計しやすくなります。

いきなりコードではなく、先に理由を聞く

よくある失敗は、最初から実装に飛びつくことです。まずは次を聞いてください。

• 何を動かすべきか
• なぜそれを動かすのか
• どれくらいの時間をかけるべきか
• どんなユーザーの混乱を防ぐのか

その後でコードを求めると、モーションがすっきりし、過剰なアニメーションも減ります。

モーション予算を指定する

次のどれを求めているかを明言してください。

• 最小限のユーティリティモーション
• 適度に磨かれたプロダクト表現
• 表現力の高いブランド寄りモーション

この 1 行で結果の質はかなり変わります。指定がないと、モデルが必要以上に盛ってしまい、プロダクトに不要なアニメーション密度になることがあります。

reduced motion とフォールバック挙動を依頼する

実運用レベルの結果が欲しいなら、次を出すようスキルに依頼してください。

• prefers-reduced-motion への対応
• アニメーションなし、またはより動きの少ないバリアント
• モーションだけに頼らない、キーボード操作時や画面状態のフィードバック

これは、そこそこ良い回答を実際に出荷できる回答へ引き上げる、最も簡単な方法のひとつです。

スクリーンショットだけでなくコード文脈も渡す

すでにコンポーネントがあるなら、関連する JSX、CSS、状態ロジックを貼ってください。interaction-design skill は、実際の event handler、state 名、DOM 構造にモーションを対応づけられると、一気に実用性が上がります。

よくある失敗パターンを見抜く

最初の出力に次の傾向があれば注意が必要です。

• 伝達目的がないのに、すべての要素にアニメーションが付いている
• 関連コンポーネント間で timing が揃っていない
• 遅延を説明する代わりに、遷移でごまかしている
• hover 効果が touch に置き換わっていない
• scroll animations の発火頻度が高すぎる、または可読性を損ねる

こうした兆候があるなら、プロンプト側の制約をもっと強くするべきです。

interaction-design は 1 つのインタラクション群ずつ検証する

一度にすべてのモーションを作り直さないでください。まずは buttons や modal transitions のように、1 系統ずつ始めてから広げるのがおすすめです。そのほうが、interaction-design skill が本当に分かりやすさを改善しているのか、それとも単に動きを増やしているだけなのかを判断しやすくなります。

実装の深さは参照ファイルで裏取りする

回答が抽象的すぎると感じたら、エージェントをリポジトリの補助ファイルへ明示的に誘導してください。

• references/microinteraction-patterns.md で一般的なコンポーネント状態を確認する
• references/animation-libraries.md で API レベルの例を見る
• references/scroll-animations.md でビューポート起点の挙動を確認する

これだけで、概念寄りの回答から実装に近い回答へ引き上げられることが多いです。

推奨案だけでなくトレードオフも聞く

価値の高いプロンプトの例:

• “Use interaction-design and compare CSS transitions vs Framer Motion for this component, including bundle cost, complexity, and maintainability.”

こうすると、単にコードを生成するだけでなく、導入判断に必要な比較までモデルにさせることができます。

具体的なレビュー基準で output 品質を上げる

プロンプトの最後に、次のようなレビュー基準を添えてください。

• “Keep motion purposeful, short, and consistent.”
• “Avoid layout shift.”
• “Respect reduced motion.”
• “Prefer patterns that are easy to maintain.”
• “Explain how the interaction improves feedback or orientation.”

こうした基準があると、interaction-design guide の出力が、チームが実際にレビューし、承認し、出荷するための観点に揃いやすくなります。