はじめに
旅行の計画を立てるとき、あなたはどこから手をつけますか？
まずフライトの料金だけ調べて、そこから宿を決める人もいます。一方で、航空券・ホテル・レンタカー・観光地をすべてリストアップして、全体が揃ってから予約を入れる人もいます。どちらが「正しい」ということはありません。同じ「旅行を計画する」という行動でも、アプローチはかなり違います。
新居で鍵の置き場所を決めるときも同じです。一度決めれば自然と覚えられる人もいれば、スマートフォンにリマインダーを設定する人もいますし、「絶対に忘れそうだから」と鍵を複数本複製しておく人もいます。
こうした違いは、意志の強さや几帳面さの差ではありません。人が情報を処理し、記憶し、判断する仕組み、つまり認知のパターンに、もともと多様性があるからです。
Microsoft が公開している Inclusive Design for Cognition Guidebook は、この認知の多様性に正面から向き合ったガイドです。この記事では、その考え方を紹介しながら、Web アプリ設計にどのような問いをもたらすかを考えてみます。
関連記事として、以前書いた Webアクセシビリティは『特別な配慮』ではなく、すべての人の使いやすさであるという話 もあわせて読むと、今回の話がよりつながりやすいと思います。
認知の多様性とは 🧠
「認知」とは、情報を取得し、保存し、処理し、想起する一連の精神的プロセスです。私たちはこの仕組みを使って、何かを学び、注意を向け、判断を下し、ものごとを覚え、他者とやりとりしています。
大事なのは、この仕組みが人によって大きく異なるという点です。
Microsoft のガイドでは、同じ診断名を持つ人でも必要な支援は大きく異なり、逆に異なる診断名でも似たニーズを持つ場合があると説明しています。だからこそ、「この障害のある人のために設計する」という出発点だけでは不十分です。
代わりにガイドが促しているのは、その体験がどのような認知的負荷を求めているのかから考えるアプローチです。
“What kind and what level of cognitive demands do our experiences place on our users?”
この問いは、障害の有無にかかわらず、すべてのユーザーに向けられています。
Microsoft のガイドから学んだこと 📖
モチベーションから始める
ガイドが最初に示すのは、Start with motivation という考え方です。
私たちはプロダクトを設計するとき、つい「どんな機能を追加するか」から考えがちです。しかしガイドはその逆を提案しています。まず「作りたい」「学びたい」「つながりたい」といった人間のモチベーションから出発し、そこからゴールとタスクを設計する、という流れです。
ガイドでは、故 Dr. Bruce Baker の考えに基づく次の式も紹介されています。
For any task to be successful, motivation must equal or surpass cognitive load.
つまり、どれだけ機能的に正しくても、タスク完了に必要な認知的負荷がユーザーのモチベーションを上回ると、その体験は成立しにくくなります。
5 つの認知的負荷
ガイドは、認知的負荷を 5 つの観点で捉えています。Web アプリに引き寄せると、次のように考えられます。
| 認知の種類 | 日常の場面での問い | Web アプリへの問い |
|---|---|---|
| 学習 | 新しいレシピは動画で覚える？自分で試す？ | 初回ユーザーに必要なガイダンスは十分か？ |
| 集中 | 集中するときは無音がよい？少し雑音がある方がよい？ | 通知や自動更新は中断コストを増やしていないか？ |
| 意思決定 | 旅行は一部の情報だけで決める？全体を見てから決める？ | 重要な操作に必要な情報と結果が明確か？ |
| 想起 | 鍵の場所は自然に覚えられる？リマインダーが必要？ | 手順の途中で迷子にならないか？入力内容は保持されるか？ |
| コミュニケーション | 初対面と慣れた相手では接し方が変わる？ | UI の説明や支援は習熟度に応じて変えられるか？ |
この表を見ると、認知の多様性は決して特別な場面の話ではなく、日常の延長線上にあることが分かります。
認知の多様性を前提に共同設計する
もう一つ印象的だったのが、Co-create with cognitive diversity in mind という原則です。
ここで重要なのは、「特定の診断名を持つ人を想定する」のではなく、「集中しづらさを感じる人」「思い出すことに負荷を感じる人」といった体験ベースで考えることです。そうすると、ある診断のある人だけではなく、状況的に同じ困りごとを抱える人も一緒に設計に参加できます。
またガイドは、感情状態や置かれた文脈も認知に強く影響すると述べています。落ち着いたときには簡単な作業でも、疲れているときや焦っているときには急に難しく感じることがあります。認知はその人固有の特性だけではなく、状況によっても揺れるものだと捉える必要があります。
Web アプリ設計への示唆 💡
ここからは、私の解釈も交えながら、Web アプリ設計にどうつなげられるかを整理します。
意思決定を支える情報設計
削除、保存、設定変更、購入確定。Web アプリには、ユーザーが判断しなければならない場面がたくさんあります。
そのとき、「OK」「キャンセル」だけの UI になっていないでしょうか。元に戻せるのか、何が変わるのか、今の選択でどんな影響があるのか。そうした情報が不足していると、判断の負荷は急に高くなります。
一部の情報だけあれば判断できる人もいれば、全体像が見えないと決められない人もいます。だからこそ、重要な判断の前には十分なコンテキストを渡せているかを見直すことが大切です。
想起の負荷を減らす設計
ユーザーに「前に見たはず」「一度やったから覚えているはず」と期待していないかも重要です。
長いフォームで途中離脱したあと、入力内容が消えてしまう。管理画面でたまにしか使わない機能なのに、操作手順に毎回迷う。こうした体験は、想起の負荷をユーザーに押しつけている状態です。
Microsoft のガイドは、人が自分なりの方法で「置き場所」「思い出し方」「探し方」を作っていることに着目しています。Web アプリでも、進捗表示、自動保存、下書き復元、直前の操作履歴などは、ユーザーの想起を補う設計として機能します。
集中と中断のコスト
「通知は親切」「自動更新は便利」と考えがちですが、集中の途中に入る情報は、それ自体が認知的な割り込みになります。中断前の文脈へ戻る手がかりを残せているかどうかで、その UI のやさしさは大きく変わります。
たとえば、編集中に突然バナーが出る、別タスクの通知が頻繁に届く、オートリフレッシュで読んでいた位置がずれる。こうした挙動は、集中が切れたあとに「今どこを見ていたのか」「何をしようとしていたのか」を思い出す負荷まで発生させます。
W3C の認知アクセシビリティ ガイダンスとの接点
こうした視点は、W3C の Making Content Usable for People with Cognitive and Learning Disabilities とも重なります。
この文書は WCAG の適合要件そのものではありませんが、理解しやすさ、見つけやすさ、ミスの防止と回復、記憶への依存を減らすことなど、認知アクセシビリティの観点を具体的に補っています。
つまり、WCAG を満たしていても、まだ「認知的に使いやすい」とは言い切れないことがあります。Microsoft のガイドも W3C の COGA も、そのギャップに目を向けるための重要な手がかりだと感じます。
開発者として最初に持ちたい問い 🔍
ここまでを踏まえると、私は少なくとも次の問いを最初に持ちたいと思いました。
1. 一度やったら覚えてもらえる前提で設計していないか
初見では理解しづらい操作、たまにしか使わない設定、複数段階の手順は、とくに記憶への依存が強くなります。ラベル、補足テキスト、下書き保持、履歴表示などで、その負荷を減らせないかを考えたいです。
2. 一つの認知パターンだけを「普通」としていないか
情報を一覧で見たい人もいれば、ステップごとに進みたい人もいます。結果から逆算したい人もいれば、最初に全体像を把握したい人もいます。「想定ユーザー」という言葉の裏に、無意識に一つの考え方だけを置いていないかを疑うことが必要です。
3. モチベーションとタスクがつながっているか
ユーザーは何のためにこの画面を使うのか。この入力は何のために必要なのか。そうした理由が UI から伝わらないと、タスクは「やらされている作業」に見えます。モチベーションとタスクがつながるだけで、認知的な摩擦はかなり減ります。
おわりに 🌿
旅行の計画の立て方も、鍵の置き場所の覚え方も、人それぞれ違います。それは単なる好みではなく、認知の多様性の表れです。
Microsoft の Inclusive Design for Cognition Guidebook は、そうした違いを「例外」ではなく、設計の出発点として扱うべきだと教えてくれます。機能ではなくモチベーションから始めること。認知的負荷の種類を見ること。認知の多様性を持つ人と一緒に設計すること。その視点は、Web アプリにもそのまま持ち込めます。
私は、Web アプリをより直感的で使いやすいものにしたいなら、見た目や動線だけでなく、人がどう考え、どう迷い、どう思い出し、どう判断するかを学ぶ必要があると強く感じました。
まずは、「この UI は、ユーザーに何を覚えていてほしいと期待しているか？」という問いから始めてみるのがよいかもしれません。そこから、見えていなかった前提が少しずつ浮かび上がってくるはずです。