UIでは、長い情報をどこまで最初から見せるかという判断が頻繁に出てきます。

画面が狭いモバイルでは折りたたみ、広いPCではすべて表示する。直感的には分かりやすい方針ですが、実際には画面幅だけで決めるとうまくいかないことがあります。

たとえば、今回このテーマを考えるきっかけになったのは、ChatGPTでPCとモバイルの長いコードブロックの見え方が違っていたことでした。狭い画面ほど情報を隠した方がよさそうなのに、操作の流れまで見ると逆の設計にも理由がありそうです。

ただし、これはChatGPT固有の話ではありません。

FAQ、長い補足、目次、「続きを読む」、設定画面、広告モーダル、確認ダイアログなど、情報を隠すか、そのまま見せるかという判断には同じ問題があります。

重要なのは、表示面積だけでなく、情報を隠すことで増える操作や判断、そしてユーザーの作業を中断するコストまで見ることです。

「モバイルでは折りたたむ」というルールはない

UI/UXには「PCでは展開、モバイルでは折りたたみ」のような固定ルールがあるわけではありません。

折りたたみを検討するときは、少なくとも次の3つを比較する必要があります。

観点問題になること
情報の占有長い情報が画面を使いすぎて、次に読みたい内容へ到達しにくくなる
操作コスト展開、閉じる、ページ移動など、目的達成までの操作や判断が増える
中断コスト読んでいる流れを止められ、元の文脈へ戻る必要が生まれる

折りたたみは、表示面積を減らす代わりに操作を増やします。

逆に、すべて表示すれば操作は減りますが、情報量や移動距離が増えることがあります。

したがって見るべきなのは、隠すことで減らせる負担と、隠したことで増える負担のどちらが大きいかです。

Progressive Disclosure:必要になるまで情報を見せすぎない

折りたたみUIと関係が深い考え方の一つが、Progressive Disclosureです。日本語では「段階的開示」などと呼ばれます。

最初からすべての情報を同じ強さで提示するのではなく、まず主要な情報を見せ、詳細は必要になったときに開けるようにします。

たとえば長い補足情報なら、次のような形です。

主要な説明

┌─────────────────────────┐
│ 補足情報の冒頭            │
│ ...                      │
│ [すべて表示]              │
└─────────────────────────┘

次の説明

補足を必要としない人は、そのまま先へ進めます。必要な人だけが詳細を開けます。

Aaron SpringerとSteve Whittakerの2018年の研究「Progressive Disclosure: Designing for Effective Transparency」では、AIシステムの透明性を題材に、情報を段階的に提示する方法を検討しています。

この論文はアコーディオンやコードブロックを研究したものではありません。それでも、複雑な情報を最初からすべて提示するのではなく、ユーザーが理解するために必要な情報量を段階的に調整するという考え方は、一般的なUIを考えるうえでも参考になります。

一方で、Progressive Disclosureを「長いものは隠せばよい」と理解すると逆効果になります。

多くのユーザーが結局その情報を開くのであれば、折りたたみは情報量を減らしたのではなく、読む前に追加操作を要求しただけになるからです。

そこで重要になるのが操作コストです。

Interaction Cost:1クリックだけを数えない

UIの操作コストを考えるとき、「クリックが1回増えるだけ」と評価するのは十分ではありません。

ユーザーは実際には、次のような処理をしています。

  1. ここに追加情報があると気づく
  2. 今読む必要があるか判断する
  3. 操作できる場所を見つける
  4. クリックまたはタップする
  5. 表示が変わった後に読む位置を確認する

つまり、コストにはクリックやタップだけでなく、認識と判断も含まれます

FAQが分かりやすい例です。

質問が20件あり、そのうち1件だけ確認したいのであれば、すべてを折りたたんで質問だけ一覧できることに意味があります。

しかし、利用規約の説明や手順書のように多くの項目を順番に読むのであれば、項目ごとに毎回開かせるUIはかえって負担になります。

見た目がすっきりしていることと、利用時の負担が小さいことは同じではありません。

スクロールも一つの操作手段として考える

情報を展開したままにすると、当然ページは長くなります。

ただし、長いこと自体が直ちに使いにくさを意味するわけではありません。特にモバイルでは、縦方向のスクロールやフリックは非常に基本的な操作です。

Chaoran Chenらの2022年の研究「ScrollTest: Evaluating Scrolling Speed and Accuracy」は、11種類のスクロール手法・デバイスを比較し、flickingとtwo-finger scrollingが特に高速だったと報告しています。

この研究から「モバイルでは折りたたむべきではない」とまでは言えません。研究対象も特定のWeb UIではありません。

ただ、不要な情報をフリックで簡単に通過できる場合、折りたたみによって追加のタップを要求するより、そのまま表示しておいた方が流れを壊さないことがあります。

逆に、巨大な表や固定領域のように、スクロールしても簡単に避けられない情報では折りたたみや別表示の価値が高くなります。

見るべきなのはページの長さだけではなく、不要な人がどれだけ簡単に通過できるかです。

中断コスト:閉じる1回だけでは終わらない

操作コストより見落とされやすいのが、中断のコストです。

Web小説やニュース記事を読んでいる途中で突然ポップアップが表示される場面を考えると分かりやすくなります。

文章を読む

文章を読む

ポップアップが表示される

読むのを止める

内容を認識する

閉じる場所を探す

閉じる

どこまで読んだか確認する

文章へ戻る

問題は「閉じるボタンを1回押す」ことだけではありません。

進行中のタスクを止め、別の対象へ注意を移し、その後に元の作業状態を取り戻す必要があります。

タスク中断の研究では、この復帰に時間や認知的なコストが発生することが知られています。

Duncan Brumbyらの2013年の研究では、作業中に認知負荷のある別タスクで中断した場合、元の作業へ戻るまでのresumption lag(再開遅延)とエラーの関係を調べています。

研究室で行うデータ入力タスクとWebサイトのポップアップは同じではありません。

それでも、「中断した後は、閉じれば元通り」というわけではない点は重要です。

文章、フォーム入力、コードレビューなど、直前までの文脈を保持しながら進める作業では、操作そのものより中断後の復帰が大きな負担になることがあります。

「摩擦」は必ず悪いわけではない

ここまで操作や中断を減らす話をしてきましたが、摩擦をなくすことが常に正解というわけでもありません。

Nicolas Ruizらの2024年の研究「Design Frictions on Social Media」では、無限スクロールの途中に意図的な操作を要求するUIを実験しています。摩擦を加えた条件では投稿内容の記憶が改善した一方、多くの参加者がそのUIをフラストレーションと感じました。

ECサイトの購入確認、危険な操作の確認、削除、公開、権限変更などでは、あえて一段止めることに意味があります。

ここでは操作が増えること自体が目的ではなく、誤操作を防ぐためにユーザーへ再確認を促しています。

一方、文章を読む、検索結果を見る、長い回答を読むといった場面で同じ摩擦を入れると、主タスクを邪魔するだけになる可能性があります。

つまり評価すべきなのはクリック数の少なさではなく、その摩擦に役割があるかどうかです。

PCとモバイルで判断が変わる理由

同じ情報でも、PCとモバイルではコストの重みが変わります。

たとえば長いコードや長い補足を表示する場合、次のような違いがあります。

PCモバイル
長い情報を全部表示ページ全体を占有しやすい不要ならフリックで通過しやすい
折りたたむ全体を俯瞰しやすくなる読みたいときに追加タップが必要
主な摩擦になり得るもの情報量・移動距離操作の追加・読む流れの中断

もちろん、これは「PCでは必ず折りたたむ」「モバイルでは必ず展開する」という意味ではありません。

重要なのは、viewportの幅だけではなく、そのデバイスでユーザーがどのように情報を移動するかまで見ることです。

Lasse EinfeldtとAuriol Degbeloの2021年のモバイルUX研究では、短いフォームにおいて、タブとスクロールというナビゲーション方式の間にUX上の差が見られなかったと報告されています。

この研究も「スクロールが常に正解」と示すものではありません。むしろ、モバイルならタブや折りたたみの方が優れている、という単純な前提を置けないことを示す材料として読む方が適切です。

具体例として長いコードブロックを考える

ここで、冒頭のChatGPTの例に戻ります。

今回のきっかけは、PCとモバイルで長いコードブロックの見え方が異なっていたことでした。

仮に200行のコードが回答の途中にあるとします。

説明A

コード 1行目
コード 2行目
...
コード 200行目

説明B

PCでは、説明とコードを行き来したり、回答全体を見渡したりすることがあります。この場合、長いコードが常に展開されていると、次の説明へ移動するまでの距離が大きくなります。

一方、モバイルでは回答を上から下へ連続して読むことが多く、不要なコードならフリックで飛ばせます。コードを読みたい人に毎回展開操作を要求すると、スクロールだけで完結していた流れに別の操作を追加することになります。

もしこのように評価するのであれば、PCでは折りたたみ、モバイルでは展開したままにする設計も成立します。

ただし、ここからChatGPTの実際の設計意図まで断定することはできません。

この例の価値は、特定サービスの正解を当てることではなく、同じコンテンツでもデバイスごとに異なるコストを比較する必要があると分かる点にあります。

折りたたむか迷ったときに見るポイント

フロントエンドでアコーディオンや「続きを読む」を実装するときは、画面幅だけで決めず、次の順序で見ると判断しやすくなります。

1. この画面の主タスクは何か

記事なら読むこと、APIドキュメントなら必要な仕様を探すこと、設定画面なら値を変更することが主タスクになります。

同じ長文でも、主タスクが違えば扱いは変わります。

2. その情報はどれくらいの人が必要とするか

ほとんどの人が読む内容なら、折りたたむことで毎回展開操作が発生します。

一部の人しか必要としない補足なら、Progressive Disclosureの効果が出やすくなります。

3. 不要な人は簡単に通過できるか

数回のフリックで通過できるなら、展開したままでも負担が小さい場合があります。

簡単に避けられない領域なら、折りたたみや別表示の価値が上がります。

4. 開く操作が流れを壊さないか

展開した瞬間にページ位置が大きくずれたり、別ページへ移動したりすると、単純な1タップ以上の負担になります。

操作後にユーザーがどこを見ればよいのかまで確認する必要があります。

5. あえて摩擦を入れる理由があるか

削除、決済、公開、権限変更など、間違えると影響が大きい操作では、効率だけを追求しない方がよい場合があります。

ここでは追加確認が邪魔なのではなく、安全のための設計になります。

よくあるUIを同じ軸で見る

この考え方を使うと、アコーディオン以外のUIも同じ軸で評価できます。

UI隠す・中断するメリット注意したいコスト
長いコードブロック本文全体を俯瞰しやすい読む人に展開操作を要求する
FAQ多数の質問を一覧しやすい多くの項目を読むなら操作が増える
目次本文の占有を減らせる頻繁に使うなら開閉が邪魔になる
長い補足・注釈本論を読みやすく保てる重要情報まで隠す危険がある
広告モーダル広告へ強く注意を向けられる主タスクを強制的に中断する
削除確認ダイアログ誤操作を防ぎやすい頻繁な操作では摩擦が積み重なる

大切なのはコンポーネント名ではありません。

そのUIによって何のコストを減らし、代わりに何のコストを増やしているかを見ることです。

画面幅より先に、ユーザーの流れを見る

レスポンシブデザインでは、画面幅に応じてレイアウトを変える必要があります。

しかし、情報設計まで単純に「狭いから隠す」としてしまうと、モバイルでかえって操作が増えることがあります。

反対に、何でも展開したままにすればよいわけでもありません。長い情報が主タスクを押し流すなら、折りたたみには十分な意味があります。

判断の中心に置きたいのは画面サイズではなく、ユーザーがその画面で連続して何をしているかです。

読む、探す、飛ばす、入力する、確認する、戻る。

その一連の流れの中で、情報を隠すことが助けになるのか、それとも新しい操作や中断を増やしてしまうのかを見る必要があります。

「折りたたむか、全部見せるか」で迷ったときは、見た目のすっきりさより先に、ユーザーが目的を達成するまでに何を増やし、何を減らしているのかを確認すると判断しやすくなります。