microinteractions
トリガー・ルール・フィードバック・ループ・モードといった細部のインタラクション設計を行い、「普通の製品」を「優れた製品」へと引き上げます。「マイクロインタラクション」「ボタンのフィードバック」「ローディング状態」「トグルデザイン」「アニメーションの細部」「インタラクションの磨き込み」「状態遷移」「入力フィードバック」などに言及された際や、フォームバリデーション・プログレスインジケーター・確認ダイアログなどユーザーが即時フィードバックを期待するUI要素を設計する場面で活用してください。
description の原文を見る
Design the small details -- triggers, rules, feedback, loops and modes -- that separate good products from great ones. Use when the user mentions "microinteraction", "button feedback", "loading state", "toggle design", "animation detail", "interaction polish", "state transitions", or "input feedback". Also trigger when designing form validation responses, progress indicators, confirmation dialogs, or any UI element where the user expects immediate feedback. Covers trigger design, state rules, feedback mechanisms, and progressive loops. For overall UI polish, see refactoring-ui. For affordance design, see design-everyday-things.
SKILL.md 本文
マイクロインタラクション フレームワーク
ユーザーが毎日インタラクションする小さく、完全に独立した製品の瞬間—トグル、パスワードフィールド、ローディングインジケーター、プルトゥリフレッシュ、「いいね」ボタン—を設計するための体系的なアプローチ。Dan Saffer の 4 つの構成要素(トリガー、ルール、フィードバック、ループとモード)に基づく本フレームワークは、目に見えない細部を、忘れられた製品と愛される製品を分ける磨きへと変えます。
コアプリンシプル
許容できる製品と愛される製品の違いは、ほぼ常にマイクロインタラクションにあります。 マイクロインタラクションは、単一のユースケース—設定の変更、データの同期、アラームの設定、パスワードの選択—を中心に構築された、完全に独立した製品の瞬間です。これらは非常に小さいため、ユーザーはそれらについて意識的に考えることはめったにありません—しかし、ユーザーはそれらを感じます。すべてのマイクロインタラクションは同じ 4 つの構成要素に従います。トリガーがそれを開始し、ルールが何が起こるかを決定し、フィードバックが何が起こっているかを示し、ループとモードがその長期的な動作を定義します。
スコアリング
目標: 10/10。 マイクロインタラクションをレビューまたは作成する際に、以下の原則への準拠に基づいて 0~10 で評価します。10/10 は、すべての対話的な瞬間に意図的なトリガー、明確なルール、即座のフィードバック、考え抜かれたループ/モード動作がある状態です。低いスコアは対処すべきギャップを示します。常に現在のスコアと 10/10 に到達するために必要な具体的な改善を提供してください。
マイクロインタラクション構造
世界的に優れたマイクロインタラクションを設計するための 6 つの焦点領域:
1. トリガー
コアコンセプト: トリガーはマイクロインタラクションを開始するものです。マニュアル(ユーザー主導—タップ、クリック、スワイプ、音声コマンド)またはシステム主導(条件が満たされる—時間、位置、受信データ、エラー状態)です。トリガーはすべてのマイクロインタラクションの入り口です。
機能する理由: 明確なトリガーがなければ、ユーザーは対話を発見または開始できません。システムトリガーがなければ、製品は変化する条件に応答できません。よく設計されたトリガーは機能を発見可能にし、次に何が起こるかについて正確な期待を設定します。
主要な洞察:
- マニュアルトリガーは既存の UI コントロール内に存在します: ボタン、スイッチ、アイコン、フォームフィールド、ジェスチャー
- システムトリガーは条件が満たされたときに自動的に発火します: 経過時間、閾値に達する、データを受信する
- トリガーは 3 つのことを伝える必要があります: それが存在すること、それが何をするか、どの状態にあるか
- トリガーのアフォーダンスはアクションの重要性と一致するべきです—高リスクアクションには目立つトリガーが必要です
- 不可視なトリガー(ジェスチャー、シェイク、近接検知)は発見可能性のために表示される代替手段とペアリングされる必要があります
- トリガー状態—デフォルト、ホバー、アクティブ、無効、ローディング—は視覚的に区別できる必要があります
製品への応用:
| コンテキスト | 応用 | 例 |
|---|---|---|
| トグルコントロール | バイナリ状態のマニュアルトリガー | iOS Wi-Fi スイッチ: タップしてトグル、位置が状態を示す |
| プルトゥリフレッシュ | 表示されたアフォーダンスを持つ隠されたジェスチャートリガー | 閾値を超えて下に引っ張ると、リフレッシュアニメーションが開始 |
| システムアラート | 条件が満たされたときのシステムトリガー | 20% で低電力通知 |
| 検索フィールド | 自動提案システムトリガーを持つマニュアルトリガー | 入力がアニメーションを開始し、結果がシステムトリガーとして表示される |
| ホバー表示 | 近接を使用するマニュアルトリガー | カードホバー時にツールバーアクションが表示される |
倫理的な境界: 表示されたフォールバックなしに、重要なトリガーをジェスチャーや不可視な対話の背後に隠さないでください。ユーザーは常に必須機能を発見できる必要があります。
参照: references/trigger-design.md
2. ルール
コアコンセプト: ルールはマイクロインタラクションがトリガーされたら何が起こるかを決定します。これらはイベントのシーケンス、何ができて何ができないかという制約、入力を処理するアルゴリズム、そしてマイクロインタラクションがいつ終了するかを定義します。ルールは不可視のロジック—ユーザーはそれらを直接見ることはありませんが、ルールが間違っているときに感じます。
機能する理由: ルールはユーザーが対話がどのように機能するかについて構築するメンタルモデルを作成します。ルールが一貫していて期待に合致すると、対話は自然に感じられます。ルールが期待に違反するとき—トグルしないトグル、値で跳ぶスライダー—ユーザーは信頼を失います。
主要な洞察:
- マイクロインタラクションの目標をまず定義し、次にそれからルールを導き出す
- ルールは自然に感じられるべき—既存のメンタルモデルとプラットフォーム規約に合致する
- エラーを防ぐために入力を制約する: 文字数を制限する、値の範囲を設定する、形式を強制する
- エッジケースを明示的に処理する: ゼロで、最大値で、繰り返しトリガー時に、中断時に何が起こるか
- シンプルなルールは複雑に感じる対話を生み出し、複雑なルールは混乱を招く対話を生み出す
- 最良のルールは不可視—ユーザーはそれらについて考えず、ただ機能する
製品への応用:
| コンテキスト | 応用 | 例 |
|---|---|---|
| パスワード強度 | リアルタイムで入力を評価するルール | メーターはユーザーが入力するときに更新、赤から緑に色が変わる |
| 文字カウンター | ルールが残りを制約して表示 | Twitter/X: カウンターが減少し、限界に達すると赤くなる |
| ボリュームコントロール | ルールが入力を出力にマップして制約 | スライダーは 5% の増分でスナップ、長押しでミュート |
| ショッピングカート | ルールが数量と状態を管理 | 1 未満にできない、限界で「最大 10」を表示 |
| アクションを取り消す | ルールが反転のための時間ウィンドウを設定 | Gmail の「送信を取り消す」は 30 秒間利用可能 |
倫理的な境界: ルールは透明で予測可能である必要があります。登録解除により多くのステップが必要になるなど、ユーザー動作を操作する隠されたルールを作成しないでください。
参照: references/rules-and-state.md
3. フィードバック
コアコンセプト: フィードバックはマイクロインタラクションのルールをユーザーに通知します。「今、何が起こっているのか?」に答えます。フィードバックは視覚的(色、アニメーション、動き)、聴覚的(クリック、チャイム)、または触覚的(振動)です。重要な制約は、重要なものだけを表示すること—最小限、意味のある、状況に応じた表示です。
機能する理由: フィードバックがなければ、ユーザーはアクションが登録されたか、システムが機能しているか、操作が成功したかを判断できません。フィードバックは評価の湾曲を閉じます。フィードバックが少なすぎると不安を生み出し、多すぎるとノイズを生み出します。適切な時間に適切なフィードバックは、対話をレスポンシブ、信頼できる、そして活力のあるものに感じさせます。
主要な洞察:
- フィードバックは直接操作に対して 100 ミリ秒以下で即座である必要があります
- モーダルダイアログの前に微妙な色の変化など、最も気付きにくいが依然として通信するフィードバックを使用する
- フィードバックはイベントの重要性にマップされるべき: 小さいアクション = 小さいフィードバック、大きい結果 = 大きいフィードバック
- 視覚的フィードバックが主要で、音声と触覚は補足的であり、唯一のチャネルであってはいけません
- 進捗インジケーターは、実際の時間が同じままでも、知覚される待ち時間を削減する
- フィードバックは可能な場合は既存の要素を使用する—別の通知ではなく、ボタンをアニメーション化する
製品への応用:
| コンテキスト | 応用 | 例 |
|---|---|---|
| ボタン押下 | クリック時のビジュアル状態変更 | ボタンが沈む、色がシフト、テキストが「保存中...」に変わる |
| フォーム検証 | ユーザーが入力するときのインラインフィードバック | 有効なメールフィールドの横に緑色のチェックマークが表示される |
| ファイルアップロード | パーセンテージ付きの進捗インジケーター | プログレスバーが埋まり、パーセンテージと推定時間が表示される |
| エラー状態 | ソースの近くの状況に応じたエラー | フィールドに赤い枠線 + メッセージ「パスワードは 8 文字以上である必要があります」 |
| 成功確認 | 簡潔で非ブロッキングの確認 | チェックマークアニメーションが送信ボタンを 1.5 秒間置き換える |
倫理的な境界: フィードバックは正直である必要があります。偽りの進捗バー、操作的なカウントダウンタイマー、または虚偽の完了パーセンテージを使用して虚偽の緊迫感を作成しないでください。
参照: references/feedback-patterns.md
4. ループとモード
コアコンセプト: ループはマイクロインタラクションのメタルール—時間経過とともに何が起こるかを決定します。100 回目の使用後に対話は変わりますか? 有効期限が切れますか? 適応しますか? モードはルール内のフォーク—マイクロインタラクションが異なる動作をする一時的な状態です(例えば、編集モード対表示モード)。
機能する理由: 進化しない製品は古臭く感じられます。予測不可能に動作をシフトする製品は信頼できなく感じられます。考え抜かれたループにより、マイクロインタラクションは優雅に成熟できます—パワーユーザーの摩擦を削減しながら、新規ユーザーにとって発見可能なままにします。モード、控えめに使用する場合、単一のコントロールが複数の目的に役立つようにでき、インターフェースを散らかすことなく。
主要な洞察:
- オープンループは明示的に停止されるまで続行します(繰り返しアラーム)、クローズドループは一度実行されて終了します(タイマー)
- 長いループは時間の経過とともにマイクロインタラクションを変更します: 最初の使用ではツールチップが表示される、50 回目の使用では表示されない
- 漸進的削減: ユーザーが習熟を示すのと同様にスキャフォールディングを削除する
- モードは危険—同じアクションは同じ結果を生み出すべきという原則に違反する
- モードを使用する必要がある場合は、現在のモードを非常に表示される(Caps Lock インジケーター、編集モードバナー)
- モードエラーを避ける: モード数を最小化し、モード遷移を意図的にする
製品への応用:
| コンテキスト | 応用 | 例 |
|---|---|---|
| オンボーディングツールチップ | N 回の使用後、長いループがヒントを削除 | 最初の 3 セッションは「スワイプしてアーカイブ」を表示、その後停止 |
| 目覚まし時計 | 無効にされるまで毎日繰り返すオープンループ | アラームは毎週日曜日午前 7 時に発火し、トグルされるまで続行 |
| テキスト編集 | モード: 表示対編集 | バナーが「編集中」と読み、「完了」ボタンでモードを終了 |
| スマート デフォルト | 長いループが優先を学習 | メールアプリはマネージャーを常に CC することを学び、提案する |
| 通知頻度 | 長いループが配信を適応 | ユーザーが 5 つを連続して無視した場合、通知を削減 |
倫理的な境界: ループはユーザーに利益をもたらすべきで、ビジネスには利益をもたらすべきではありません。適応ループを使用して通知頻度を増やしたり、オプトアウトを段階的に難しくしたりしないでください。
参照: references/loops-modes.md
5. シグネチャー モーメント
コアコンセプト: シグネチャー モーメントは、製品のアイデンティティの一部になるほど独特なマイクロインタラクションです。それは機能的な必要性をブランド定義の詳部へと変えます—Facebook のいいね親指アップ、iPhone のスライドからロック解除、Slack のローディングメッセージ。すべてのマイクロインタラクションがシグネチャー モーメントであるべきではありませんが、すべての製品は 1 つまたは 2 つを持つべきです。
機能する理由: シグネチャー モーメントは感情的な記憶を作成します。これらは製品を組み立てたのではなく職人によって作られたように感じさせます。ユーザーが他の人に製品を説明するとき、シグネチャー モーメントは彼らが最初にデモンストレーションするものです。これらはユーティリティをパーソナリティに変えます。
主要な洞察:
- シグネチャー モーメントは頻繁で表示されたアクションで最もよく機能します—埋められた設定ではなく
- それらは機能的である必要があります最初に、嬉しい第二に—決して使いやすさを新奇性に犠牲にしない
- アニメーション、サウンド、およびコピーはシグネチャー モーメントを作成するための 3 つの最も一般的なツールです
- シグネチャー モーメントはブランド性格に合致するべき: 遊び心のあるブランドは遊び心のあるモーメントを得る
- 抑制は重要—すべてがシグネチャー モーメントであれば、何も重要ではない
- 詳部が削除された場合、ユーザーが逃すかどうかをテストする; そうでない場合、それは装飾であって、シグネチャーではない
製品への応用:
| コンテキスト | 応用 | 例 |
|---|---|---|
| ソーシャル反応 | エンゲージメントへのアニメーション反応 | Facebook いいね: 親指アップはパーティクルでアニメーション化 |
| ローディング状態 | ブランド化された待機体験 | Slack: ローディング中に回転する引用 |
| 完了 | 祝賀的な確認 | Stripe 支払い: 紙吹雪でアニメーション化されたチェックマーク |
| 空状態 | コンテンツなし時のパーソナリティ | Dropbox: イラストシーンとフレンドリーなコピー |
| エラー復帰 | グレースフルな失敗とパーソナリティ | GitHub 404: パララックス Octocat イラスト |
倫理的な境界: シグネチャー モーメントは決して重要な情報を隠したり、アニメーションを表示するためにユーザーを遅延させるべきではありません。機能は常に嬉しさに先行します。
参照: references/signature-moments.md
6. 削減と簡潔化
コアコンセプト: 最良のマイクロインタラクションは、ユーザーがほぼ気づかないもの—非常にシンプルで高速なためです。削減は少なくすること—より少ないオプション、より少ないステップ、より少ない決定を意味します。簡潔化は、残っているものが楽に感じさせることを意味します。目標はすべてのマイクロインタラクションをその絶対的本質に蒸留することです。
機能する理由: すべてのオプション、フィールド、および決定は認知負荷を追加します。ユーザーはトグルスイッチを構成したくありません。彼らはトグルが機能することを望みます。削減は最小レベルで機能追加に対抗します。最も優雅なマイクロインタラクションは、ゼロ構成、1 つのアクション、および即座の結果を持ちます。
主要な洞察:
- マイクロインタラクションに指示が必要な場合、それは複雑すぎます
- スマートデフォルトを選択してオプションを削除する—最良の選択を選んでそれにコミットする
- 複数ステップの対話を単一のアクションに折りたたむ
- 漸進的な開示を使用: シンプルを最初に表示、リクエスト時にのみ複雑性を表示
- 「設定内の設定」を避ける—マイクロインタラクションが独自の優先設定を持つ場合は、再検討する
- ルール数は使用頻度に比例する: 一般的なアクションは少ないルールが必要です
製品への応用:
| コンテキスト | 応用 | 例 |
|---|---|---|
| スマート デフォルト | 構成を排除 | カメラアプリはデフォルトで写真モード、設定ではなく |
| インライン編集 | モーダルを削除、その場で編集 | スプレッドシートセル: クリックして編集、Enter で保存 |
| 自動検出 | システムがユーザーの代わりに処理 | クレジットカード種別は最初の数字から検出 |
| 単一アクション | 1 回のタップが複数ステップフロー置き換える | ダブルタップしていいね、メニューを開く代わりに、反応を選択 |
| 予測的設計 | 予測して事前入力 | 配送フォームは郵便番号から都市と州を事前入力 |
倫理的な境界: 簡潔化は意味のある選択に対するユーザーコントロールを削除するべきではありません。ユーザーの費用で企業に利益をもたらす機能にユーザーを自動的にオプトインさせないでください。
参照: references/trigger-design.md トリガー複雑性の削減について。
一般的な間違い
| 間違い | 失敗する理由 | 修正 |
|---|---|---|
| アクション時のフィードバックなし | ユーザーはタップが登録されたかを知らない | すべてのインタラクティブ要素に即座のビジュアル状態変更を追加 |
| シンプルな瞬間の過度な設計 | 複雑なアニメーションが頻繁なアクションを遅延 | リッチアニメーションは非頻繁で高影響な瞬間に予約 |
| エッジケースの無視 | 対話がゼロで、最大で、またはダブルタップで壊れる | あらゆる状態をマップ: 空、ローディング、部分、完全、エラー、無効 |
| 不可視なトリガー | ユーザーは機能を発見できない | ジェスチャートリガーを表示される代替手段とペアリング |
| モードエラー | 同じアクションが隠された状態に応じて異なる結果を生み出す | 現在のモードを表示; モード数を最小化 |
| 長いループの無視 | 対話は 1 日目と 100 日目で同じに感じられる | 漸進的削減を使用して戻ってくるユーザーに対して簡潔化 |
| フィードバック過負荷 | すべてのアクションがトースト、サウンド、またはアニメーションをトリガー | 通信する最小フィードバックを使用; 大きいイベントに対して大きいフィードバックを予約 |
| 偽りの進捗インジケーター | ユーザーはバーが偽りであることを発見したときに欺かれたと感じる | 正直で確定的な進捗を使用; 不明な場合は不定形スピナーを表示 |
クイック診断
任意のマイクロインタラクションを監査:
| 質問 | 「いいえ」の場合 | アクション |
|---|---|---|
| 明確で発見可能なトリガーがありますか? | ユーザーは対話を開始できない | 表示されたコントロールまたはアフォーダンスを追加 |
| トリガーは現在の状態を示していますか? | ユーザーはそれがオン、オフ、またはローディング中かを判断できない | すべてのトリガー状態に対して異なるビジュアル状態を追加 |
| ルールはシンプルで予測可能ですか? | ユーザーは何が起こったかについて混乱している | ルールを簡潔化; プラットフォーム規約に一致させる |
| 即座のフィードバックがありますか? | ユーザーはアクションが機能したかを疑問に思う | 100 ミリ秒以内のビジュアル反応を追加 |
| フィードバックはイベントの重要性と一致していますか? | 小さいアクションは劇的に感じ、大きいアクションは些細に感じる | フィードバックをイベント重要性に一致させるスケール |
| 対話は時間とともに進化しますか? | パワーユーザーは依然として初心者ヒントを見ている | 長いループを通じて漸進的削減を追加 |
| 対話は不要なモードから自由ですか? | ユーザーは間違ったモードで間違ったアクションを実行 | モードを削除するか、現在のモードを非常に表示可能にする |
| 初回ユーザーはヘルプなしでそれを計算できますか? | 対話は説明が必要 | 簡潔化するか、長いループを通じてワンタイムヒントを追加 |
リファレンスファイル
trigger-design.md: マニュアルおよびシステムトリガー、トリガーアフォーダンス、トリガー状態、不可視なトリガー設計、配置と可視性rules-and-state.md: ルールの定義、状態管理、制約、エラー状態、エッジケースfeedback-patterns.md: 視覚的、聴覚的、触覚的フィードバック、タイミング、漸進的な開示、過負荷防止loops-modes.md: オープンおよびクローズドループ、長いループ、モード、モードエラー、漸進的な複雑性signature-moments.md: ブランド定義のマイクロインタラクション、例、投資時期、平凡な対話を嬉しくさせるcase-studies.md: フォーム送信、トグル/スイッチ、プルトゥリフレッシュ、ローディング状態、および通知の詳細な設計分解
さらに詳しく読む
このスキルは、良い製品と優れた製品を分ける詳部を設計するための Dan Saffer の決定的なガイドに基づいています:
- "Microinteractions: Designing with Details" 著者: Dan Saffer
著者について
Dan Saffer は、Twitter、Jawbone、Smart Design でデザインチームを率いたデザイナー、著者、デザインリーダーです。彼は詳細レベルでのインタラクション設計の仕事で知られています—ユーザー体験の大部分を構成する小さく完全に独立した瞬間。Microinteractions は、世界中の企業のデザインチームが小さな詳部を監査、設計、改善し、製品をポーランド化して活力のあるものにするために使用するフレームワークをコード化しました。Saffer はまた Designing for Interaction および Designing Gestural Interfaces を著述し、インタラクション設計の職人工に関するデザイン会議で定期的にスピーチします。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- wondelai
- リポジトリ
- wondelai/skills
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/wondelai/skills / ライセンス: MIT
関連スキル
nano-banana-2
inference.sh CLIを通じてGoogle Gemini 3.1 Flash Image Preview(Nano Banana 2)で画像を生成します。テキストから画像を生成する機能、画像編集、最大14枚の複数画像入力、Google Searchグラウンディング機能に対応しています。トリガーワード:「nano banana 2」「nanobanana 2」「gemini 3.1 flash image」「gemini 3 1 flash image preview」「google image generation」
octocode-slides
洗練されたマルチファイル形式のHTMLプレゼンテーションを生成します。6段階のフロー(概要 → リサーチ → アウトライン → デザイン → 実装 → レビュー)で構成されています。各スライドは独立したHTMLファイルとなり、iframeで読み込まれます。「スライドを作成してほしい」「プレゼンテーションを作ってほしい」「HTMLスライドを生成してほしい」「デックを構築してほしい」といった依頼や、ノート・ドキュメント・コードを洗練されたプレゼンテーションに変換する際に使用できます。
gpt-image2-ppt
OpenAIのgpt-image-2を使用して、視覚的に優れたPPTスライドを生成します。Spatial Glass、Tech Blue、Editorial Monoなど10種類のキュレーション済みスタイルに対応し、ユーザーが提供したPPTXファイルを模倣するテンプレートクローンモードも搭載しています。HTMLビューアと16:9形式のPPTXファイルを出力します。プレゼンテーション、スライド、ピッチデック、投資家向けPPT、雑誌風PPTの作成依頼などで活用してください。
nano-banana
Nano Banana PRO(Gemini 3 Pro Image)およびNano Banana(Gemini 2.5 Flash Image)を使用したAI画像生成機能です。以下の場合に活用できます:(1)テキストプロンプトからの画像生成、(2)既存画像の編集、(3)インフォグラフィックス、ロゴ、商品写真、ステッカーなどのプロフェッショナルなビジュアルアセット制作、(4)複数画像での人物キャラクターの一貫性保持、(5)正確なテキスト描画を含む画像生成、(6)AI生成ビジュアルが必要なあらゆるタスク。「画像を生成」「画像を作成」「写真を作る」「ロゴをデザイン」「インフォグラフィックスを作成」「AI画像」「nano banana」またはその他の画像生成リクエストをトリガーとして機能します。
oiloil-ui-ux-guide
モダンでクリーンなUI/UXガイダンス・レビュースキルです。新機能や既存システム(Webアプリ)に対して、実行可能なUI/UX改善提案、デザイン原則、デザインレビューチェックリストが必要な場合に活用できます。CRAP(コントラスト・反復・配置・近接)をベースに、タスクファーストなUX、情報設計、フィードバック・システムステータス、一貫性、affordances、エラー防止・復旧、認知負荷を重視します。モダンミニマルスタイル(クリーン・余白・タイポグラフィ主導)を強制し、不要なテキストを削減、アイコンとしての絵文字を禁止し、統一されたアイコンセットから直感的で洗練されたアイコンを推奨します。
axiom-hig-ref
Apple Human Interface Guidelines リファレンス — 色(セマンティックカラー、カスタムカラー、パターン)、背景(マテリアル階層、ダイナミック背景)、タイポグラフィ(標準スタイル、カスタムフォント、Dynamic Type)、SF Symbols(レンダリングモード、色、多言語対応)、ダークモード、アクセシビリティ、プラットフォーム固有の考慮事項を網羅したガイドラインです。