UIと認知負荷の関係を構造的にとらえる
前回の記事でヒックの法則を取り上げました。選択肢の数を絞る、カテゴリ分けで段階的に選ばせる、推奨オプションを示して実質的な選択を減らす。いずれも「選択肢の数を管理する」という同じ原則から導かれる設計手法でした。
ただ、実際にUIと対峙するユーザーを観察していると、選択肢の数は適切なはずなのにユーザーが迷っている、という場面に出会うことがあります。メニュー項目は5つしかないのにスムーズに操作できない画面。オプションを3つに絞っても離脱率が改善しない設定フロー。選択肢の数だけでは説明しきれない認知的なつまずきを感じることがあります。
この記事は、そんな古典的なヒックの法則が扱う選択肢の数の先にある「認知負荷」を、認知負荷理論という考え方によって整理を試みた備忘録です。
ヒックの法則が扱えない領域
前回の記事で確認した通り、ヒックの法則は等確率で出現 するN個の選択肢に対する反応時間が選択肢の数の対数に比例するという予測モデルです。選択肢の数というひとつの変数だけで意思決定時間を予測できる。そのシンプルさが故にこの法則はこれまで長く支持されてきたのだと思います。
一方で、シンプルさだけでは説明がつかないこともあります。ヒックの法則は選択肢の数を扱いますが、選択肢の提示方法については何も言及していません。実際には、レイアウト、色、タイポグラフィ、ラベルの明確さなど選択肢の提示方法をとっても多くの要素が関係しているはずです。
同じ5つのメニュー項目でも、論理的にカテゴリ分けされて視覚的な階層を持つ場合と、ランダムに並んでいる場合では、同じユーザーでもその体験はまったく異なるはずです。また、ユーザーの熟達度や情緒も考慮されていません。
現実的には、選択肢が多い複雑なUIほど、ヒックの法則だけで認知的な負荷を捉えて説明することには限界があります。選択肢の数よりも広い枠組みで認知負荷を捉えるには、どのような考え方があるのでしょうか。
認知負荷理論の3つの負荷
認知負荷理論は、オーストラリアの教育心理学者ジョン・スウェラーが1988年の論文で提唱しました。
出発点は、ジョージ・ミラーが1956年に示したワーキングメモリの容量制限です。ミラーの研究では短期記憶の容量は「7±2」のチャンクとされていましたが、スウェラーはさらに踏み込んで、情報処理中に有効に使えるワーキングメモリは2〜3項目程度だと主張しています。人間の認知的な処理能力には限界があり、その限界を超えない設計をすべきだという原則は、もともとは教育設 計の文脈で生まれたものですが、それがUI設計にも応用されています。
認知負荷理論では、情報処理にともなう認知負荷を以下の3つに分類しています。
内在的負荷
タスクそのものの複雑さに由来する負荷で、タスクの難易度とユーザーの既有知識によって決まる
例えば、確定申告のフォーム入力は、UIをどれほど洗練させてもタスク自体が複雑で、天気アプリで気温を確認するタスクとは根本的に負荷の水準が異なる、という考え方
外在的負荷
情報の提示方法に起因する不必要な負荷で、UIデザイナーが最も直接的に介入できる領域
同じタスクでも、乱雑なレイアウトや一貫性のないナビゲーションや視覚的なノイズがあれば外在的負荷は跳ね上がるが、情報が整理されていて視覚的な階層が明確でユーザーの注意が適切に誘導されていれば低く抑えられる、という考え方
有効負荷
学習や理解の深化に使われる認知リソースのことで、ユーザーがシステムのメンタルモデルを組み立てるために費やす認知的な努力を指す
初めて使うアプリのチュートリアルは認知負荷を発生させますが、それによって2回目以降の操作が速くなるのであれば、その負荷は有効だったと評価する考え方です。
この3つが示す設計の方向性は、外在的負荷を削って、浮いた認知リソースを有効負荷に回す、ということです。
ヒックの法則との関係で言えば、ヒックの法則は主に内在的負荷の一側面、つまり選択肢の数がもたらす情報量を扱っていたと捉えられます。選択肢を 減らす、カテゴリ分けするという設計指針は、内在的負荷の管理です。
認知負荷理論はそこに、提示方法の問題である外在的負荷と、学習に寄与する有効負荷という2つの軸を加えた考え方であると整理できます。
UIにおける外在的負荷
3つの認知負荷のうち、UIデザイナーが日々の仕事で最も手を入れられるのは外在的負荷です。認知負荷理論から導かれた原則を、いくつかUIの文脈に翻訳してみます。
分割注意効果の回避
関連する情報が物理的に離れた場所に置かれていると、ユーザーはそれらをワーキングメモリ上で統合しなければならず、外在的負荷が増します。
フォームのバリデーションで考えるとわかりやすいです。入力エラーが発生したとき、エラーメッセージが画面上部にまとめて表示される設計を見かけることがあります。ユーザーは上部のメッセージを読んで、どの入力欄に対応するのかを探しながらスクロールして該当フィールドを探す。これは典型的な分割注意です。
エラーメッセージを該当フィールドの直近に置けば、この統合コストはほぼなくなります。関連する情報は空間的に近接させるというゲシュタルト原則の近接の原理が、認知負荷理論の側からも裏付けられています。
冗長性効果の回避
同じ情報を異なる形式で繰り返すと、冗長な処理が発生してかえって外在的負荷が増す現象です。
例えば、見ただけで意味が伝わるゴミ箱アイコンに対して、テキストラベルで「削除」を付け、さらにツールチップで「この項目を削除します」と表示する。一見丁寧ですが、同じ情報の3重提示はワーキングメモリに余計な処理を 要求しています。
ただし、アイコンの意味が曖昧な場合にはテキストラベルの併記は冗長ではなく必要な補完です。アクセシビリティの観点からも、アイコンだけでは伝わらない場面もあります。つまり、そのアイコンだけで対象ユーザーに伝わるかどうか、が判断の分かれ目になります。
モダリティ効果
人間の視覚チャネルと聴覚チャネルにはそれぞれ独立した処理容量があり、両方を使うと負荷を分散できるという考え方です。
実務での応用場面は限られますが、オンボーディングで視覚的なアニメーションとナレーション音声を併用したり、ゲームコンソールなどでエラー発生時に赤枠のハイライトとコントローラーの振動を組み合わせたりするケースがこれにあたります。
視覚的ノイズ
画面上の要素数、使われている色の種類、余白の比率。これらが総合的に視覚的複雑さを構成し、外在的負荷に影響します。
最近では、この視覚的複雑さを定量的に測るツールも出てきています。Attention InsightはFigmaプラグインとして、デザイン中にヒートマップを生成できます。以下は実際にヒートマップを生成している様子です。

こうしたツールの数値だけで設計を判断するわけにはいきませんが、外在的負荷を定量的に捉えようとする方向性自体は、従来の経験や主観に頼ったUI評価を補完するものと言えるかもしれませ ん。
認知負荷は静的ではないことの留意
認知負荷理論の古典的なモデルは、ユーザーの認知状態をどちらかといえば静的に扱っています。しかし実際には、同じUIに対する認知負荷は、ユーザーの情緒や疲労やタスクの文脈で変動します。
ストレスや不安はワーキングメモリの実効容量を下げると言われています。リラックスしているときには問題なく使えるUIでも、高ストレス下では処理しきれなくなって投げ出したくなることもあると思います。医療現場の電子カルテ、緊急通報システム、災害時の情報表示などの、ただちに人命に関わるような環境で使われるUIでは、見間違いや誤認が重大インシデントにつながることから認知負荷の変動幅を織り込んだ設計が求められるでしょう。
マルチタスク環境の問題もあります。通知、メッセージ、バックグラウンドの情報更新などの割り込みのたびにスイッチングコストが発生し、認知負荷が蓄積されていきます。無限スクロール、自動再生、プッシュ通知といった設計パターンが、ひとつひとつは小さな認知コストでも、積み重なればユーザーの認知リソースをじわりと消耗するのです。
認知負荷理論をUIデザインに反映する
ヒックの法則が選択肢の数を管理するための方法論だとすれば、認知負荷理論は認知負荷を3つに分解して分析するための枠組みです。UIのわかりにくさに直面したとき、次のような問いが設計判断の手掛かりになります。
このタスク自体の複雑さはどの程度か
分割して一度に処理する量を減らせないか
情報の提示方法に起因する無駄な負荷がないか
関連する情報 が空間的に離れていないか
同じ情報を冗長に繰り返していないか
視覚的なノイズ、つまり不要な装飾や一貫性の欠如や過密なレイアウトがないか
ゲシュタルト原則で知覚レベルの整理ができているか
ユーザーがシステムを学ぶための認知的な余裕を残せているか
ストレスや疲労の下でも使えるUIか
マルチタスク環境での使用を想定しているか
ヒックの法則はこのうち、内在的負荷の一側面である選択肢の情報量を扱っていました。認知負荷理論は、そこに提示方法の整理、学習の支援、動的な変動への対応を加えます。
選択肢の数は適切なのに使いにくいと感じたとき、その原因が外在的負荷にあるのか、内在的負荷の分割が足りないのか、ユーザーの感情や文脈に起因するのか。認知負荷を数ではなく構造で捉えることが、問題の所在を特定する助けになるのではないかと思います。
わかりやすいUIを実現するには、選択肢の数のような内在的負荷だけでなく、不必要な認知的摩擦、つまり外在的負荷を減らしていくことが求められるというこの構造は、この先人間がデザインしようがAIが生成しようが変わらないきっと変わらないはずです。



