リンクとボタンを｢押せる｣だけでデザインしない

リンクとボタンのビジュアルが似たものもしくは同じものになる理由のひとつに「押せる」^[1]という共通点があるからだと思っている。

ビジュアルを似たもの・同じものにするかどうかは状況により判断されるので、そこに画一的な優劣は存在しない。しかしリンクとボタンは明確に異なる機能や振る舞いをもっている。その振る舞いやそれに対するユーザーのメンタルモデルから結果ビジュアルが同じになるのならいいのだが、ただ単純に「押せる」ことだけを基準にデザインされてしまうのは具合が悪い。このエントリーでは、リンクとボタンをデザインするにあたって「押せる」だけではなく、他にも判断材料となるものがあることを共有したいと思う。

前提と定義

今回の話はウェブブラウザで動作するUIを前提に考える。途中で言及するが、リンクがURLに関係していることと、URLをユーザーが意図的に変更できることが大きく関係するので、ネイティブアプリやWebViewを利用しているケースは想定に入れない。

今回扱うリンクとボタン、つまりインタラクティブ要素は次のものに限定する。

• リンク（ <a href> ）
• ボタン（ <button type="button"> ）
• サブミットボタン（ <button type="submit"> ）

それ以外のボタン（リセットボタンや、ビデオ・オーディオコントロール、summary要素など）は今回は言及しないことにする。また、input要素のtype="button"はボタン、type="submit"とtype="image"はサブミットボタンと同様に考えることとする。なお、hrefのないa要素（プレースホルダー・リンク）は、リンクではないこととする。

それぞれの機能と振る舞い

共通する振る舞い

• クリックもしくはタップによる作動
• キーボードのエンターキーもしくはスペースキーによる作動
• フォーカスを受け取る

作動は次に挙げる基本機能と、 click イベントの発火を意味する^[2]。

基本機能（「押されて」作動したときの振る舞い）

要素	基本機能
リンク	ハイパーリンク
ボタン	開発者によって定義される（デフォルトではなにもしない）
サブミットボタン	フォームデータを送信する

ハイパーリンクの種類

• サイト（もしくはアプリ）内の別ページ
• 外部ページ
• ページ内のフラグメントへの移動
• ページ以外のファイルへの参照
• 電話
• ネイティブアプリへのアクセス（アプリを開く）

javascriptスキームの利用についてはバッドノウハウなので今回は考えない。

また、属性によって振る舞いが変化する場合がある

属性	振る舞い
target	リンクが指定されたブラウザコンテキスト[3]で開く
download	リンクを先をダウンロードする

基本機能以外の振る舞い

リンク

• コンテキストメニュー（右クリックメニュー）のリンク用の機能が使える
  • URLをコピーする
  • 別タブで開く
  • リンク先をダウンロードする など
• Commandキーと同時にクリックで別タブで開く
• Option(Alt)キーを押していればリンクにジャンプせずに内容のテキストを選択できる
• マウスポインタを重ねるとURLを表示する
• ブラウザによって^[4]は長押しすると小さいモーダルフレームで開く
• 重ねるとポインターが矢印から指に変わる
• 訪問済み（:visited）の場合、それを示唆する^[5]

ボタン・サブミットボタン

• 上記のリンクの振る舞いをしない^[6]
• 無効（:disabled）状態になるとフォーカスを受け取らず、クリックなども受け付けない

予想可能な手がかりをつくる

それぞれの機能によって、あるいは開発者の実装によって、そのリンクもしくはボタンが押されたときの結果が異なる。ユーザーは「押す」時に結果を予想し、期待する^[7]。押された結果が期待したものとギャップが大きい場合、それはユーザーの学習コストとなる。意図したギャップはともかく、そうでないのであればユーザーのそういったコストはなるべく減らしたい。

そうなると予想できるような手がかりを与える必要がある。手がかりのひとつとしてはラベルがある。何が起こるのか説明しているラベルであれば、それに越したことはないだろうが、多くの場合、特にボタンは表示領域などの関係で簡潔に短いラベルになる。そうなるとラベルだけでは説明できない部分^[8]をアイコンやシグニファイアに頼ることになる^[9]。

ここで最初のリンクとボタンのビジュアルが同じものであることの話に戻る。リンクとボタンの結果はほとんど場合同じにはならない。ビジュアルが同じだと、ユーザーはラベルからでしか結果を予想できなくなってしまう。予想する必要性についてはコンテンツやサービスの性質や状況により異なるが、必要なのであればビジュアルが同じものになるのは避けたほうがいいだろう。ただし、ラベルや文脈から十分に予測可能なのであればこれに限らない。

結果を知ってから次に期待されること

たとえば押した結果、ページ全体もしくはほとんどの部分が変わりURLが変更されたとする。ユーザーは慣習的におそらく「ページが変わった」と認識するだろう。それと同時に「さっき押したものはリンクだったのだ」と認識する。そうなるとラベルが異なっていても同じビジュアル（シグニファイア）を持っているものは「リンクかもしれない」と次から認識するようになる。そう認識したものにはリンクの振る舞いを期待することになるので、コンテキストメニューを開いて操作しようとするかもしれないし、Commandキーを押しながらクリックして別タブで開くことを期待するかもしれない。そこでもし、それがリンクではなくボタンだとしたら、期待と異なる振る舞いに混乱し戸惑うかもしれない。そして「さっきのリンクの同じ見た目でもただのボタンの可能性がある」と再学習することになるが、次のアクションは「リンクかボタンかどうか確かめなければわからない」という状況を作ることになる。

今挙げた例はリンクとボタンの振る舞いを熟知しているインターネットにかなり慣れたリテラシーの高いユーザーかもしれない。しかし、慣れていないユーザーだとしても偶然標準の機能を発見する可能性はあり、その後に別のボタンで使えなかったときの混乱はすごいだろう。アプリのバグと思うかもしれない。また、多くの一般的なブラウザが共通にもつ機能でインターネットをする上で普遍的に通用する知識ではあるため、サービスに対してのユーザー像のそれと紐付けることもできないだろう。今の時代、サービスの新規ユーザーと既存のヘビーユーザーとでどちらがインターネットリテラシーが高いかなど極めて測りにくい^[10]。

リンクのようなボタン

ビジュアルが同じことによって生じる予測と結果のギャップについては述べたとおりだが、そもそも慣例的なビジュアルを採用することによっても予測と結果のギャップが起こる。

視覚的に「これはリンクだろう」「リンクかもしれない」と予想できたものが、ページ遷移しなかったり、コンテキストメニューに期待の機能が表示されなかったり、テキストコピーできなかったら。ビジュアルが同じときと同様、混乱と再学習を余儀なくされる。一般と異なることに再学習の抵抗感はことさら大きいだろう^[11]。

サブミットボタンと副作用

結果としてページが変わりURLが変更されたとすることがリンクと定義するのだとしたら、サブミットボタンはリンクなのではないか？と考えるかもしれない。たしかにそこだけを切り取るとリンクと同じだが、サブミットボタンの多くはページの切り替えとは別に副作用を発生させている。それはアプリ上のデータを書き換えたかもしれないし、メールを送信したかもしれない^[12]。URLのみによって再現可能だとまずいもの、つまりPOST送信^[13]でないと再現しえないものはリンクではない。よってサブミットボタンとリンクのビジュアルは異なってもよい^[14]。

ボタンとサブミットボタンのビジュアルは、これは正直どちらでもいいと思っている。実際、ボタンに実装された処理がAPIを介してサブミットボタンと同じことを行っていることも少なくない。なのでもしもビジュアルに差をつけるとしたら副作用があるかどうかを判断材料にするとよいかもしれない。

リンクのバリエーションと予想の手がかり

当然ハイパーリンクの種類やリンクの属性によっても手がかりをつけてあげたほうが予想しやすくなる。ラベルや文脈で十分の場合もあるが、アイコンや場合によってはビジュアルを大きく変えてもいいだろう。target="_blank"を指定して別タブで開くようにしたときにアイコンを付与することが多いがまさにこのようなことだ。特にdownload属性はページを開かない結果となるので差をつけたほうがいいかもしれない。電話リンクは、おそらくラベルから予想可能なことが多いだろうがアイコンをつけたりビジュアルを変更してもいいだろう。

まとめ

• ｢押せる｣以外の機能や振る舞いがあることに注目する
• それが引き起こす結果を予想できる手がかりをなるべくつくる
• 手がかりはラベルや文脈で済む場合もある
• 期待と異なる結果はユーザーに学習コストを発生させること認識する
• 学習によりさらに期待をつくる場合もあることを認識する
• コンテンツやサービスの性質や状況によって必要性はそれぞれなので画一的な答えはない

[追記] そもそも｢押せる｣とは？

公開後、表示に重要な指摘をいただいたので追記する。

指摘の詳細はツイートにぶら下がったリプライを読んで欲しい。

記事内の「押す」というものを全て「クリック」に置換してしまえば、それはそれで収まり良いかと思ったが、この記事を書こうと思ったキッカケを考えるとそうもいきそうにないので、ただただ言い訳を述べる。

着想としては「なんで多くのUIはリンクをボタンにしてしまうんだろうね？」というところ。ここから「リンクもボタンも押せるものだから、一緒に考えちゃうのも無理ないよね」と変換される。ここで既に自分が「クリック」と「押す」を混同している。

ボタン要素はボタンを模しているので画面上でクリックすることで押下可能ですが、リンクを画面上でクリックする際に押下しているのはマウスボタンです。

そもそも自分は昔からクリックのことを押すと言っていた気もする。物心ついたときからマウスというデバイスは傍にあったし、マウスポインターがスクリーン上のオブジェクトをクリックすることはボタンだろうがリンクだろうが、マウスボタンを押しているので、自分の行動は「押す」だった。幼い頃から既にずっと今まで混同した可能性がある^[15]。

この【リンクに対しても「押す」という概念で考えてしまう】のはひょっとしたら僕だけではないのかもしれない。この記事が一定の同意を既にツイッターなどで観測しているし、「押す」に関してのツッコミがなかったのを考えると、「リンクは押せるもの」という風に捉えている可能性はある。リンクをボタンの見た目にしてしまう根幹がそこにあるのではないか、とか。

自分としては今後はユーザーの行動に関して詳細に厳密に分析をする上で「クリック」と「押す」という行動は別のものとして考えていきたい。しかし、デザインの話をするときに「リンクは押せるものだからボタンのようなメタファーをつくっても問題ない」という人がいたら、その動機がどこからやってくるのかに注目しながら会話をしたいと思う。

脚注

1. 「押せる」の定義については最後に記載。 ↩︎

2. これを記載する意図としては、その他の要素はキーボードのエンターキーもしくはスペースキーによってclickイベントは発火しないため、抑えておきたい共通の振る舞いだからだ。 ↩︎

3. タブやフレームやウィンドウ ↩︎

4. iOS Safariなど ↩︎

5. デフォルトのスタイルシートではフォントカラーが変わり、スクリーンリーダーにも「訪問済み」と伝える。 ↩︎

6. 振る舞いをしないことが重要な振る舞いと考えるので、こういう表現する。 ↩︎

7. 意識的にの場合もあるし、無意識的の場合もある。 ↩︎

8. もちろん前後の文脈も関係するので、完全にラベルだけではないが。 ↩︎

9. ビジュアルデザインの文脈なので注釈になるが、アクセシビリティを担保するためにそれらの手がかりを視覚以外の方法でも提供する必要があるのは言うまでもない。 ↩︎

10. 平たく言うと「うちのサービスを使うユーザーに、そんなに詳しいやつおらんやろ」は通用しにくい、ということだ。 ↩︎

11. 自分なら少なくとも舌打ちする ↩︎

12. 厳密にはメールを送信するのはサブミットされたデータを受けたサーバーだが。 ↩︎

13. HTTPメソッドはもっとあるが、わかりやすさのためにPOSTとした。 ↩︎

14. むしろ異なったほうがよい ↩︎

15. 「マウスポインターが指マークになるから」説もあると思う。 ↩︎