mcpField
I
interaction-design

interaction-design

github.com/cuellarfrデザイン・UI116370 回インストール4 週間前に更新
リポジトリ

interaction-design について

デジタル製品のユーザー入力への反応を設計するための、プロダクトデザイナー向けインタラクションデザインスキルです。マイクロインタラクション、プロダクトの姿勢、フロー、ナラティブの枠組みを用いて設計判断を支援します。

主な機能

  1. 01マイクロインタラクションのトリガー・ルール・フィードバック・ループモデル
  2. 02トリガーとフィードバックの設計原則
  3. 03プロダクトの姿勢とユーザーの注意
  4. 04フローとインタラクションの構成
  5. 05プロダクト体験のナラティブアーク
  6. 06UI の状態とモーションの指針

活用シーン

  1. 01フォーム送信後のフィードバック設計
  2. 02頻度の異なるタスクに合わせた操作部品の選定
  3. 03オンボーディングやタスクフローの整理
  4. 04インタラクション状態とモーションの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/cuellarfr/design-skills --skill interaction-design

インストール後、Claude Code で/interaction-designを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

examples/
interaction-audit-walkthrough.md
microinteraction-walkthrough.md
references/
error-prevention.md
microinteractions.md
motion-principles.md
product-behavior.md
state-and-transitions.md
templates/
microinteraction-spec-template.md
state-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)。

要素定義主な質問
トリガーインタラクションを開始するものユーザー(またはシステム)はどのように開始しますか?
ルール振る舞いを決める隠れたロジック何が、どの順序で、どのような制約のもとで起こりますか?
フィードバック起きていることをシステムが伝える方法ユーザーには何が見え、聞こえ、感じられますか?
ループとモードインタラクションが時間とともに変化する方法繰り返されますか?期限切れになりますか?適応しますか?
トリガー

手動トリガー(ユーザーが開始):ボタン、切り替え、ジェスチャー、音声コマンド、キーボードショートカット。

システムトリガー(自動):通知、位置情報に基づくアラート、時刻に基づくイベント、状態の変化、エラーの検出。

トリガーの設計原則:

  1. データを前面に出す — トリガー自体に重要な情報を表示します。未読件数が表示されたメールアイコン、充電レベルを示すバッテリーアイコンなどです。状態を確認するだけのために、何かを開かせないようにします
  2. 使用頻度に合わせて視認性を調整する — 使用頻度の高いトリガーは目立たせ、いつでもアクセスできるようにします。使用頻度の低いトリガーは、目立たない場所に配置できます
  3. 一貫した振る舞い — トリガーは毎回同じ操作を開始しなければなりません。一貫性のなさは信頼を損ないます
  4. 状態を伝える — トリガーには、通常、ホバー、アクティブ、無効、更新済みなどの状態があります。それぞれの状態を視覚的に区別できるようにします
ルール

ルールは、トリガーが作動したときに何が起きるかを定義します。ユーザーがルールを直接目にすることはなく、フィードバックを通じて体験します。

ルールの設計原則:

  1. 目標から始める — ユーザーは何を達成しようとしていますか?すべてのルールはその目標に役立つものでなければなりません
  2. ゼロから始めない — 過去の行動、ユーザーの状況、一般的なパターンに基づいて、適切な初期設定を使います。前回ユーザーが行った操作を覚えておきます
  3. エラーを見つけるだけでなく、防ぐ — ポカヨケの原則を適用します。誤った操作ができない入力方法を設計します(自由入力ではなくドロップダウン、数値入力欄ではなく範囲を制限したスライダーなど)
  4. あらゆる例外ケースを定義する — 入力が空の場合はどうなりますか?最大値の場合は?ネットワーク障害の場合は?操作が中断された場合は?設計で想定していなければ、ユーザーがその状況に直面します
フィードバック

フィードバックによって、目に見えないルールが見えるようになります。また、プロダクトの個性が表れる場所でもあります。

種類最適な用途ガイドライン
視覚ほとんどのインタラクショントリガーの近くに表示します。簡潔にします。視覚的な階層を尊重します。コンテンツの邪魔をしないようにします
聴覚確認、アラート、バックグラウンド処理控えめに使います。短くします。否定的な音は避け、肯定的な音を使います。必ずミュートできるようにします
触覚モバイルやウェアラブルでの確認、境界の通知シンプルなパターンにします。操作を確認します。エラーを知らせます。語彙は限定します

フィードバックの原則:

  1. 最小限で最大限を伝える — 最小限で、目的を明確にします。微妙な色の変化はモーダルダイアログより効果的です
  2. 重要度に強度を合わせる — 日常的な確認には控えめな表現を、データ損失を伴うエラーには目立ち、消えない表現を使います
  3. 繰り返すほどフィードバックを弱める — 初回はうれしい表現でも、100回目には煩わしくなります。操作を繰り返した場合は、フィードバックの強度を下げることを検討します
  4. 適度に個性を加える — 少しの個性は効果的です。作業を妨げるような、かわいらしいエラーメッセージは避けます
ループとモード

ループは繰り返しとタイミングを制御します。

  • 回数制御:3回再試行してから停止します
  • 条件制御:接続されるまで確認し続けます
  • 長期ループ(「The Long Wow」):初回から100回目までインタラクションがどのように変化するかを設計します。段階的な情報開示、状況に応じたデフォルト、習熟によって使えるようになるショートカットなどが含まれます

モードは機能を切り替えます。

  • 設定モード:パラメーターを調整します(アラーム音、スヌーズ時間など)
  • スプリングロードモード:物理的に押し続けている間だけ有効です(長押し、キーの押下など)。ユーザーは常に有効状態を把握できるため、最も安全なモードです
  • 一時モード:1回の操作に対して有効になり、その後、自動的に元の状態に戻ります

重要なルール: モードは最小限にします。ゼロが理想です。明確に見えるなら1つは許容できます。マイクロインタラクションに複数のモードがある場合は、設計上の問題を示すサインです。


プロダクトの姿勢

プロダクトの姿勢によって、ユーザーにどの程度の注意を求めるか、またインタラクションをどのように設計すべきかが決まります(Cooper)。

姿勢ユーザーの注意継続時間設計上の対応
主権型集中した十分な注意数時間豊富なコントロール、キーボードショートカット、情報量の多い表示、落ち着いたビジュアルスタイル。常に中級者であるユーザーを対象にします
一時型短時間、タスクに集中数秒から数分ひと目で分かるUI、明るく明快な表示、最小限の選択肢、ユーザーの選択を記憶します
デーモン型なし(バックグラウンド)継続的正常に動作している間は見えないようにします。問題がある場合にのみ表面化させます。一時的な設定パネルから設定できるようにします
永続的な中級者

ユーザーの約80%は初心者でもエキスパートでもなく、永続的な中級者です(Cooper)。学習段階は終えていますが、すべての機能を覚えているわけではありません。

設計上の留意点:

  • 初心者やエキスパートではなく、中級者の利用パターンに合わせてインターフェイスを最適化します
  • 複数のコマンド操作方法を用意します。ツールバーボタン(学習しやすく、見つけやすい)とキーボードショートカット(高速で、覚えて使える)を組み合わせます
  • 段階的な情報開示を取り入れます。重要なコントロールは初期状態で表示し、高度なものは展開可能なパネルの中に隠します
  • インターフェイスを利用状況に合わせて調整します。最もよく使われる機能を、最もアクセスしやすい場所に配置します
  • 中級者に、スキップできない初心者向けの手取り足取りの案内を強制しないでください
  • 重要な機能を、エキスパートだけが使える操作方法の背後に隠さないでください

オーケストレーションとフロー

フロー状態

インタラクションが適切に設計されていると、ユーザーはフロー状態に入り、作業に集中して生産性を高め、インターフェイスの存在を意識しなくなります。インターフェイスが透明な存在になります。

フローを妨げる要因:

  • 作業を中断するモーダルダイアログ
  • 取り消し可能な操作に対する確認プロンプト(「本当によろしいですか?」ではなく、取り消し機能を提供します)
  • 文脈を損なうナビゲーション
  • システムがすでに保持している情報を再入力させること
  • ユーザーを責めるエラー
調和のとれたインタラクションの原則(Cooper)
  1. メンタルモデルに従う — 実際の仕組みではなく、ユーザーがどのように動作すると 考えているか に基づいて設計します
  2. 少ないほど豊かです — 要素が増えるたびに、ユーザーの注意を奪い合います
  3. 質問するのではなく、選択肢を提示する — 確認ダイアログよりも、トグルやオプションを使います
  4. ツールをすぐ使える場所に配置する — コンテキストツールバー、右クリックメニュー、インライン編集を活用します
  5. モードレスなフィードバックを提供する — 邪魔にならないステータス情報を表示します。進行状況はダイアログではなく UI 内に表示します
  6. 起こりそうなことに備え、起こり得ることを予測する — よくある操作を最適化し、エッジケースにも適切に対応します
  7. 何もない状態を避ける — 空の状態は、ただ黙って待つのではなく、次の行動を案内するべきです

プロダクトデザインにおけるナラティブ構造

マイクロインタラクションは、個々の瞬間がどのように動作するかを定義します。ナラティブ構造は、それらの瞬間をどのように組み合わせて魅力的な体験にするかを定義します。人々に愛されるプロダクトは、ただうまく機能するだけではありません。ユーザーが主人公となる物語を紡ぎます。Donna Lichaw のストーリーマッピングの手法に基づくこのフレームワークでは、脚本家が使うものと同じ物語の流れを、プロダクトのフロー設計に適用します。

プロダクトに応用する物語の流れ

あらゆる物語、そしてあらゆるプロダクト体験は、同じ流れをたどります。

物語の要素物語の場合プロダクトの場合デザイン上の問い
導入世界と登場人物を紹介するユーザーが訪れ、状況を把握するこれが何で、何ができるのか、すぐにわかりますか?
きっかけ何かが現状を揺るがすユーザーがタスクや目標に直面するプロダクトはユーザーの問題やニーズを認識していますか?
展開登場人物が行動し、緊張が高まるユーザーがフローを進める各ステップが進展を感じさせますか? エンゲージメントは高まりますか?
危機最大の障害、最も高まる緊張ユーザーが摩擦、不安、複雑さに直面するこの摩擦は意図的なものですか? ユーザーは乗り越えられますか?
クライマックス転換点、感情の頂点報酬となる「なるほど!」という気づきや達成感ユーザーの記憶に残る、最高にポジティブな瞬間がありますか?
結末への展開事態が収束する確認、共有、次のステッププロダクトは成功を祝福し、次の行動を提案していますか?
結末新たな日常ユーザーが印象を胸にその場を離れる終わり方は意図的に設計されていますか?

主人公は常にユーザーです。 プロダクトは、主人公が目標を達成するのを助けるツールであり、物語の主人公ではありません。

プロダクトストーリーの3つの種類
ストーリーの種類対応する内容規模主な問い
コンセプトストーリー全体像 — このプロダクトは何で、なぜ重要なのかプロダクトレベル「このプロダクトの物語とは何か?」
オリジンストーリー初めてユーザーになるまでの過程獲得 + オンボーディング「ユーザーの初めての体験は、どのような物語か?」
利用ストーリー特定のタスクでプロダクトを使う方法1回のセッションまたはフロー「この機能を使う体験は、どのような物語か?」
コンセプトストーリー

中核となる価値提案を伝える、基盤となる物語です。プロダクトが存在する理由を、物語の流れに当てはめます。

  • 導入: 誰のためのものですか? その人の世界はどのようなものですか?
  • きっかけ: どのような問題が現状を揺るがしますか?
  • 展開: これまでにどのような方法を試しましたか?
  • クライマックス: このプロダクトは、驚きや喜びをもたらす方法で、どのように問題を解決しますか?
  • 結末: ユーザーの世界は、今どのようになっていますか?

クライマックスのないコンセプトストーリーは、期待外れに終わります。「よくある X の一つ」に過ぎなくなります。プロダクトを意外性のあるもの、心躍るもの、あるいは変革をもたらすものにする要素を見つけましょう。

オリジンストーリー

認知から初めて意義のある利用に至るまでの道のりです。マーケティングとプロダクトデザインをつなぎます。

プロットポイントとして設計する主なタッチポイント:マーケティング資料 → ランディングページ → サインアップフロー → オンボーディング → 初めての意義あるインタラクション。各段階は、前の段階を踏まえて展開する必要があります。多くの場合、危機となるのは「また登録するものが増えるの?」という疑問です。すぐに価値を実感できる体験を用意し、それに答えるクライマックスを設計しましょう。

利用ストーリー

単一のタスクやセッションを、物語の弧として表現したものです。ストーリーマッピングがインタラクションデザインと最も直接的に結び付く領域です。

  • タスクを完了するまでの体験を、瞬間ごとにマッピングします
  • 最もポジティブな瞬間となる「ブーム」がどこにあるべきかを特定します
  • 終わりを意図的にデザインします。ピーク・エンドの法則によると、ユーザーは最も良かった瞬間と終わりによって、体験全体を評価します
ストーリーマッピングのプロセス
  1. ストーリーを定義する — 主人公は誰ですか?目標は何ですか?どの種類のストーリーをマッピングしますか?
  2. 物語の弧を描く — 壁やスプレッドシートに付箋を使います。プロットのポイントごとに1枚ずつ用意し、左から右へ時系列にマッピングします
  3. 物語の弧を検証する — 声に出して読みます。盛り上がっていきますか?本当の緊張感はありますか?クライマックスに満足できますか?弱いプロットのポイントがあれば、ストーリー全体に影響します
  4. 画面やインタラクションにマッピングする — 各プロットのポイントを、画面、状態、または重要なインタラクションの瞬間に対応させます
  5. 危機を意図的にデザインする — あらゆる摩擦を取り除く必要はありません。ある程度の摩擦はエンゲージメントを生みます。危機を乗り越えたときの満足感が、クライマックスに意味をもたらします
  6. クライマックスをデザインする — これはユーザーの記憶に残る瞬間です。ここに、他の部分よりも多くのデザイン労力を注ぎます
  7. 終わりをデザインする — 確認、お祝い、共有、または次のストーリーへの橋渡しを用意します
ピーク・エンドの法則を適用する

人間が体験をどのように評価するかに関する研究(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秒以上待たせないでください。操作に時間がかかる場合は、結果が届く前でも、スケルトン、スピナー、メッセージなどをすぐに表示します。


ジェスチャーのパターン

タッチジェスチャー
ジェスチャーアクション使用する場面
タップ選択、実行タッチ可能な要素での主要な操作
長押し副次的な操作、コンテキストメニュー発見しにくいため、必ず別の操作経路も用意します
スワイプナビゲーション、閉じる、アクションの表示リスト、カード、ページで自然な操作です。初回使用時に操作方法を示します
ピンチ/スプレッドズームイン/アウト地図、画像、ドキュメントで使用します。双方向に操作できます
ドラッグ並べ替え、移動、サイズ変更ドロップ先を表示します。しきい値に達したときに触覚フィードバックを提供します
下方向へのプル更新リストやフィードで使用します。進行状況のアニメーションを表示します
ジェスチャーの設計ルール
  1. ジェスチャーだけを唯一の操作経路にしない — ボタンやメニュー項目など、目に見える代替手段を必ず用意します
  2. ジェスチャー中にフィードバックを提供する — 要素は指を離した後だけでなく、指の動きにリアルタイムで反応する必要があります
  3. プラットフォームの操作に従う — iOSのスワイプバック、Androidの戻るボタンなど、システムジェスチャーを上書きしないでください
  4. 段階的開示で使い方を伝える — 初めて使うときにジェスチャーのヒントを表示し、その後は徐々に消します
  5. タッチターゲットは最低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 — 架空のプロダクトの操作を監査し、改善する例

コメント