エンジニアが自分でUIを設計する機会が最も多いのは、管理画面や社内ツールです。参考にできる公開事例が少なく、デザイナーのレビューも入りにくい領域ですが、幸い管理画面のUIは「定番パターン」がかなり固まっています。ゼロから考えるのではなく、パターンに沿って組むのが最短ルートです。
この記事では、管理画面の三大要素であるテーブル・フォーム・確認ダイアログの設計パターンを整理します。
テーブル設計：列の優先順位を先に決める
管理画面のテーブルでありがちな失敗は、DBのカラムをそのまま全部並べてしまうことです。列が10個を超えると横スクロールが発生し、肝心の情報が探せなくなります。設計の順序を逆にして、「ユーザーがこの一覧で何を判断するか」から必要な列を選びます。
- 識別列（名前・タイトルなど）を左端に置き、詳細画面へのリンクにする
- 判断に使う列（ステータス、更新日時など）を続け、列数は5〜7列までに絞る
- 数値は右揃え、テキストは左揃え。桁を揃えると比較しやすい
- IDや作成者などの補足情報は詳細画面に逃がす
空状態（Empty State）を設計する
見落とされがちなのが、データが0件のときの表示です。ヘッダー行だけが表示された空のテーブルは、ユーザーに「壊れているのでは」という不安を与えます。空状態には最低限、次の2つを入れます。
- 状況の説明：「まだユーザーが登録されていません」
- 次のアクション：「ユーザーを追加」ボタンをその場に置く
また、「検索結果が0件」の空状態は別物です。この場合は「条件に一致する結果がありません。検索条件を変更してください」と、フィルタ解除の導線を出します。初期0件と検索0件を同じ文言にすると、ユーザーはデータが消えたと誤解します。
フォーム設計：バリデーションの出し方で体験が決まる
フォームの使いやすさは見た目よりも、エラーの伝え方でほぼ決まります。定番のルールは次の通りです。
- エラーメッセージは該当フィールドの直下に表示する。ページ上部にまとめて出すだけでは、どこを直せばいいか分からない
- 「入力が不正です」ではなく「メールアドレスの形式で入力してください」のように直し方を書く
- 検証タイミングは「フォーカスが外れたとき」が基本。1文字打つたびに赤くするのは早すぎ、送信時にまとめて出すのは遅すぎる
- 送信ボタン押下後にエラーがある場合は、最初のエラーフィールドへスクロールする
必須項目の表現
必須マークは赤い「*」が広く使われますが、凡例がないと意味が伝わりません。実務では「必須」バッジをラベル横に付けるのが最も誤解が少ない方法です。さらに、フォームの大半が必須項目なら、発想を逆にして任意項目の方に「任意」と付ける方が画面がすっきりします。どちらの方式でも、1つのシステム内で統一することが重要です。
<label for="email">
メールアドレス
<span class="badge-required">必須</span>
</label>
<input id="email" type="email" required aria-describedby="email-error">
<p id="email-error" class="field-error" role="alert"></p>確認ダイアログ：本当に必要な場面だけに絞る
「本当に削除しますか？ OK/キャンセル」というダイアログは、乱発するとユーザーが読まずにOKを押す習慣がつき、肝心なときに機能しません。確認ダイアログは取り返しのつかない破壊的操作だけに限定します。
- ボタンのラベルは「OK」ではなく「削除する」など操作名にする。何が起きるかをボタン自体が語るようにする
- 破壊的操作のボタンは赤系にし、キャンセルを目立たない側に置く
- 対象を本文に明示する：「プロジェクト『A』を削除します。この操作は取り消せません」
- 影響が大きい削除（配下データも消えるなど）は、対象名の入力を求める方式も検討する
逆に、編集内容の保存やステータス変更のような可逆的な操作には、確認ではなく「元に戻す」手段（Undo、履歴）を用意する方がユーザーの負担は小さくなります。
まとめ
管理画面のUIは、テーブルは「判断に必要な列だけ＋空状態の設計」、フォームは「フィールド直下のエラー表示＋必須/任意の明示」、ダイアログは「破壊的操作限定＋操作名のボタンラベル」という定番パターンで大部分をカバーできます。凝ったデザインは不要です。ユーザーが迷わない・誤操作しない構造を、パターンの組み合わせで淡々と作ることが、管理画面デザインの本質です。
