ドロップダウンのUIデザイン：検索・セレクト・ラジオボタンの使い分け

ドロップダウンは、値を一つ選ぶ必要があり、すべての候補を同時に比較しなくてもよい場合に役立ちます。見慣れた値を無理なく見渡せるなら通常のセレクト、探し出すのが難しいなら検索可能なコンボボックス、選択肢の違いをよく見て判断してほしいならラジオボタンを使います。「複製」「削除」などの命令を並べるメニューは、値を入力するフィールドとは用途が異なります。

適したコントロールは、候補の数だけでなく、利用者が何を判断するかで変わります。備品を注文する社員が、配送方法、地域、オフィスを選ぶ場面を考えましょう。フォーム全体を一つのドロップダウン形式で統一する前に、PixsoのUIデザインワークスペースで、それぞれのコントロールを比較できます。

セレクト、ラジオボタン、検索可能なコンボボックスを使い分ける

まず、選択する前に何を理解する必要があるかを書き出します。備品の注文では、配送方法によって届く場所やタイミングが変わります。地域は見慣れた分類ですが、オフィスの一覧には似た名前が多くあります。この三つの判断に、同じコンポーネントを機械的に当てはめるべきではありません。

「候補が何個以上ならドロップダウン」という普遍的な境界はありません。分かりにくいプラン名が六つなら説明が必要かもしれませんし、もっと多い場所の一覧でも、見慣れた名前なら検索しやすい場合があります。名前への慣れ、ラベルの長さ、比較の必要性、毎回一覧を開く手間を考えます。

WAI-ARIAのラジオグループパターン（英語）は、複数の候補のうち最大一つを選択する形式です。配送方法のように候補を見える状態にしておきたい場合に適しています。縦のスペースを節約するためだけに、重要な費用や日程の違いを隠さないようにしましょう。

ラベルと選択済みの値を分ける

「地域」はフィールドのラベル、「北部地域」は選択できる値、「地域を選択」は未選択時の案内です。これらを分けておけば、選んだ後やフォームを見直したときにも、その項目の意味が分かります。

プレースホルダーだけをラベルの代わりにしないでください。値が入ると消えてしまいます。「リバーサイド」というオフィス名だけでは、その欄がオフィス、受取場所、アカウントの所在地のどれを表すのか説明できません。

初期値は、設定する根拠がある場合に使います。確認済みの社員プロフィールに通常利用するオフィスがあれば、それを表示して入力の手間を減らせます。ただし、何が設定されているか分かり、変更できる必要があります。フォームを埋まって見せるためだけに一覧の先頭を選ぶと、別の場所へ備品を送る原因になります。

選択肢の表現はそろえます。動作、場所、曖昧な形容詞を混ぜるのではなく、「オフィス配送」「自宅配送」「窓口受取」のように同じ観点で並べます。同じ名前のオフィスがあるなら、各候補に所在地を添えます。違いをアイコンから推測させるより、短い補足行のほうが役立ちます。

候補を探しやすくなる場合に検索を加える

検索を加えると、入力できる内容、検索対象、結果の並び順、自由入力を認めるかどうかも決める必要があります。この備品注文の例では、オフィス欄には一覧に登録されたオフィスだけを指定できます。「リバー」と入力すると候補が絞られますが、新しい配送先が作成されるわけではありません。

WAI-ARIAのコンボボックスパターン（英語）では、編集可能なものと選択専用のもの、さらにオートコンプリートの動作が区別されています。どの動作を採用するかを明確にしましょう。下向きの矢印だけでは、文字を入力できるのか、固定された一覧から選ぶのかは伝わりません。

この例では、オフィス名と、候補に表示される都市名を検索対象にします。表示と検索結果を一致させることが重要です。「リバーサイド — ブリストル」と表示するなら、ブリストルで検索したときにも関連が分かるようにします。すべての略称が使えると暗黙に想定せず、別名を検索対象にするかも決めます。

候補には、一覧の全情報ではなく、選ぶために役立つ詳細を表示します。オフィス名と都市名だけで区別できるなら、住所全体を各行に載せる必要はありません。行が長すぎると一覧を見渡しにくくなります。選択後にフィールドの下へ配送先住所を表示すれば、社員が最終的な宛先を確認できます。

検索が完了しても一致する候補がなければ、入力した語句を残し、検索条件を広げる方法を伝えます。一覧を取得できなかった状態を「オフィスが見つかりません」と表示してはいけません。候補を外部から取得する場合の応答遅延や、入力した文字と確定したレコードの違いは、非同期検索フィールドの設計ガイド（英語）で扱っています。それらを検討する前に、まず検索がこの選択作業に役立つかを判断します。

値の選択と命令の実行を混同しない

地域フィールドを閉じた後も、選択した地域が表示される必要があります。一方、「操作」ボタンは既存の申請に対する命令を開きます。見た目に共通性を持たせることはできますが、同じ操作として扱うわけではありません。

たとえば「北部地域」を選ぶと、フィールドの値が設定されます。アクションメニューから「申請を取り消す」を選ぶと、結果を伴う処理が始まります。場所の候補の末尾に「申請を取り消す」を混ぜると、利用者がほかの無害な候補と同じ感覚で選んでしまうおそれがあります。

WAI-ARIAのメニューボタンパターン（英語）では、メニューを開くボタンの展開状態や、キーボードでの入り方が説明されています。必須のフォーム項目へメニューの役割をそのまま流用せず、実際の動作に合ったパターンを選びます。

複数選択では、設計すべき内容も変わります。複数の付属品を選べる場合には、単一選択のドロップダウンを無理に買い物かごのように使うより、チェックボックス群のほうが明確なことがあります。長い一覧で複数選択が必要なら、選択済みの項目、解除方法、選択数が分かるようにします。チェックマークを加えるだけで、単一選択の設計が複数選択へ変わるとは考えないでください。

開いた一覧も丁寧に設計する

閉じたフィールドが整っていても、開いた一覧が使いにくいことはあります。画面下部にある場合、オフィス名が長い場合、画面幅が狭い場合を試します。一覧はフィールドとの視覚的なつながりを保ち、利用できる領域からはみ出さないようにします。

候補が多い場合は最大の高さを決め、一覧内でスクロールできるようにします。次の候補の一部を見せるなどして、まだ続きがあることを伝えましょう。数件で終わって見えたり、一度に一つしか見えないほど小さなスクロール領域になったりしないようにします。

現在の値と、候補を見ている途中の状態を区別します。一覧を開いて別のオフィスを確認し、そのまま閉じたら何が起こるのか、利用者が理解できる必要があります。候補の間を移動した時点で値が変わるのか、明示的な確定が必要なのかは、採用する選択方式として決めます。

長いラベルでも候補を区別できるようにします。「北棟 — サービス…」が二つ並んでいては、見えない末尾が違っていても選びようがありません。折り返すか、違いが分かる部分を2行目に表示します。特にタッチ端末では、唯一の違いをホバー時のツールチップに隠すべきではありません。

モバイルでは、ネイティブのセレクトが端末で見慣れた選択画面を提供する場合があります。独自の検索付きピッカーには、キーボードと結果一覧のための広い領域が必要かもしれません。ソフトウェアキーボードの上に収まらない小さなデスクトップ用ポップアップを作る前に、開発チームと実装上の選択肢を比較します。

依存する選択項目の変化を説明する

この備品フォームでは、地域によって配送可能なオフィスが絞られます。そのため地域の変更は、選択済みのオフィスにも影響します。不可能な組み合わせを残したり、理由を示さず選択を消したりせず、項目間の関係を伝えます。

「リバーサイド — ブリストル」を選んだ後、そのオフィスを含まない地域へ変更したとします。新しい地域を保持し、適合しなくなったオフィスを未選択に戻して、「選択した地域のオフィスを指定してください」などの短い案内を表示します。そのまま次へ進もうとしたときには、その欄へ注意を向けます。配送先が問題なく完成したようには見せません。

組織のルールで別地域への配送が認められているなら、そもそもこの制限は不要です。コンポーネントの動作は、実際の業務ルールに従います。連動するドロップダウンの見本を整えるために、存在しない所在地の制限を作ってはいけません。

オフィス配送から窓口受取へ変える場合には、別の依存関係があります。どの項目が引き続き必要か、元に戻したときのために何を保持できるか、配送内容の表示をどこまで更新するかを決めます。送信前に結果をまとめ、社員が選択内容を普通の言葉で確認できるようにします。

Pixsoのフォームで選び方を比較する

配送方法を並べた選択肢、地域のセレクト、検索可能なオフィスピッカーという、三つの異なるコントロールで備品フォームを作ります。ラベル、文字、間隔、補足説明のスタイルは共通化し、動作の違いが不要な見た目のばらつきにならないようにします。

Pixsoでは、再利用可能なコンポーネントとAuto Layoutを使い、フィールドの基本構造をそろえながら、閉じた状態、開いた状態、選択済み、入力エラー時の見た目を検討できます。一覧には同じ業務例に沿った候補を入れます。実際的なオフィス名を「選択肢1」「選択肢2」に置き換えると、解決すべき折り返しや見分けにくさの問題が隠れてしまいます。

特定のオフィスへノートパソコンを送る、窓口受取へ変更する、再びオフィス配送へ戻す、という順序で試してもらいます。宛先を探しやすいか、どの選択が保持されたかを理解できるかを観察しましょう。「ドロップダウンが今風に見えるか」と尋ねるより、フォームの分かりやすさを具体的に確かめられます。

採用したキーボード操作と確定のルールを、該当コンポーネントのそばに記録します。ネイティブのセレクト、編集可能なコンボボックス、アクションメニューに、一つの独自のキー操作仕様を当てはめるべきではありません。プロトタイプは意図する結果を示せますが、実装後にはブラウザー、キーボード、支援技術でのテストが必要です。

Pixsoでフォームのコントロールを比較し、利用者が実際に選ぶ内容に合わせて設計しましょう。