ボタンが押せそうに見える仕組み｜文言・見た目・反応の3条件

ミナ申込ページで「どのボタンを押せばいいか分からない」と言われたんです。

レン作った側は行き先を知っている。その記憶で合図の不足を補ってしまうんだ。

押せる合図が3つ必要な仕組み

ボタンは、影や角丸があれば成立するものではありません。押す前に何が起きるかを予測でき、ほかの要素と区別でき、押した後に受け付けたことが分かる必要があります。

たとえるなら、初めて訪れた建物のドアです。取っ手や押し板があれば、説明がなくても操作を予測できます。画面のボタンも、見慣れた合図を使います。ただし、この例が示すのは操作を予測できることだけです。画面では文言、キーボード操作、フォーカス、処理後の反応まで確かめます。

3条件は互いの代わりになりません。文言が明確でも本文中へ埋もれていれば見つからず、目立つ色でも「次へ」だけなら結果を予測しにくく、押せても処理中の反応がなければ連打を招きます。実際の画面では、押す前・押した瞬間・処理後を1本の流れとして確認します。

条件1は、結果が分かる文言

「送信」「次へ」だけでは、押した後に何が確定するか分からない場合があります。「予約を確定する」「資料をダウンロードする」のように、行動と結果を短く書きます。

取り消せない操作や料金が発生する操作は、特に曖昧にしません。ボタンの近くで条件を示し、確認画面や取り消し方法も用意します。長い説明をボタンへ詰め込むのではなく、判断に必要な情報を直前に置きます。

身近な例で見る、区別できる見た目

主なボタンは、背景と十分な差を持たせ、余白で周囲から分けます。角丸、枠、塗り、下線などは選択肢で、影や立体感は必須ではありません。サイト内で同じ役割に同じ見た目を使う一貫性のほうが重要です。

押せない見出しやカードへ同じ見た目を使うと、約束が崩れます。クリックできる要素には手がかりを与え、クリックできない要素からはボタンらしい手がかりを外します。色だけでなく形や文言も使います。

たとえば商品カード全体がリンクなのに、内部の見出しだけがボタンのように見えると、利用者は狭い範囲を狙います。カード全体を操作対象にするなら、フォーカスの輪郭もカード全体へ出し、内部に別のボタンを重ねない構造を検討します。見た目と実際の反応範囲を一致させることが大切です。

条件3は、押した後の状態と反応

押した瞬間には、色、形、進行表示、完了メッセージなどで受け付けたことを伝えます。処理中に何も変わらないと、利用者が連打して二重送信することがあります。処理中は再操作を防ぎ、終わったら結果と次の行動を示します。

キーボードで移動したときのフォーカス、無効状態、エラー状態も区別します。見た目の変化だけでなく、支援技術へ状態が伝わる実装も必要です。

処理に時間がかかる場合は、ボタンを消して無言にするより、処理中であることを伝えます。失敗した場合は「エラー」だけでなく、何を確認し、再試行できるかを示します。決済や予約のように結果が重い操作では、二重送信を防ぐ実装と、受付結果を後から確認できる手段も用意します。

自分の画面では主ボタン1つから使う

同じ強さのボタンが3つ並ぶと、押せることは分かっても、どれを選ぶかで迷います。標準は、主な行動を1つ、戻る・保存などを副次的な見た目にすることです。

選択肢が本当に同格なら、無理に1つだけ強くしません。料金プランや回答の選択など、利用者が比較して選ぶ場面では、同格であること自体が情報になります。画面の目的に合わせて優先度を決めます。

主ボタンを決めるには、その画面を見た人に次に何をしてほしいかを1文にします。「内容を確認して予約する」なら予約が主で、戻る・下書き保存は副です。一方、契約する・相談する・資料を見るの3つが異なる検討段階なら、1つを強制的に主にせず、違いを説明して選べるようにします。

見た目だけでは効かない場合

押せそうに見えても、対象が小さすぎれば操作できません。重要なボタンは44×44 CSSピクセル以上を候補にし、少なくともWCAG 2.2の最低基準を確認します。測り方はスマホのボタンの大きさの目安で解説しています。

マウスだけでなく、Tabキー、Enterキー、タッチでも操作します。見た目、文言、大きさ、実装のどれか1つだけでは「使えるボタン」になりません。

ボタンの文字と背景の差、フォーカスの見え方、画像だけのボタンの名前も確認します。アクセシビリティの最初の3点を入口にすると、ボタン単体だけでなくページ全体の読む順番まで点検できます。紙面上の「ボタン風の案内」は実際には操作できないため、URLやQRコードなど、その媒体で取れる行動へ置き換えます。

1つのボタンを3条件で直す

自分は行き先を知っているため、第三者にも操作してもらいます。「押せたか」だけでなく、「押す前に結果を予測できたか」を聞いてください。

観察するときは、説明を始める前に相手が最初に触れた場所を記録します。迷った場所、押し直した回数、完了を確認できたかを見れば、色の好みではなく操作上の問題として修正できます。ただし少人数の観察だけで全利用者を代表したとは考えず、アクセス解析や問い合わせも合わせます。

共通部品として実装しているなら、文言、色、サイズだけでなく、読み込み中、成功、失敗、無効の各状態を部品の見本へ残します。新しい画面で独自のボタンを増やす前に既存部品で役割を表せるかを確認すると、サイト内の操作の約束を保ちやすくなります。

分析ではクリック数だけでなく、完了、取り消し、エラー、二重送信も見ます。押されない原因が見た目ではなく、直前の料金説明や入力エラーにある場合もあるからです。ボタンだけを目立たせる前に、判断材料から完了までの流れを通して確認します。

ボタンは、無言の飾りではなく約束

押せるボタンは、結果が分かる文言、周囲と区別できる見た目、押した後の反応をそろえます。迷ったら主な行動を1つに絞り、文言から直します。

影や角丸を足すことが目的ではありません。押す前の予測と押した後の結果がつながることが、安心して操作できるボタンの条件です。