そのフォームにドロップダウンリストは本当に必要か
ドロップダウンリストは限定された特定のシナリオにおいては有効だが、使い方を誤ると、他の入力方法よりも大きな問題を引き起こす恐れがある。
ドロップダウンリストは、フォームにおいて最もお馴染みのコントロールの1つである。デザイナーがドロップダウンリストを使うのは、コンパクトで柔軟性があり、実装が容易だからである。しかし、そうした便利さには代償が伴う。ドロップダウンは、クリックするまで利用可能な選択肢が非表示になっているため、選択しようとするたびに摩擦が生じ、意思決定を遅らせてしまうのである。
定義
ドロップダウンリスト（選択メニューとも呼ばれる）は、折りたたみ可能な入力コントロールで、クリックすると選択肢のリストが表示され、ユーザーはそのリストから1つの選択肢を選ぶことができる。
「ドロップダウン」はインタフェースでよく使われる用語だが、コンテキストによって異なるパターンを指すこともある。この記事では特に、データを収集するための入力コントロールとして使われるドロップダウンリストを取り上げ、別のページに遷移するためのナビゲーションメニューや、システムのアクションを起動するコマンドメニューは対象としない。これらのコンポーネントは見た目のパターンは似ているが、対応するユーザーの目的は異なる。
ドロップダウンリストの魅力
ドロップダウンリストが広く使われているのは、次のような利点からである：
- 省スペース：ドロップダウンリストはコンパクトで、画面上の1行分のスペースしか取らないにもかかわらず、いくつでも選択肢を収めることができる。利用できるスペースに収まりきらないほど選択肢が多い場合、選択肢のリストを折りたたみ、クリックするまで見えないようにするのは、見た目をすっきりさせる解決策に思える。
- 入力の制約：あらかじめ定義された有効な選択肢からしか選べないため、タイプミスや無効な入力が発生しない。その結果、データを構造化されたクリーンな状態に保てる。
- 馴染み深さ：ドロップダウンリストは、何十年も前から存在する標準的な入力パターンである。シグニファイアとして強力であり、ユーザーはどのプラットフォームであっても、下向き矢印のパターンを見ればドロップダウンだとわかる。
ドロップダウンリストに潜むコスト
ドロップダウンリストは、画面の見た目をすっきりさせたいデザイナーにとっては魅力的だが、多くの場合、ユーザーにとってはデータ入力を容易にするものではない。
気づきにくさ
デフォルトで選択肢を非表示にするのは、段階的開示の一種といえる。これは視覚的な煩雑さを軽減する洗練された解決策である一方、非表示になっている選択肢、あるいは入力フィールド自体の気づきやすさを損なうという側面もある。
長いフォームでは、コンパクトなドロップダウンリストは見落とされやすく、入力済みのフィールドだと勘違いされやすい。そのため、何をデフォルトで表示しておくかが極めて重要になる。ユーザーは、コントロールを操作してまで、デフォルト以外の選択肢を確認しようとはしない可能性があるからだ。
高いインタラクションコスト
ドロップダウンを操作するには、次の3つのステップが必要である：
- （クリック、タップ、またはキーボード操作で）リストを開く
- 目的の選択肢までスクロールする
- 選択するためにもう一度クリックする
カスタムドロップダウン（ブラウザやOSのデフォルトではないもの）では、リストをスクロールしている最中に誤ってドロップダウンの外側をクリックすると、リストが閉じてしまうことが多く、そうなるとユーザーは選択プロセスを最初からやり直さなければならない。
長いドロップダウンリストは、画面の煩雑さを抑えるためによく用いられるが、特に問題になりやすい。ユーザーは、目的の選択肢を正確に選べるだけの精度を保ちながら、リストを慎重にスクロールしなければならないからだ。この操作は、デスクトップ（スクロールが速すぎると目的の項目を通り過ぎてしまう）でも、モバイル（ファットフィンガー問題や、誤ってリストを閉じてしまうことがよく起こる）でも、エラーが起こりやすい。
アクセシビリティ上の障壁
GOV.UKはドロップダウンについて広範な調査を行い、キーボードユーザーや運動機能に障害のあるユーザーに繰り返し見られる、次のようなユーザビリティ上の問題を報告している：
- ドロップダウンをうまく閉じられない
- ドロップダウンの中に文字を入力しようとする
- フォーカスされている項目と選択されている項目を混同する
- スクロールすればさらに選択肢が出てくることに気づかない
- 小さな画面で、選択肢をピンチ操作で拡大しようとする
GOV.UKは、一般利用者向けの行政サービスでは、ドロップダウンリストは最後の手段としてのみ使用するよう、明確に推奨している。
クリーンなデータという幻想
ドロップダウンリストは、入力内容を制限することでデータをクリーンに保ち、その結果、バックエンドシステムが標準化された機械判読可能な値を受け取れるようになるため、テキスト入力よりも好まれることが多い。しかし、入力を制限する方法がうまく機能するのは、選択肢がユーザーのメンタルモデルと一致している場合に限られる。一致していない場合、そのずれはドロップダウンによって次の2つのかたちでさらに問題になる。
同じ回答を表す方法が複数ある
ドロップダウンを開くまですべての選択肢が非表示になっていると、ユーザーはあらかじめ選択肢を流し読みして、そのリストでどの命名規則が使われているのかを把握することができない。
自分の国籍を選ぼうとしている英国のユーザーなら、「United Kingdom」「UK」「Britain」「Great Britain」のいずれかを予想するかもしれないが、リスト全体をスクロールしなければ、それらのうち、どの表記が用いられているのかを知る術はない。
ユーザーが探しているものがリストに存在しない
フォームでは、例外的なケースが抜けていたり、あり得るすべての選択肢が考慮されていなかったりすることが少なくない。ドロップダウンでは、提示される各選択肢のラベルが1つの決まった表記に固定されるが、ユーザーは文化、日常的な言葉遣い、政治、個人のアイデンティティによってかたちづくられた、豊かで、コンテキストに応じたメンタルモデルを持ってフォームにやって来る。こうしたメンタルモデルのずれは、単純な書式エラーよりもはるかに予測しにくい。
想定していた選択肢がリストにない場合、ユーザーは次のいずれかの行動を余儀なくされる：
- リスト全体をくまなく確認する
- 最も近い（ただし、おそらく不正確だったり、間違っていたりする）選択肢で妥協する
- あきらめてフィールドを空欄のままにする
これはコントロールの種類を問わないコンテンツデザイン上の問題であることに注意してほしい。ラジオボタンでも、同じように必要な選択肢が欠けていれば、該当するユーザーを回答から締め出すことになる。しかし、ドロップダウンではこの問題はさらに悪化する。ドロップダウンを開くという操作に入ってからでないと選択肢が表示されないため、求めている回答がないとわかったときの戸惑いもより大きくなるからである。
この問題をよく目にするのが、職種や業界についての選択リストである。そうしたリストは、人々が実際に自分の仕事をどう表現するかではなく、組織内部の硬直した（そして往々にして時代遅れになっている）分類体系を反映していることが多い。たとえば、業界を選択するリストには「デザイン」がない、あるいは「建築」や「アート」「メディア」にまとめられていることがよくある。
このような場合、バックエンド側では無効な入力のないクリーンなデータが揃ったと喜んでいるのかもしれないが、データがクリーンに見えるのは、ユーザーが「何か」を選ばざるを得なかったからにすぎない。彼らが適切な回答を見つけたからではないのである。
ドロップダウンリストを避けるべき場合
選択肢が少なすぎる場合
メニューに含まれる選択肢がほんの数個しかないのに、それらのリストを折りたたんで、クリックするまで見えないようにすると、不要なインタラクションコストが生じる。ユーザーは、すべての選択肢を確認するためだけにコントロールを開かなければならないからだ。さらに、折りたたまれた状態では情報の匂いもほとんどない。中に何があるのかを示すシグナルや操作に入る前にどのような選択肢があるのかを予測する助けになるものが何もないのである。
ここでは、ラジオボタンのほうが適している。ラジオボタンは誰にでもわかりやすく、すべての選択肢が最初から表示され、1回クリックするだけで選択できる。
「選択肢が少ない」とされる数は、コンテキストによって異なる。複数のデザインシステムがドロップダウンリストの使用を検討する選択肢数の最低基準を定めていて、たとえば、U.S. Web Design System（USWDS）は、7項目未満ならラジオボタンを推奨している。Google マテリアルデザイン（M3）はその基準を6項目、IBMのカーボンデザインシステムは3項目としている。厳密な境界線はレイアウトや情報の複雑さによって変わってくるが、基本的な原則は変わらない。つまり、数個の選択肢が無理なく画面内に収まる場合、ドロップダウンは実際に得られる価値以上の摩擦を生み出す。
選択肢が多すぎる場合
長いドロップダウンも同様に問題がある。国のリスト（選択肢が200個以上になる）のように、選択肢がおよそ15個を超えると、リストを目で流し読みするインタラクションコストや、スクロールするのに必要な指先の細かなコントロールが大きな負担になってくる。
このような場合は、コンボボックス（テキスト入力フィールドと絞り込み可能なドロップダウンリストを組み合わせたもの）を用いると、長いリストから目的の選択肢を探す負担を軽減できる。すべての選択肢を流し読みする代わりに、探している語を入力すると、インタフェースが結果を絞り込んでくれるからである。このパターンは、国や州、言語、大学など、ユーザーが目的の選択肢をあらかじめ想定できる長いリストに適している。
場合によっては、データの構造を見直すことで、選択という行為そのものを完全になくすこともできる。たとえば、自動住所検索機能を使えば、州を長いドロップダウンリストから選択せずに済む。
よく知っている、または予測しやすいデータ
年齢、生年月日、身長など、すぐに答えられる値では、ドロップダウンから選択するより入力するほうが速いことが多い。数秒で入力できる値を見つけるために長いリストをスクロールさせるのは、ユーザーに不要な負担をかけることになる。
適切な入力モード（たとえば数字）を設定し、モバイルで適切なキーボードが自動的に表示されるようにしたテキスト入力は、ドロップダウンよりも入力が速く、エラーも起こりにくい上、アクセシビリティも高い。
見た目を比較する必要がある場合
ユーザーが商品のバリエーション（サイズ、色、素材など）を選ぶ必要がある場合、選択コントロールを採用することには正当な理由がある。こうした場合、選択肢はバックエンドの在庫情報に紐づいているため、自由に入力できるようにしてしまうと、エラーが生じるからである。
しかし、ここでは、ドロップダウンリストは避けるべきである。選択可能な項目がタップしないと表示されないので、ユーザーは選択肢を確認するためにメニューを開かざるを得ず、選択を妨げ、遅らせてしまうためである。この問題は、選択可能な組み合わせが複数の種類のバリエーション（たとえば、サイズ「と」色）によって決まる場合、さらに悪化する。ユーザーはそれぞれのドロップダウンを行き来しながら、どの組み合わせなら購入可能なのかを頭の中で割り出すしかなくなるからだ。
対照的に、選択肢をボタンとして並べれば、すべての選択肢を一度に表示できるため、ユーザーは流し読み、比較、選択までをワンステップで行える。また、在庫切れの選択肢もすぐにわかるようにできるので（たとえば、在庫のないサイズをグレーアウトする）、ユーザーが長いリストを順番に見ていって選択肢を選んだのに、結局在庫がなかったとわかって苛立つ、といったこともない。色や柄のような見た目に関する特徴に関しては、ボタンにスウォッチを表示すれば、テキストラベルだけの場合よりもはるかに多くの情報を伝えられる。
それでもドロップダウンを用いる意味がある場合
ドロップダウンには欠点があるが、どんな場合にも不適切というわけではない。依然として、限られた状況では適切である。
ドロップダウンを用いるかどうかを決める前に、まず、そもそも選択というインタラクションパターンが適切なのかを判断する必要がある。
選択コントロール（ドロップダウンリスト以外にも、チェックボックス、ラジオボタン、その他の種類のリストなど）は、次のような場合にうまく機能する：
- 有効な入力値があらかじめ定められ、選択肢が限定されている場合。ユーザーは事業者側が認めているものの中からしか選べないが、どんな選択肢があるかを事前に知っているとは限らない。たとえば、利用可能な配送方法は、その時点に提供されている選択肢の中から選ぶ必要がある。
- データの標準化がきわめて重要である場合。自由なテキスト入力を許してしまうと、データにばらつきやエラーが生じたり、後続の処理で問題が発生したりする恐れがある。不揃いな入力をシステム側で確実にクリーンアップできない場合、最初から選択肢を制限することでデータの整合性を保つことができる。
- データが連続値ではなくカテゴリー値である場合。選択肢の数が限られていて、それぞれが別個の値として存在し、値同士は連続していない。たとえば、Tシャツのサイズ（S、M、L）を決める場合は選択式が理にかなっているが、予算の上限（10～500ドル）を設定する場合はスライダーや数値入力のほうが適している。
- 選択にすることでユーザーの手間を減らせる場合。選択肢を1回クリックするだけのほうが詳しい回答を入力するよりも容易であることは少なくない。たとえば、サブスクリプション解約時のアンケートでは、すでに解約を決めているユーザーが時間をかけて詳しいフィードバックを提供したいと思っているとは考えにくい。しかし、選択肢をリストで提示すれば回答のハードルが下がり、何らかのフィードバックを提供してもらえる可能性が高くなるだろう。
選択コントロールが適している場合でも、ドロップダウンリストが必ずしも最適とは限らない。以下の条件をもとに、ドロップダウンリストを使うのが妥当かどうかを判断しよう。
適度な選択肢数（およそ5～10個）
ドロップダウンリストが最もうまく機能するのは、選択肢の数が多すぎることも少なすぎることもない限られた範囲に収まっている場合である。つまり、画面スペースを節約するために選択肢を非表示にする意味がある程度には数が多いものの、リスト内の移動が難しくなるほどの数ではない。選択肢が5個未満なら、すべての選択肢が表示されていて、1回のタップで選択できるラジオボタンのほうが通常は適している。逆に、選択肢が15個を大きく超えるようなら、コンボボックスを検討しよう。
そのフィールドがメインタスクに対して副次的な位置づけである
画面上のすべてのコントロールが同じ重要度を持つわけではない。あるフィールドがユーザーの主要な目的に対して副次的な位置づけだったり、入力が任意だったりする場合は、選択肢をデフォルトで表示しておく必要はない。ドロップダウンなら、それらの選択肢が必要になるまで非表示にしておけるため、ユーザーの注意を主要なタスクに引きつけておけるし、画面スペースも失われない。
この点は、要素が密集している管理画面UIや情報量の多いインタフェースでは特に有効である。こうしたインタフェースでは、すべての選択肢を最初から表示すると視覚的なノイズが増えて、コンパクトなレイアウトが崩れ、認知負荷も高まってしまうからである。このような場合には、ドロップダウンのコンパクトさが本領を発揮する。
フォーマットの選択、フィルター、並べ替えメニューなどの設定用フィールドは、タスクの中心ではないことが多く、頻繁に変更されるものでもない。こうした場合、よく選ばれる値を妥当なデフォルトとしてあらかじめ設定しておけば、ユーザーはドロップダウンリストをまったく操作せずに済む。
そのフィールドが1つのまとまりの一部である
フィールドは常に単独で存在するわけではない。複数のフィールドを1つのまとまりとしてとらえたり、まとめて確認したりすることもある。このような場合には、すべての選択肢をすぐに見えるようにすることより、全体のレイアウトを維持することのほうが重要である。
ドロップダウンリストを使えば、関連するフィールドをコンパクトにまとめ、視覚的なつながりも維持できる。近接性を保つことで、フィールド同士の関係がより明確になり、ユーザーもひと目で1つのグループとして理解しやすいからだ。一方、選択肢をインラインで表示してしまうと、フィールドが縦に長くなり、関連する項目同士が離れて、フォーム全体を流し読みしたり、全体を見渡して確認したりすることが難しくなる。
要するに、ドロップダウンリストを用いる意味があるのは、適切に機能する条件が揃う、狭い「スイートスポット」に該当する場合に限られる。すなわち、選択肢が非表示にしておくのが妥当な程度にはたくさんあるが、リストを見ていくのが面倒になるほど多くもない、ということだ。また、ドロップダウンリストが最も適しているのは、そのフィールドがメインタスクに対して副次的な位置づけであったり、そのフィールドをより大きなグループの一部としてとらえる必要がある場合である。こうした条件を満たさない場合（実際、満たさないことはよくある）、ドロップダウンリストはメリットをもたらすよりも問題を引き起こすことのほうが多い。
では、ここでドロップダウンリストがそうした条件を満たしている例をいくつか見てみよう。
例1：言語セレクター
1Passwordのウェブサイトのフッターでは、言語選択にドロップダウンリストを用いて、10言語から選択できるようにしている。一方、このサイトのフッターはすでに情報量が多く、プロダクト、機能、ソリューション、リソース、企業情報などへの数十個のリンクがページ幅いっぱいに並んでいる。
ここでは、選択コントロールを使うのが適切である。なぜなら、言語の選択肢はあらかじめ定義された固定のセットで、ユーザーが選べるのは1Passwordが対応している言語だけであり、それぞれの選択肢がサイトの特定の翻訳版に対応しているからである。
10個という選択肢数は、ドロップダウンにするのに適度な数である。情報量がすでに多いこのレイアウトに、インラインで並べて表示するには多すぎて煩雑になるが、ドロップダウンを開いたときに無理なく流し読みできる程度の数だからだ。また、言語セレクターは副次的な位置づけのコントロールといえる。つまり、このフッターに来るユーザーの目的は、ほとんどの場合、サイト内を移動することであって、言語を変更することではないし、このサイトはデフォルトで適切な言語を表示するようになっているので、大半の人は言語セレクターを操作したりしない。
この例では、ドロップダウンを用いることで、言語の選択が必要なユーザーにはそれを可能にしつつ、より優先度の高いフッターコンテンツのためのスペースを確保し、そこにユーザーの注意を引きつけているのである。
例2：スキップロジック（条件分岐）の設定
User Interviewsは、スクリーナーアンケートツールでスキップロジックのルールを構築するためにドロップダウンリストを採用している。それぞれのルールは、「もし［質問］［条件］［回答］ならば、［遷移先］にスキップする」という1つの文として読める構成になっている。
この例では、入力データがバックエンドに直接紐づいているため、正確さを確保するには選択コントロールが必要である。これらのルールは参加者の回答を振り分けるために用いられ、選択された値はシステムが認識する値に正確に一致していなければならないからである。
これらのドロップダウンの中には、選択肢が数個しかないものもあり（たとえば、［条件］のフィールドは「is」（〜である）、「is not」（〜でない）の2つのみ）、そうしたフィールドは選択肢の数だけで言えば、本来ならラジオボタンのほうが適している。しかし、4つのフィールドが横一列に並び、「もしこうならば、こうする」という条件文として読み取れるようになっているので、フィールドのうちのどれかがラジオボタンになると、文としてのレイアウトが崩れ、残りのフィールドの位置もずれて、ルール全体を1つの論理的なまとまりとして読み取りにくくなる。複数のルールを並べて設定できるビルダーでは、こうしたレイアウトの乱れは急速に積み重なっていく。
結論
そのフォームに本当にドロップダウンリストは必要だろうか。おそらく、必要なケースは思っているほど多くないだろう。そこで、ドロップダウンを用いる前に、こう自問してみよう。選択肢はいくつあるか、ユーザーが自信を持って選ぶためにすべての選択肢を見る必要があるか、そして、選択肢を隠すことでレイアウトに本当にメリットがあるのか。
多くの場合、その答えを考えていくと、ドロップダウンではなく、ラジオボタンやテキスト入力、コンボボックス、あるいはまったく別のフォーム要素を選ぶことになるはずだ。ドロップダウンリストは、デフォルトの選択肢ではなく、トレードオフを伴うものとして扱おう。使用する場合は意図を持って選び、そのコストを正当化できる明確な理由がある場合に限って採用しよう。
記事で述べられている意見・見解は執筆者等のものであり、株式会社イードの公式な立場・方針を示すものではありません。
