デザインシステムの運用｜命名・レビュー・改訂フローの作り方

デザイン標準づくりで最も多い失敗は、作れないことではなく 作った後に使われないこと です。ここでは、標準を運用に載せるための仕組みを扱います。

誰が持つのかを決める

最低条件

体制の形はどれでも構いませんが、「この標準の変更を承認する人が誰か」が明確であることだけは必須です。ここが曖昧だと、議論が止まった場所で標準も止まります。

コンポーネント名が設計書・デザインツール・実装で食い違うと、会話のたびに翻訳が発生します。

命名の原則

人はガイドラインを読みません。したがって、読まなくても守れる導線を作ります。

最も強力な方法です。共通コンポーネントを提供し、標準どおりに作るのが一番ラクな状態にします。生の色コードを禁止するLintルールを入れると、逸脱が物理的に減ります。

設計レビューのアジェンダにチェックリストを組み込みます。「良い／悪い」ではなく「標準に適合しているか」で会話することで、指摘が個人攻撃になりません。

新規画面を作るとき、白紙から始めさせない。一覧画面・入力画面・確認画面のテンプレートを用意しておけば、標準は自動的に引き継がれます。

ベンダー開発の場合

発注仕様書に「画面は本デザイン標準に準拠すること」と明記し、標準そのものを添付してください。検収条件に含めておくと、後から直す交渉が不要になります。

標準は必ず例外に出会います。例外を認めない運用にすると、現場は標準を無視するという形で例外を作ります。

例外申請の最小フォーマット

同じ理由の例外が3件たまったら、それは標準側を直すべきサインです。例外の蓄積を、標準の改訂トリガーとして扱ってください。

標準にもバージョン番号を付け、変更履歴を残します。「いつから変わったのか」が追えないと、既存画面が違反なのか旧版準拠なのか判別できません。

説明のコツ

経営層への報告では、見た目の統一ではなく「設計工数の削減」「問い合わせ件数の減少」「教育期間の短縮」で語ってください。デザイン標準への投資が継続されるかは、この翻訳ができるかで決まります。

使われていないコンポーネントはないか

利用率が極端に低い部品は、要件に合っていないか、存在が知られていないかのどちらかです。削除するか、周知し直すかを判断します。

ドキュメントと実装がずれていないか

最も起きやすい劣化です。実装のほうが先に進むため、定期的に突き合わせる時間を確保してください。理想は、実装からドキュメントを自動生成する仕組みです。

標準に載っていない判断が増えていないか

レビューで毎回同じ議論が出ているなら、その論点は標準に追加すべきです。「二度議論した論点は標準に書く」というルールを持っておくと、標準は自然に育ちます。