ボタンのUIデザイン：優先順位・サイズ・操作状態の設計

使いやすいボタンには、「何が起こるか」「今どの操作を優先すべきか」「現在操作できるか」が明確に示されています。まず操作の内容とラベルを決め、重要度に合った見た目を与え、ポインターでもキーボードでも操作しやすい領域を確保します。クリックすると注文が確定するのに「次へ」と書かれていれば、目立つ色を使っても誤解は防げません。

たとえば購入手続きの画面には、「注文を確定」「カートを保存して後で購入」「配送先を編集」という三つの操作があります。すべてを同じ強さで目立たせる必要はありません。PixsoのUIデザインワークスペースでは、これらを再利用可能なコンポーネントとして作り、ボタン一覧だけでなく実際の画面に配置して比較できます。

色より先に、操作の優先順位を決める

見た目の強弱は、製品側が目立たせたい操作の数ではなく、利用者がその場で行う作業に合わせます。最終確認画面では、内容を確認した後の「注文を確定」が購入手続きを完了する操作です。「カートを保存して後で購入」は別の意図に応え、「配送先を編集」は注文内容の一部を変更します。それぞれの役割を分けましょう。

「主要なボタンは一つにする」は、一つの判断領域では便利な原則です。ただし、長いページ全体で目立つ操作を一つしか置けないという意味ではありません。商品ページに独立した購入領域と設定領域がある場合もあります。判断の基準は、利用者が選択する瞬間に操作同士が競合していないかどうかです。

削除などの破壊的な操作は、さらに別の扱いが必要です。住所の削除が重要だからといって、注文確定と同じブランド色の主要ボタンを使うべきではありません。結果を説明し、製品で定めた削除操作のスタイルを使い、安全に戻れる方法を用意します。一方、「編集をキャンセル」は通常、安全に抜けるための操作です。否定的に見える言葉をすべて赤にする必要はありません。

実行結果を予測できるラベルにする

結果が曖昧になりそうな場合は、対象と動作を示します。「住所を保存」なら、何が変わるか分かります。「完了」では、保存するのか、閉じるだけなのか、保存せずに離れるのかが不明です。「注文を確定」は購入を確定することを伝えます。「次へ」は、本当に次の手順が残っているときに使います。

補助的な操作のラベルも正確にします。「カートを保存して後で購入」は、実際にカートの内容が保持される場合に適しています。単に商品一覧へ戻るなら、「買い物を続ける」のほうが適切です。安心できそうな表現でも、実際の動作と違っていれば役に立ちません。

リンクとボタンは動作で使い分けます。注文履歴ページへの移動はナビゲーションなので、見た目を強調していてもリンクが適しています。注文の送信や住所編集画面を開く動作は操作です。WAI-ARIAのボタンパターン（英語）では、この役割の違いとキーボード操作が説明されています。

アイコンは意味や認識しやすさを補える場合に使います。小さな矢印は次の手順への移動を補助できますが、曖昧な「実行」というラベルの意味までは説明できません。編集をアイコンだけで示す場合は、「配送先を編集」のような意味のあるアクセシブルな名前を指定します。ホバーに頼らなくても用途が分かる見た目にしましょう。

四角形だけでなく、操作領域を設計する

ボタンには、見えている形と実際に反応する領域があります。デザインでは両方を指定する必要があります。小さな鉛筆アイコンの周囲に広い操作領域を設けることはできますが、隣の「住所を削除」の領域と重なってはいけません。見えない余白を増やすことが有効なのは、どこを押せば反応するかが予測できる場合です。

WCAG 2.2のターゲットサイズに関する最低基準（英語）は、ポインター操作の対象を24×24 CSSピクセル以上とし、間隔や行内テキストなどに定められた例外を設けています。これは最低基準であり、購入画面の主要ボタンをその小ささにするという推奨ではありません。タッチ操作の主要なボタンには、より余裕のある領域を選び、周囲の操作と合わせて確認します。

この例では、高さ48ピクセルの主要ボタンから始め、読みやすい文字と、ラベルが窮屈にならない左右の余白を設定します。48ピクセルは設計上の出発点であって、すべてのボタンに適用されるアクセシビリティ要件ではありません。住所編集の操作はコンパクトな見た目でも、十分な操作領域を持たせられます。

関連する操作は近くにまとめつつ、誤操作を避けられる間隔を確保します。「注文を確定」と「カートを保存して後で購入」が同じ強さで目立つなら、間隔を広げるだけでは優先順位は伝わりません。先に見た目の強弱を整え、その後で間隔を調整します。

幅は内容とレイアウトに合わせる

デスクトップの購入画面では、内容に合った幅のボタンを注文概要の下に置けます。狭い画面では、主要ボタンを領域いっぱいに広げると、見つけやすく操作しやすい場合があります。ただし、短いラベルの周囲が不自然に空いたり、長い翻訳が切れたりするような一律のルールにはしません。

ラベル、必要なアイコン、余白、最小の高さを基にボタンを構成します。英語の文字数に合わせて、すべてのボタンを固定幅にするのは避けましょう。同じコンポーネントで「注文を確定」「カートを保存して後で購入」、さらに長い他言語のラベルを試します。幅が足りないときは、文字を小さくして押し込むのではなく、補助操作を主要操作の下に移します。

特に長いラベルへの対応も決めます。まず意味を失わない範囲で不要な言葉を削り、それでも必要ならコンテナーを広げるか、操作群を縦に並べます。コンポーネント自体が対応していれば2行のラベルも使えますが、高さが固定された細いボタンで偶然改行される状態は避けます。

見た目とキーボード操作の両方で、順序を自然に保ちます。モバイル向けに配置を変えた結果、デスクトップでの並びを引き継いだフォーカスが補助操作に先に移る、といった食い違いに注意します。購入操作を固定バーに置く場合は、ページ末尾の内容と、フォーカスされた操作が隠れない空間も必要です。

状態ごとに役割を分ける

ホバー、フォーカス、押下中、読み込み中は、単なる色違いではありません。それぞれが違う疑問に答えます。購入する人には、どの操作か、キーボードで次に反応するのはどれか、操作が受け付けられたか、注文がまだ処理中かを伝える必要があります。

• 通常：操作する前に、内容と優先順位を示します。
• ホバー：ポインターに反応します。ただし、タッチ利用者にも必要な情報をホバー時だけに隠しません。
• キーボードフォーカス：現在の操作対象を明示します。ホバーと同時に発生する場合があるため、必ずどちらか一方になるものとして扱いません。
• 押下中：操作への短い反応を示します。購入が成功したことを意味するわけではありません。
• 処理中：「注文を処理中…」などで待機中の作業を伝え、意図しない重複送信を防ぎます。
• 操作不可：今は実行できないことを示します。理由が自明でない場合は説明を添えます。

ラベルが「注文を処理中…」に変わったり、進行を示す表示が加わったりしても、ボタンの幅が急に変わらないようにします。幅が動くと、ポインターの下で対象がずれたり、隣の操作の位置が変わったりします。何を待っているのかを説明するラベルのほうが、スピナーだけよりも理解しやすい場合があります。

クリックした直後に、成功を表すチェックマークへ置き換えてはいけません。注文完了は、処理結果が確認された後に表示します。決済システムが結果を確認できない場合は、その不確実な状態と適切な次の行動を説明し、すぐに二度目の支払いを促さないようにします。これは見た目のバリアントを追加するだけでなく、実装チームとの合意が必要な動作です。

フォームで無効なボタンを使うときは注意が必要です。不足項目を示さず「注文を確定」を灰色にすると、利用者は原因を探さなければなりません。適切な場合には送信操作を可能にし、実行時に未入力の項目を示します。操作を無効にする必要があるなら、たとえば配送方法が未選択であることを、近くで明確に伝えましょう。

目立たせても、読みやすさを失わない

ブランドカラーは枠線では使えても、白文字の背景には向かないことがあります。ホバーやフォーカスを含む各状態で、実際の文字色と背景色の組み合わせを確認します。通常サイズのボタン文字について、WCAGの文字コントラスト基準（英語）は4.5:1以上を求めています。大きな文字や非アクティブな操作には別の規定がありますが、それを理由に補助操作を読みにくくしてよいわけではありません。

キーボードを使う人には、見えるフォーカス表示が欠かせません。WCAGのフォーカス可視化の基準（英語）は、キーボードで操作できるインターフェースに視覚的な表示を求めています。ホバー色から開発者に推測してもらうのではなく、デザインファイルにフォーカスの見た目を用意します。

住所編集では、「配送先を編集」で開いたときのフォーカス先と、閉じた後に戻る位置を記録します。「注文を確定」では、入力エラー時と確定後の移動先を決めます。見た目が整っていても、フォーカスが予想外の場所へ移るボタンは作業を妨げます。

Pixsoで小さなボタン体系を作る

実際の購入画面にある三つの操作から始めます。Auto Layoutのコンテナー内にラベルと必要なアイコンを配置し、余白、配置、間隔をそろえます。再利用可能なコンポーネントにする前に、長いラベルでも比較しましょう。

画面に必要な主要・補助・文脈内の操作について、関連するコンポーネントバリアントを作り、必要な操作状態を加えます。適切な箇所では共通の文字・色スタイルを使い、関連する操作が同じ設計方針に従うようにします。PixsoはAuto Layout、コンポーネントバリアント、共有スタイルに対応しています。ここで目指すのは、組み合わせを最大限に増やすことではなく、一貫した操作群を作ることです。

コンポーネントの見た目と、画面全体の応答は分けて考えます。処理中のボタンは再利用できますが、注文が処理中か、失敗したか、確定したかは購入画面の動作が決めます。同様に、「編集」の見た目を共通化しても、住所をダイアログと別ページのどちらで編集するかは決まりません。その判断を購入画面のフレームのそばに記録します。

次に、同じページのデスクトップ版とモバイル版へインスタンスを配置します。短いラベルと長いラベル、キーボードフォーカス、送信中、復帰可能なエラーを比較します。実際の画面で、購入を完了する操作と、詳細だけを変更する操作が引き続き区別できるか確認しましょう。

開発への引き継ぎには、見た目の役割、操作領域の寸法、サイズ変更のルール、状態の表現、各インスタンスが実行する処理を含めます。キーボードと送信の動作は、実際のインターフェースに実装してテストします。デザインファイルは要件を明確にするものであり、購入処理そのものを実行するものではありません。

Pixsoでボタンコンポーネントを作成し、利用者が実際に操作する画面で比較してみましょう。