ユーザーの視点でインタラクションを考える
問題
AIがインタラクションを書くとき、実装の順序で画面を構成しがちで、ユーザーの順序ではありません。最初にデータ構造があれば、そのコントロールを配置し、コード内で先に書かれた関数の近くにボタンを置きます。その結果：
- 長いフォームの「保存」ボタンがページの上部にあり、ユーザーが一番下まで入力した後、戻って探さなければならない
- 「削除」が「保存」のすぐ隣にあり、同じ色、同じサイズ
- 最もよく使う機能が「その他 ⋯」メニューの第2階層に隠れ、めったに使わない設定がツールバーの最も目立つ場所を占めている
- 選択肢が1つしかないのに、それを選択しないと「次へ」をクリックできない
- 名前を変更するのに："編集モード"をクリック → 変更 → "適用"をクリック → "保存"をクリック → 確認ダイアログ「保存してもよろしいですか？」
- 新しいものを作成するのに3ステップのウィザードが必要だが、実際には名前を入力するだけ
- ボタンに「送信」、「実行」、「確定」と書いてあり、ユーザーはクリックしたら何が起こるかわからない
- エラー時に「操作に失敗しました」と一言表示され、入力内容がすべて消去される
これらはそれぞれ致命的ではありませんが、組み合わさると「なんだか使いにくい」という印象になります。
ステップ1：ユーザーが何をしに来たかを明確にする
着手する前に書き留めてください（頭の中でだけでも構いません）：
- 誰が使うのか：初めて使う初心者か、毎日使う熟練者か？
- 最もよく行う1～3のタスクは何か：これらのタスクは最も速く、最も目立つようにする必要があります。
- 各タスクの理想的なパス：プログラムを開いてから完了するまで、最低限必要な手順はいくつか？
画面のレイアウトはこの順序で並べ、機能リスト、データベースフィールド、コードモジュールの順序ではありません。
ステップ2：ボタンとエントリを配置する場所
| 原則 | 方法 | 悪い例 |
|---|---|---|
| 操作は操作対象の近くに配置する | 行内の編集/削除はその行に、カードの操作はカード上に配置する | まず行を選択し、ページ上部の「編集」を探す |
| 完了フローの位置に応じて配置する | フォームの送信ボタンはフォームの末尾に、ダイアログのボタンは下部に配置する | 長いフォームの保存が最上部にある |
| 頻度で目立ち具合を決める | 最もよく使うものは直接表示し、たまに使うものはメニューに、めったに使わないものは設定に配置する | よく使う機能が2階層目のメニューに隠れている |
| 1つの画面に1つのメイン操作 | メイン操作は強調スタイルで、それ以外は二次スタイルで表示する | 同じように目立つ青色のボタンが5つ並んでいる |
| 危険な操作は離して配置する | 削除は異なる色で、少し離れた場所かメニュー内に配置する | 削除と保存が並んでいて、同じように見える |
| プラットフォームの慣例に従う | Windowsのダイアログボタンは右下、「OK」は「キャンセル」の左側。macOSは「キャンセル」が左、メインボタンが右。Webポップアップの右上に閉じるボタン | 独自の順序を考案する |
| 同じ操作は常に同じ場所に配置する | すべてのページの「新規作成」は同じ場所にある | ページごとに位置が異なる |
| エントリはユーザーが探す場所に配置する | ユーザーが「エクスポートしたい」と思ったときに見る場所（ツールバー、ファイルメニュー、リストの上部など） | エクスポートが設定ページ内に隠れている |
ステップ3：不要な手順を削除する
メインタスクの各手順をリストアップし、順に問いかけます：
- 削除できるか？ この手順でユーザーが決定を下す必要がありますか？そうでなければ削除します。
- デフォルト値を設定できるか？ 90%の人が同じものを選ぶなら、デフォルトで選択しておきます。ユーザーの前回の選択を記憶します。
- 統合できるか？ 「編集 → 適用 → 保存」を直接編集、自動保存、または1回の保存にできないか？
- 後回しにできるか？ 登録、詳細設定、任意のフィールドは、ユーザーが実際に必要になった時点で尋ねることはできないか？
- 自動推測できるか？ ファイル名、コンテキスト、既存のデータから推測できるものは、ユーザーに入力させない。
よくある不要な手順：
| 不要な手順 | 変更後 |
|---|---|
| 元に戻せる操作に対して「よろしいですか？」と確認する | 直接実行し、「元に戻す」を提供する（Gmailのトーストのように）。不可逆で影響の大きい操作のみ確認する |
| 確認ダイアログが「よろしいですか？[はい][いいえ]」 | 結果と対象を明確に記述する：「3つのファイルを削除しますか？この操作は元に戻せません。[削除][キャンセル]」 |
| 選択肢が1つしかないのに選択させる | 自動的に選択するか、この手順自体をスキップする |
| 独立した「編集モード」の切り替え | 直接編集可能にする |
| 1つのフィールドのために複数ステップのウィザード | 1つの入力フィールドと1つのボタン、または行内作成 |
| 設定を変更した後、「適用」をクリックしてから「保存」をクリックする | 1回の操作、または即時反映 |
| 操作後に別のページに移動し、ユーザーが戻ってこなければならない | 元の場所に留まり、その場で更新する |
| 毎回同じ情報を再入力する | 記憶するか、事前に入力する |
ステップ4：ユーザーが求めていないものを追加しない
AIは「ついでに」やりすぎることがよくあります。ユーザーがエクスポートボタンを要求したのに、結果としてエクスポート形式のドロップダウン、エクスポート履歴、エクスポート設定ページが追加されます。ユーザーが小さなツールを要求したのに、サイドバー、設定メニュー、テーマ切り替え、アバウトページ、ヘルプセンター、「近日公開」のプレースホルダエントリが追加されます。
機能、メニュー、エントリが1つ増えるごとに、ユーザーは理解してスキップしなければならないものが1つ増え、メインタスクのエントリが見つけにくくなります。画面上のすべてのものは、ユーザーの注意を奪い合っています。
何かを追加する前に問いかけます：
- ユーザーが求めたか？ 求められておらず、メインタスクの完了に必須でなければ、追加しない。
- それがなくてもユーザーは困らないか？ 困らないなら、追加しない。
- 選択肢が1つしかない、またはほとんど誰も変更しないものか？ であれば、設定項目やドロップダウンは不要で、適切なデフォルト値を直接使用する。
- 空であったり、未実装であったり、「後で使うかもしれない」ものか？ プレースホルダのエントリ、グレーアウトした「お楽しみに」、クリックしても反応しないメニューは配置しない。
よくある不要なもの：
| 不要なもの | 変更後 |
|---|---|
| 機能が1つか2つしかないツールに、サイドバー + 上部ナビゲーション + 設定メニューがある | 1つの画面に直接機能を配置する |
| 誰も要求していないテーマ切り替え、言語切り替え、パーソナライズ設定 | 実装しない。必要になったら追加する |
| 1ページで十分なものを「ホーム / ダッシュボード / アバウト / ヘルプ」に分割する | 1つのページにする |
| 同じ機能に3つのエントリ（ツールバー、右クリックメニュー、設定ページ） | ユーザーが最も探しそうな1つのエントリにする。ショートカットキーは別途追加してもよい |
| プレースホルダの「近日公開」、「高度な機能」、空の統計カード | 削除する |
| すべての値を設定可能にする | 適切なデフォルト値を設定し、ユーザーが実際に変更するものだけを公開する |
追加機能が本当に役立つと感じた場合は、主要な要件を完了した後で提案として一言述べ、ユーザーに追加するかどうかを決めてもらいます。直接実装してはいけません。
ステップ5：ユーザーに常に何が起こっているかを知らせる
- ボタンのラベル = 動詞 + 目的語：「CSVをエクスポート」、「プロジェクトを削除」、「招待状を送信」とし、「送信」、「実行」、「確定」ではありません。ユーザーの言葉を使い、実装の言葉は使いません（「ペイロードを同期」、「ジョブをトリガー」などとは書きません）。
- クリックしたら反応がある：100ミリ秒以内に視覚的なフィードバックがあること。1秒を超える場合は進捗状況やローディング状態を表示し、ボタンを無効にして重複送信を防止します。
- 完了したらユーザーに伝える：軽量な成功通知、または画面に直接結果を表示します。
- エラー時には対処法を伝える：どこが間違っているか、どのように修正するかを説明します。エラーはエラーが発生したフィールドの横に表示します。ユーザーが入力した内容は保持します。
- 空の状態では次のステップに導く：リストが空の場合、ここに何が表示されるかをユーザーに伝え、「最初の1つを作成」ボタンを直接表示します。
- キーボード：ダイアログを開いたときのフォーカスは最初の入力フィールドに。Enterで送信、Escで閉じる。Tabの順序は視覚的な順序と一致させる。
- 突然変化させない：ユーザーが操作しているときにボタンの位置を動かしたり、クリックしようとしている場所をポップアップで遮ったりしない。
CLIも同様です：よく使うパラメータには短いオプションと適切なデフォルト値を設定します。危険な操作には確認を求めますが、--yesも提供します。エラーメッセージは修正方法を説明します。長時間のタスクでは進捗状況を表示します。
ステップ6：実際に一通り実行する
書いただけでは使いやすくなりません。納品前に実際にユーザーとしてメインタスクを一通り実行する必要があります（スクリーンショットの方法は background-friendly を参照）：
- 初めて開くふりをします：コードは見ず、画面だけを見て、5秒以内にやりたいことのエントリを見つけられますか？
- 手順数を数えます：メインタスクを完了するのに必要なクリック数/入力数はいくつですか？ステップ1で書き留めた理想的なパスと比較し、余分な手順にはそれぞれ理由が必要です。
- キーボードだけで一通り実行します。
- 意図的に間違えてみます：誤った入力、途中でのキャンセル、ネットワーク切断などを行い、何が起こるか、入力が失われるかどうかを確認します。
- ウィンドウを小さくしたり、コンテンツが多い場合や空の場合でも、ボタンは適切な位置にありますか？
実行できない（実行環境がない）場合は、ユーザーに「インタラクションフローは実際に検証されていません」と明確に伝え、設計した手順をリストアップしてユーザーが確認できるようにします。
境界
- ユーザーがレイアウトやフローを指定した場合は、ユーザーの指示に従います。問題があると思ったら、その旨を伝え、ユーザーに判断を委ねます。
- プロフェッショナルツールの熟練ユーザーは、習得のしやすさよりも効率を重視する場合があります。そのような場合、ショートカットキー、バッチ操作、高密度表示が初心者ガイドよりも重要です。まずユーザーが誰かを判断します。
- 不可逆でリスクの高い操作（支払い、本番データの削除、一斉送信）には、確認のための余分な手順があっても構いません。「手順を減らす」ために削除してはいけません。
- 既存のプログラムを変更する場合、ユーザーが慣れ親しんだ位置を「より合理的」だからといって大幅に変更してはいけません。変更する必要がある場合は、その理由を説明します。
チェックリスト
- 最もよく行う1～3のタスクは何ですか？それらは最も速く、最も目立つように配置されていますか？
- 各ボタンは、操作対象の近く、ユーザーがフローを完了する位置にありますか？
- 各画面には1つのメイン操作しかありませんか？危険な操作はメイン操作から離して配置されていますか？
- プラットフォームの慣例（ボタンの順序、位置、ショートカットキー）に従っていますか？
- メインタスクの各手順について、「削除できるか、デフォルト値を設定できるか、統合できるか」を検討しましたか？
- すべての機能、メニュー、エントリはユーザーが求めたもの、または必須のものですか？プレースホルダのエントリや誰も必要としていない設定項目はありませんか？
- 確認ダイアログは不可逆な操作にのみ使用していますか？元に戻せる操作には元に戻すオプションを提供していますか？
- ボタンのラベルは「動詞 + 目的語」ですか？ユーザーの言葉を使用していますか？
- ローディング、成功、エラー、空の状態はすべて処理されていますか？エラー時に入力は保持されていますか？
- 実際に新規ユーザーとして一通り実行し、手順数を数えましたか？実行していない場合は「未検証」と伝えていますか？