guided-gui-design

ガイド付きGUIデザイン

プロダクト自体が使い方をユーザーに教える必要がある、ユーザー向け画面でこのスキルを使用します。

このスキルは gui-standards ルールモジュールを補完します。 gui-standards では譲れない要件を示し、このスキルではその背景にある理論、デザインの視点、ワークフロー、判断の指針を提供します。

根拠となる理由、明示された出典、またはより深いレビューの視点が必要な場合は、references/hci-usability-foundations.md をお読みください。

中核となる成果

初めて使うユーザーが、別途チャットで説明を受けなくても、画面を見て次のことを理解できるように設計します。

1. この画面で何を達成できるか。
2. 最初に何をすべきか。
3. 現在どの状態を操作しているか。
4. 最も重要な結果は何か。
5. 間違えた場合にどうやり直せるか。

理論的な視点

これらは診断の視点として使い、厳格な法則として扱わないでください。視点同士が衝突する場合は、タスクの成功、エラーの防止、復旧のしやすさを優先してください。

観点	中核となる問い	設計上の示唆
タスク中心／人間中心設計（ISO 9241-210）	UI はユーザーの実際の業務と利用状況に合っていますか？	実装モデルではなく、タスクを中心に構成します
Norman：実行の溝と評価の溝	ユーザーは、意図を形にし、翻訳なしに結果を判断できますか？	見つけやすいコントロールと明確なフィードバックで、両方の溝を埋めます
Norman：アフォーダンス、シグニファイア、マッピング、制約、フィードバック、概念モデル	ユーザーは、何ができるか、何を選択したか、何が変化したかを把握できますか？	操作、選択、システムの状態、結果を明確に示します
Nielsen の 10 ヒューリスティック	UI は状態を表示し、馴染みのある言葉を使い、エラーを防ぎ、復旧を支援していますか？	視認性、一貫性、エラー防止、認識、ユーザーの制御を優先します
Shneiderman の 8 つのゴールデンルール	一貫性、ショートカット、フィードバック、完了感、可逆性が確保されていますか？	一貫したフロー、元に戻す操作、対話の完了、わかりやすいフィードバックを提供します
認知負荷理論／ワーキングメモリ（Miller、Cowan）	ユーザーは一度にどれだけの情報を頭に留める必要がありますか？	同時に求める判断を減らし、段階的開示を使い、状態を外部化します
Hick-Hyman の法則	1 つの判断時点で、同等に重み付けされた選択肢が多すぎませんか？	同じ階層の選択肢を絞り、判断を段階的に行い、妥当なデフォルトを使います
Fitts の法則	主要な操作に簡単にたどり着き、押すことができますか？	よく使うターゲットを十分な大きさにし、作業領域の近くに配置します
Steering の法則	ユーザーは狭い経路（メニュー、トンネル）を移動する必要がありますか？	長く細いホバー経路を避け、よく使う操作経路を広くします
ゲシュタルト原則（近接、類同、連続、閉合、共通領域、共通運命、図と地）	グループ分けと階層構造がひと目でわかりますか？	余白、整列、コントラスト、囲みを使って構造を示します
視覚的階層とスキャンパターン	最も重要な要素に、視線が最初に向かいますか？	強さ、大きさ、コントラスト、位置を使って重要度を示します
情報の香り（Pirolli）	ラベルやリンクから、ユーザーが見つけるものを予測できますか？	ラベルで遷移先や結果を具体的に説明します
Reason：スリップとミステイク／ポカヨケ	よくあるエラーは、操作のスリップですか、それとも意図のミステイクですか？	入力を制限し、破壊的な操作の意図を確認し、簡単に復旧できるようにします
アクセシビリティ（WCAG／POUR）	より多くのユーザーが UI を知覚し、操作し、理解し、信頼できますか？	ラベル、フォーカス、コントラスト、キーボード操作、色以外の手がかり、動きの抑制への配慮
プラットフォームの慣習（Material、HIG、Fluent）	UI は、そのプラットフォームのユーザーがすでに期待しているとおりに動作しますか？	プラットフォームの慣習に従い、明確な理由がある場合のみ変更します

デフォルトのワークフロー

1. ユーザーの本当の目的を見つける

目的を、タスクが分かる平易な言葉で示します。

• 良い例：Capture, annotate, and save the correct tutorial shot
• 悪い例：Manage shot manifests、Edit rendering metadata

UI は、内部のデータモデルではなく、ユーザーの作業を中心に構成しなければなりません。

2. 主要な経路と状態モデルを定義する

レイアウトを変更する前に、次の項目を明確にします。

1. ユーザーがたどる主要な経路。
2. 必要最小限のセットアップ。
3. 重要なシステムの状態と遷移。
4. ユーザーが評価する結果。

例：

1. 対象の項目を選択します。
2. 変更を加えます。
3. 結果を確認します。
4. 保存するか、再試行します。

画面に複数の作業が混在している場合は、それらを分けるか、副次的な作業として扱います。

3. 初回利用時の認知負荷を減らす

開始時にユーザーが考えなければならないことを減らします。

• 次に意味のある判断だけを最初に表示します（段階的開示）。
• 副次的なコントロールは視覚的に目立たなくします。
• ユーザーが状況を把握してから、高度な詳細を表示します。
• 同じくらい目立つ選択肢をたくさん提示するより、次に行うことが明確なアクションを1つ提示します（Hick-Hymanの法則）。
• 画面をまたいだ記憶をユーザーに求めるのではなく、見やすいラベル、プレビュー、現在の選択項目を示す表示によって、必要な情報を画面上に示します。
• 説明文を常時表示するより、見れば使い方が分かるUIを優先します。
• UI 自体から次のアクションを推測できない場合に限り、説明文を追加します。

4. 内部向けの表現と記憶の負担を取り除く

関係のない実装用語や、そのサイト内でしか通じない専門用語を、一般的なタスクの言葉に置き換えます。

• 良い例：Choose the shot to edit
• 悪い例：Select output artifact、Bind manifest target

正確な操作用語やドメイン用語が、ユーザーの実際の作業に欠かせない場合は残します。ユーザーのタスクではなく実装モデルを反映している表現だけを取り除きます。ドメイン用語の補足が必要な場合は、作業の流れを妨げないよう、その場で説明します。

5. 状態と次のアクションを明確にする

どの段階でも、ユーザーが次のことに答えられるようにします。

• 今どこにいるか。
• 今、何を操作しているか。
• 今、何をすべきか。
• それを行うと何が起きるか。
• 実行後に何が変わったか。

インタラクティブなフロー（ドラッグ＆ドロップ、選択、移動、比較、注釈、複数選択）では、色だけに頼らず、現在の選択項目、移動元、移動先、結果を常に視覚的に区別します。形状、太さ、アイコン、テキスト、位置などを色と組み合わせ、色覚の違いやコントラストの低いディスプレイでも状態が分かるようにします。

6. 操作の負担を減らす

主要なアクションは、見つけやすく、手が届きやすく、操作しやすくしなければなりません（Fittsの法則）。

• よく使う操作対象は、入力デバイスに適した大きさにします。
• 密接に関連するコントロールは近くに配置します。
• 主な確定アクションは、確定対象の近くに配置します。
• 狭く、階層が深いホバー経路は避けます（Steering law）。
• 同時に提示する、同程度に目立つ選択肢の数を減らします。

ユーザーが作業を始める前に多くの選択肢を比較しなければならない場合は、選択肢を絞るか、段階的に提示します。

7. エラーを防ぎ、復旧を支援する

うまくいく場合だけでなく、間違いに強い設計にします。

• スリップ（意図は正しいが、操作を間違える）とミステイク（意図そのものが間違っている）を区別します。入力を制限してスリップを減らし、確認やプレビューによってミステイクを減らします。
• 破壊的な操作や取り消せない操作は視覚的に区別し、明示的な確認を求めます。
• 可能な場合は、入力時点で無効な状態にならないようにします（ポカヨケ）。
• 検証エラーは、概要欄だけでなく、原因となったコントロールの隣に表示します。
• 元に戻す、再試行、リセット、キャンセルを、操作後だけでなく操作中にも見つけやすく、実行しやすくします。
• 作り直しに多大なコストがかかる場合は、作業中の内容を安全に保持します。

8. 判断に最も役立つ結果を最初に示す

入力がそろったら、主要な結果または次の確認ポイントを最初に表示します。

• ユーザーが判断の基準にする結果を1つ特定します。
• 補足的な診断情報より上に配置します。
• 説明、前提条件、メタデータは後に回すか、折りたたみます。

9. 視覚的な構造を意図的に設計する

ゲシュタルト原則と視覚的階層を使って、ユーザーがテキストを読む前に構造を伝えます。

• 近接性と共通領域によって、関連するコントロールをグループ化します。
• 配置と一貫した間隔によって、視覚的なノイズを減らします。
• サイズ、太さ、コントラストによって、重要度を示します。
• 囲みと図地関係によって、アクティブな領域を背景のクロームから分離します。

画面上で最も重要な要素を、最も目立つようにします。

10. 最初からアクセシビリティを考慮して設計する

アクセシビリティは仕上げの工程ではなく、基本要件です。

• すべてのインタラクティブなコントロールに、アクセシブルな名前と視認できるフォーカスインジケーターが必要です。
• 主要なフローは、論理的な順序でキーボードだけを使って操作できる必要があります。
• 色による手がかりには、色以外の手がかりも組み合わせます。
• 少なくとも WCAG 2.1 AA のコントラスト基準を満たします。
• 動きや半透明表現で状態を伝える場合は、プラットフォームの視差効果低減と透明度低減の設定を尊重します。

11. 初めて使うユーザーの視点で画面を検証する

ユーザーがページを順にたどることで目的を達成できるかを検証します。

最低限、次の点を確認します。

1. 上から読んだり、視覚的な流れをたどったりして操作できますか？
2. 数秒以内に、この画面の目的がわかりますか？
3. 現在、何に対して操作しているかわかりますか？
4. 次にどの操作をすればよいかわかりますか？
5. 操作後に何が変わったかわかりますか？
6. 間違えた場合に元に戻せますか？
7. ユーザーには理解できない内部用語が表示されていませんか？
8. 標準的なビューポートサイズで、主要な UI に横スクロールが発生しませんか？
9. 幅を狭めたときに、はみ出し、クリッピング、予期しないテキストの折り返しが発生しませんか？
10. キーボードと視認できるフォーカス表示を使って、主要なフローを完了できますか？
11. グレースケール表示でも、すべての状態を示す手がかりが伝わりますか（色だけに依存した情報はありませんか）？

大きな GUI の変更を行う場合は、作業完了と判断する前にスクリーンショットを撮り、視覚的に確認します。標準幅と幅を狭めた状態の両方を抜き取りで確認します。

よくある修正

• セットアップを結果より上に移動します。
• セクション名をタスクに沿った表現に変更します。
• 空の状態を、明確な次の操作と例に置き換えます。
• 検証エラーを、問題のあるコントロールの近くに表示します。
• メタデータや詳細設定は、必要になるまで折りたたんでおきます。
• 色だけに頼らない、持続的な選択表示やソース／ターゲットの強調表示を追加します。
• 保存、適用、確認の操作を、変更を確定する対象のすぐ近くに配置します。
• ユーザーが現在行き詰まる箇所に、元に戻す、リセット、再試行の操作を追加します。
• タッチ操作で使う主要な操作のターゲットサイズを大きくします。
• アイコンだけのコントロールに、アクセシブルな名前または視認できるラベルを追加します。

手軽な評価方法

実際の失敗モードを明らかにできる、最も手軽な方法を選びます。

• ヒューリスティック評価 — Nielsen の 10 ヒューリスティクスまたは Shneiderman の 8 つのルールに照らして画面を評価します。手軽で、明らかな問題を見つけられますが、既知のパターンに偏りやすい方法です。
• 認知的ウォークスルー — 主要なタスクの各ステップについて、ユーザーは何をすべきかわかるか、どう操作すればよいか見てわかるか、フィードバックを理解できるかを確認します。
• 最初のクリック／初回利用テスト — 画面を初見のユーザーに見せ、最初にどこを見てクリックするかを観察します。
• 思考発話法 — 画面を操作しながら考えを声に出してもらいます。概念モデルと UI の食い違いが明らかになります。

UI が「直感的」だという抽象的な主張よりも、具体的な失敗例とスクリーンショットを重視します。

成果物に関する期待事項

変更点はユーザーにとってのメリットとして説明します。

• どのタスクが以前より簡単になったか。
• ユーザーが最初に何を見るようになったか。
• ユーザーが次に何をするようになったか。
• どのような混乱やエラーのリスクを取り除いたか。
• その説明を裏付ける証拠（スクリーンショット、ウォークスルーの結果、名前を挙げたヒューリスティックによる評価など）。

依頼されていない限り、エージェントはレポートの中心を内部のコンポーネント名にしてはなりません。