はじめに
目的
この章では、Webボタンの命名規則を学ぶための導入を行います。ボタン名をわかりやすく統一することで、デザインや開発、保守が楽になります。具体的な例を交えて、実践で使える考え方を示します。
対象読者
デザイナー、フロントエンド開発者、プロダクトマネージャーなど、ボタン名を扱う方すべてを想定しています。CSSクラスやプロパティに触れたことがある方なら、すぐに実践できます。
本書の構成
第2章で基本的な命名フォーマットを説明し、第3章でよく使われるパターンを例示します。第4章では命名時の注意点をまとめます。どの章も実践向けの例を中心にしています。
なぜ命名が重要か
ボタン名が明確だと、実装時の誤解が減り、再利用性が高まります。チームで作業するときも意図が伝わりやすくなり、品質向上に寄与します。
使い方の目安
まずは第2章の基本フォーマットを試してみてください。実際のプロジェクトで短いサイクルで試行し、チームルールとして定着させることをおすすめします。
基本的な命名フォーマット
命名の基本構造
Webボタンの命名で最も使われるのは「コンテキスト＋エレメント＋バリアント」です。順に画面や機能（コンテキスト）、要素名（エレメント）、見た目や用途の差（バリアント）を表します。
具体例
- dashboard_btn_primary：ダッシュボード画面の主要ボタン
- profile_btn_edit_sm：プロフィール画面の編集ボタン（小サイズ）
- cart_btn_checkout_disabled：カートの決済ボタン（無効状態）
これにより、どの画面の何のボタンかが一目で分かります。
階層構造（種類／用途／バリエーション）
もう一つの一般的な考え方は「種類／用途／バリエーション」の階層です。種類でボタンの役割（例：primary, secondary, ghost）を決め、用途で置き場所や機能を示し、バリエーションでサイズや状態を表します。
例：primary/checkout/sm → primaryボタン、チェックアウト用、小サイズ
簡単なルール
- 一貫した順番で書く（例：context_element_variant）。
- 略語はチームで統一する。例：btn＝button、sm＝small。
- ステートは明示する（disabled, loading）。
- 長すぎない名前を心がける。
こうしたフォーマットを使うと、保守や検索が楽になり、デザインと実装の橋渡しができます。
よく使われるボタン命名パターン
概要
ボタンは役割ごとに名前を付けるとわかりやすくなります。UI設計や開発で共通理解を持てるため、機能や優先度を反映した命名が望ましいです。
代表的なパターン
- button / primary
- メインのアクション用。送信や保存など目立たせたいボタンに使います。
- button / secondary
- 補助的なアクション。キャンセルや戻るなどに適します。
- button / tertiary
- リンク風の控えめなボタン。ページ内の補助導線に使います。
- button / icon
- アイコンのみのボタン。スペースが限られるときやツールバー向けです。
- button / text
- テキストリンクに近い見た目。補助的な操作に向きます。
状態や目的に応じた拡張
- action / submit, action / cancel, action / destructive
- 役割を明確にするために追加します。例えば「button/primary/submit」のように階層で表現できます。
CSSクラスの例
フロント実装では英小文字とハイフンを使うと標準的です。
– .btn
– .btn-primary
– .btn-submit
使い分けのポイント
- 優先度（primary/secondary）で視覚を統一してください。2. アイコンだけのボタンは意味が分かるツールチップを付けてください。3. 名前は短く具体的にして、チームでルールを決めると運用が楽になります。
命名時の重要なポイント
1. 役割を最優先で表す
見た目（色やサイズ）で命名すると、デザイン変更で名前が矛盾します。たとえば .red-button より .primary-button や .danger-button としておくと、役割が明確で保守性が高まります。
2. 動詞で行動を表す
ボタンが行う操作は動詞で示します。例: save-button、cancel-button、delete-confirm。これによりコードを見ただけで何をするか分かります。
3. 状態や優先度を付ける
通常の状態と状態変化を区別します。例: primary-button, secondary-button, loading, disabled。状態はクラスや属性で分けると分かりやすいです。
4. コンポーネントやコンテキストを含める
同じ名前のボタンが複数ある場合は、コンテキストを補足します。例: header-login-button, modal-confirm-button。これでどこで使うかすぐ分かります。
5. 色や見た目は避ける
色やフォントなど外見に依存した名前は避けます。デザインを変えても名前を変えずに済むようにします。したがって、役割や状態で判断してください。
6. 一貫性を守る
チームで命名規則を決めてドキュメント化します。命名の例と禁止事項をまとめておくと新しいメンバーも迷いません。
7. アクセシビリティを意識する
クラス名は見た目の手掛かりにせず、操作の意味を表現します。スクリーンリーダー用の aria-label やボタンテキストで具体的な説明を入れてください。
命名は小さな作業に見えますが、積み重なると保守性や可読性に大きく影響します。簡潔で意味のある名前を習慣にしましょう。
