こんにちは！　今日もコーディングを楽しんでいますか？

Web やアプリの開発では、プログラマは「機能が動けば十分」と考えがちです。ですが実際のユーザーは、必ずしも直感的にシステムを操作できるわけではありません。

ユーザーが迷わず操作できるかどうかは、「どこを、どのように操作すればよいか」を自然に示す UI の手がかりによって大きく左右されます。

これがないと、ユーザーは画面上で迷い、誤操作を繰り返す結果、最終的には離脱してしまいます。

この「操作の手がかり」を、アフォーダンス（Affordance）やシグニファイア（Signifier）と呼びます。

画面デザイナーが意図して仕込んだアフォーダンスをプログラマが見落とすと、せっかくの工夫が失われ、使い勝手が損なわれてしまいます。

逆に UI デザイナーが、流行のデザインや美観を優先するあまり、アフォーダンスが軽視されるケースもあります。

こんかいは、この「アフォーダンス」および「シグニファイア」について整理し、特にプログラマ視点でどのように実装に落とし込むべきかを考えてみます。

---

アフォーダンスとは何か？

「アフォーダンス」とは知覚心理学者ジェームス・ギブソンが提唱した概念で、「特定の対象物が持つ操作可能性」、簡単に言えば「それに対してできる、働きかけ」を意味します。

身近なアフォーダンスの例

現実世界の身近な例として、「ドア、ふすま」が挙げられます（画像は AI サービスによる自動生成です）。

……わざわざ「回してください」「押してください」「引いてください」と書かなくても、取っ手の形を見れば開け方がわかります。

このように、取っ手そのものが「扉を開ける方法」を示す場合、「これらの扉には『開ける』というアフォーダンスがある」と言います。

（※後述するように、厳密には取っ手は「アフォーダンス」よりも「シグニファイア」と呼ぶのが適切です）

Web ブラウザのビルトイン UI においては、「クリックできる ボタン は立体的に見える」「テキストリンクは下線が付いている」といった、慣習的な挙動がアフォーダンスにあたります。

プログラミングの UI 実装において留意すべきアフォーダンスは、たとえば次のようなものです。

• 視覚的手がかり（ボタンの影、リンクの下線）
• 状態変化（「hover（マウスを重ねたとき）、focus（入力中）、active（クリック中）、disabled（無効化）のスタイル）
• 動きやフィードバック（クリック時の押し込み感、ローディング中のスピナー）

アフォーダンスとシグニファイアの違い

結論から言うと、

• アフォーダンス（Affordance）＝その UI が備えている、「できること」
• シグニファイア（Signifier）＝ユーザーに示される、「してほしいこと」

です。

アフォーダンス (Affordance)

アフォーダンスは、「特定の対象物が、周囲の環境に対して『どのような操作可能性を備えているか』を示す（afford）こと」という概念です。「示す」相手は環境そのものであり、観測者の有無は問いません。また、示している操作可能性も、特定の操作に限りません（たとえばドアの場合、「開ける」以外にも「外す」「壊す」などの操作が可能、という意味です）。

シグニファイア (Signifier)

一方、シグニファイアとは認知心理学者ドナルド・ノーマンが提唱した概念で、「特定の対象物のアフォーダンスのうち、観測者に対して『特定の操作のみ』を示唆する（Signify）こと」です。観測者の存在を前提とし、操作可能性を絞り込む＝操作を誘導するという明確な意図があります。「アフォーダンスのうち、特定の文脈を持つもの」と考えてもよいでしょう。

よくある失敗パターン

ここからは、具体的な失敗パターンを3つ紹介します。

UI の演出（視覚的なフィードバック）不備による「これじゃない感」

HTML によって Web サービスを構築している場合、 <button> タグに CSS を適用することはよくあることです。以下はそれを模したコードですが、２つのボタンを実際に操作してみて、「これじゃない感」を比べてみてください。

２つのボタンを触り比べて、皆さんはどう感じたでしょうか。　前者のボタンには「違和感がある」「え？　なぜ？」という感覚を覚えたと思います。一方で後者のボタンには「違和感がない」「納得できる」という感覚を覚えたことと思います。その理由は、前者は「ボタン UI として立体的に見せているのに、触っても一切の視覚的なフィードバックが返ってこない」からです。

実は <button> 要素はブラウザのデフォルトスタイルとして、 button:hover が定義されているのですが、スタイルを与えてしまうと、デフォルトの挙動が上書きされてしまいます。つまり、もし UI デザイナーから button:hover のスタイルを指定された場合、プログラマは button:hover のときのスタイルを明示的に指定しなければならないということです。これは CSS を担当するプログラマにとって、必須の知識です。

また、スマートフォンにはマウスカーソルに相当するものがないため、ボタンをタップした時に「確かにタップされた」というフィードバックは欲しいところです。ユーザーが「押せそうに見えるボタン」をタップしたのに、フィードバックもなく内部処理を始められても、ユーザーは「タップできていなかったのでは？」と不安になり、二重送信してしまうおそれがあるためです。仮にそれで不具合が発生しないようにプログラミングされていたとしても、ユーザーの「欲しかったボタン UI は、これじゃない」という失望によって、そのボタンに対する信用は間違いなく下がってしまいます。

いわゆるプログラマの一部には、どうしたわけか、こうしたスタイリングの変化を「たかが演出」と軽視する傾向があるように見受けられます。しかしこれらの演出は、ユーザーの使い勝手の向上に欠かせないアフォーダンスなのです。

ユーザーが快適に利用できるよう、プログラマも「これじゃない感」に敏感になりましょう！

フィードバックを出さないフォーム送信

Web サービスを利用しているユーザーにとって最大のストレスの一つは、「送信ボタンを押したが、本当に送信されているのかわからない事」です。ただ fetch 通信処理を実装しただけでは、ユーザーからはブラウザが何もしていないようにしか見えません。

以下のコード例の、「これは悪い例です」と書かれたフォームの送信ボタンを押してみてください。いつの間にか通信が終わっており、その間に何が起こっているのかわかりません。その上、送信ボタンを何度も押すことさえできてしまいます。これではユーザーが困惑するだけでなく、通信が失敗する可能性も出てしまいます。

「フォーム送信中」状態を示す代表的なアフォーダンスは、「画面に『送信中』と明示すること」と、「送信ボタンを非活性化すること」です。

例えば、上のコード例の「これは良い例です」と書かれたフォームの送信ボタンを押してみてください。送信中は画面に「送信中…」と表示され、さらに送信ボタンが非活性化されることで、「今はフォーム送信中である」というアフォーダンスとなります。

更に強力なアフォーダンスの例として、「これはより良い例です」のフォームも用意しました。送信すると、 <dialog> 要素を利用したモーダル UI が画面全体を覆い、中央に「送信中…」と表示します。本来、フォーム送信中に他の通信ができてしまうのは好ましくないので、画面全体の操作をユーザーに明示して制御するわけです。この UI の形は、「フォーム送信中」を示す強力なアフォーダンスとなります。

「良い例」「より良い例」ともに、通信が終わったら「通信中」である表示を消しているところにもご注目ください。状態を即座に視覚的にフィードバックすることも、重要なアフォーダンスです。

フラットデザインの落とし穴

ここでは、UI デザイナーの視点でも注意したい点を紹介します。

本記事執筆時は、フラットデザインが流行しています。これは簡単に言うと、

エンボスや影など、 UI に立体感を演出するのではなく、できる限り情報量を省いた、平面的な UI によって、直感的に操作を理解させるデザイン

です。

しかし、UI をフラットにしすぎるあまり、単なる文字や背景と区別がつかなくなることがあります。リンクにしろボタンにしろ、「クリックできるのかどうか」が伝わらなければ、ユーザーは行動を起こせません。

例として、このような見栄えのサイトを想定してみます。

この例では、 <a> と <button> による UI が存在しています。でも、このページを見ただけで、それがユーザーに伝わる可能性は低いでしょう。 <a> には下線がありませんし、 <button> は <h2> と色味でしか区別ができないのですから。

「リンクテキストの下線を省くのは、最近の流行だ」や「そこにマウスカーソルを重ねたら、カーソルの形が変わることで区別できる」という意見は、あまりにもユーザー目線を欠いています。HTML における慣例的な挙動は、ユーザーにとって強力なアフォーダンスです。それを省く以上、より良いアフォーダンスが存在してしかるべきですが、先の例では本当にそれが果たせているかは、一考の余地があります。

以下の例のように、同じフラットデザインでも強力なアフォーダンスを意識し、控えめなスタイリングで表現できないか、いま一度考えてみましょう。

プログラマが意識すべきポイント

プログラマが UI 実装を担当するとき、以下の観点を常に意識し、時に UI デザイナー担当者と意見のすり合わせをすることが大切です。

1. 状態の視覚化
   • ホバーやフォーカス時にスタイルを変える
   • 無効ボタンはグレーアウトする
   • エラーは赤、成功は緑など、ユーザーに状態を即座に伝える
2. 操作対象のサイズと余白
   • モバイル環境ではタップ領域を十分に確保する（最低 44px 四方が推奨）
   • 押しやすさそのものがアフォーダンスになる
3. 一貫性の確保
   • 同じ機能には同じデザインと挙動を適用する
   • ページによってボタンの見た目や挙動が違うと、ユーザーの学習効果（慣れ）が失われる
4. 補助的なフィードバック
   • ローディング時にスピナーを表示する
   • フォーム送信時には「送信中」「送信完了」の旨を表示する
   • これらもアフォーダンスの一種であり、ユーザーの安心感を支える

まとめ

本記事では、UIデザインにおける「アフォーダンス」という考え方を整理しました。アフォーダンスとは「行為の可能性」を意味し、ユーザーが画面や要素から「これができそうだ」と直感的に理解できる状態を指します。

実務では、アフォーダンスそのものを意識して設計することが重要です。ボタンなら「押せそうに見えること」、リンクなら「クリックできそうに見えること」が大切です。さらに、「その操作を誘導するサイン」である「シグニファイア」を適切に与えることで、ユーザーは迷わず操作できます。

もし UI が使いにくいと感じられるなら、それはアフォーダンスの設計不足か、あるいはシグニファイアの提示不足に原因があるかもしれません。UI を作るときは、「アフォーダンスがユーザーに伝わっているか？」を一度立ち止まって考えてみてください。

こんかいのお話は、以上です。それでは、よきコーディングライフを！