「削除」と「保存」が同じ見た目で隣り合っている画面は、いつか必ず事故を起こします。ボタン設計は美観の問題ではなく、誤操作の確率を構造的に下げるための設計です。
ボタンの4分類
| 種別 | 見た目 | 用途 | 1画面あたり |
|---|---|---|---|
| Primary（主） | 塗りつぶし・アクセント色 | その画面の主目的（登録・検索・承認） | 原則1つ |
| Secondary（副） | 枠線のみ | 補助操作（キャンセル・下書き保存・条件クリア） | 複数可 |
| Tertiary（テキスト） | 文字のみ | 影響の小さい操作（詳細を表示・すべて選択） | 複数可 |
| Destructive（破壊的） | 赤系・枠線または塗り | 取り消せない操作（削除・締め処理） | 必要な数だけ |
主ボタンが2つある画面は、その画面の目的が2つあるということです。まず画面の目的を1つに絞れないか検討してください。どうしても2つ必要なら、片方をSecondaryに落とします。
配置の標準
フォーム画面
実行ボタンはフォームの右下。左に副操作、右に主操作を置きます。
［キャンセル］［下書き保存］ ［登録する］（右端・Primary）
［登録する］［削除］が同じ大きさで隣接。Tab移動でも隣り合い、押し間違いが起きる。
削除ボタンの置き場所
削除は主要導線から物理的に離すのが原則です。
- 実行ボタン群とは反対側（左端）に置く、または画面下部の別区画にまとめる
- 一覧の行内では、アイコンのみにせず「削除」の文言を添える
- 削除の直後は必ず取り消し導線（Undo）か、復元可能な論理削除にする
- Tab移動の順序で、保存ボタンの直後に削除ボタンが来ないようにする
ラベルの書き方
ボタンのラベルは「押すと何が起きるか」を動詞で書きます。
| ✕ 避ける | ◯ 推奨 | 理由 |
|---|---|---|
| OK | 登録する / 承認する | 何が起きるか分からない |
| はい / いいえ | 削除する / キャンセル | ダイアログ文を読まないと判断できない |
| 送信 | 承認申請を送信 | 何を送るのか不明確 |
| 実行 | 一括承認する（12件） | 対象と件数が見えない |
| 閉じる | 保存せずに閉じる | 変更が失われることが伝わらない |
確認ダイアログの選択肢を「はい／いいえ」にすると、質問文が否定形のときに意味が反転して事故ります。常に動詞ラベルにしてください。
状態の設計
ボタンには最低でも6つの状態があります。すべてトークンとして定義し、実装をコンポーネント化します。
- 通常（default）
- ホバー（hover）：わずかに濃くする、影を強める
- フォーカス（focus-visible）：必ずリングを表示。キーボード操作の生命線
- 押下中（active）：少し沈む表現
- 無効（disabled）：コントラストを下げる。ただし理由の提示が必要
- 処理中（loading）：ラベルを「登録中…」に変え、二重押下を防ぐ
無効化には理由を添える
承認ボタンがグレーアウトしているだけ。なぜ押せないのか分からず、問い合わせが発生する。
ボタン下に「承認するには金額の入力が必要です」と表示、またはホバーで理由をツールチップ表示。
必須項目が埋まるまで送信ボタンを無効化する設計。何が足りないか分からないまま押せない状態になり、利用者は行き詰まります。ボタンは押せる状態にしておき、押したときにエラーで具体的に伝えるほうが親切です。
処理中の表現
1秒未満
何も出さない。ローディング表示が一瞬ちらつくほうが不快です。
1〜3秒
ボタン内にスピナー、ラベルを「処理中…」に変更。ボタンは無効化します。
3〜10秒
画面全体または対象領域にオーバーレイを表示し、他の操作を止めます。「処理中です。画面を閉じないでください」と明記します。
10秒以上
非同期処理に切り替え、画面を解放します。完了は通知またはメールで知らせ、進捗（○件／全△件）を表示します。
サイズとタップ領域
- 標準ボタンの高さは 36〜40px（業務システムの密度なら36pxが扱いやすい）
- クリック可能領域は最小 32×32px 以上を確保する
- タブレット併用の画面では 44×44px 以上にする
- アイコンのみのボタンには必ず `aria-label` と、ホバー時のツールチップを付ける
チェックポイント
- 1画面のPrimaryボタンが1つに収まっている
- 削除など破壊的操作が主要導線から離れている
- ラベルが「登録する」など動詞になっている
- フォーカスリングを消していない
- 処理中はボタンが無効化され、状態が見える
- 無効化されたボタンの理由が分かる