design-better-interfaces

より優れたインターフェースの設計

インターフェースを、ひとまとまりの製品ワークフローとして捉えます。この品質ゲートを、設計上の判断と完了判定における唯一の基準として使用します。見た目を改善する前に、タスク、情報、状態、動作を維持してください。

現在の環境で利用できる検査、レンダリング、ブラウザー、スクリーンショット、アクセシビリティ、テストの各機能を使用してください。

リクエストを振り分ける

次のいずれかの分岐を選び、その手順に従ってください。

• レビューまたは診断： ブリーフ → 検査 → マッピング → 状態／リスク → 検証 → 報告。 成果物は変更しないでください。該当するすべてのゲートを合格、不合格、または未検証として示し、ユーザーへの影響が大きい順に調査結果を並べて完了します。
• 設計または検討： ブリーフ → 成果物がある場合は検査 → マッピング → 決定 → 状態／リスク → 報告。 特に指定がなければ、一貫性のある方向性を1つ提示します。依頼された代替案は、階層、インタラクション、またはレイアウトに実質的な違いを持たせます。トレードオフを明確にし、ユーザーが中立的な比較を求めていない限り、推奨する方向性を1つ示して完了します。
• 構築、改良、または修正： ブリーフ → 検査 → マッピング → 決定 → 状態／リスク → 実装 → 検証 → 報告。 依頼された範囲が実装され、テスト条件下で主要なタスクが成功し、該当するすべてのゲートに根拠があることを確認して完了します。合格結果を妨げる外部要因があれば報告します。

外部への公開は、ユーザーから明示的な依頼があった場合にのみ行う別個の作業として扱います。

1. ブリーフを確立する

入手可能な根拠から、次の事項を明らかにします。

• ユーザー、主要なタスク、実行頻度、エラーのコスト、目に見える成功の基準；
• ドメイン、ブランド、トーン、想定される情報密度、注意力の予算；
• 影響を受ける画面、対象サイズとプラットフォーム、入力方法、テーマ、デザインシステム、技術的制約；
• データの状態、権限、コンテンツの極端なケース、リアルタイムまたは時間制限のある動作。

質問する前に、製品とリポジトリを調査します。選択肢の不足によって製品が大きく変わる場合は質問し、それ以外の場合は妥当な仮定を明示します。

すべての項目が解決済み、不該当、または明示的な仮定によって扱われていれば、この手順を完了します。

2. 製品を検査する

既存の製品の場合：

1. プロジェクトの指示を読み、影響を受けるフローを実際にたどります。
2. トークン、コンポーネント群、タイポグラフィ、間隔、情報密度、ナビゲーション、用語、インタラクション、プラットフォームごとのバリエーションを洗い出します。
3. 関連する画面サイズで、現実的なデータを使ってレンダリング済みのベースラインを記録します。
4. 観察された問題を、ユーザーに見える形で説明します。

適切な慣例は再利用します。アクセシビリティに問題がある、または有害な慣例は、一貫性を保てる最も近い代替案に置き換えます。

新規開発のインターフェースでは、対象ユーザー、ドメイン、コンテンツ、タスク、想定される情報密度からビジュアルの方向性を導きます。

現在のフロー、適用可能な慣例、観察された問題、ベースラインが記録されていれば、この手順を完了します。環境でレンダリングを生成できない場合は、未検証として示します。新規開発の場合は、ブリーフに基づく方向性が定まり、既存成果物の確認項目が該当なしとして示されていれば完了です。

3. マップの保持とサーフェス

既存のインターフェースを変更する前に、保持に関する契約を作成します。

• 判読可能な状態を保つ必要がある情報と階層。
• 同等性を保つ必要があるタスク、インタラクション、ショートカット、代替の エントリーポイント。
• ユーザーが頼りにしている安定した位置や形状。
• 変更後も維持すべき製品の規約と意味上の定義。

影響を受けるすべてのサーフェスを、以下の観点で整理します。

• ページ、繰り返し表示される行、ツールバー、メニュー、ダイアログ、バナー、 ツールチップ、ポータル、オーバーレイ、埋め込みコンテンツやサードパーティの コンテンツ。
• 小、中、大のサイズ。サポート対象のプラットフォームとテーマ。
• ポインター、キーボード、タッチ。
• 通常、長文、空、読み込み中、エラー、古い、無効、権限による制限、 選択済み、折りたたみ、フィルタリング済み、ページネーション済みの状態。

大規模な刷新、オーバーレイ、カスタムコントロール、レスポンシブ対応やクロスプラットフォーム対応、 ライブ状態や時間制限のある状態、フィルタリング／折りたたみ／ページネーションに取り組む場合は、 references/interface-failure-checklist.md の該当セクションを読み、適用します。

すべての契約項目について検証方法が計画され、該当するすべてのサーフェスと状態の組み合わせが 列挙されているか、明示的に除外されていれば、このステップは完了です。

4. 品質ゲートに基づいて判断する

以下の優先順位を適用します。

1. ユーザーが主要なタスクを完了できる。
2. 状態、階層、次のアクションが明確である。
3. リスク、失敗、復旧、可逆性が正直に表現されている。
4. 結果が製品およびデザインシステムと一貫している。
5. サポート対象のサイズ、入力方法、テーマ、プラットフォームで、アクセシブルかつ堅牢である。
6. 空間的な安定性とランタイムのパフォーマンスが保たれている。
7. ビジュアルの仕上がりが意図的で、対象領域に適している。

優先度の低い改善は、優先度の高い基準をすべて満たした状態でのみ採用できます。

主要な成果を中心にインターフェースを構成します。

• 決定的な状態と、次に行う可能性が高いアクションを見つけやすくします。
• 補足情報の比重を下げ、関連する代替手段を選べる状態で、適切なデフォルトを提示します。
• タスクの複雑さにインターフェースの複雑さを合わせます。比較には表、直線的な作業には手順、 空間的な作業には空間的なサーフェスを使用します。
• 圧縮より理解しやすさを優先します。ラベルを短くしたり、文脈を隠したりする前に、 意思決定に影響しない情報を取り除きます。
• 補足的な詳細は段階的に提示し、なじみのないアクションにはラベルを付けます。
• ホバー、選択、ライブ更新の間、繰り返し表示されるターゲットの位置を安定させます。
• 装飾的な要素は、階層、状態、アフォーダンス、コンテンツ、ブランドの意味を支える場合にのみ使用します。

主要な成果、アクションの階層、情報構造、コンポーネント戦略、レスポンシブな動作、ビジュアルの根拠が 明確で、ブリーフと保持に関する契約の両方に一貫して沿っていれば、このステップは完了です。

5. 状態、遷移、リスクを定義する

該当するすべてのライフサイクル状態を考慮してください。初期、データあり、読み込み中、進行中、空、初回利用、一部表示、古いデータ、オフライン、検証、エラー、再試行、復旧、成功、無効、権限による制限、競合、楽観的更新、ロールバック、キャンセル、有効期限切れ、アンマウントです。

各表示条件について、唯一の信頼できる所有者を定め、描画、レイアウト、アクセシブルな説明、副作用が同じ導出結果を使用するようにしてください。複数のステータスが競合する場合の優先順位を定義してください。ドメイン状態、対応が必要な状態、装飾は概念上分離してください。

すべてのコントロールに定義済みの動作を与えてください。操作が確定した後に成功を表示してください。下書き、プレビュー、保存済み、適用済み、公開済み、一部完了、失敗の状態を区別してください。フィルター、ページネーション、折りたたまれたグループを使っても、アクティブな項目にアクセスできるようにしてください。空状態は、描画された範囲だけでなくドメイン上の真の状態から導出してください。

各変更を、影響範囲、結果、可逆性によって分類してください。

• ローカルで可逆な操作は直接適用し、実用的であれば取り消しも可能にしてください。
• 影響範囲が広くても可逆な変更では、対象範囲を明示し、確認できるようにしてください。
• 破壊的、高コスト、外部から見える、または元に戻すのが困難な操作の前には、正確な対象、現在の影響範囲、結果を示し、状況に応じた確認を必須にしてください。
• 警告には、実行可能な復旧方法または明示的な続行手段を用意してください。

すべての主要な操作について、担当箇所、遷移先、フィードバック、終了経路、失敗時の動作、復旧経路、検証可能な最終状態が揃い、適用しない状態にはそれぞれ理由が示されていれば、このステップは完了です。

6. 垂直スライスを実装する

要求された範囲を通じて、利用可能な経路を1つ完成させてください。

• トークン、コンポーネント、プロダクトの用語、インタラクションのセマンティクスを再利用してください。
• ある操作へのすべての入口に、同じ利用可否と権限のガードを適用してください。
• セマンティックな構造、入れ子にしないインタラクティブなロール、アクセシブルな名前、キーボード操作、視認できるフォーカス、十分なコントラストとターゲットサイズ、モーション低減、読みやすい文字を使用してください。
• 連続する各サーフェスについて、背景、境界線、シャドウ、ぼかし、クリッピング、安全領域の動作を一元的に担う箇所を1つ定めてください。共有プリミティブがその役割を引き継いだら、古いローカルの補正を削除してください。
• オーバーレイをシステムとして扱ってください。アンカー、幅、衝突、クリッピング、フォーカス、Escape、外側のクリック、スクロール、背後のコンテンツの隠れ方を考慮してください。
• 名前付きブレークポイントだけでなく、中間の幅でもクリッピング、重なり、はみ出し、レイアウトシフトを防ぐレスポンシブ制約を定義してください。
• 要求された範囲内で、現実的なコンテンツ、長い文字列、空のデータ、極端な値、ローカライズによる文字数の増加を試してください。

通常の経路と、前のステップで定義した該当するすべての例外状態について、主要なタスクがコード上で動作すれば、このステップは完了です。

7. レンダリング結果で検証する

利用可能な最も強力な機能を使い、レンダリングされた成果物から視覚的な品質を判断します。静的チェックだけでは、視覚的な品質、レスポンシブ動作、インタラクションの正しさは証明できません。

製品でサポートされているビューポートを使用します。定義されていない場合は、CSS ピクセルで 375、768、1440 ピクセルと、各レイアウト遷移付近の中間幅を確認し、320 ピクセルで水平方向のオーバーフローをチェックします。

完了する前に、次のことを行います。

1. 同じデータ、ビューポート、テーマを使って変更前と変更後を比較します。
2. サポートされているすべての入力方法で、主要なフローを最後まで実行します。
3. 該当するすべての状態、遷移、逆操作、リスクの高い変更を確認します。
4. 階層、配置、間隔、クリッピング、重なり、折り返し、フォーカス、ホバー、アクティブ、無効、スクロール動作、空間的な安定性を確認します。
5. コンテンツの極端なケースも含め、小・中・大の幅でテストします。
6. 該当する場合は、アクセシブルな名前、フォーカス順、コントラスト、セマンティクス、動きを抑える設定、強制カラーモード、プラットフォームまたはブラウザーのフォールバックを確認します。
7. オーバーレイは、トリガーおよび背後のコンテンツとあわせて確認します。
8. 同系統のコンポーネントについて、形状、見た目のサイズ、動作、トークンのずれを監査します。
9. 実行時エラーを確認し、関連するビルド、型、lint、テストの検証を実行します。

視覚的な変更にはスクリーンショットを、動きや時間に依存する動作には短い録画を、プラットフォーム依存の作業には対象デバイスでの証拠を使用します。対象ハードウェアまたはサポート対象ブラウザーが利用できない場合は、成功したと推測せず、unverified と記載します。

該当するチェックはそれぞれ、合格、失敗、未検証として記録します。未検証のチェックについては、可能な範囲で最も近い確認を行い、制約を明記します。

すべての保持項目と、該当するすべての画面・状態の組み合わせに証拠がそろったら、このステップは完了です。対象範囲内の失敗は修正するか、ブロッカーとして報告します。レビューで見つかった問題は、優先度を付けた指摘事項にまとめます。

8. 証拠を報告する

結果を冒頭に記載します。変更または発見したこと、確認された問題、重要な設計上の選択、影響を受けた画面またはファイル、保持項目の結果、合格したチェック、失敗または未検証の項目を明記します。

報告だけで内容が完結し、残る不明点すべてに未確認であることが示され、現在のタスクでまだ実行可能な検証がすべて行われたら、このステップは完了です。