ux-baseline-check

UX ベースラインチェック

役割と範囲

ADS の状態とコンポーネント契約を管理します。想像できるすべての状態ではなく、要求された動作とプロダクトの契約に基づいて状態を選択します。コピーや間隔の小さな変更では、影響を受ける動作を確認し、読み込み状態、フォーム、権限、追加画面を勝手に作り出さないようにします。ADS のタスク予算を使います。このインベントリは同じ作業／レビューの一部であり、別個の儀式ではありません。

重複の前にコンポーネント契約を確認する

新しい再利用可能なコンポーネントを導入したり、複製したりする前に、既存のコード、型、ストーリーから契約を把握するか、定義します。それらですでに答えが得られる場合は、別のドキュメントを必須にしません。

• 構造とコンテンツのスロット
• プロパティと意味のあるバリアント
• 適用されるデータ、インタラクション、バリデーション、読み込み、エラー、成功の各状態
• 対象ブレークポイントでのレスポンシブ動作
• キーボード、ポインター、タッチ、セマンティクスの動作
• 再利用する既存のコンポーネントとトークン

すべてのインスタンスが同じ契約に従う必要があります。この契約がないコンポーネントは、広く展開できる段階ではありません。

状態インベントリ

ページまたはコンポーネントを「完了」とする前に、該当する各状態が存在することを確認します。

1. データの状態

• 空 — まだデータがありません。画面を空白にせず、役立つメッセージと明確な CTA を表示します
• 読み込み中 — コンテンツの形状を保ち、実際に保留中の処理があることを示します。キャッシュ済みまたは高速なデータを、ローダー表示のために遅らせてはいけません
• 読み込み済み — 当然ながら、期待どおりの正常な状態です
• エラー — API の失敗やネットワークの問題です。ユーザーフレンドリーなメッセージと再試行アクションを表示します
• 一部読み込み済み — 一部のデータは読み込まれ、一部は失敗しています。正常に取得できたデータを隠してはいけません
• 長いコンテンツ — 200 件の項目や、2000 文字の名前ではどうなりますか？実際にテストします

2. インタラクションの状態

• ホバー — ポインターに適切なフィードバックを返します。タッチやキーボードでの利用をホバーに依存させてはいけません
• フォーカス — キーボードで操作でき、フォーカスリングが見えるようにします
• アクティブ／押下中 — ボタンをクリックすると、視覚的に反応します
• 無効 — ネイティブのセマンティクスと判読可能な状態を保ちます。必要な場合は、無効なコントロールにフォーカスしないと読めないツールチップではなく、近くの常時表示されるコピーで理由を説明します
• 選択済み — 複数選択、現在のタブ、アクティブなフィルターを、いずれも視覚的に区別できるようにします

3. フォームの状態

• バリデーション — タスクに適したタイミング（フォーカスが外れたとき、送信時など）で、フィールド単位のガイダンスを適切なタイミングで表示します。入力が完了する前に性急に拒否してはいけません
• 必須フィールド — 明確に示します
• 成功フィードバック — アクションが成功したことをユーザーが確認できるようにします（トースト、インライン表示、リダイレクトなど）
• 破壊的な操作からの復旧 — 元に戻せる操作では「元に戻す」を優先します。本当に取り消せない操作や重大な結果を伴う操作では、プロダクトの権限モデルを維持しながら確認を求めます
• 自動入力 — ブラウザーの自動入力でレイアウトが崩れないようにします

4. レスポンシブ

サポート対象のブレークポイントを使います。以下は幅の例であり、4 種類すべてのキャプチャが必須という意味ではありません。

• モバイル（375px） — 表示されるだけでなく、使いやすいこと。タッチターゲットは 48px 以上、間隔は 8px 以上にします
• タブレット（768px） — 単に縮小するのではなく、レイアウトを適応させます
• デスクトップ（1280px） — 主な対象として、意図が伝わる見た目にします
• ワイド（1800px 以上） — コンテンツが不自然に引き伸ばされないようにします。最大幅を設けるか、中央揃えにします

5. アクセシビリティ

• キーボード操作 — Tab キーですべてのインタラクティブ要素に移動できます
• スクリーンリーダー — セマンティックな HTML、アイコンの aria-label、画像の alt テキストを使用します
• 色のコントラスト — 最終的に合成された色を、該当するテキスト／コントロールの要件に照らして測定します。不透明度の割合だけでコントラストを満たすと判断してはいけません
• 色だけに頼らない表示 — ステータスを赤／緑だけで示してはいけません

6. エッジケース

• 初回利用者 — オンボーディングまたは空の状態でガイドします
• 権限不足 — 壊れたページを表示するのではなく、アクセスできない理由をユーザーに示します
• 古いデータ — データが古くなっている可能性がある場合は、タイムスタンプまたは更新インジケーターを表示します
• 同時編集 — 2 人が同じものを編集した場合、どうなりますか？

隣接アクションとの一貫性

読み取り専用、無効、オフライン、権限制限、または破壊的な状態を変更した場合は、影響を受けるブレークポイントで、近くにあるすべての主要アクション、二次アクション、ツールバーアクション、インラインアクションを確認してください。ラベル、強調表示、有効状態、ネイティブのセマンティクス、補足テキストは、その状態と一致している必要があります。矛盾がある場合は、影響を受けない状態で有効なアクションを維持しつつ、削除、無効化、ラベル変更、または説明を行ってください。修正後に再度確認してください。指定されたコントロールだけを修正しても不十分です。

ADS パスでの使用

実装前に該当する状態を特定し、設計の合否を判断する前に検証してください。フォームの小さな変更でも、関連するフォームおよびアクセシビリティの確認が必要です。一方、静的ページに、実在しない非同期状態を作り出す必要はありません。必須の状態が欠けている場合は未解決のままとし、機能が完成したと主張できないようにしてください。入手できない証拠や意図的な製品上の先送りは、合格とは別に記録してください。意味のあるインタラクションの変更では、該当する場合、対象となるモバイル／WebKit 環境も含めて、実際のブラウザーを使用してください。ソース文字列やスクリーンショットだけでは、状態遷移が確認できたことにはなりません。