この記事の内容
あやね
カタログはデザインシステムの場所を教えます。コンポーネントレビューは、そのルールが実際の画面に役立つかを確かめます。ここでは文書化されたコンポーネント判断を作る4つの演習を紹介します。ユーザビリティテストの報告書や製品全体の適合判定ではありません。
1. コンポーネントレビューシートを用意する
繰り返しの手戻りを生む実画面とコンポーネントを1つ選び、例を見る前にユーザータスク、プラットフォーム、コンテンツ、現在の問題を記録します。
- タスクと文脈：何をする人が、どこでコンポーネントを見るか。
- 必要な状態：該当するdefault、focus、active、disabled、loading、empty、error。
- コンテンツ：短い・長いラベル、翻訳文字列、現実的なデータ。
- 証拠：公式コンポーネントガイドのリンク、確認したバージョンやパッケージ。
- 判断：使う、適応する、却下するのいずれかと、理由、実装レビュー責任者。
2. 4つのコンポーネント演習を行う
Material：ボタンの状態を明確にする
対象プラットフォームのMaterial Designでボタンガイドを開き、画面の主操作と副操作を特定します。デフォルト形状を写すだけでなく、実際に必要な状態を作ります。
成果物：ラベル、強調、フォーカス、ローディング挙動を含む状態シート。翻訳後の長いラベルや隣接する操作でも意味が保てるか確認します。
Polaris：入力とフィードバックを確認する
対象のShopify面に対応するPolaris Web Components公式ドキュメントを使います。入力欄を選び、ラベル、説明、検証メッセージ、送信結果を分けます。
成果物：ready、invalid、submitting、successの小さなフォーム。選んだコンポーネントが提供する挙動と、アプリが実装する挙動を分けます。アクセシビリティガイダンスは評価を支えますが、完成フォームの適合を保証しません。
Apple HIG：プラットフォームの期待を保つ
Apple Human Interface Guidelinesでナビゲーションや選択の関連項目を読みます。独自コントロールをプラットフォーム慣習と比べ、逸脱が必要な理由を書きます。
成果物：注釈付きの2案と、タスクに基づく判断。大きな文字設定や対応入力方式を含め、スクリーンショットを完全な操作仕様と扱わないでください。
Fluent：対象プラットフォームとテーマを見る
Fluent 2のコンポーネントとプラットフォーム資料を確認し、画面のコンテンツ、状態、テーマ要件と比べます。全デバイスに一つの見た目を適用しません。
成果物：対応テーマのコンポーネント例に、フォーカス、コントラスト、コンテンツあふれを注記します。実装パッケージが対象プラットフォームに合うか確認します。
3. デザインとエンジニアリングで適応をレビューする
- レビュー者が判断を確認できるよう、元の公式資料リンクをコンポーネントの横に置く。
- デフォルト寸法を受け入れる前に、現実的なデータと長いラベルで試す。
- 提案した状態と実装で利用できる挙動を比べ、欠けている挙動を視覚変更と分けて記録する。
- 実装済みコンポーネントのキーボードと支援技術をレビューする。デザインファイルだけでは適合を証明できない。
- 例外とレビュー日を記録し、後の更新でローカル適応が壊れないようにする。
4. 共有Pixsoファイルで演習を保つ
Pixsoワークスペースに元画面、コンポーネントのバリエーション、レビュー記録をまとめます。再利用可能なコンポーネントと共有レビューで判断を見えるようにし、チーム全体へ拡張する前にライブラリ権限とプランの上限を確認します。
明確なコンポーネント名を使い、開発者が実装すべき状態を注記します。共有スタイルは視覚ルールを保てますが、製品が変わる間も所有者、文書、テストは必要です。
5. 出力を小さくレビュー可能にする
1つのコンポーネント判断、状態シート、元リンク、未解決の質問で終えます。実製品で機能してから拡張し、未検証の魅力的な画面集を増やさないようにします。
広い候補を探すなら公式デザインシステム資料ディレクトリへ戻ります。このページは場所と内容の探し方ではなく、コンポーネントの調べ方に集中しています。
