業務システムのUI/UXデザイン標準とは？作り方と導入の5ステップ

業務システムの画面レビューで、こんな会話をしたことはないでしょうか。

🧑‍💼

レビュー担当

このボタン、もう少し目立たせたほうがいいと思うんですよね。

🧑‍💻

設計担当

……どのくらい目立たせれば正解なんでしょうか？

この往復が起きるのは、担当者の能力の問題ではありません。判断の基準がドキュメント化されていないからです。デザイン標準とは、この「正解がどこにあるか」を先に決めておく仕組みのことです。

デザイン標準は「見た目」ではなくコストの話

業務システムのUIは、コンシューマ向けサービスとは評価軸が違います。初見の印象より、1日8時間・数年にわたって使い続けたときの総コストで良し悪しが決まります。

デザイン標準が下げる3つのコスト

操作コスト：ボタン位置や一覧の並びが画面ごとに違うと、利用者は毎回探し直す
教育コスト：画面ごとにルールが違うと、マニュアルが画面数だけ必要になる
判断コスト：設計・レビュー・実装の各工程で、同じ議論を毎回繰り返す

特に見落とされやすいのが3つ目です。標準がないプロジェクトでは、画面ごとに「必須マークは赤い米印か、ラベル横の『必須』バッジか」を議論します。100画面あれば100回議論することになり、しかも結論が揃いません。

POINT

デザイン標準の価値は「きれいになること」ではなく、同じ議論を二度としなくてよくなることです。稟議を通すときも、この観点で説明したほうが通りやすくなります。

いきなり完璧なガイドラインを作らない

デザイン標準づくりが失敗する典型が、最初から100ページのガイドラインを目指してしまうケースです。完成前にプロジェクトが動き出し、結局使われないドキュメントが残ります。

✕ よくある失敗

全コンポーネントを網羅した資料を半年かけて作る。完成時点で実装と乖離しており、誰も参照しない。

◯ 現実的な進め方

「色」「フォーム」「一覧」の3つだけ先に決める。運用しながら、実際に揉めた論点だけを追記していく。

業務システムの画面は、突き詰めると 一覧画面・検索画面・入力画面・確認画面・ダイアログ の組み合わせでほぼ説明できます。この5つの型を決めるだけで、画面のばらつきの大半は消えます。

デザイン標準を作る5ステップ

現行画面を棚卸しして「ぶれ」を集める

既存システムのスクリーンショットを20〜30枚並べ、同じ役割なのに表現が違う箇所に印をつけます。必須マーク、日付書式、ボタンの並び順、エラー表示位置。この時点でリストは数十件になるはずです。

ここで重要なのは優劣を議論しないことです。まず「揃っていない」という事実だけを集めます。

デザイントークンを数値で決める

色・文字サイズ・余白・角丸・影を、名前と数値のセットで定義します。「濃い青」ではなく --color-primary: #23415a と書ける状態にします。

色は必ず役割名で定義してください。blue-600 ではなく primary、red-500 ではなく danger です。役割名なら後から色を変えても意味が壊れません。

フォーム・一覧・ダイアログの型を決める

操作時間の大半を占める3つを先に固定します。ラベル位置、必須表示、エラー表示位置、検索条件の並び、ページング方式、確認ダイアログの文言テンプレート。

この3つが決まれば、新規画面の設計時間は体感で半分以下になります。

チェックリスト化してレビューに組み込む

ガイドラインを読ませるのではなく、レビュー時に通すチェックリストに変換します。人は資料を読みませんが、チェック項目は埋めます。

当サイトの設計チェックリストをたたき台にして、自社の項目に置き換えるのが早道です。

改訂フローを決めて運用に載せる

標準は必ず例外に出会います。「例外を認めない」ではなく「例外を申請・記録する場所を決める」のが正解です。記録された例外が3件を超えたら、それは標準側を直すサインです。

最初に決めるべき10項目

時間がない場合、以下の10項目だけでも先に決めてください。画面のばらつきの体感8割はここで止まります。

#	決める項目	決め方の例
1	主ボタンの色と位置	primary色・フォーム右下に配置
2	必須／任意の表示	ラベル右に赤い「必須」バッジ、任意は無表示
3	ラベルの位置	入力欄の上に左揃え
4	エラーの表示位置	該当項目の直下＋画面上部にサマリ
5	日付の書式	`YYYY/MM/DD`（曜日は括弧書き）
6	数値の表示	3桁区切り・右揃え・単位は列見出しに
7	一覧の初期並び順	更新日時の降順
8	ページングの方式	ページ番号方式・1ページ50件
9	確認ダイアログの要否	取り消せない操作のときだけ表示
10	完了メッセージ	画面上部にトースト・件数を含める

注意

この10項目は「正解」ではなく「揃っていること」に価値があります。他社の事例をそのまま持ってくるより、自社の業務に合う選択肢を1つ選んで全画面に適用するほうが効果が大きいです。

標準が守られないときに疑うこと

標準を作っても守られない場合、原因はたいてい次の3つのどれかです。

ドキュメントが探せない場所にある

共有フォルダの深い階層にPDFで置かれている、というのが最悪のパターンです。設計者が日常的に開くツール（社内Wiki、リポジトリのREADME、Figmaのファイル）に置いてください。

ルールに理由が書かれていない

「必須マークは赤バッジ」とだけ書かれていると、納得できない人は従いません。「米印は視認性が低く、入力漏れの問い合わせが多かったため」と1行の理由を添えるだけで遵守率が変わります。

守るための実装コストが高い

標準どおりに作るのに毎回CSSを書き直す必要があるなら、守られないのは当然です。共通コンポーネントとして実装し、標準どおりに作るのが一番ラクな状態を作ってください。

まとめ

デザイン標準の目的は見た目の統一ではなく、操作・教育・判断コストの削減
完璧なガイドラインより、色・フォーム・一覧の3点を先に決める
ルールは資料ではなくチェックリストとしてレビューに組み込む
例外は禁止せず、申請・記録して標準の改訂に使う
「標準どおりが一番ラク」な実装環境をセットで用意する

次は、標準を作るときの判断軸になる原則をまとめた記事を読むと理解が早くなります。