管理画面は、社内の人が毎日何十回も触るものです。1回あたり3秒の迷いが、年間では相当な時間になります。それでいて、デザインに時間をかけてもらいにくい領域でもあります。
この記事では、時間をかけずに効く定番のパターンを、実際に作例を作って比較します。テーブル・確認ダイアログ・フォームの3つです。
テーブルは「比べられる」ことが仕事
列も件数もデータも同じです。変えたのは並び・揃え・表記だけです。
数値は右揃え・等幅・桁区切り
いちばん効くのがこれです。128000 と 1240500 が左揃えで並んでいると、桁数を数えないと大小が分かりません。
.num {
text-align: right;
font-variant-numeric: tabular-nums; /* 数字の幅を揃える */
}tabular-nums は、多くのフォントで既定になっている「文字ごとに幅が違う数字」を、すべて同じ幅にする指定です。これがないと、右揃えにしても桁の位置が微妙にずれます。
右揃え・等幅・桁区切りの3つが揃うと、縦に読むだけで桁の違いが分かります。
探すための列を左端に置く
Before では ID が左端にありました。ユーザーがIDで探すことは、ほとんどありません。探すときの手がかりは顧客名や件名です。
After では顧客名を左端に置き、IDはその下に小さく添えました。必要なときには見えるが、視線の入口は占領しないという扱いです。
列の順番は「探す → 判断する → 操作する」の順にすると自然になります。識別する列、状態や金額、そして右端に操作、という並びです。
日時は用途に合わせて削る
2026-09-08 14:23:41 の秒が必要な場面は、一覧ではまずありません。19文字が横幅を占領し、視線が右へ流れるのを邪魔します。
After では「9/8 14:23」に短縮し、下に「3時間前」を添えました。相対表記は「最近かどうか」を計算せずに判断できます。一方で相対表記だけにすると正確な日時が分からなくなるので、両方出しています。
年は、当年なら省略していい情報です。今年のデータばかりの一覧で「2026」を全行に出す意味はありません。
ステータスは翻訳して、色をつける
paid pending canceled はDBの値であって、画面に出す文字ではありません。実装の都合がそのまま漏れている状態です。
日本語にして、色つきのバッジにすると、読まずに形と色で判別できます。ただし色だけに頼ると区別できない人がいるので、必ず文字も入れます。
確認ダイアログは、押す前に判断できるか
「本当に削除しますか？」だけのダイアログには、判断に必要な情報が1つも入っていません。
結果として何が起きるかというと、ユーザーは読まずにOKを押すようになります。毎回同じ文言で、毎回OKで問題なかったからです。そうなると、この確認は事故を防ぐ機能を失い、クリックを1回増やしているだけになります。
確認ダイアログに入れるべきものは4つです。
- 何が対象か
「請求書 #8842」のように具体的に。一括操作なら件数も - 他に何が巻き込まれるか
「明細3件と送付履歴2件も削除されます」 - 取り消せるかどうか
取り消せないなら明示する - 代わりの手段があるか
「削除ではなくキャンセル扱いにできます」
ボタンの扱いも重要です。危険な操作のほうを既定にしない。Beforeでは「OK」が塗りつぶしで、Enterキーでも実行されます。Afterではキャンセルを通常のボタンにして、削除は赤で、しかも確認入力をしないと押せないようにしました。
この「番号や名前を入力させる」方式は、反射で押せなくするためのものです。取り返しのつかない操作にだけ使います。全部に付けると、ただ面倒なだけの画面になります。
そもそも確認しない、という選択
実は、いちばん良い設計は確認を出さずに、取り消せるようにすることです。
削除したら即座に消すのではなく、「削除しました [元に戻す]」という通知を数秒出す。実データは論理削除にしておき、一定期間後に消す。この形なら、確認ダイアログは要りません。
「確認させる」より「やり直せる」ほうが、操作は速く、事故は減ります。確認ダイアログは、取り消しの仕組みを作れない場合の次善策と考えるのが実際のところだと思います。
絞り込みと一括操作
一覧画面が実用になるかどうかは、目的の行にたどり着けるかで決まります。ここも定番の形があります。
条件をURLに載せる
絞り込み条件は、コンポーネントの状態ではなくURLのクエリパラメータに持たせます。
/orders?status=pending&from=2026-09-01&q=サンプル&page=2これだけで、いくつもの問題が同時に解決します。
- リロードしても条件が残る
管理画面では致命的に効きます - URLを人に送れる
「この条件の一覧を見てほしい」が1行で済みます - 詳細画面から戻ったときに条件が生きている
ブラウザの戻るがそのまま使えます - ブックマークできる
3つ目が特に大きいです。1件ずつ確認して戻る、という作業を繰り返すとき、戻るたびに条件がリセットされる画面は使い物になりません。
いま何で絞られているかを見せる
絞り込みがフォームの中に隠れていると、「0件です」と出たときに、条件のせいなのかデータが無いのか分かりません。
適用中の条件を、一覧の上に外せるタグとして並べます。「未入金 ×」「2026/09/01以降 ×」のように見せて、その場で外せるようにします。「すべて解除」も添えておくと、迷子から復帰できます。
一括操作は「何件に効くか」を先に出す
チェックボックスで複数選択して一括処理する機能では、事故の規模が大きくなります。1件の削除と100件の削除が、同じ手数で実行できてしまうからです。
- 選択数を常に表示する
「3件を選択中」を操作バーに出す - 「全選択」の意味を明示する
ヘッダーのチェックボックスは表示中の20件なのか、条件に一致する全1,284件なのか。ここを曖昧にしない - 確認ダイアログに件数を入れる
「3件を削除します」と「1,284件を削除します」では、手が止まります - 部分的な失敗を報告する
100件中3件が失敗したとき、どれが失敗したかを出す
2番目は実際によく混乱するところです。「表示中のものだけ選択しました。条件に一致する1,284件すべてを選択しますか？」という一段を挟む形が、分かりやすさと安全性のバランスが取れています。
フォームは「いつ検証するか」を決める
管理画面のフォームで多いのが、送信ボタンを押して初めてエラーが出る作りです。長いフォームだと、上まで戻ってどこが悪いか探すことになります。
| タイミング | 向いているもの |
|---|---|
| 入力中 | 文字数カウント、使える文字の制限。エラーを出すのは早すぎる |
| 入力欄から離れたとき | 形式のチェック（メール、日付、数値の範囲） |
| 送信時 | サーバー側でしか判定できないもの（重複、権限、在庫） |
入力中にエラーを出すのは避けたいところです。メールアドレスを打ち始めた瞬間に「形式が正しくありません」と出るのは、正しいけれど不快です。まだ入力が終わっていないので当たり前です。
逆に、一度エラーになった項目は、入力中に再検証して構いません。直した瞬間にエラーが消えると、直ったことが分かります。
エラーは項目の隣に出す
画面上部にまとめて「入力に誤りがあります」と出す形式は、どの欄が悪いかを探す作業を利用者に押しつけています。該当する入力欄の直下に、その項目のエラーだけを出します。
APIから項目ごとのエラーが返ってくれば、そのまま各欄に配れます。API設計の記事で「バリデーションエラーは項目ごとに返す」と書いたのは、これが理由です。APIの設計が、そのまま画面の作りやすさに効いてきます。
入力内容を失わせない
管理画面で起きるといちばん恨まれるのがこれです。
- 送信エラーで入力内容が消える
サーバーエラーのときこそ、値を保持する - セッション切れで消える
長いフォームでは、下書きを自動保存する - 誤って画面を離れる
未保存の変更があるときは離脱を確認する
どれも「起きたときに困る度合い」が大きいわりに、実装は難しくありません。フォームが長いほど優先度が上がります。
まとめ
- 数値は右揃え・等幅・桁区切り
比べられないテーブルは仕事をしていない - 探すための列を左端に
IDは補助情報に降格させる - 日時は削る
秒は要らない。相対表記を添える - DBの値をそのまま出さない
日本語にして、色と文字の両方で示す - 確認ダイアログには対象・影響・取り消し可否・代替手段を書く
危険なほうを既定にしない - いちばんいいのは確認せずに取り消せること
ダイアログは次善策 - 検証は入力欄から離れたときに
エラーは項目の隣に出す - 入力内容を失わせない
長いフォームほど効く
次に読む記事
