interaction-design

インタラクションデザイン

プロダクトデザイナー、UX デザイナー、UI デザイナー、サービスデザイナー、インタラクションデザイナーのための、インタラクションデザイン実践ガイドです。このスキルでは、基礎原則から実用的な状態設計、フロー仕様、インタラクションレビューまで、IxD 業務の全領域を扱います。

このスキルでできること

• インタラクションの設計と仕様策定：フロー、状態、遷移、アフォーダンス
• 確立された原則に基づくインタラクション品質の評価
• インタラクション仕様書と引き継ぎ用注釈の作成
• マイクロインタラクションの設計（トリガー、ルール、フィードバック、ループ）
• フィードバックシステムの設計：タイミング、種類、階層
• 応答時間の基準と体感パフォーマンス
• デザイン分野ごとの役割に応じた IxD の責務
• よくあるインタラクションのアンチパターンとその修正方法

Claude に必要なことを伝えてください。例：

• 「複数ステップのチェックアウトのインタラクションフローを設計するのを手伝ってください」
• 「このボタンにはどのような状態が必要ですか？」
• 「このインタラクションをレビューしてください。フィードバックは適切なタイミングで表示されますか？」
• 「このドラッグ＆ドロップ機能のインタラクション仕様書を作成したいです」
• 「このモーダルに適切なアニメーション時間はどれくらいですか？」
• 「このダッシュボードの空の状態はどのように扱えばよいですか？」

---

インタラクションデザインの5つの次元

インタラクションデザインは、5つの要素を軸に展開されます。すべてのインタラクションは、これらの次元のいくつかを組み合わせて構成されます。

次元	内容	デザイン上の問い
言葉	ラベル、手順、マイクロコピー、エラーメッセージ、ボタンのテキスト	言葉は明確で、行動を促すものですか？正確な期待値を伝えていますか？
視覚的表現	アイコン、画像、タイポグラフィ、色、データビジュアライゼーション	視覚表現は、インタラクションのアフォーダンスを明確に伝えていますか？
物理的なもの／空間	デバイスの種類、画面サイズ、入力方式（タッチ／マウス／音声／キーボード）、物理的環境	適切な入力方式と利用状況に合わせてインタラクションが設計されていますか？
時間	遷移の長さ、アニメーションのタイミング、応答の遅延、シーケンス	タイミングは応答性が高く、意図的に感じられますか？状態の変化を伝えていますか？
振る舞い	ユーザーの操作に対するシステムの応答 — プロダクトが何をし、どのように反応するか	システムの振る舞いは、ユーザーのメンタルモデルと明示された意図に合っていますか？

インタラクションを設計するときは、どの次元が関係するかを特定してください。インタラクションの失敗の多くは、次元間の不一致が原因です。たとえば、システムの振る舞いが視覚的なアフォーダンスと矛盾している場合や、マイクロコピーが実際の動作と一致していない場合です。

---

基本原則

Norman の 6 つの基本原則

Norman の 6 つの基本原則は、インタラクションの品質に最も広く適用できるフレームワークです。

可視性 システムの状態と利用可能な操作を見えるようにします。ユーザーが、システムで何が起きているのか、次に何ができるのかを推測する必要がないようにします。

• 現在の状態が見える（選択中、読み込み中、アクティブ、エラー）
• 操作可能な要素が見える（インタラクティブな要素は、操作できるように見える）
• 製品内のナビゲーションと現在位置が見える

❌ 読み込み状態が表示されず、何も反応しないまま送信されるフォーム ✅ クリックするとすぐにスピナーへ切り替わる送信ボタン

フィードバック すべての操作に対して、即座に知覚できる反応を返します。ユーザーの入力を受け取ったことと、それに対して何をしたかをシステムが伝える必要があります。

• 即時の応答（処理が完了する前、100ms 以内）
• 結果を明確に伝える（成功、失敗、処理中）
• 操作の重要度に応じたフィードバック

❌ 確認、アニメーション、応答のいずれもない削除操作 ✅ すぐに取り消し用のトーストを表示してから、項目をフェードアウトさせる削除操作

制約 その状況で有効な操作だけを利用可能にします。エラーから復旧するよりも、エラーを防ぐようにします。

• 無効な操作は、実行後にエラーを表示するのではなく、無効化する
• プログレッシブディスクロージャーを使って、関連するコントロールだけを表示する
• 有効な入力形式のみを受け付けるフォームフィールド

❌ 日付を自由入力できるようにして、送信時に「無効な日付」と表示する ✅ 有効な日付だけを選択できるように制限する日付ピッカー

マッピング コントロールとその効果の関係を直感的にします。コントロールは、その影響を与える対象と空間的または概念的に結び付いている必要があります。

• 上にスクロール → コンテンツが上に移動する（自然な対応）
• 音量スライダーは左から右に動かすと音量が上がる
• 「次へ」ボタンは右側、「戻る」ボタンは左側に配置する

❌ コントラストのアイコンに見えるアイコンだけで示された明るさコントロール ✅ 「明るさ」とラベルが付いており、「光を強くする」方向に動かすと明るくなるスライダー

一貫性 似た操作は、製品全体で同じように機能する必要があります。ユーザーはパターンからメンタルモデルを構築するため、それを崩すとエラーや混乱が生じます。

• 内部的な一貫性：同じコンポーネントはどこでも同じように動作する
• 外部との一貫性：ユーザーがすでに知っているプラットフォームの慣習に沿う
• ブレークポイントやプラットフォームをまたいだ一貫性

❌ スワイプによる閉じる操作が、あるリストでは機能するのに別のリストでは機能しない ✅ すべての破壊的な操作に同じ確認パターンを使う

アフォーダンス UI 要素は、その動作に合った見た目にします。コンポーネントの外観から、操作方法が伝わるようにします。

• ボタンは押せるように見える
• ドラッグ可能な要素には目に見えるドラッグハンドルを付けるか、ホバー時にカーソルを変える
• タップ可能な項目には十分なサイズと視覚的な存在感を持たせる

❌ 静的な本文と同じ見た目の、実際にはリンクであるテキスト ✅ リンクに下線を付けるか、インタラクティブではないテキストには決して使わない独自の色を使う

---

Tognazzini の 19 原則

19 の原則は、人間とコンピューターのインタラクションに関する、より広範なシステムを扱います。 これらは実践者のための応用原則です。

先回り ユーザーが探す前に、情報やツールを提示します。ユーザーの次のステップを見越して設計します。

• 関連する操作を状況に応じて提示する
• 既知のデータを事前入力する（アカウントに登録された配送先住所など）
• ワークフロー内で破壊的な操作を実行する前に警告する

自律性 ユーザーは自分でコントロールできていると感じる必要があります。システムは、ユーザーが理解し、必要に応じて変更できる制約の範囲内で動作する必要があります。

• デフォルトをカスタマイズできるようにする
• 明示的な確認なしに、取り消せない操作を決して実行しない
• システムの状態を透明に示し、何が起きているかをユーザーが把握できるようにする

一貫性 製品内、プラットフォーム全体、業界の慣習全体、ユーザーの期待との間という、4 つのレベルで一貫性を保ちます。迷ったときは、ユーザーの期待との一貫性を最も重視します。 デフォルト デフォルトは、ほとんどのユーザーがほとんどの状況で選ぶ最適な選択肢を示すべきです。簡単に変更でき、明確にラベル付けされ、意味のあるものにしてください。技術的に最も安全な選択肢というだけではいけません。

• よくあるケースでは、スマートなデフォルトによって手間を減らします
• デフォルトの選択肢は明確に示します
• デフォルトのラベルでは専門用語を避けます

見つけやすさ ユーザーが機能を見つけられなければ、そのユーザーにとっては存在しないも同然です。事前知識がなくても、操作項目を見つけて利用できるようにします。

• ナビゲーションでは、説明がなくても主要な経路が分かるようにします
• 機能はマニュアルではなく、使いながら見つけられるようにします
• 高度な機能は段階的に開示し、隠さないようにします

ユーザーの効率 システムではなく、ユーザーの時間を最適化します。よくあるタスクはすばやく実行できるようにします。熟練ユーザー向けにはショートカットを用意します。最もよく使われる経路を最短にします。

• 頻繁に使う操作にはキーボードショートカットを用意します
• 繰り返しの操作には一括操作を用意します
• 主要な操作はワンクリックで実行できるようにします（よくあるタスクで複数段階の確認を求めないようにします）

探索できるインターフェース ユーザーが不安なく操作を試せるようにします。取り消し可能な操作があれば、試行錯誤できます。

• 破壊的な操作はすべて取り消せるようにします
• 確定前にプレビューを表示します（画像の切り抜き、ドキュメントの形式など）
• パンくずリストと分かりやすい戻るナビゲーションを用意します

フィッツの法則 ターゲットを選択する時間 ＝ f（距離、サイズ）。ターゲットを大きくし、距離を短くすることで、操作時間と誤操作を減らせます。

• タッチターゲット：最小 44×44px（iOS/Android）、48×48px（Material）
• マウスターゲット：最小 32×32px
• 主要な CTA は、そのエリアで最も大きな操作要素にします
• 関連する操作は近くに配置します
• 画面の端や角を活用します。一方向には無限に大きなターゲットとして機能します

遅延の軽減 入力から 100ms 以内に応答します。処理にそれ以上かかる場合は、操作をすぐに受け付けたことを示し、進行状況を表示します。

• 0～100ms：視覚的な状態変化以外のフィードバックは不要です
• 100ms～1s：読み込みインジケーター（スピナーまたはスケルトン）を表示します
• 1s～10s：完了予定時間を含む進行状況インジケーターを表示します
• 10s 以上：バックグラウンドで処理できるようにし、完了時に通知します

習得しやすさ インターフェースは、初めて使うときだけでなく、使い続けるうちに習得できるようにします。熟練者は初心者よりもすばやく操作できるべきです。

• ユーザーの習熟に合わせて、複雑な機能を段階的に表示します
• 分かりにくい機能には、ツールチップやインラインのガイダンスを用意します
• 初回の利用だけに最適化しないでください

メタファー システムの機能を正確に伝えるメタファーを使います。制約になったり、誤解を招いたりする場合は使わないようにします。

• 「ゴミ箱」アイコンは、削除と復元を連想させます
• 「フォルダー」は、整理と階層化を連想させます
• 実際には存在しない制約があるかのように示すメタファーは避けます

ユーザーの作業を保護する インターフェースのエラーや予期しないユーザーの操作によって、データを失わせてはいけません。自動保存を継続的に行い、取り消しを可能にし、上書き前には確認します。

• 下書きを自動保存します
• 保存していない状態でページを移動しようとしたときは警告します
• 入力内容の検証に失敗しても、フォームを消去しないでください

読みやすさ テキストは、理想的な条件下だけでなく、あらゆるユーザーが読みやすいようにします。

• Web の本文テキストは 16px 以上にします
• コントラスト比は最低 4.5:1 にします（WCAG AA）
• 文章の行の長さは 50～75 文字にします
• 50 歳以上のユーザーや、明るい場所で使うユーザーを対象にテストします

シンプルさ シンプルであることは、最小限であることと同じではありません。シンプルさとは、ユーザーに必要な機能を維持しながら、不要な複雑さを取り除くことです。

• 機能を削除するのではなく、段階的に開示します
• 必要な操作項目を隠す、見せかけのシンプルさを避けます
• 画面上のすべての要素に、存在するだけの価値を持たせます

状態 ユーザーがどこにいて、何をしたかを追跡します。セッションをまたいで状態を復元します。

• スクロール位置、フォームの進行状況、開いているパネルを記憶します
• 現在位置を明確に示します（パンくずリスト、選択中のナビゲーション項目など）
• 新しいコンテンツと、すでに閲覧したコンテンツを区別します

ナビゲーションの可視性 ユーザーが現在位置、移動先、戻り方をいつでも把握できるようにします。

• ナビゲーションで現在の位置を強調表示します
• 深い階層ではパンくずリストを表示します
• 戻るボタンの動作は、ブラウザーとネイティブアプリのどちらでも期待どおりにします
• 明確な終了方法がないまま、ユーザーをフローに閉じ込めないでください

美しさ ビジュアルデザインは、使いやすさの印象に影響します。洗練されたインターフェースは、より信頼されます。

• 美的な品質は単なる装飾ではありません。配慮と品質を示すものです
• 美的なトレンドによって使いやすさを損なわないでください
• ビジュアルの変更がタスクのパフォーマンスに与える影響をテストしてください

色 色は意味を伝えます。色だけに頼れないユーザーを想定してデザインしてください。

• 意味（エラー、成功、必須など）を示す唯一の手段として色を使わないでください
• 形状、パターン、ラベルを使って色覚障害のあるユーザーをサポートしてください
• 赤はエラーにのみ使用してください。中立的な操作には赤を使わないでください

ヒューマンインターフェースオブジェクト インタラクティブなオブジェクトは、どこに表示されても一貫して動作する必要があります。ボタンはボタンです。リンクはリンクです。

• コンポーネントの動作は、見た目から予測できるようにしてください
• 画面ごとにインタラクションを独自に考案するのではなく、確立されたパターンを再利用してください

---

NNGroupのインタラクティビティ属性

NNGroupは、ユーザーが製品をどう認識するか、ひいてはその背後にあるブランドをどう認識するかを形作る、8つのインタラクション品質を特定しています。

属性	定義	デザインへの示唆
応答性	入力に対する要素の反応速度	すべての操作に対し、100ms以内に応答を示す必要があります
直接操作性	ユーザーが対象そのものを操作するか、仲介要素を介して操作するか	ドラッグ＆ドロップとメニュー、直接編集とフォームダイアログ
精度	ユーザーによる制御の細かさ	細かく調整できるスライダーと、大まかな段階で調整するスライダー
変更の容易さ	変更を加える容易さ	何かを変更するには、どの程度の労力が必要ですか？
連続的か段階的か	滑らかな遷移か段階的な遷移か	音量スライダーと音量ボタン
明確なラベル／フィードバック	システムが利用可能な操作とその結果をどの程度うまく伝えるか	ツールチップ、ラベル、ARIA、補助テキスト
期待される動作	ユーザーのメンタルモデルとの一致度	見た目どおりの動作をしますか？
一貫性	確立されたパターンへの準拠	同じコンポーネントなら、常に同じ動作をします

---

応答時間とフィードバックの設計

3つの応答しきい値

しきい値	時間	ユーザーの認識	デザイン上の対応
瞬時	≤ 0.1s	直接操作しているように感じられ、遅延を認識しません	視覚的な状態変化のみ（ボタンのアクティブ状態）
フローを維持	0.1s – 1.0s	遅延に気づきますが、集中を保ちます	スピナーまたはスケルトンスクリーン
注意の限界	1s – 10s	注意がそれます。意識して集中を保つ必要があります	推定時間を表示する進行状況インジケーター
離脱のリスク	> 10s	特にウェブではユーザーが離脱します	バックグラウンド処理し、完了時に通知します

フィードバックの種類

視覚的フィードバック — 基本となるフィードバックです。すべてのインタラクションで視覚的な状態変化を示す必要があります。

モーションフィードバック — 変化が起きていることと、その方向を伝えます。

• ページ遷移でナビゲーションの方向を伝えます（左にスライド＝前進）
• 高さのアニメーションで展開／折りたたみを伝えます
• フェードで表示／非表示を伝えます

触覚フィードバック — ネイティブのモバイルアプリ向けです。控えめに使用し、意味のある確認に限って使います。

• 成功：1回タップ
• 警告：2回タップ
• エラー：振動パターン

音声フィードバック — 状況に応じて使用します。日常的な操作では避けてください

知覚されるパフォーマンスのパターン

スケルトンスクリーン — コンテンツの読み込み中にレイアウト構造を表示します。ページ全体のコンテンツでは、スピナーよりも適しています。体感待ち時間を短縮し、レイアウトシフトを防げるためです。

楽観的 UI — サーバーの確認を待たずに、操作の結果を UI に即座に反映します。失敗した場合は元に戻します。確実性の高い操作（いいね、フォロー、賛成票など）に最適です。

進捗インジケーター — ユーザーが待つことになる、1 秒を超える操作に使用します。進捗を確定できる場合はパーセンテージを表示し、確定できない場合はアニメーション付きのインジケーターを使用します。

即時遷移 — ページ全体の遷移を、150ms より速くしたり、400ms より遅くしたりするのは避けます。最適な速度は200～300msです。

→ 実装パターンの詳細については、reference/response-time.mdを参照してください。

---

インタラクションの設計

コンポーネントの状態

すべてのインタラクティブなコンポーネントには、完全な状態のセットが必要です。状態が不足すると、表示のリグレッション、アクセシビリティ上の問題、一貫性のない動作が発生します。

状態	適用される場面	デザイン要件
デフォルト	初期状態、未操作の状態	インタラクティブであることが明確にわかる
ホバー	要素上にカーソル／ポインターがある（デスクトップ）	控えめに表示を変化させる。大きなレイアウトシフトは避ける
フォーカス	キーボードまたはプログラムによるフォーカス	視認できる必要があります（WCAG 2.4.7）。代替手段なしにアウトラインを削除しない
アクティブ／押下	要素がクリック／タップされている	入力を受け付けたことが伝わるよう、押し下げるか強調表示する
読み込み中	操作の進行中	追加の入力を無効にし、進捗を表示する
無効	操作を現在実行できない	不透明度を下げるかスタイルを変更する。ホバー状態は設けない。cursor: not-allowed
エラー	検証失敗またはシステムエラー	赤色＋アイコン＋テキストを使用する。色だけで伝えない
成功	操作が正常に完了した	成功を明確に伝える。通常の操作では一時的に表示する
空	表示するコンテンツがない	画面を空白にしない。状況説明と次の操作を提示する
スケルトン	初回のコンテンツ読み込み中	表示予定のコンテンツのレイアウトに合わせる

状態設計のチェックリスト：

• インタラクティブなコンポーネントについて、10種類すべての状態を定義している
• フォーカス状態が視認でき、WCAG 2.4.7 を満たしている
• エラー状態では色＋アイコン＋テキストを使用している（色だけに頼っていない）
• 無効状態が視覚的に区別でき、色だけに頼っていない
• 空の状態から先に進める手段を提示している

インタラクションフロー

フローとは、ユーザーが目標を達成するために製品内を進む経路です。優れたフローには、明確な開始点、正常に進む経路、エッジケースに対応する分岐、エラーからの復旧手段があります。

フローの構成：

Entry point → [Trigger] → Interaction sequence → [Decision] → Outcome
                                                      ↓
                                                  Error path → Recovery → Resume

フロー設計に関する質問：

• このフローに入るユーザーの目標は何ですか？
• 各ステップでユーザーに必要な情報は何ですか？
• 判断が必要な箇所はどこですか？各分岐では何が起こりますか？
• 何が問題になり得ますか？復旧するにはどうすればよいですか？
• 終了地点はどこですか？明確で一貫していますか？

複数ステップのフローの原則：

• 進捗を表示する（ステップインジケーター、パンくずリスト、パーセンテージ）
• データを失わずに前のステップへ戻れるようにする
• 進捗を自動保存し、ユーザーが後から再開できるようにする
• エラーは送信時ではなく、発生したステップ内に表示する
• 破棄を伴う終了時には確認する（「本当に終了しますか？進捗が失われます。」）

トランジションとアニメーション

IxDにおけるアニメーションの目的はただ一つ、コミュニケーションです。状態の変化、空間的な関係、システムからのフィードバックを伝えます。装飾目的のアニメーションは避けてください。

アニメーションを使う場合：

• 要素の表示／非表示（フェード、拡大・縮小）
• ビュー間のナビゲーション（スライド、プッシュ）
• コンテンツの展開／折りたたみ（高さのトランジション）
• 読み込み中および進捗状況の状態
• 確認およびエラーの状態

アニメーションを使わない場合：

• ホバー状態（わずかな色の変化で十分です）
• ツールチップの表示（瞬時で問題ありません）
• テキストの変更
• ユーザーが結果を待つことになるあらゆるトランジション

時間の目安：

インタラクションの種類	時間	イージング
マイクロインタラクション（ボタンの状態、トグル）	100–150ms	ease-out
小さなコンポーネントのトランジション（ドロップダウン、ツールチップ）	150–200ms	ease-out
中程度のコンポーネントのトランジション（モーダル、パネル）	200–300ms	ease-in-out
ページ全体のトランジション	250–400ms	ease-in-out
読み込みアニメーション	1～2秒でループ	linear

イージング：

• ease-out — 速く始まり、ゆっくり終わります。画面に入ってくる要素に使用します。
• ease-in — ゆっくり始まり、速く終わります。画面から出ていく要素に使用します。
• ease-in-out — トランジション全体を通して滑らかに変化します。位置の変更に使用します。
• linear — 一定の速度です。読み込みスピナーやプログレスバーに使用します。

アフォーダンスとシグニファイア

アフォーダンス — 要素が実際に備えている機能です（ボタンは押すことができます）。

知覚されるアフォーダンス — 要素が何をできるように見えるかです。重要なのはこちらです。

シグニファイア — 操作方法を伝える手がかりです（ドラッグ用のハンドル、下線、テキストフィールドのプレースホルダー）。

実際のアフォーダンスだけでなく、知覚されるアフォーダンスを考慮して設計してください：

• 影も背景も境界線もないフラットなボタンは、知覚されるアフォーダンスが乏しいです
• テキスト入力欄は、編集可能であることを示すために境界線、背景とのコントラスト、または下線が必要です
• ドラッグ可能な要素には、ドラッグできることを示す視覚的なハンドル、またはカーソルの変化が必要です

アンチアフォーダンス — 何かができないことを示す手がかりです（無効なボタン、グレー表示されたテキストフィールド）。これはアフォーダンスと同じくらい重要です。誤った操作を未然に防ぎます。

メンタルモデル

メンタルモデルとは、システムの仕組みに関するユーザーの内的な認識です。優れたインタラクションデザインは、システムの動作をユーザーがすでに持っているメンタルモデルに合わせます。

メンタルモデルに合わせる場合：

• ナビゲーションのパターン（戻るボタン、ハンバーガーメニューの位置）
• フォームの動作（タブ順序、検証のタイミング）
• 破壊的な操作（続行してから確認するのではなく、確認してから続行する）
• データの永続化（自動保存と明示的な保存）

メンタルモデルが食い違う場合： 新しいインタラクションパターンが既存のメンタルモデルを崩す場合は、次の対応が必要です：

1. 変更が起きる前に、明確に伝える
2. 既存のモデルから逸脱する箇所でオンボーディングを提供する
3. その逸脱がコストに見合うかどうかを検討する

❌ 警告なしにスワイプジェスチャーの意味を変える ✅ 初回使用時にツールチップを表示する：「左にスワイプしてアーカイブ（以前は削除）」

---

マイクロインタラクション

マイクロインタラクションとは、単一のユースケースを処理する、小さく独立したインタラクションです。 インターフェースを形作る要素であり、目玉となる機能ではありませんが、製品に洗練された意図的な印象を与えます。

マイクロインタラクションのフレームワーク：

Trigger → Rules → Feedback → Loops & Modes

トリガー

マイクロインタラクションを開始するのは何でしょうか？ユーザーが開始するトリガーは明示的です（ボタンのクリック、 スワイプなど）。システムが開始するトリガーは自動的です（通知の受信、ダウンロードの完了など）。

ルール

トリガーが作動すると何が起こるでしょうか？ルールによって動作を定義します：

• どの状態が変化しますか？
• イベントはどのような順序で発生しますか？
• どのような制約がありますか？（取り消せますか？最小値／最大値はありますか？）

フィードバック

ルールが実行されていることをユーザーにどう知らせるでしょうか？

• 視覚：状態の変化、アニメーション、色の変化
• テキスト：ラベルの変更、確認メッセージ、エラーメッセージ
• 音：通知音、エラー音（控えめに使用してください）
• 触覚：確認のタップ（ネイティブモバイルのみ）

ループとモード

マイクロインタラクションは繰り返されますか？ 履歴に応じて動作が変わりますか？

• パスワード強度メーターは、ユーザーの入力中にループします
• トグルは2つのモードを切り替えます
• プルして更新する操作は、完了時点が明確なループです

マイクロインタラクションの一般的な例

ボタンの状態： トリガー：クリック → ルール：フォームを送信 → フィードバック：ボタンのテキストが「保存中…」に変わり、スピナーが表示される → ループ：「保存済み」または「エラー」に変化

インラインフォーム検証： トリガー：フォーカスアウト（フィールドから離れる） → ルール：形式を検証 → フィードバック：インラインで緑色のチェックマークまたは赤色のエラーメッセージを表示 → ループ：変更時に再検証

トグル： トリガー：タップ → ルール：ブール値を反転 → フィードバック：つまみがスライドし、色が変わり、ラベルが更新される → モード：オン／オフ

プルして更新： トリガー：しきい値を超えるまで引っ張る → ルール：新しいデータを取得 → フィードバック：スピナーと「更新中…」を表示し、その後コンテンツを更新 → ループ：完了後に再び利用可能

いいね／リアクション： トリガー：タップ → ルール：「いいね」の状態を切り替える → フィードバック：アイコンが色付きで塗りつぶされ、カウントが増える（楽観的 UI） → モード：「いいね」済み／未「いいね」

---

役割別の適用

プロダクトデザイナー

IxD の業務は、フロー、状態、フィードバック、トランジションなど、プロダクト全体に及びます。

• 探索段階：ハッピーパスだけでなく、タスク全体をマッピングするためにフローを使います。分岐やエラー状態を早い段階で特定します。
• 仕様作成時：見た目だけでなく、動作も明記します。「必須フィールドがすべて有効になるまでボタンは無効です」は、灰色のボタンを示すだけのビジュアルよりも有用です。
• 引き継ぎ時：コンポーネントの状態を10種類すべて記録します。トランジションの時間とイージングを注記します。分かりにくいアニメーションには、モーションの参考資料（Figma プロトタイプまたは動画）を含めます。
• デザイン批評時：インタラクションに関する判断をユーザーの目標に結び付けます。「これは…というメンタルモデルと一致しています」は、「しっくりきます」よりも説得力のある意見です。

UX デザイナー

IxD の重点は、タスクフロー、情報アーキテクチャ、エラーからの回復です。

• 画面のデザインに着手する前に、すべてのフローをマッピングします。行き止まり、つまりユーザーが到達できても、スムーズに抜け出せない状態を特定します。
• エラーからの回復を、後回しにせず主要なデザインタスクとして扱います。すべてのエラー状態で、何が起きたか、なぜ起きたか、次に何をすべきかを伝える必要があります。
• マイクロコピーは後からではなく、インタラクションデザインの一部として作成します。ラベル、プレースホルダー、エラーメッセージ、補助テキストは、いずれもインタラクションの一部です。
• ビジュアルデザインに進む前に、タスクベースのテストでフローを検証します。

UI デザイナー

IxD の重点は、コンポーネントの状態、モーションデザイン、インタラクションの忠実度です。

• すべてのインタラクティブコンポーネントについて、デフォルトとホバーだけでなく、状態を10種類すべて用意します。
• 個別のアニメーションを場当たり的に作るのではなく、モーションシステムを使います。時間のトークン（速い：150ms、中：250ms、遅い：400ms）を定義し、一貫して適用します。
• 引き継ぎ前にインタラクションをプロトタイプ化します。エンジニアが実装するのは、推測した内容ではなく、理解した内容です。
• 実装されたプロダクトを仕様と照らし合わせてレビューします。デザイナーが関与しないと、実装時にインタラクションの品質は低下します。

サービスデザイナー

IxD の業務は画面の範囲を超え、複数チャネルのタッチポイントやスタッフ向けシステムにも及びます。

• インタラクションは、ウェブ、アプリ、キオスク、IVR、対面など、あらゆるタッチポイントで発生します。個々の画面をデザインする前に、サービスブループリントですべてをマッピングします。
• スタッフ向けのインタラクションには、顧客向けとは異なる要件があります。発見よりも効率、エラーへの寛容さ、状況認識が重視されます（スタッフは忙しく、フローの途中で中断されることもあります）。
• チャネル間の移行もインタラクションです。「確認メールをお送りします」は、インタラクションの仕様です。
• 顧客と現場スタッフの両方を対象にテストします。スタッフ向けの体験で起きる失敗は、顧客向けの失敗につながります。

インタラクションデザイナー

専任の IxD 担当者として、行動レイヤー全体を担当します。

• モーションシステムを担当し、一貫して実装されるようにします。
• プロダクト全体のインタラクションを監査し、一貫性の欠如や不足している状態を特定します。
• エンジニアリングチームが追加の質問をせずに実装できる行動仕様を作成します。
• アクセシビリティの専門家と連携し、インタラクションパターンがキーボードとスクリーンリーダーで利用できるようにします。

---

インタラクションレビューチェックリスト

引き継ぎやリリースの前にデザインをレビューする際は、このチェックリストを使用してください。

フロー

• 想定どおりに進む場合のフローが明確で曖昧さがない
• すべての判断分岐がデザインされている（想定される分岐だけではない）
• エラーフローから復旧でき、行き止まりにならない
• 複数ステップのフローでは進捗が示され、前のステップに戻れる
• 破壊的な操作で終了する前に警告が表示される

状態

• 各インタラクティブコンポーネントの10種類の状態がすべてデザインされている
• フォーカス状態が視認でき、WCAGに準拠している
• エラー状態が色＋アイコン＋テキストを使用している
• 空の状態にコンテキストと次のアクションが示されている
• 読み込み状態で入力の重複を防いでいる

フィードバック

• すべてのアクションに即時の視覚的な応答がある（100ms以内）
• 成功状態と失敗状態が明確に区別されている
• フィードバックがアクションの重要度に見合っている
• 時間のかかる処理で進捗が表示される

アフォーダンス

• インタラクティブ要素がインタラクティブに見える（知覚されるアフォーダンス）
• 非インタラクティブ要素がインタラクティブに見えない
• ドラッグ可能な要素に視覚的なハンドルまたはカーソルの表示がある
• 無効な要素が視覚的に区別できる

モーション

• すべてのアニメーションに伝達上の目的がある
• 再生時間とイージングがモーションシステムに従っている
• アニメーションによってユーザーの進行が遅れない
• prefers-reduced-motion が尊重されている

マイクロコピー

• ボタンのラベルが行動を示す動詞になっている
• エラーメッセージで、何が起きたのか、なぜ起きたのか、次に何をすべきかが説明されている
• プレースホルダーテキストが補足として使われ、ラベルの代わりになっていない
• 確認ダイアログで、削除または変更されるものが明示されている

アクセシビリティ

• すべてのインタラクションをキーボードで操作できる
• フォーカス順序が視覚的な読み取り順序に沿っている
• 時間制限のあるインタラクションを延長または一時停止できる
• テキスト以外のインタラクティブ要素に ARIA ラベルが設定されている

---

よくあるアンチパターン

見えないアフォーダンス

❌ クリック可能なテキストが、クリックできないテキストと同じ見た目になっている ❌ ドラッグ可能な項目に視覚的な手がかりがない ❌ ボタンが単なる平文のように見える ✅ インタラクティブな要素に対して、明確で一貫した視覚表現を確立してください。インタラクティブな要素はインタラクティブに見える。非インタラクティブな要素は静的に見える。

状態の欠落

❌ デフォルトのデザインしかないコンポーネント（エラー、空、読み込み、フォーカスの各状態がない） ❌ 想定どおりに進む場合のフローだけを示した引き継ぎ ✅ コンポーネントを引き継ぐ前に、10種類の状態をすべてデザインしてください。

フィードバックが遅すぎる

❌ 5つのフィールドに入力した後、送信時にしか検証されないフォーム ❌ 即時のフィードバックがない破壊的な操作 ✅ フォーカスが外れた時にインラインで検証してください。すべてのアクションに100ms以内に応答してください。

操作を遅らせるアニメーション

❌ 操作を始める前に待たなければならない、600msのモーダル表示アニメーション ❌ すべてのナビゲーションで実行され、操作のたびに時間がかかるアニメーション付きの画面遷移 ✅ 表示アニメーションは200～300msに抑えてください。ユーザーを待たせるためのアニメーションは使用しないでください。

エラーからの復旧手段がない

❌ 「問題が発生しました」としか表示されず、アクションも再試行手段もないエラーメッセージ ❌ 検証に失敗すると、すべてのフィールドがクリアされるフォーム ✅ すべてのエラー状態で、何が起きたのか＋なぜ起きたのか＋次に何をすべきかを伝えてください。ユーザーの入力内容は保持してください。

警告なしにメンタルモデルに反する

❌ ユーザーがプラットフォームから期待するものとは異なる動作をするスワイプジェスチャー ❌ 前の画面に戻らず、状態をリセットする「戻る」ボタン ✅ プラットフォームの慣習に合わせてください。慣習から外れる必要がある場合は、そのことを明確に示してください。

説明のない無効状態

❌ 無効になっている理由を説明するツールチップやコンテキストがなく、グレーアウトしたボタン ✅ 有効になる条件を伝える無効状態にします。「日付を選択すると利用できます。」

一貫性の欠如

❌ 同じコンポーネントが画面によって異なる動作をする ❌ モーダルの確定ボタンが、画面によって左側にあったり右側にあったりする ✅ インタラクションパターンはシステム全体で決めるものであり、画面ごとに決めるものではありません。文書化し、徹底してください。

---

出力形式

このスキルが有効な場合、Claude は必要な内容に合わせて出力を調整します。

インタラクション仕様

コンポーネントまたはフローの完全な動作仕様：

• トリガー条件
• 状態遷移
• フィードバックの説明（視覚、動き、文言）
• エッジケースとエラー処理
• アクセシビリティに関する注意事項

状態テーブル

コンポーネントのすべての状態をまとめた構造化テーブル：

• 状態名
• 視覚的な説明
• トリガー条件
• 遷移の動作

フロー図（テキスト）

フローを構造化テキストで表現：

• 開始点
• 状態の順序
• 判断分岐
• エラーパスと復旧方法
• 終了点

インタラクションの評価

原則に照らした既存のインタラクションの評価：

• 違反している原則
• ユーザーにとって重要な理由
• 具体的で実行可能な修正案

モーション概要

アニメーション仕様：

• アニメーションする要素とプロパティ
• 継続時間とイージング
• トリガーと終了条件
• 動きを抑えた代替案

形式に関する規則

• 複数パートの出力では構造化された見出しを使用
• 状態セットと比較マトリックスにはテーブルを使用
• アンチパターンと推奨事項には ❌/✅ を使用
• タイミング値と CSS プロパティはコード形式で記述
• 判断だけでなく、その理由を説明する注釈を付記

---

参考ファイル

• reference/principles.md — Tognazzini の 19 原則と Norman の 6 原則の全容、適用例、違反パターン
• reference/response-time.md — Nielsen の 3 つの応答時間しきい値と、各読み込み／フィードバックのシナリオにおける実装パターン
• reference/patterns-and-flows.md — 一般的な IxD パターン：フォーム、ナビゲーション、検索、オンボーディング、エラー処理、空の状態、モーダル