デザインギャラリーだけでなく意思決定を定義する
デザインシステムはスクリーンショット以上のものです。セクション間の余白、主要アクションの扱い、フォームエラーの動作、成功や失敗時の表現など、繰り返し現れる意思決定を記録します。USWDSはデザイントークンをタイポグラフィ、間隔、色、行間、高さ、不透明度などの値の離散的パレットとして説明しています。ルール、目的、承認されたバリアント、オーナーを文書化してください。基礎項目と、重要なジャーニーで使われる5〜8個のコンポーネントから始めましょう。すべてのページを一度に標準化しようとすると、明確さより雑音が増えることが多いです。
実際にサイトで使う承認済みの色の役割、書体、間隔、境界線、角丸、ブレークポイント、モーションの選択を記録してください。
単一の視覚的アクセントではなく、アカウント作成や検索結果などの繰り返し発生するタスク配置のためにパターンを定義してください。
繰り返し値を管理するためにトークンを使う
デザイントークンは、人間が読める名前とそれに対応する値の組です。Design Tokens Community Groupはトークンをプラットフォーム非依存でデザイン決定を表現する方法として説明しており、最小限ではトークンは名前と値です。color-action-primary や space-section のような目的ベースの名前を使い、テンプレート内に生の値を散在させないでください。目的用トークンとベース値の対応を文書化しておきます。トークンは協調した変更を容易にしますが、コントラスト、ブランディング、良い階層を保証するものではありません。レンダリングされた組み合わせとページ状態を検証してください。
例外すべてではなく繰り返しの選択のためにトークンを作成してください。さもないとトークン一覧が不一致をそのまま保存するだけになります。
広く使われるトークンでは影響を受けるページを列挙し、代表的な画面でテストし、必要に応じて移行やロールバックの指針を提供してください。
振る舞いと境界を持つコンポーネントを作る
コンポーネントは視覚的形状だけでなく振る舞いを持つ再利用可能なUIです。意味的構造、必須・任意の入力、バリアント、レスポンシブな振る舞い、読み込み、無効、エラー、空、成功などの関連するすべての状態を文書化してください。キーボード操作の挙動とコンテンツ指針も含めます。すべてのレイアウトを無理にコンポーネント化しないでください。GOV.UKは共有コンポーネントを有用性、独自性、使いやすさ、一貫性、多用途性で評価しており、これは共有メンテナンスに値するか判断する有益な基準です。広く再利用されるコンポーネントは欠陥も広く伝播する可能性があるため、利用されるページでのテストが重要です。
ユーザーに見える各状態を列挙し、実際のラベル、長いテキスト、エラーを示して実装上の制限が見えるようにしてください。
古いバリアントは明確にマークし、置き換えを名指しし、影響を受けるジャーニーをレビューした後でのみ削除してください。
アクセシビリティをリリース条件にする
アクセシビリティはシステムに組み込む必要があります。繰り返しの選択は障壁を繰り返す可能性があるからです。WCAG 2.2 は、レベルAで、移動経路が固有のものでない限り機能に対するキーボード操作を要求し、順序が重要な場合は意味のあるフォーカス順を要求します。コンポーネント指針には意味的なコントロール、可視フォーカス、ラベル、論理的なフォーカス移動、エラーの識別、非ポインタ操作でのタスク完了を含めてください。自動チェックを早期に使い、その後にキーボード、ズーム、レスポンシブ、ページ単位の手動テストを行ってください。USWDSは、アクセシブルなコンポーネントがサービス全体のアクセシビリティを保証するわけではないことに注意を促しています。カスタムコード、文言、統合、コンテキストは引き続きレビューが必要です。
マウスを使わずにコントロールに到達、操作、理解、離脱できること、キーボードトラップがないことを確認してください。
法的義務は管轄、契約により異なります。準拠が重要な場合は、資格あるアクセシビリティおよび法律のレビューを受けてください。
コンテンツ基準をインターフェース基準として扱う
言葉はデザイン後に付ける装飾ではなく、コンポーネントの入力です。アクションラベル、フォームラベル、エラー、見出し、リンク、用語、日付、数値、略語のルールを定めてください。GOV.UKの指針は可能な限り能動態でユーザーに対して「あなた（you）」で呼びかけることを好みます；明確で一貫した言葉遣いの原則を使いつつ、対象読者に合わせて声の調子を調整してください。ルールにはコンテンツモデルを組み合わせ、どのフィールドが必須か、妥当な長さの指針、情報が欠けているときに何が起きるかを明記します。指針はコンポーネント文書とCMSワークフローに置き、編集者が利用できるようにしてください。
何が失敗したか、どこで起きたか、そして安全かつ有用であれば次に取るべき行動を示してください。
上限は再設計や書き直しの合図であり、重要な意味を削る許可ではありません。
信頼が追いつく前にガバナンスを整える
ガバナンスは所有、要求、レビュー、リリース、廃止のための軽量なプロセスです。責任あるオーナーと、デザイン、エンジニアリング、コンテンツ、アクセシビリティの専門知識を持つレビューグループを名指ししてください。影響の範囲に応じて証拠を揃えます。ローカルなパターンは問題提起とページテストが必要なことがあります。共有ボタンやトークンの変更は、影響を受けるジャーニー、アクセシビリティチェック、視覚的比較、移行ノート、ロールバック手順を含めるべきです。GOV.UKは、寄稿者に対してコンポーネントが多くのチームにとって有用であること、重複でないこと、代表的なユーザーでテストされていることを示すよう求めています。これは普遍的な規則ではなく現実的なモデルとして利用してください。
問題、選択肢、決定、オーナー、影響バージョン、レビュー日をチームが検索できる場所に保存してください。
パッチ、追加、破壊的変更とラベル付けして、消費者が移行や互換期間の必要性を把握できるようにしてください。
リリース前に回帰を防ぐ
システムをデリバリに接続してください。変更には触れたトークンとコンポーネントの特定を必須にし、影響を受ける状態と代表的なページをテストします。視覚比較、インタラクションテスト、コンテンツレビュー、アクセシビリティチェックは異なる欠陥を検出します。トラフィックが少なくてもアカウントアクセスや問い合わせフォームは重要なことがあるため、重要なジャーニーと高トラフィックの両方を優先してください。これは Status Is UP のプロアクティブな稼働率最適化と修復作業を支援し、欠陥の範囲を狭め、承認済みの修正を検証しやすくします。これは稼働監視やインシデント計画の代替ではありません。
コンポーネントのバージョン、テスト結果、所見、承認、および受け入れたリスクをリリース記録に保持してください。
以前の安定版を保持し、低リスクの保守時に復元と検証手順を実際に試験してください。