このノートはWebの画面にある慣習と操作について考えたものです。画面を見たときに何を操作でき、どのように進めると予測するのか。見た目だけで分かることと経験から分かることを分けながら、慣習を残す場所と独自の操作を加える範囲を整理します。
Webをつくっていると見慣れた操作をそのまま使うか、画面固有の構造に合わせて別の関係をつくるかを何度も判断します。慣習に寄せれば説明を減らせますが、すべてを同じ形へ揃えるとその画面にある構造や動きまで見えにくくなることがあります。反対に独自の操作を増やすと利用者は内容より先に使い方を読み続けることになります。
この記事で整理したいのは、慣習に従うか外れるかという二択ではなく、既知の操作と画面固有の変化をどう分担させるかです。操作方法は慣習に預け、独自性は操作によって何がどう変わるかに置く。その関係を実際のデモと制作例から見ていきます。
ここでいう慣習とは人間の文化全体ではなく、操作する前から利用者が持っている共有された予測の範囲です。下線のある文字は別の場所へ移動し、三本の線はメニューを開き、縦方向の入力は画面を下へ進めると予測します。こうした予測は個々の形だけから生まれるというより、別の画面でも同じ関係を繰り返し経験してきた結果です。
押せそうに見えるもの
物理的な押しボタンには指で押せる大きさと形があり、押せば表面が沈んで指を離せば戻るものもあります。形と身体の関係が行為を可能にし、動いた結果が操作を返します。画面のボタンは物理的な押しボタンと違い、描かれた四角形そのものが沈むのではなくマウスや指による入力をプログラムが受け取ります。それでも枠、塗り、文字、影などを見れば押せそうに感じます。押している間だけ少し縮み、色が変われば入力が届いたことも分かります。
前のノートで触れたドナルド・ノーマンは、何ができるかを人が知覚するための手がかりをシグニファイアとしてアフォーダンスと分けています。画面のボタンはこの違いが分かりやすい例で、操作できる仕組みが存在していてもその場所や方法を知る手がかりがなければ行動にはつながりません。
一方で手がかりは入力方法によって変わります。マウスではカーソルの形や:hoverを使えますが、タッチには触れる前の:hoverがありません。キーボードではフォーカスしている場所が見える必要があります。同じボタンでも使う身体と機器が変われば必要な手がかりも変わります。
学習された操作
Webでは多くの形が以前の経験を通して読まれます。物理的な押しボタンに近い見た目から始まった長方形も、現在は影のない平らな形でボタンとして使われます。周囲との色の差や短いラベル、置かれている位置から操作を予測できるためです。ハンバーガーメニューも三本の線そのものがメニューを開く訳ではなく、同じ記号と操作の組み合わせを繰り返し見たことで意味が共有されています。
ただ慣習は誰にでも同じように共有されているとは限らず、使ってきた機器やサービス、年齢、地域、操作の頻度によって知っている記号は変わります。広く使われている形であっても初めて見る人には説明にならない可能性があります。
なので実務での慣習はWeb全体の固定したルールではなく、対象とする人と利用状況の中で借りられる予測として扱います。毎日使う管理画面と一度だけ訪れる申し込みページでは反復で覚えられる回数が異なります。マウスを中心に使う人とタッチやキーボードを使う人では受け取れる手がかりも異なります。「慣習的か」という問いは、誰が、どの機器で、何回使うかまで含めて判断します。
また同じサイトを使う中で新しい慣習が生まれることもあります。最初のボタンを押したときに形が変わって次の状態へ進み、その反応が別の場所でも繰り返されれば二回目からは同じ形を操作できるものとして予測できます。一般的な慣習を借りるだけでなく一つの画面の中で関係を揃えることも操作を伝える手がかりになります。
この関係を単純にしたButton Learningでは、最初の画面だけ印に「次へ」という言葉を添えています。次の画面から言葉を外して位置を変えても印と反応の組み合わせは変えません。一度の操作で覚えた関係を次の画面へ持ち込めるかを見るデモです。
このような学習を設計に含められるのは、同じ人がその後も操作を繰り返し最初の失敗から戻れる場合に限ります。一度の訪問で目的を終えるページや、誤操作が申し込みや決済につながる場所では学習を前提にしません。初回から意味の分かるラベルと一般的な操作を残します。
ジェフ・ラスキンは『ヒューメイン・インタフェース―人に優しいシステムへの新たな指針』で、習慣の形成をインタフェース設計の認知的な基礎の一つに置いています。繰り返した操作はやがて手順を意識しなくても実行できるようになります。利用者がボタンを探し続けるのではなく文章を書く、情報を探すといった本来の目的へ注意を向けられるのは、この習慣化が働くためです。広く共有された慣習は画面を使う前からある蓄積を借り、独自の操作は一つの画面の中で新しい蓄積をつくるものと考えられます。
一方で習慣化は内容を確かめずに同じ反応を返すことでもあります。ラスキンは確認ダイアログを繰り返すと確認する操作そのものが習慣になり、警告が判断を促さなくなると指摘します。誤操作の影響が大きい場面では見慣れた確認ボタンを置くだけでは足りず、取り消せる仕組みを用意するなど操作の前後を含めて考える必要があります。
ここで重要なのは独自の形も反復すれば使いやすくなるということではありません。同じ形と反応が保たれていれば一度の経験を次へ持ち込めますが、同じ操作が途中から別の結果を返すと覚えた動きがそのまま誤操作につながります。一般的な慣習を借りる場合もサイトの中で関係を学ばせる場合も、何を繰り返させ、どこで改めて注意を向けてもらうかを分ける必要があります。
ボタンを分解する
まずは分かりやすいボタンから始めます。塗りや枠、短いラベルがあれば多くの場合は押せそうに見えます。見た目を考えるときはこの完成した形を増やすより、同じ操作から手がかりを一つずつ外して比べた方が分かりやすいかもしれません。
同じ大きさと言葉を使い、塗り、枠、影、:hover、カーソル、押している間の変化を切り替えながら操作の結果は揃えます。何を外した時点で周囲の文字と区別できなくなるか、押す前には分からなくても一度押した後は理解できるか、マウスでは分かってもタッチやキーボードでは分からなくなっていないかを確かめます。手がかりを一つずつ切り替えるとボタンらしさをつくっている要素を分けて見られます。
Button Cuesでは操作の多いUIを想定し、ホバーと押下変化のないボタンを個人的な基準として置きました。左のメニューから塗り、枠、影、:hover、カーソル、押下変化を切り替え、同じ場所にあるボタンの見た目と反応だけを変えられます。各項目は手がかりの有効と無効を保持する設定なので左のメニュー自体にもトグルUIを使っています。デモ本体には同じONとOFFを切り替えるトグルUIも比較対象として置き、現在の状態を操作する形そのものへ残す違いも見られるようにしています。
このデモのように背景が単純で、塗り、枠、ラベルによって周囲の要素と区別でき、操作結果が同じ場所へすぐ返る条件では、私はホバーと押下変化の両方がないものを一番自然に感じました。キーボード操作の:focus-visibleは別に残しています。操作の多い場所ではカーソルを重ねるたび、押すたびに色や形が変わると一回ごとの変化は小さくても繰り返す中で少し気持ち悪さがありました。
ここで外しているのはホバーや縮小といった装飾的な反応です。フォーカス、選択中の状態、処理中、完了といった操作に必要な情報まで削ってよいわけではありません。WCAG 2.2のフォーカスの可視化はキーボードのフォーカスが視覚的に分かることを求めています。名前・役割・値では操作部品の名前、役割、状態をプログラムから判別できること、ステータスメッセージではフォーカスを移さない処理結果も支援技術から取得できることが示されています。スクリーンリーダーへ状態を伝えるのは押下アニメーションではなく、HTMLの意味と状態変化の通知です。
このデモでは手がかりを分離し、自分の判断がどこで変わるかを見ています。ここで得られるのは完成画面の正解ではなく、何を次の検証へ戻すかという比較の基準です。実装を減らすことと検証を減らすことは別です。ホバーを外すこと自体を目的にすると好みの衝突になりやすいので、実際の文章や画像の中でボタンを見つけられるか、マウス、タッチ、キーボードで状態を追えるか、操作結果を認識できるかを確かめて残す反応を決めます。情報が多い画面ではデモで重複に見えた変化が操作対象を区別する手がかりになります。
ボタンの手がかりは操作の影響に合わせて増減します。申し込みの確定やデータの削除のように誤操作の影響が大きい場所では、独自の形を学ばせずラベルと状態を明確にします。一方で何度も触れる操作では、関係を揃えた上で重複する反応を減らせます。
ボタンから状態へ
同じように押すUIでも、ボタン、トグル、ラジオボタンでは操作後に残るものが異なります。通常のボタンは送信や保存など一回の処理を起こします。トグルはONとOFFを切り替え、どちらが選ばれているかを次の操作まで保持します。ラジオボタンやセグメントUIは複数の候補から一つを選び、選択中の項目をほかの候補との関係で示します。
違いは形よりも操作と状態の関係にあります。例えば「状態を変更」というボタンだけでは、押した後にONとOFFのどちらになったかを別の場所へ表示する必要があります。トグルであればつまみの位置や塗りによって現在の状態を操作する場所そのものへ残せます。一方で「ファイルを書き出す」のように処理を一度実行する操作をトグルへ置き換えても、保持する状態がないため形と機能が噛み合いません。
Button Cuesにトグルを並べたのは、ボタンらしい見た目の比較だけでなくこの違いを見るためです。押せるかどうかに加え、押した結果が一時的な処理なのか、次まで続く状態なのかを決めると使うUIも変わります。
重要なのは見た目だけでなく、押せることを示して入力を受け取ったことを返すまでの流れです。処理中であれば待っている状態を見せ、完了したら何が変わったかを伝えます。見た目が慣習に沿っていても反応がなければ操作できたのか分かりません。反対に最初は見慣れない形でも一度の操作で関係が分かり、その後も同じ反応が続けばサイト内の慣習になります。
Button Feedbackでは同じ時間で終わる処理に対して、完了時だけ結果を返すもの、処理中を文字で返すもの、完了までの進捗も返すものを並べました。操作結果が同じでも途中の反応によって何を待っているかの分かり方が変わります。
操作を戻せること
操作後の反応には、入力を受け取ったことを知らせるだけでなく次に取れる行動を残す役割もあります。その一つがUndoです。誤操作を防ぐ方法を操作前の確認だけに置くと、利用者は毎回そこで立ち止まることになります。先に触れたように同じ確認が繰り返されれば、内容を読むより確認ボタンを押すこと自体が習慣になりやすくなります。
Undoは安全性を操作後にも分けます。削除や並べ替えを一度反映し、その結果を見た上で元へ戻せるようにすれば、意図した操作まで確認で止めずに済みます。操作によって戻せる時間も変わります。通知のように直後だけ判断できればよいものは一時的なUndoで足りますが、文書編集やレイアウト変更では履歴を残した方が過去の状態をたどれます。
Undo Actionsでは同じ削除を、操作前に毎回確認するもの、削除後の5秒間だけ戻せるもの、履歴から後でも戻せるものに分けました。最初の結果はどれも同じですが、確認のために止まる位置とやり直せる時間が異なります。
Undoの採用条件は画面を元の見た目へ戻せるかではなく、技術的にも業務上も操作の副作用を回収できるかです。ブラウザ内の並べ替えは状態を保存すれば戻せます。データベースの削除は論理削除や履歴が必要になります。外部APIへの送信、決済、権限の変更は送信先で起きた処理まで戻せない場合があります。Undoの実装には戻すためのデータ、期限、複数人で操作した場合の整合性も必要です。
実務では操作の可逆性、失敗が及ぶ範囲、回復の実装コストを分けて見ます。可逆性が高く影響が小さい操作は先に結果を見せてUndoを残す。完全には戻せないが実行を遅らせられるなら、下書き、保留、送信待ちの時間を用意する。外部へ即時に影響する操作は実行前に対象と結果を明確にする。確認かUndoかをUIの好みで選ばず、どこまで戻せるかを先に決めます。
配置で関係を伝える
操作するものが一つならボタンのラベルだけでも対象を示せます。照明やコンロのように同じ形の操作が複数並ぶと、どのボタンがどの対象を動かすかという関係も伝えなければなりません。一つずつ名前を付ける方法もありますが、対象と操作の配置を揃えれば位置そのものを手がかりにできます。
ドナルド・ノーマンが紹介している部屋の平面図に合わせた照明スイッチはこの対応づけが分かりやすい例です。四つの部屋が二行二列に並んでいるならスイッチも同じ並びにする。一列に並べたスイッチのラベルを順番に読む代わりに、部屋の位置と手元の位置を重ねて対象を選べます。
Spatial Mappingでは部屋とスイッチを2×2から5×5まで切り替えられます。初期状態は4×4です。部屋と同じ配置と幅に合わせて折り返す横並びの配置に切り替え、ボタンの大きさと押した後の反応は変えず並びだけを変えています。対象の部屋はランダムに選ばれ、一度押した照明は点灯したまま残ります。青い枠の部屋に対応するスイッチを選び続けると、個々のボタンが同じでも配置によって関係の追い方が変わります。左のメニューには最初のクリックからの経過時間と誤操作の数を残しています。
ここで対応づけているのはボタンらしさではなく、離れた二つの構造です。操作対象を選ぶ場合は部屋とスイッチを揃え、現在地を示す場合は実際の経路と表示の形を揃える。同じ考え方を使っても、何と何を結びつけるかによってUIの役割は変わります。
ストーリーの構造と現在地
私が担当したHONKA REFRAMEでは、ストーリーの切り替わりに合わせてデスクトップの移動方向を変えています。TOPからCONCEPTまでは馴染みのある縦スクロールで、このクラスの思想へ入っていく導入です。ABOUTに入ると横へ変わり、PURPOSE、CURRICULUM、SUPERVISORとクラスを構成する考え方、学び、関わる人の関係を広げます。最後のENTRYでは再び縦へ戻り、問いに向き合う時間から応募へ向かう行動に収束します。軸の変更は情報の役割が変わる境界を明示するために使っています。
右下のUIは縦、横、縦と折れる経路を小さな地図へ置き換え、現在地を示す点がスクロールと同期してその上を移動します。これから進む方向が途中で折れることと、この先にいくつのセクションがあるかを画面が動く前から暗に示します。移動先を選ぶ役割は文字のあるナビゲーションが担い、セルから各セクションへ移動する機能は副次的なものです。
これに近い例はスライダーの下に並ぶ現在地表示です。横に並んだ点の数がスライドの総数を示し、色の変わった点が現在位置を示します。点に名前が書かれていなくてもスライドの順序と点の順序が揃っているため、移動に合わせて関係を追えます。
この制作ではストーリーの切り替わりが先にあり、その境界を示すスクロール軸を決め、同じ構造を右下のUIへ縮約しています。操作方法は慣習的な縦スクロールに預け、サイト固有の構造は画面の移動方向と現在地表示に表しました。
この判断はストーリーの境界を移動として見せるブランドサイトの条件に寄っています。SaaSの管理画面やECサイトの購入導線のように、日常的な反復と素早い比較が優先される場所ではスクロール軸の変更が情報より先に意識される可能性があります。HONKA REFRAMEの形を応用することではなく、目的に必要な情報の切り替わりがあるから移動を変え、その結果をUIが補助するという順序の例です。
何を残すか
慣習に従えば必ず分かりやすくなるわけではありません。見慣れた部品を並べても情報の優先順位や操作後の状態が曖昧であれば迷います。反対に画面固有の変化があっても、操作方法が分かり状態を追えるなら関係を理解できます。
実務ではWebサイト全体に共通する判断と、状態を持つUIに必要な判断を分けます。まず共通するのは次の三つです。
- 対象とする人が操作できる場所と方法を訪問した時点の知識から予測できるか
- 入力によって起きる変化が情報の切り替わりや進む方向を伝えているか
- その変化の中で現在地と次に起こることを追えるか
フォームの送信、設定の変更、データの削除など状態を持つ操作では、ここに選択中、処理中、完了と失敗の表示を加えます。状態は視覚と支援技術の両方から追えるようにし、失敗からどこまで戻すかは操作の影響と実装コストに合わせて決めます。
操作する場所や方法を見つけるために説明が必要なら、まず入力の部分を慣習へ戻します。特に申し込みや削除では明確なラベル、結果、取り消す方法を残します。一方で入力方法を変えず、画面の変化そのものが情報の構造を伝える場合は、すべてを見慣れた動きへ揃える必要はありません。
操作方法は既存の慣習に預け、画面固有の構造は操作によって何がどう変わるかに表す。独自のUIを加える場合も新しい操作方法を学ばせるのではなく、その構造と現在地を既知の関係へ対応づけます。
慣習は守るべき形の一覧というより、説明を始める前から借りられる知識です。これまでのノートで見てきた形と変化は、操作へ置き換えると手がかりと反応になります。何を操作できると予測し、触れたときに何が返り、その経験が次の操作へどう残るか。操作を一回の入力ではなく前後の関係として見ることで、慣習を残す場所と独自の関係をつくる場所を分けられます。