保存ボタンを押した後に何も変わらないと、利用者はもう一度押すべきか迷います。マイクロインタラクションは、こうした小さな操作と反応を設計する考え方です。装飾の量ではなく、今の状態と次の行動が分かることを目指します。
30秒で要点：小さな反応の設計
- トリガー・ルール・フィードバック・ループとモードを一組にする。
- 処理中、成功、失敗、結果不明を区別し、秒数だけで成功にしない。
- 文字や支援技術でも状態を伝える。不要な動きは利用者設定で止められるようにする。
四つの要素を保存操作で埋める
Dan Safferの書籍の出版社による公開紹介では、トリガー・ルール・フィードバック・ループとモードを説明しています。ここでは書籍全文の要約ではなく、この語彙を使った著者作成の保存例を扱います。
表が収まらない場合は、横にスクロールできます
| 要素 | 保存フォームで決める内容 |
|---|---|
| トリガー | 入力確認後、利用者が保存ボタンを押す |
| ルール | 処理中は二重開始を防ぎ、結果を受けて表示を変える |
| フィードバック | 保存中・保存済み・未保存・結果確認が必要、を文字で伝える |
| ループとモード | 再操作時の扱い、編集可能/保存中の振る舞い、再試行条件を決める |
状態の一覧だけでは、繰り返したときや操作条件が変わったときのルールが抜けます。「3秒経ったので完了」にせず、何を確認したら成功と言えるかまで書きましょう。
保存の結果が分からない場合を用意する
サーバーは保存したのに返事だけ届かなかった場合、画面からは結果を確定できません。単に「失敗」としてもう一度送ると重複になることがあります。
表が収まらない場合は、横にスクロールできます
| 表示状態 | 根拠 | 利用者への案内 |
|---|---|---|
| 編集中 | まだ保存要求を開始していない | 入力を確認して保存 |
| 保存中 | 保存処理を開始した | 待機、二重開始を防止 |
| 保存済み | 契約上の保存完了応答を確認 | 編集を続けられる |
| 未保存 | 保存していないことを確定できる応答 | 理由を直して再操作 |
| 結果不明 | 応答が途切れ、完了を判定できない | 状況照会・再送条件を確認 |
例えばHTTP 2xxでも、非同期処理の「受付」しか意味しないAPIなら保存完了の表示には使いません。以下は外部通信を行わない教材で、simulateから明示した結果だけを返します。本番では冪等性、認可、結果照会を含めた契約が必要です。
文字による状態表示を先に置く
<button id="save" type="button">保存</button>
<p id="save-status" role="status" aria-live="polite" aria-atomic="true">編集中</p>export function attachSave(button, status, simulate) {
let busy = false;
const messages = {
saved: '保存しました',
rejected: '保存されていません。入力を確認してください',
unknown: '結果を確認できません。保存状況を確認してください'
};
async function onClick() {
if (busy) return;
busy = true;
button.disabled = true;
status.textContent = '保存中です';
try {
const result = await simulate();
status.textContent = messages[result] || messages.unknown;
} catch { status.textContent = messages.unknown; }
finally { busy = false; button.disabled = false; }
}
button.addEventListener('click', onClick);
return () => button.removeEventListener('click', onClick);
}この関数はsimulateを渡して接続します。教材ではsaved、rejected、unknownを順に返す模擬処理で、表示と二重開始防止を調べます。結果不明後の再クリックを安全にする仕組みまではありません。本番接続前に、同じ操作IDでの状況照会などを追加してください。
重要な結果や進捗を、フォーカスを奪わず伝える方法としてstatusを使います。ただし全ての細かい変更を読み上げると邪魔になるため、通知の量も確認します。WCAG 2.2の状態メッセージの解説
動かなくても意味が残るスタイルにする
次の0.2秒は教材の仮設定で、推奨値や最適値ではありません。動きではなく色の変化だけに抑え、操作可能かどうかは文字と無効状態でも示します。
#save {
background-color: #17475e;
color: white;
transition: background-color 0.2s ease;
}
#save:hover:not(:disabled) { background-color: #28647d; }
#save:disabled { background-color: #526775; }
#save:focus-visible { outline: 3px solid #ad6700; outline-offset: 3px; }
@media (prefers-reduced-motion: reduce) {
#save { transition: none; }
}大きい移動や拡縮などの不要な動きは、操作を助けるつもりでも負担になります。動作によるアニメーションの解説はAAAの条件であり、ここで適合を認定するものではありません。prefers-reduced-motionの設定に従う場合も、動きを消した後に結果の文字が残ることを確認します。
一つの操作を観察して直す
架空の確認で、保存を試した20回のうち再度押した操作が4回なら、再操作率は4/20＝20%です。表示を変えた別の20回で2回なら10%、差は10パーセントポイントです。ただし利用者や入力内容が違えば、それだけで改善の原因を断定できません。
観察票には、開始時刻、結果を理解した時点、二度押しの有無、エラーからの回復、利用した入力方法を記録します。成功率だけを上げるために結果不明を成功へ分類してはいけません。
- 迷いが起きる一つの操作を選び、今の表示と利用者の行動を観察する。
- 正常・拒否・遅延・応答消失の状態を紙に書く。
- 文字中心の試作で、次に何をすればよいか説明してもらう。
- キーボード、支援技術、動きを減らす設定も対象環境で確かめる。
- 理解を妨げる反応を減らし、条件をそろえてもう一度観察する。
本稿のDOM教材検証は、ブラウザーや支援技術による受入を意味しません。最初は通知を増やすより、「何が終わり、何が残っているか」を利用者が判断できる状態を作ってください。