Webフォームをデザインするとき、オプション選択のためのUI要素を選ぶ場面があるでしょう。その際の候補は、チェックボックス、トグルボタン、ラジオボタン、ドロップダウンなどさまざまありますが、この記事では、ラジオボタンとチェックボックスを取り上げます。この2つはとても単純であるにも関わらず、インタラクションデザインの観点から誤った使われ方をすることが少なくありません。ラジオボタンとチェックボックスの基本動作ラジオボタンは昔のラジオに使われていた、局を切り替えるためのボタンから名付けられました。あるボタンを押すと他の押されていたボタンが元の位置に飛び出します。そのため、常に一つのボタンだけが”押された状態”になります。ラジオボタンのUI要素は、こうしたラジオの物理的なボタンをモデルにしています。リスト内の選ばれていないラジオボタンをクリックして選択すると、その前に選ばれていたボタンは非選択の状態になります。そのため、複数の相反的なオプションからひとつを選ばなければならない場合に使用されます。チェックボックスの起源は紙の記入用紙です。ラジオボタンは相反するオプションからの選択に使われますが、チェックボックスは複数の併存可能なオプションを選択する際に使われます。ユーザーはリストから、0個から全部まで好きな数だけオプションを選べます。リスト内のチェックボックスはそれぞれ独立していて、どれかをチェックしても他のチェックが外れたりはしません。チェックボックスの一種に単独型があります。「はい」か「いいえ」を選択する場合に使われます。標準的な視覚的表現を使用するラジオボタンとチェックボックスの見た目は、標準的な表現に従うべきです。ラジオボタンは小さな円で、選択されると中にもうひとつの円が表示されます。チェックボックスは小さな四角で、選択されると中に十字やチェックマークが表示されます。スタイルを設定しましょう。どの状態でもスタイルが同じだと、ユーザーが混乱する恐れがあります。Monoオプションの順番は論理的にオプションのリストは論理的な順に並べましょう。選ばれそうなものから並べる、最も簡単な操作から並べる、最もリスクの少ないものから並べる、などが考えられます。あいうえお順は論理的ではありませんし、言語依存のためお薦めしません。オプションを縦に並べるオプションは横ではなく縦に並べましょう。横に並べると読みにくく、また多言語対応が困難になります。ページ全体の長さを減らさなければならないなどの理由で横に並べる場合には、混乱を減らすように個々の要素を明確に区切ることが重要です。選択した要素がどのラベルと関連付けられているか迷わせてはなりません。iOS向けのDuolingoアプリにはその良い例が見つかります。Duolingoの水平に並べられたラジオボタンは、視覚的に区別しやすいようにデザインされ、タッチ操作に十分な大きさが確保されています。ラベルもクリック対象にするユーザーが、ボタンとラベルのどちらをクリックしても選択できるようにしましょう。フィッツの法則によれば、ターゲットが大きいほどクリック操作が素早くできます。HTMLフォームには、<label>要素を使って簡単にこれを実現する方法があります。入れ子になるのを避けるすべてのオプションは同じレベルに並べて、不要な混乱や画面内のノイズを減らしましょう。ラジオボタンやチェックボックスを、他のラジオボタンやチェックボックスの中に配置することは避けましょう。アクションを実行するボタン代わりに使用しないラジオボタンとチェックボックスは設定の変更のためだけに使われるべきです。変更された設定は、ユーザーがOKボタンをクリックするまで反映されるべきではありません。ボタンのクリックを必要にすることで、ユーザーは確定前に設定の再確認を行えます。これは、意図しない設定ミスを防ぐのに役立ちます。ユーザーが「戻る」や「キャンセル」ボタンをクリックしたら、ラジオボタンやチェックボックスに行われた変更は破棄して、元の設定に復帰させましょう。ラジオボタンの推奨される使い方ラベルの長さを短く保つラベルは関連付けられたラジオボタンの意味をユーザーに伝えます。ラベルは説明テキストではありません。ユーザーがすべてのオプションを素早く見渡せるよう、簡潔で短く意味が伝わるラベルを使いましょう。ラジオボタンのラベルを複数行にしないラベルは文ではなく句として書き、読点(。)は使わないすべてのラベルの長さをできるだけ揃える常にデフォルトの選択を設定するユーザビリティの10原則のひとつは、ユーザーは操作のやり直しができるべきというものです。ユーザーはUIを元の状態に戻せるべきということです。ラジオボタンに当てはめるらな、これは事前にオプションがひとつ選ばれているべきだと解釈できます。何も選ばれていない状態がデフォルトでは、選択した後に元の状態に戻す手段がユーザーにはありません。これはユーザーに不親切な状態でしょう。安全で確実なオプションをデフォルトに選びましょう。安全さも確実さも重要でない場合は、最も選ばれそうなオプションを選びましょう。顧客調査のように、データ収集が目的の場合は例外です。デフォルトを設定すると集めたデータが偏ることになるでしょう。オプションは包括的にユーザーが選ぶものが無いと感じることがないように十分な選択肢を用意しましょう。包括的なオプションの提供が難しければ。「その他」の選択肢を提供し、追加情報を入力するためのフィールドを配置しましょう。ドロップダウンよりラジオボタンを優先して使うもしリスト内の選択肢の数が少ないなら(2から7の間)、ドロップダウンではなくラジオボタンの使用を考えるべきです。ラジオボタンはすべてのオプションが常に表示されているため、認知が容易で、ユーザーはオプションの比較を簡単に行えます。ユーザーのオプションの選択を助けるもし、あるオプションを強く推したいなら、それをラベルに加えるべきです。上級ユーザー専用のオプションがあれば、「上級」をラベルに付け加えましょう。モバイルアプリでのラジオボタンの使用ラジオボタンをモバイルアプリで使用すること自体は問題ありません。タップしやすさには配慮しましょう。選択肢の数が2つ3つだけであれば、iOSでセグメントコントロールと呼ばれる部品が有効でしょう。チェックボックスの推奨される使い方デフォルトは「オフ」にするチェックボックスは、デフォルトではチェックされていない状態にします。選択の判断はユーザーに任せましょう。チェックボックスのラベルの意味をはっきりさせるチェックボックスに関する最も多いユーザビリティの問題は、曖昧だったり誤解されやすいラベルに起因します。ユーザーはチェックボックスを選択するかどうかによる結末を簡単に理解できるべきです。従って、ラベルはチェックしたときはもちろん、チェックしなかったときの結果も分かるように書く必要があります。「通知を送らない」のような否定は避けましょう。ユーザーは何かを起こさないためにチェックしなくてはなりません。チェックしなかったときに何が起きるのか、分かりやすいでしょうか?可能な限り、チェックすると実現されることを文章としてラベルに書きましょう。チェックしないとその文章が偽になることを確認しましょう。チェックボックスを二択に使うラジオボタンは二択に使うべきではありません。2つの排他的な選択肢だけの場合なら、ひとつのチェックボックスにまとめましょう。チェックボックスをアクションのトリガーにしないチェックボックスは状態を表すためもので、アクションを実行するためのものではありません。WiFiをオンにするためにチェックボックスを使うと、WiFiがオンであることの確認なのか、WiFiをオンにするためなのか、ユーザーが考えなければなりません。このような場合は、トグルスイッチを使えば明確です。まとめラジオボタンとチェックボックスは基本的な要素ですが、正しく使うことでユーザビリティに貢献することができます。インタラクションから不明瞭さをなくすためには、正しくUI要素を使うだけでなく、視覚的なフィードバックをユーザーに提供することも重要です。モバイルアプリでは、UIに実際に触れているかのように感じられることが重要な役割を果たすでしょう。