interaction-design について
デジタル製品のユーザー入力への反応を設計するための、プロダクトデザイナー向けインタラクションデザインスキルです。マイクロインタラクション、プロダクトの姿勢、フロー、ナラティブの枠組みを用いて設計判断を支援します。
主な機能
- 01マイクロインタラクションのトリガー・ルール・フィードバック・ループモデル
- 02トリガーとフィードバックの設計原則
- 03プロダクトの姿勢とユーザーの注意
- 04フローとインタラクションの構成
- 05プロダクト体験のナラティブアーク
- 06UI の状態とモーションの指針
活用シーン
- 01フォーム送信後のフィードバック設計
- 02頻度の異なるタスクに合わせた操作部品の選定
- 03オンボーディングやタスクフローの整理
- 04インタラクション状態とモーションの確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ cuellarfr/ design-skills --skill interaction-designインストール後、Claude Code で/interaction-designを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
examples/interaction-audit-walkthrough.mdmicrointeraction-walkthrough.mdreferences/error-prevention.mdmicrointeractions.mdmotion-principles.mdproduct-behavior.mdstate-and-transitions.mdtemplates/microinteraction-spec-template.mdstate-inventory-template.md詳細
インタラクションデザイン
人間の入力に対して製品がどのように振る舞うかを定義する分野、インタラクションデザインの専門家です。推奨事項は、Dan Saffer の『Microinteractions』(トリガー・ルール・フィードバック・ループのフレームワーク)、Alan Cooper の『About Face』(製品の姿勢、永続的な中級者、オーケストレーション、余計な操作)、Donna Lichaw の『The User's Journey』(物語の弧、ストーリーマッピング、ピークエンドの設計)、UI 向けに応用したアニメーションの 12 原則、UI の状態モデリングにおける David Harel のステートチャート、Material Design 3 と Apple HIG のモーションガイドラインに基づいています。
インタラクションデザインとは、振る舞いのデザインです。製品の見た目はユーザーが目にするものですが、インタラクションデザインはユーザーが体験するものです。ユーザーが我慢して使う製品と、愛着を持つ製品との違いは、ほとんどの場合、インタラクションの質にあります。
マイクロインタラクションのフレームワーク
スイッチの切り替えからフォームの送信まで、あらゆるインタラクションは 4 つの要素で構成されます(Saffer)。
| 要素 | 定義 | 主な質問 |
|---|---|---|
| トリガー | インタラクションを開始するもの | ユーザー(またはシステム)はどのように開始しますか? |
| ルール | 振る舞いを決める隠れたロジック | 何が、どの順序で、どのような制約のもとで起こりますか? |
| フィードバック | 起きていることをシステムが伝える方法 | ユーザーには何が見え、聞こえ、感じられますか? |
| ループとモード | インタラクションが時間とともに変化する方法 | 繰り返されますか?期限切れになりますか?適応しますか? |
トリガー
手動トリガー(ユーザーが開始):ボタン、切り替え、ジェスチャー、音声コマンド、キーボードショートカット。
システムトリガー(自動):通知、位置情報に基づくアラート、時刻に基づくイベント、状態の変化、エラーの検出。
トリガーの設計原則:
- データを前面に出す — トリガー自体に重要な情報を表示します。未読件数が表示されたメールアイコン、充電レベルを示すバッテリーアイコンなどです。状態を確認するだけのために、何かを開かせないようにします
- 使用頻度に合わせて視認性を調整する — 使用頻度の高いトリガーは目立たせ、いつでもアクセスできるようにします。使用頻度の低いトリガーは、目立たない場所に配置できます
- 一貫した振る舞い — トリガーは毎回同じ操作を開始しなければなりません。一貫性のなさは信頼を損ないます
- 状態を伝える — トリガーには、通常、ホバー、アクティブ、無効、更新済みなどの状態があります。それぞれの状態を視覚的に区別できるようにします
ルール
ルールは、トリガーが作動したときに何が起きるかを定義します。ユーザーがルールを直接目にすることはなく、フィードバックを通じて体験します。
ルールの設計原則:
- 目標から始める — ユーザーは何を達成しようとしていますか?すべてのルールはその目標に役立つものでなければなりません
- ゼロから始めない — 過去の行動、ユーザーの状況、一般的なパターンに基づいて、適切な初期設定を使います。前回ユーザーが行った操作を覚えておきます
- エラーを見つけるだけでなく、防ぐ — ポカヨケの原則を適用します。誤った操作ができない入力方法を設計します(自由入力ではなくドロップダウン、数値入力欄ではなく範囲を制限したスライダーなど)
- あらゆる例外ケースを定義する — 入力が空の場合はどうなりますか?最大値の場合は?ネットワーク障害の場合は?操作が中断された場合は?設計で想定していなければ、ユーザーがその状況に直面します
フィードバック
フィードバックによって、目に見えないルールが見えるようになります。また、プロダクトの個性が表れる場所でもあります。
| 種類 | 最適な用途 | ガイドライン |
|---|---|---|
| 視覚 | ほとんどのインタラクション | トリガーの近くに表示します。簡潔にします。視覚的な階層を尊重します。コンテンツの邪魔をしないようにします |
| 聴覚 | 確認、アラート、バックグラウンド処理 | 控えめに使います。短くします。否定的な音は避け、肯定的な音を使います。必ずミュートできるようにします |
| 触覚 | モバイルやウェアラブルでの確認、境界の通知 | シンプルなパターンにします。操作を確認します。エラーを知らせます。語彙は限定します |
フィードバックの原則:
- 最小限で最大限を伝える — 最小限で、目的を明確にします。微妙な色の変化はモーダルダイアログより効果的です
- 重要度に強度を合わせる — 日常的な確認には控えめな表現を、データ損失を伴うエラーには目立ち、消えない表現を使います
- 繰り返すほどフィードバックを弱める — 初回はうれしい表現でも、100回目には煩わしくなります。操作を繰り返した場合は、フィードバックの強度を下げることを検討します
- 適度に個性を加える — 少しの個性は効果的です。作業を妨げるような、かわいらしいエラーメッセージは避けます
ループとモード
ループは繰り返しとタイミングを制御します。
- 回数制御:3回再試行してから停止します
- 条件制御:接続されるまで確認し続けます
- 長期ループ(「The Long Wow」):初回から100回目までインタラクションがどのように変化するかを設計します。段階的な情報開示、状況に応じたデフォルト、習熟によって使えるようになるショートカットなどが含まれます
モードは機能を切り替えます。
- 設定モード:パラメーターを調整します(アラーム音、スヌーズ時間など)
- スプリングロードモード:物理的に押し続けている間だけ有効です(長押し、キーの押下など)。ユーザーは常に有効状態を把握できるため、最も安全なモードです
- 一時モード:1回の操作に対して有効になり、その後、自動的に元の状態に戻ります
重要なルール: モードは最小限にします。ゼロが理想です。明確に見えるなら1つは許容できます。マイクロインタラクションに複数のモードがある場合は、設計上の問題を示すサインです。
プロダクトの姿勢
プロダクトの姿勢によって、ユーザーにどの程度の注意を求めるか、またインタラクションをどのように設計すべきかが決まります(Cooper)。
| 姿勢 | ユーザーの注意 | 継続時間 | 設計上の対応 |
|---|---|---|---|
| 主権型 | 集中した十分な注意 | 数時間 | 豊富なコントロール、キーボードショートカット、情報量の多い表示、落ち着いたビジュアルスタイル。常に中級者であるユーザーを対象にします |
| 一時型 | 短時間、タスクに集中 | 数秒から数分 | ひと目で分かるUI、明るく明快な表示、最小限の選択肢、ユーザーの選択を記憶します |
| デーモン型 | なし(バックグラウンド) | 継続的 | 正常に動作している間は見えないようにします。問題がある場合にのみ表面化させます。一時的な設定パネルから設定できるようにします |
永続的な中級者
ユーザーの約80%は初心者でもエキスパートでもなく、永続的な中級者です(Cooper)。学習段階は終えていますが、すべての機能を覚えているわけではありません。
設計上の留意点:
- 初心者やエキスパートではなく、中級者の利用パターンに合わせてインターフェイスを最適化します
- 複数のコマンド操作方法を用意します。ツールバーボタン(学習しやすく、見つけやすい)とキーボードショートカット(高速で、覚えて使える)を組み合わせます
- 段階的な情報開示を取り入れます。重要なコントロールは初期状態で表示し、高度なものは展開可能なパネルの中に隠します
- インターフェイスを利用状況に合わせて調整します。最もよく使われる機能を、最もアクセスしやすい場所に配置します
- 中級者に、スキップできない初心者向けの手取り足取りの案内を強制しないでください
- 重要な機能を、エキスパートだけが使える操作方法の背後に隠さないでください
オーケストレーションとフロー
フロー状態
インタラクションが適切に設計されていると、ユーザーはフロー状態に入り、作業に集中して生産性を高め、インターフェイスの存在を意識しなくなります。インターフェイスが透明な存在になります。
フローを妨げる要因:
- 作業を中断するモーダルダイアログ
- 取り消し可能な操作に対する確認プロンプト(「本当によろしいですか?」ではなく、取り消し機能を提供します)
- 文脈を損なうナビゲーション
- システムがすでに保持している情報を再入力させること
- ユーザーを責めるエラー
調和のとれたインタラクションの原則(Cooper)
- メンタルモデルに従う — 実際の仕組みではなく、ユーザーがどのように動作すると 考えているか に基づいて設計します
- 少ないほど豊かです — 要素が増えるたびに、ユーザーの注意を奪い合います
- 質問するのではなく、選択肢を提示する — 確認ダイアログよりも、トグルやオプションを使います
- ツールをすぐ使える場所に配置する — コンテキストツールバー、右クリックメニュー、インライン編集を活用します
- モードレスなフィードバックを提供する — 邪魔にならないステータス情報を表示します。進行状況はダイアログではなく UI 内に表示します
- 起こりそうなことに備え、起こり得ることを予測する — よくある操作を最適化し、エッジケースにも適切に対応します
- 何もない状態を避ける — 空の状態は、ただ黙って待つのではなく、次の行動を案内するべきです
プロダクトデザインにおけるナラティブ構造
マイクロインタラクションは、個々の瞬間がどのように動作するかを定義します。ナラティブ構造は、それらの瞬間をどのように組み合わせて魅力的な体験にするかを定義します。人々に愛されるプロダクトは、ただうまく機能するだけではありません。ユーザーが主人公となる物語を紡ぎます。Donna Lichaw のストーリーマッピングの手法に基づくこのフレームワークでは、脚本家が使うものと同じ物語の流れを、プロダクトのフロー設計に適用します。
プロダクトに応用する物語の流れ
あらゆる物語、そしてあらゆるプロダクト体験は、同じ流れをたどります。
| 物語の要素 | 物語の場合 | プロダクトの場合 | デザイン上の問い |
|---|---|---|---|
| 導入 | 世界と登場人物を紹介する | ユーザーが訪れ、状況を把握する | これが何で、何ができるのか、すぐにわかりますか? |
| きっかけ | 何かが現状を揺るがす | ユーザーがタスクや目標に直面する | プロダクトはユーザーの問題やニーズを認識していますか? |
| 展開 | 登場人物が行動し、緊張が高まる | ユーザーがフローを進める | 各ステップが進展を感じさせますか? エンゲージメントは高まりますか? |
| 危機 | 最大の障害、最も高まる緊張 | ユーザーが摩擦、不安、複雑さに直面する | この摩擦は意図的なものですか? ユーザーは乗り越えられますか? |
| クライマックス | 転換点、感情の頂点 | 報酬となる「なるほど!」という気づきや達成感 | ユーザーの記憶に残る、最高にポジティブな瞬間がありますか? |
| 結末への展開 | 事態が収束する | 確認、共有、次のステップ | プロダクトは成功を祝福し、次の行動を提案していますか? |
| 結末 | 新たな日常 | ユーザーが印象を胸にその場を離れる | 終わり方は意図的に設計されていますか? |
主人公は常にユーザーです。 プロダクトは、主人公が目標を達成するのを助けるツールであり、物語の主人公ではありません。
プロダクトストーリーの3つの種類
| ストーリーの種類 | 対応する内容 | 規模 | 主な問い |
|---|---|---|---|
| コンセプトストーリー | 全体像 — このプロダクトは何で、なぜ重要なのか | プロダクトレベル | 「このプロダクトの物語とは何か?」 |
| オリジンストーリー | 初めてユーザーになるまでの過程 | 獲得 + オンボーディング | 「ユーザーの初めての体験は、どのような物語か?」 |
| 利用ストーリー | 特定のタスクでプロダクトを使う方法 | 1回のセッションまたはフロー | 「この機能を使う体験は、どのような物語か?」 |
コンセプトストーリー
中核となる価値提案を伝える、基盤となる物語です。プロダクトが存在する理由を、物語の流れに当てはめます。
- 導入: 誰のためのものですか? その人の世界はどのようなものですか?
- きっかけ: どのような問題が現状を揺るがしますか?
- 展開: これまでにどのような方法を試しましたか?
- クライマックス: このプロダクトは、驚きや喜びをもたらす方法で、どのように問題を解決しますか?
- 結末: ユーザーの世界は、今どのようになっていますか?
クライマックスのないコンセプトストーリーは、期待外れに終わります。「よくある X の一つ」に過ぎなくなります。プロダクトを意外性のあるもの、心躍るもの、あるいは変革をもたらすものにする要素を見つけましょう。
オリジンストーリー
認知から初めて意義のある利用に至るまでの道のりです。マーケティングとプロダクトデザインをつなぎます。
プロットポイントとして設計する主なタッチポイント:マーケティング資料 → ランディングページ → サインアップフロー → オンボーディング → 初めての意義あるインタラクション。各段階は、前の段階を踏まえて展開する必要があります。多くの場合、危機となるのは「また登録するものが増えるの?」という疑問です。すぐに価値を実感できる体験を用意し、それに答えるクライマックスを設計しましょう。
利用ストーリー
単一のタスクやセッションを、物語の弧として表現したものです。ストーリーマッピングがインタラクションデザインと最も直接的に結び付く領域です。
- タスクを完了するまでの体験を、瞬間ごとにマッピングします
- 最もポジティブな瞬間となる「ブーム」がどこにあるべきかを特定します
- 終わりを意図的にデザインします。ピーク・エンドの法則によると、ユーザーは最も良かった瞬間と終わりによって、体験全体を評価します
ストーリーマッピングのプロセス
- ストーリーを定義する — 主人公は誰ですか?目標は何ですか?どの種類のストーリーをマッピングしますか?
- 物語の弧を描く — 壁やスプレッドシートに付箋を使います。プロットのポイントごとに1枚ずつ用意し、左から右へ時系列にマッピングします
- 物語の弧を検証する — 声に出して読みます。盛り上がっていきますか?本当の緊張感はありますか?クライマックスに満足できますか?弱いプロットのポイントがあれば、ストーリー全体に影響します
- 画面やインタラクションにマッピングする — 各プロットのポイントを、画面、状態、または重要なインタラクションの瞬間に対応させます
- 危機を意図的にデザインする — あらゆる摩擦を取り除く必要はありません。ある程度の摩擦はエンゲージメントを生みます。危機を乗り越えたときの満足感が、クライマックスに意味をもたらします
- クライマックスをデザインする — これはユーザーの記憶に残る瞬間です。ここに、他の部分よりも多くのデザイン労力を注ぎます
- 終わりをデザインする — 確認、お祝い、共有、または次のストーリーへの橋渡しを用意します
ピーク・エンドの法則を適用する
人間が体験をどのように評価するかに関する研究(Kahneman)によると、人は2つの瞬間、つまりピーク(感情の強度が最も高い瞬間)と終わり(最後の印象)によって体験を評価します。全体の所要時間や平均的な質は、はるかに重要度が低いものです。
デザインへの示唆:
- ピークを特定する — すべてのフローに、感情的な高まりとなるようデザインされた瞬間を1つ設けます
- 終わりに力を注ぐ — 弱い終わりは、それ以外が優れた体験であっても台無しにします。成功状態、確認画面、「次にすること」を示す瞬間には、コアワークフローと同じくらいデザイン上の配慮が必要です
- 許容できる摩擦 — ピークと終わりが強ければ、ユーザーは途中の摩擦を許容します。クライマックスを犠牲にして、中盤を最適化しすぎないようにします
- ピークと終わりを測定する — ユーザビリティテストでは、「何が印象に残りましたか?」「どのように終わりましたか?」と尋ねます。これらの質問から、記憶に残る体験がわかります
ストーリーマッピングを使う場面
| 状況 | マッピングするストーリーの種類 |
|---|---|
| 新しい製品や主要機能をデザインする | まずコンセプトストーリー、次にオリジンストーリー |
| オンボーディングや利用開始を改善する | オリジンストーリー |
| 特定のフローをデザインまたは改善する | 利用ストーリー |
| ユーザーがエンゲージしていない理由を診断する | 3種類すべて — どのストーリーに問題があるかを見つけます |
| ステークホルダーに製品ビジョンを提案する | 物語の骨格としてのコンセプトストーリー |
余分な作業
余分な作業とは、ユーザーの目標達成に貢献しない作業です(Cooper)。ユーザーが望むことを直接達成するものではないクリック、スクロール、ページ移動、混乱する瞬間は、すべて余分な作業です。取り除きましょう。
余分な作業の4つの種類
| 種類 | 定義 | 例 |
|---|---|---|
| 認知的 | 製品の動作を理解すること、レイアウトを読み解くこと | わかりにくいラベル、曖昧なアイコン、複雑な専門用語 |
| 記憶 | コマンド、場所、パスワード、設定を覚えておくこと | 設定の場所を忘れること、同じデータを再入力すること |
| 視覚的 | どこを見るべきかを判断すること、項目を探すこと、階層を読み解くこと | ごちゃついた画面、コントラストの低さ、違いがわかりにくいリスト |
| 物理的 | 不要なクリック、マウスの移動、モードの切り替え | 階層の深いナビゲーション、離れた場所にある操作部、何度もスクロールすること |
ナビゲーションによる余分な作業(最も多いもの)
ナビゲーションは、余分な作業の最も一般的な原因です。次の方法で減らしましょう。
- 移動先を減らす — 階層をフラット化します。関連する機能をまとめます
- 道しるべを用意する — パンくずリスト、アクティブ状態、現在位置の表示を活用します
- 概要を用意する — ダッシュボード、要約、プレビューを活用します
- ウィンドウや画面の切り替えを強制しない — 現在のコンテキストに影響する機能は、現在のコンテキスト内で実行します
- 機械時代のモデルをそのまま再現しない — デジタル製品は、物理的な制約を模倣するべきではありません
過剰な機能を見極めるテスト
各インタラクションの手順について、次のように問いかけます。「これはユーザーが目標を達成するうえで、直接役立つか?」
- はい → 残し、最適化します
- いいえ → 削除、自動化するか、段階的開示の背後に隠します
状態の設計
すべての要素に状態を持たせる
あらゆるインタラクティブ要素について、考えられるすべての状態を設計します。
| 状態 | 状況 | 必要な視覚的変化 |
|---|---|---|
| デフォルト | 待機中、操作可能 | 基本の外観 |
| ホバー | カーソルが上にある(デスクトップ) | さりげないハイライト、カーソルの変化 |
| フォーカス | キーボードでのナビゲーション中 | 視認可能なフォーカスリング(2px、コントラスト比3:1) |
| アクティブ/押下 | 操作中 | 押し込まれた外観、縮小 |
| 無効 | 現在利用できない | 不透明度を下げる(40%)、ポインターイベントを無効化 |
| 読み込み中 | データ/応答を待機中 | コンテンツをスケルトンまたはスピナーに置き換える |
| 空 | 表示するデータがない | イラスト+ガイダンス+アクション |
| エラー | 問題が発生 | エラー色+メッセージ+復旧手段 |
| 成功 | 操作が完了 | 確認+次のステップ |
| 選択済み | 複数選択で選ばれている | アクセントカラーの境界線または背景 |
| 展開/折りたたみ | コンテンツの表示/非表示を切り替え | 矢印/シェブロンの回転+コンテンツの表示 |
| ドラッグ中 | 位置を変更中 | 影を強調し、元の位置にゴーストを表示 |
状態マシン
複雑なインタラクションでは、振る舞いを有限状態マシンとしてモデル化します。
[Idle] --click--> [Loading] --success--> [Displaying Data]
--error--> [Error State]
[Error State] --retry--> [Loading]
[Displaying Data] --refresh--> [Loading]
--delete--> [Confirming]
[Confirming] --confirm--> [Deleting] --done--> [Idle]
--cancel--> [Displaying Data]
利点:
- 不可能な状態を起こらないようにできます(読み込み中は削除できません)
- すべての遷移を明示的に定義する必要が生まれます
- 不足している状態を早い段階で発見できます(タイムアウト時にはどうなるか?)
- 開発者がそのまま実装できるドキュメントになります
応答速度のしきい値
| 時間 | ユーザーの感じ方 | デザイン上の対応 |
|---|---|---|
| 0~100ms | 瞬時 | 状態の変化以外にフィードバックは不要 |
| 100ms~1s | 応答性が高く、わずかな遅延 | 結果を表示します。1秒近くかかる場合はスケルトンまたは控えめなインジケーターを表示します |
| 1~10s | 待ち時間を感じる | 進行状況を表示します。何が起きているかを説明し、キャンセルできるようにします |
| 10s以上 | 注意がそれ始める | 推定時間付きで進行状況を継続して表示します。タスクをバックグラウンドで実行し、完了時に通知します |
重要なルール: フィードバックがないまま、ユーザーを1秒以上待たせないでください。操作に時間がかかる場合は、結果が届く前でも、スケルトン、スピナー、メッセージなどをすぐに表示します。
ジェスチャーのパターン
タッチジェスチャー
| ジェスチャー | アクション | 使用する場面 |
|---|---|---|
| タップ | 選択、実行 | タッチ可能な要素での主要な操作 |
| 長押し | 副次的な操作、コンテキストメニュー | 発見しにくいため、必ず別の操作経路も用意します |
| スワイプ | ナビゲーション、閉じる、アクションの表示 | リスト、カード、ページで自然な操作です。初回使用時に操作方法を示します |
| ピンチ/スプレッド | ズームイン/アウト | 地図、画像、ドキュメントで使用します。双方向に操作できます |
| ドラッグ | 並べ替え、移動、サイズ変更 | ドロップ先を表示します。しきい値に達したときに触覚フィードバックを提供します |
| 下方向へのプル | 更新 | リストやフィードで使用します。進行状況のアニメーションを表示します |
ジェスチャーの設計ルール
- ジェスチャーだけを唯一の操作経路にしない — ボタンやメニュー項目など、目に見える代替手段を必ず用意します
- ジェスチャー中にフィードバックを提供する — 要素は指を離した後だけでなく、指の動きにリアルタイムで反応する必要があります
- プラットフォームの操作に従う — iOSのスワイプバック、Androidの戻るボタンなど、システムジェスチャーを上書きしないでください
- 段階的開示で使い方を伝える — 初めて使うときにジェスチャーのヒントを表示し、その後は徐々に消します
- タッチターゲットは最低44×44px(Apple HIG)または48×48dp(Material)にします — ターゲットが小さいと誤操作につながります
よくある間違い
| 間違い | 失敗する理由 | 代わりに |
|---|---|---|
| うまくいくケースだけを設計する | 実際のユーザーは、エラー、空の状態、遅い接続、エッジケースに遭遇します | すべての要素について、あらゆる状態を設計します |
| あらゆる操作でダイアログを表示して確認する | 操作の流れを妨げ、ユーザーに内容を読まずに「OK」をクリックする習慣をつけてしまいます | 許可を求める代わりに、元に戻せるようにします |
| 結果が異なるのに、同じフィードバックを表示する | ユーザーは、操作が成功したのか、失敗したのか、まだ処理中なのかを判断できません | 成功、エラー、読み込み中のフィードバックを明確に区別します |
| 視覚的な代替手段のないジェスチャー | ジェスチャーに気づかないユーザーは操作できなくなります | ジェスチャーには必ず、視覚的なコントロールを組み合わせます |
| 操作を妨げるアニメーション | ユーザーは、操作できるようになるまでアニメーションの終了を待つことになります | 直接操作に対するアニメーションは300ms未満にします。入力を妨げてはいけません |
| キーボードを使うユーザーを考慮しない | キーボード操作が機能しなかったり、操作箇所が見えなかったりします | フォーカスの順序、視認できるフォーカス状態、キーボードショートカットを設計します |
| 明確な表示のない複雑なモード | ユーザーは現在のモードがわからず、予期しない動作に遭遇します | モードは最小限にします。避けられない場合は、現在のモードを見落としようがないように表示します |
参考ファイル
特定のトピックについて詳しく知るには、以下を参照してください。
references/microinteractions.md— トリガーの設計、ルールのロジック、フィードバックの種類、ループとモードを網羅した4部構成のフレームワークの詳細と、それぞれのデザインパターンreferences/product-behavior.md— プロダクトの姿勢、永続的な中間状態、スマートで配慮のあるプロダクトの動作、オーケストレーション、フロー、不要な手順の排除references/state-and-transitions.md— UI のステートマシン、ジェスチャーパターン、レスポンシブな動作、ドラッグ&ドロップ、キーボード操作references/motion-principles.md— UI に合わせたアニメーションの原則、タイミングとイージングのガイドライン、モーショントークン、動きを抑える設定、Material/Apple のモーションパターンreferences/error-prevention.md— エラー防止の階層、元に戻すパターン、インライン検証、空の状態、読み込みパターン、復旧フロー
テンプレート
templates/microinteraction-spec-template.md— 4部構成のフレームワークを使用した、単一のマイクロインタラクションの完全な仕様templates/state-inventory-template.md— 機能または画面内のすべてのインタラクティブ要素を対象とした状態の監査
例
examples/microinteraction-walkthrough.md— 「お気に入り」の切り替え操作を最初から最後まで設計する例examples/interaction-audit-walkthrough.md— 架空のプロダクトの操作を監査し、改善する例