私のコントロールを隠さないでください: 隠れたインターフェースコントロールがユーザビリティに影響する

• 隠れたコントロールによってユーザーインターフェースのユーザビリティが低下する
• 過去には画面上に見えるメニューがユーザビリティを大きく改善する転換点として機能した
• 最近はモバイルや各種デバイスで再び記憶ベースの操作が求められる方向への回帰現象が起きている
• インターフェースデザインの複雑さと美的要素が、隠れたコントロール増加の主な原因である
• デザイナーは今、すべての主要機能を見える形にしてユーザーが探索できるよう、構造を見直す必要に迫られている

---

序論: 知識の所在とインターフェース

• 1960年代にDouglas Engelbartが**「知識は世界の中にあるのか、頭の中にあるのか」**という概念を提示した
• **「知識 in the world」**とは、操作コントロールがインターフェース上に現れており、ユーザーが記憶に頼らず直接見つけて使えることを意味する
  • 例: ドロップダウンメニューのあるグラフィカルインターフェース
• **「知識 in the head」**とは、ユーザーがすべてのコントロールやコマンドを覚えていなければならない環境を指す
  • 例: DOSのコマンドプロンプトでは、コマンド（DIRなど）を知らなければ何も操作できない

隠れたコントロールが増える理由と逆効果

• インターフェースの複雑さが増すほど、より多くのコントロールが視覚的に隠されるようになっている
• 見た目はより簡潔になるかもしれないが、初心者ユーザーにとっては操作がはるかに難しくなる
• 初期のドロップダウンメニューなどの「見えるコントロール」が登場したことで、コンピューターの大衆化と生産性は飛躍的に高まった
• しかしモバイル機器や新しい電子機器では、再び「記憶地図ベース」の操作を求める状況が広がっている
  • 例: iPhoneのフラッシュライト、通知の表示、Apple Payの起動などでは、適切な「ヒント」がないまま隠れた動作や特定のジェスチャーを覚えていなければアクセスできない

日常にある隠れたコントロールの事例

• 自動車のワイヤレスキーやドアハンドルにも隠れたコントロールがあり、使い方を知らなければ基本的なアクセスすら難しい
  • 例: 内部キーの位置や隠された鍵穴、特定のボタンシーケンスなど
• 車載ナビゲーションシステム（CarPlay上のApple Mapsなど）も、地図を広く見せるために重要なコントロールを隠す傾向があり、特定の領域をタップすることを知らなければ機能を使えない
• 時間ベースのコントロールも隠れた形のコントロールとして機能する
  • 例: コンピューターの電源ボタンは長押ししたときにだけ正常終了し、電子ドアロックの施錠も別のキーや長押しなど特別な操作方法を必要とする

隠れたコントロールによる一般的な問題と熟練ユーザーへの影響

• 音量を0にしてもアプリが勝手に音を出すなど、**「隠れた設定」**によってユーザーの直接的な命令が上書きされる現象が起きる
• 上級ユーザーであっても、コマンド型インターフェース（例: R、DOSウィンドウなど）では深刻な「知識 in the head」依存を経験する
• 徐々に原始的なインターフェースへ回帰する傾向が見られる

なぜ隠れたコントロールが増えるのか

• 機能が多すぎて画面にすべてを表示できず、可視性が低下する
• システムモード間の相互作用、複雑さの増大、デザイナーの美的志向や実装上の都合によって、コントロールの隠蔽が頻繁に起こる
• 実際には、ユーザーへの配慮よりもデザイン上の目的（美的完成度など）が優先されて生じている

成功事例とミッションクリティカルシステムの違い

• General Motorsのナビゲーションなど一部のシステムは、必要なコントロールを常に画面上に明確に表示し、初心者でも探索しやすい
  • 例: Buick LaCrosseの物理ダイヤルによるズーム機能など
• ミッションクリティカルなシステム（航空機、工場など）では、ほぼ必ず常時見えるコントロールを中心に設計される
  • 誰も、隠れたコントロールによって迅速な操作が妨げられるリスクを受け入れない

隠れたインターフェース擁護論とその限界

• 隠れたコントロールは世代間の不満の問題ではなく、実質的なユーザビリティの問題である
• 一部では「隠れた機能」を探すこと自体を利点として宣伝するが、実際にはアクセシビリティ低下が明白である
• ユーザーの立場から見れば、見つけられないコントロールは存在しないのと同じである

ユビキタスコンピューティングとコントロールの自動化・透明化

• Mark WeiserとDonald Normanは、技術が「透明に」背景へ退きながら動作する未来を予見した
  • 例: 自動車のエンジン制御は、ユーザーが操作する必要がないよう完全にバックグラウンドで自動調整される
• 自動化によってコントロールが完全に隠れるケースは、その必要性と文脈が明確である
  • しかしユーザー操作が必要な状況では、必ず明示的なコントロールが必要である

結論とインターフェースデザイナーの方向性

• インターフェースデザイナーは隠れたコントロールの使用を避け、すべての機能を「世界の中にある知識」に基づく形へ転換すべきである
• **コントロールの発見可能性（discoverability）**は依然として中核的な設計原則である
• 現代のインターフェースにおける発見可能性の低下は、むしろ初期コンピューター時代への後退現象である

参考文献

• Engelbart, D.C. (1962) などの主要文献の整理
• Apple Macintosh, The Psychology of Everyday Things, The Invisible Computer など関連書籍や論文を引用

著者情報

• Philip Kortum: Rice University心理科学科教授。ユーザビリティと信頼評価、グローバルヘルス、モバイルシステムなど多様な分野で、ユーザビリティ中心のシステム開発を研究している

[GN⁺]

Hacker Newsの意見

• 最近のスクロールバーを隠すデザインに不便さを感じるというユーザー体験の共有。記事中の一部の直感的な物理ノブの事例については、コストと実用性に限界がある点にも言及。また、トグルスイッチのラベルが現在の状態ではなく切り替え後の状態を意味していた経験から、混乱を覚えたという話
  • 実際のトグルスイッチ自体も曖昧なので嫌いだという立場。チェックボックスや押し込まれたボタンのほうがはるかに明確だが、モダン化の流れの中で犠牲になったのが残念
  • オーストリアの列車切符自販機で、即時検証トグルスイッチが混乱を招いた記憶。スクロールバーも細すぎてFPSゲーム並みの腕前まで必要なレベルで、水平スクロールバーのほうが便利なこともある。FirefoxとCSS標準にも苦言
  • macOSでは、システム設定やターミナルコマンドで常にスクロールバーを表示できることを案内
  • トグルが動作を意味するなら、必ず動詞（"TURN ON"）を使うべきで、それなら確実。状態を示す場合も "IS ON" のような明確な方式を提案。文脈上まれに紛らわしいケースを除けば、動詞を使えばほぼ確実だと思う
  • PgUpとPgDnのサポートもお願いしたい
• 古いToyotaを運転しているが、すべてのコントロールが常に目に入り、明確にラベル付けされ、指先で区別できる。これは複製自体も容易で、最低限のエンジニアリングだと見ているが、今の自動車メーカーの大半はこれすらできていないと判断し、実力不足だと評価
  • 同意する部分はあるが、「すべてのコントロールが見えているべきだ」と主張するのは、デザイナーを過小評価する見方でもある。実際には、運転中に必須のコントロールだけが露出し、残りは小さく複雑だったり隠れていたりする。シート高調整レバー、ボンネットオープンレバーなどは隠れているがアクセシビリティは確保されている。こうした細部を考慮したデザインの過程は単純でもtrivialでもなく、こうした部分を単純化して片づけることこそ、今のUX悪化の一因だという立場
  • これは実力の問題ではなくコストの問題だという見方。今は多数のボタンやノブを個別に作って組み立てるより、タッチスクリーンのほうが安くて作りやすい
  • 米国の自動車メーカーからシステム開発者として大量の採用オファーが来たが、Hacker Newsコミュニティでは「精神の健康を守りたいなら避けろ」という意見が多かったという経験の共有
  • 個人的にも、ノブなどの機械部品を別々に作るとカスタムモールドなどの製造コストが増えるので、画面に入れるほうがコスト面ではるかに効率的だと説明
• 画面スペース効率のためにUI要素を隠すのは理解できるが、使ったスペースを空けたまま隠すのは納得できない。IntelliJではプロジェクトツリー上のアイコンが隠れていて、マウスオーバーしないと出てこないが、わざわざそうする必要があったのか疑問
  • モバイル、デスクトップ、ノートPCの画面がかつてなく大きくなっている状況で、画面要素を隠す根拠に疑問。1984年のMacintoshの小さなモノクロ画面ですら、明確さと可視性のために画面比率を犠牲にしてでもボタンを配置していたことを回想
  • ある人は視覚的な「ノイズ」が集中を妨げると不満を言い、別の人は計器盤のようにすべてのコントロールやインジケーターが常に見えていてほしいと望む。IDEのデフォルト設定は、こうした極端な嗜好の両方を満たそうとしてバランスを取る折衷案。実質的には妥協であり、一部のツールは "no distractions mode" のようなモードで細かな設定を提供している
  • IntelliJのWindows版メニューもハンバーガーアイコンの中に隠れていて、空きスペースが多くなる問題がある。幸い設定で戻せるが、デフォルト値は理解しがたい
  • ボタンの存在も、どう表示されるかも知っているのに、たまにどこにあったか忘れて画面をぼんやり見つめてしまうことがある
  • 一部のアプリは逆に追加ボタンを隠しておらず、むしろ隠すオプションがあってほしいと思うこともある。Google Mapsに言及
• 車のスマートキーを使っているが、実際の鍵が隠されていて、しかも車のドアハンドルを分解しないと鍵穴が出てこないことすらあるなど、重要なコントロールを隠すのはユーザーに非常に不親切なエンジニアリングだと指摘
  • 自分もレンタカーで似た状況を経験した。リモートキーが故障して、荷物がすべて車内に閉じ込められたことがあった。物理キーの存在は知っていたが、ドアハンドル周辺に前の利用者が開けようとして付けた引っかき傷がたくさんあり、それで鍵穴の位置をすぐ特定できた
  • こうした状況はユーザーが基本的に知っておくべきで、Googleなどで情報を調べられるという主張。新車を受け取ってすぐバックアップ手段とその動作方法を確認した実例を挙げ、所有製品の基本把握の重要性を強調
• iPhoneでホームボタンが消えたことが、Androidへ移った理由のひとつ。家族の高齢者に説明したり使ってもらったりするのが難しくなったため。新しいPixelを買うとまず3ボタンナビゲーションを有効にするが、最近のアプリはボトムナビゲーションバー前提で、3ボタンに内容が重なって隠れるなどのUI上の欠点も指摘
  • 重要なUI要素は必ず見えているべきだという主張。Appleも時々この原則を破ると見ているが、たいていは抵抗していると評価。ホームボタン削除はUI要素を隠したというより相互作用の変換と解釈できる。直感的か優れているかには議論があるが、慣れれば利用時の摩擦はほとんどない点にも言及。iOSには画面上にドラッグできる小さな円形ショートカット（テキストラベル付き）を置くアクセシビリティ機能があることも案内
  • 一般ソフトウェアで音もなく消えるメニュー項目の現象も似ている。例として、MS Wordで読み取り専用ファイルの保存機能アイコンが完全に消えた点を挙げる。無効化状態で残しておき、保存時に理由を知らせて解決方法を案内するほうが、よりよい体験ではないかという提案
  • Androidを長く使っているが、ときどきiPhoneを借りるたびに、直感的でない、あるいは存在しない操作にいら立つ。PixelやSamsungのカメラ品質も良くなっており、Appleエコシステムへ移る理由がない
• 記事では、UIが消えるのは偶然やミスではなく、ユーザーロックインのための現象だという点が十分に扱われていないという意見。成長限界に達したソフトウェアでは、既存ユーザーの離脱を防ぐために直感的でない形でUIを変えるのだと解釈。デバイスを「使う」対象ではなく「内在化」された存在にして、離脱障壁を作る。UI習得の過程で新製品への乗り換え不安を誘発し、大手ソフトウェア企業の多くがこの方法を取る理由を説明
  • この仮説は断片的に見れば当たっているかもしれないが、実際には「複雑で混み合ったインターフェース」への反発も多い。ミニマリズムのトレンドや /r/unixporn など、多様なユーザー層が自発的にコントロールを隠す傾向も強い。GNOMEなどでも最近はミニマルなインターフェースが主流で、多くのユーザーは必要なときだけ機能を探して使えるので、選択的なものだと解釈
  • この方法は諸刃の剣で、初見ユーザーの流入を妨げる面もある。Appleのあらゆるインターフェースが1つのボタンに集中している点が嫌で、Androidのほうがしっくりくるという事例の共有。Appleへのさまざまな不満は別の理由でも存在
  • 非営利のOSSでも、無批判にトレンド追従しているように見える。Firefoxの頻繁なデザイン変更や、GNOMEなども同じ文脈
• 「アーティスト」型のデザイナーがUIの決定権を握ると、すっきりさに執着して直感的な使い方（affordance）や学習機会を無視する。航空機コックピット（非専門家には圧倒的だが、専門家にはすべてがラベル付き）の対比例が代表的
  • 一般家庭の蛇口にまで方向ラベルが必要なわけではないという反論。飛行機のコックピットは初心者にはむしろ過剰に圧倒的だという例でもある。インターフェースデザイナーは何が直感的かをよく理解しており、複雑な機能を単純なフォームファクタにうまく圧縮する能力を持っている。デザイン教育のない人がよりよい結果を出せると考えるのは、傲慢さと軽視に過ぎない。実際、多くのユーザーが訓練なしで現代のスマートフォンをうまく使いこなしているのは優れた成果だと強調
• Hacker News関連のデスクトップソフトウェアへの愚痴と現状質問
• 自社のUI設計原則のひとつは、キーボードショートカットやコンテキストメニューには、必ず明確に見えるボタンやメニューからもアクセスできるようにすること。やや古風なやり方だが重要性を強調。画面の四隅はマウスを素早く移動できるためUI上の重要部位であり、Windows 11でスタートメニューを中央に移したのはユーザー不便の例として挙げられる。モバイルではなくタッチ優先の方針なのかもしれない
• アクセシビリティとUIの直感性低下が障害者や高齢者に大きく影響すると強調。タッチとジェスチャーが主流になったが、初期のモバイルUIのほうがむしろアクセシビリティが高かった点を指摘。過度にミニマルでフラットになった傾向が本質的要因。palm、compaq pilot、iPod、初期iPhoneのUI体系を肯定的に回想し、その後はむしろ後退だと評価
  • これに対し、HNコメントをスマホで見るときのように、複数のUIコントロールが隠れていることで実際のコンテンツに集中でき、より美しく快適だという考えもある。palm pilot時代はボタンやコントロールが画面の半分を占めて、かえってコンテンツ領域が減っていたとも指摘。隠されたコントロールは必ずしも悪ではなく、一度習得すれば熟練ユーザーには強力な道具にもなると肯定。ユーザーにUI学習を求めるのはある程度避けられず、自分のコードエディタや git のような高機能ツールでは、単純さと強力さのトレードオフがある。ただし最近はアプリごとに独自コントロールを過剰にカスタマイズしすぎて、UI学習の転移性が下がっているのは問題であり、palm pilotプラットフォームのように、一度学べばすべてのアプリで同様に使える構造が理想的だとする