基本的なUIコンポーネントの使い方をまとめました

1. UIコンポーネントガイドライン 基本編

2. 目次
セレクトボックス 03
ラジオボタン 06
チェックボックス 10
トグル 13
ボタン 17
モーダル 25
アイコン 28
ツールチップ 32
フォーム 35
もっとみる 41
無限スクロール 45
ページネーション 48
ナビゲーション 50
ステップ 55

3. UIコンポーネントガイドライン 基本編
セレクトボックス

4. 全体を把握することができる
展開することで、隠していた情報を表示
する必要がある
しかし、展開するかどうかをユーザーに委ねてしまうた
め、絶対に閲覧してもらいたい場合には向きません。
iOSの標準UIコンポーネントでは「ドラムロール」が該当し
ますが使い辛い点が多いため、自社サービスで使う場合は
改善をおすめします。

5. 選択肢の項目や順番を予測できる場合に使用する
選択肢が6個以上の場合はセレクトボッ
クスに選択肢を格納してしまった方が、
視覚的な負荷が減る
スマートフォンの普及に合わせて画面内の情報をコンパク
トに収めることが重要です。
また、現時点では選択肢が少なくても日時の経過で選択肢
が増減する場合も、セレクトボックスをおすすめします。
選択肢の数がいくつになっても対応でき、レイアウトへの
影響もありません。

6. UIコンポーネントガイドライン 基本編
ラジオボタン

7. 設定を変更する時に使用する
命令を実行するためのアクションボタン
ではない
常に1つの選択肢が選択されている必要があります。
ユーザーがどれも選択できない（したくない）というよう
な場合に備えて、「該当無し」といったラベルの選択肢を
用意しておく必要があります。
iOSの標準UIコンポーネントには存在しないため、アプリ化
の際は他UIコンポーネントを検討する必要があります。

8. 基本的に縦置き
複数選択肢を並べる場合、横に並べてる
と読み辛く、また多言語対応が困難とな
る
複数行にしな
文ではなく句として書き、読点（。）は使わな
すべてのラベルの長さを揃える
この3点が重要になる。
クリック領域としてはラベルもクリック可能にするとモバ
イルでも扱いやすいUIコンポーネントになります。

9. 選択した値を印象付けたい場合に使用する
全ての選択肢が常に表示されていて、
ユーザーが選択肢を見ながら考えやすい
限られた領域の中に配置しなければいけない場合、このガ
イドラインを守れないこともありますが、できる限り全て
の選択肢が見えるように心がける必要があります。
しかし、どのオプションも均等で注意を引く必要のない場
合は他UIコンポーネントを使うことを検討するべきです。
テキスト2
テキスト3
テキスト

10. UIコンポーネントガイドライン 基本編
チェックボックス

11. 複数ある選択肢から、1つもしくはそれ以上の選択ができる
さらにはすべてのチェックを外し、「何
も選択しない」ことも可能
デフォルトではチェックされていない状態にすることで、
選択の判断はユーザーに任せる必要があります。
そして選択肢が多い時は、全選択/全解除できるようにして
おくと、親切でしょう。
1つ1つのチェックボックスは独立しており、ほかのチェッ
クボックスに影響を与えません。
iOSの標準UIコンポーネントには存在しないため、アプリ化
の際は他UIコンポーネントを検討する必要があります。
テキスト2
テキスト
テキスト3

12. 送信には「決定ボタン」の押下が必要
ユーザーは送信する前に、設定を見直す
ことができ、ミスや押し間違いなどを防
ぐことができる
トグルのONが即時決定を示すのに対し、チェックマークは
選択中という状態を示しています。

13. UIコンポーネントガイドライン 基本編
トグル

14. 0か1の選択をする
スイッチさせることでアクションが起こ
るのではなく、オンかオフか、真か偽
か、という状態を選ぶ
スマートフォンの誕生がきっかけでできたUIコンポーネン
トのため、パソコンで使用する場合はチェックボックスや
ラジオボタンが受け入れられやすいです。

15. ON/OFFは「決定ボタン」なしですぐに反映する
「決定ボタン」が存在しないためユー
ザーは設定を見直すことができない
システムの関係ですぐに変化を反映させられない場合は、
読み込み中であることを示すローディングアニメーション
をつける等を行う必要があります。

16. ON/OFFのラベルは不要
ラベルを声に出して、その後ろに「オ
ン/オフ」を付け違和感がない状態にす
る
どうしても補足が必要という場合は、ラベルのかわりに対
照的な色を使って状態を明確にするというやり方もありま
す。

17. UIコンポーネントガイドライン 基本編
ボタン

18. プライマリボタンは右に配置する
ボタンを配置する順番は視線導線に伴っ
たものにする
複数選択肢がある場合、その全てを見てから決断する人が
殆どです。
例のモーダルではプライマリボタンは「削除」、セカンダ
リボタンは「キャンセル」となります。
このモーダルで「削除」が左にあると全ての選択肢を確認
するために「削除→キャンセル→削除」と2回視線を移動
してから選択する事になってしまいます。

19. 色のコントラスト比に注意する
色のコントラスト比は色覚障害の方への
対応という意味でも重要
文字の色と背景色とのコントラスト比は4.5:1以上が好まし
いです。
少なくとも18~22ptの太字のようなサイズの大きい文字は
3:1以上あれば問題ありません（アルファベット文字の場合
は、14~18ptの太字）。
色から連想できるイメージに
黄色→警
赤→危
グレー→デフォル
緑/青→優先・成功
がありコントラスト比と合わせて決める必要があります。

20. 重要度に合わせて適切な種類を選択する
「CTAボタン」「プライマリボタン」
「セカンダリボタン」が基本の3種類
CTAボタ
高強調、背景色あ
ビジネスの目標に密接に関連しており、重要度の最
も高いボタ
プライマリボタ
高強調、背景色あ
ユーザーの操作の完了を支援するために提供され
る、視覚的に力強いボタ
セカンダリボタ
「戻る」や「キャンセル」など、主要なアクション
の代替として提供されるボタン

21. 機能を示すラベルをつける
明確にボタンの働きを表しているのが理
想
「OK」の代わりには、「Remove（削除する）」というラ
ベルを使用して、ボタンがなにを実行するのかが明確にし
ます。
「削除」には、赤色を使用して危険性を示すという補足の
仕方も必要です。

22. サイズを適切に調整する
1番重要な働きをするボタンが、常に最
も目立つようにする
よりユーザーの注意を引き付けられるポイントは2つありま
す
サイズを大きくする（44px以上
補色を利用する

23. 動きに対して視覚的、聴覚的なフィードバックを提供する
フィードバックがないと、指示を感知しなかったと感じ、同じ操作を繰り返してし
まう
用意しておくべきフィードバックに
有
ボタンがクリックまたはタップ可能の場合使
無
ボタンがクリックまたはタップできない場合使
ユーザーが必要な入力を完了していない場合、ボタンを無効にしておくという使い方もあ
ホバ
ユーザーがボタンの上にポインターを移動したとき、ボタンのデザインが変化して、クリック可能であること
を示すときに使
操作済
ボタンが正常に選択されたことを示すために使用
の4種類があります。

24. 「ラベル+アイコン」の配置は単体か複数使用かで決まる
単体で使用する場合はラベルのすぐ左に
配置、複数で使用する場合はボタンの端
に配置
単体で使用する場合は、ラベルのすぐ左にアイコン配置す
ることで、情報と記号のセットでより直感的にアクション
を理解できるようにします。
逆に、並べて複数で使用する場合は、ボタンの端の部分に
アイコンを配置することで、ラベルの長さに関わらずアイ
コンを揃えることができ、情報量が均一に見えるようにな
ります。

25. UIコンポーネントガイドライン 基本編
モーダル

26. タスクに集中させ、操作を制限する必要がある場合に使用する
注意を引いて、問題を認識させ、それをすぐに修正させることができることが大き
なメリット
モーダルによって「ユーザーにとって欲しい行動」を促すことや、文章、画像などの情報に注意や関心を惹きつける
ことができます。
一般的はにエラーなどの、ユーザーの行動が即求められるシステムの状態の警告に使われます。
エラーの修正のためにはユーザーを遮ることが不可欠のため、最も目がいく画面の真ん中にモーダルを置きます。
しかし、性質上表示されたタスクが完了するまで、ユーザーは他の作業を行えません。
ユーザーは表示内容に従うか、モーダルを閉じなければならないという、強制力が強くストレスを与える可能性があ
ります。
そのため場面によっては、ユーザーに制限のない、作業中の画面の操作を続行できる「別ウィンドウ」のポップアッ
プの仕様も考慮すべきです。

27. 必要な要素
各要素を欠かさないことでモーダルのUXを担保する
エスケープハッ
ユーザーがモーダルを閉じられるような逃げ道を残して置
タイト
ユーザーが今どこにいるのかを見失わないよう、モーダルには分かりやすいタイトルや見出しをつけ
ボタ
押す場所も目的も分かりやすいラベリングを心がけ
サイズと表示位
モーダルが画面全体を占拠するようなことがあってはいけな
スクロールバーを設置する必要が出てきた場合は新しいページを作ったほうが良
フォーカ
モーダルが開いたときに背景が暗くなるようにして、視線がモーダルに行きやすくなり、親ページに干渉でき
ないことを示唆する

28. UIコンポーネントガイドライン 基本編
アイコン

29. コンテンツだけでなく行動を強調することもできる
しかし、ユーザビリティを高めるもので
はないので、重要なアクションをアイコ
ンだけで伝えない注意が必要
アイコンがラベルを補完することで、ユーザーにとってそ
のあとのアクションがより分かりやすくなります。

30. 文化・年齢・背景を超えて普遍的なものを使用する
アイコンの意味をユーザーに考えさせて
はいけない、わかりやすさ第一
アイコンのディテールはできるだけ少なくしてください。
特に使用するアイコンを並べた時に明確さ、可読性、揃
え、簡潔さ、一貫性、個性が全てが揃うようになっている
ことが重要です。
それが難しい場合はそもそも表現したいアイデアが抽象的
すぎることも考えられます。
アイコンにテキストを組み合わせるなど、別の解決策を考
慮する必要があります。

31. 左に置くと「入る」、右に置くと「遷移」
一般的に左にレイアウトされ、アイコン
はまず文字よりも先に目に入る
一覧から詳細へなどの下の階層へ入っていくような遷移
はアイコンが
階層が関係ないページへの遷移や別ウインドウで開く
ページはアイコンが右
とすることでより直感的なアイコンの配置になると考えら
れます。

32. UIコンポーネントガイドライン 基本編
ツールチップ

33. 見慣れないオブジェクトを理解する手助けをするもの
マウスオーバーによる表示のため、ユー
ザーの操作も最小限かつ省スペースで設
置可能
しかし、スマートフォンなどのタッチパネルではマウス
オーバーによる操作ができないので、タップしてもらえる
ような工夫が必要です。
一般的にはアイコンの追加だけでなく、テキスト部分に下
線をつけるものなどもあります。

34. 情報量と場所に気を付ける
性質上見られない可能性もあるため、サイトで必ず伝えたい情報や知らないと使
用できない情報はツールチップ外に表示する
マウスオーバーでは、カーソルが離れると消えてしまうため、短時間で読めないような情報量の多いものは不向きと
なります。
そのため内容は簡潔で分かりやすい文章にする必要があります。
カーソルがあるオブジェクトの近く（上下左右）に表示するのが原則です。
表示することで操作を妨害するような場所に配置してはいけません。
特にレスポンシブデザインでは、スマートフォンになった時に表示させる場所が無いといった事にならないように注
意が必要です。

35. UIコンポーネントガイドライン 基本編
フォーム

36. 入力項目とフォームを縦に眺めることができる配置を行う
ユーザーの視線の動きに配慮した配置を
行う
迷わない入力フォームは、目の動きを最小限に留めること
ができるレイアウトがされています。

37. パソコンとスマートフォンにおけるフォームは別物として考える
利用シーン・入力手段が異なる
例えばパソコンでは誤タップの恐れがないので、フォーム
の横幅を狭めるなどの工夫が可能です。
さらに、スマートフォンの場合には、キーボードの制御が
できているかどうかでも、ユーザーの負荷軽減に繋がりま
す。
電話番号の入力→数字キーボー
メールアドレス→英字キーボード
というように、使用する場面を意識したUI設計が必要で
す。

38. エラーの際は箇所と理由を明記する
直接エラー場所までスクロールした上
で、赤字で太く記載するとわかりやすい
入力中にリアルタイムで的確なエラーが表示されれば有効
ですが、誤った使われ方をするとユーザーが混乱します。
メールアドレスを入力している最中に形式が異なるという
メッセージが出てしまうと、「メールアドレス」を入力す
る欄ではないと勘違いを起こし、混乱してしまいます。
必ずしも入力中にエラーを表示してはいけない、という話
ではなく、例えば「パスワードの安全性」のチェックなど
は入力中に随時表示が変わったほうが親切で、項目によっ
てタイミングを検討する必要があります。

39. 入力要件はフォームの下に明示的に記載する
プレースホルダに、入力要件（文字制限
や文字数）を記載すると入力時に消えて
しまい、入力しながら例や要件を見られ
ない
入力要件をユーザーがエラーを起こしてから表示すると、
二度手間を強いることになり不親切なので、最初から記載
しておく必要があります。
また、入力例がプレースホルダに記入されていると、自動
入力されたものだと勘違いしてしまう場合もあります。

40. 幅を適切なものにする
内容によっては入力欄を分けるなどの工夫も必要
電話番号や郵便番号など、入力する桁数が決まっている場合は幅を狭めると入力中のユーザーの安心感も違います。
スマートフォンでマンション名を含んだ住所の入力する際、住所入力欄が一つだと住所の一部が見切れて表示されな
くなることがあります。
また、こうなると見えない部分は修正が必要かどうかが次の確認のページまで進んでから気づくということになって
しまいます。
例えばこの場合住所入力欄
「番地」と「建物名」に分け
テキストエリアで2〜3行程度表示されるようにする
と入力しやすくなります。

41. UIコンポーネントガイドライン 基本編
もっとみる

42. 複数のコンテンツを少しずつ見せるか省略する場合に設置する
どちらも間違いではないが、後者は他に
もコンポーネントの選択肢がある
複数のコンテンツを少しずつ見せる場合は、様々な切り口
の情報を少しずつ見せることで、そのサービスの全体像を
つかんでもらいたいという意図があります。
一覧画面で、省略した続きを表示する場合は特定の件数ご
とにページを分けて表示するページネーションを用いた
り、無限スクロールなど対案もいくつかあります。

43. 一覧性を持ちつつ自分にあうコンテンツを全体から探す
普段使い慣れた縦スクロールで一度に多
くの情報を見ると快適さを感じる
複数のコンテンツをコンパクトに見せる場合カルーセルが
使われていることがあります。
しかし、スワイプして続きを見るユーザーはそれほどいま
せん。

44. タイトル横に右寄せ、もしくはコンテンツ下に設置する
コンテンツ下に設置する方がユーザーの
目線に入りやすくスペースも十分確保で
きるため、「もっとみる」へのタップ数
は多くなる傾向がある
「⁠もっとみる」に遷移してほしければ下に配置し、コンテ
ンツに直接遷移してほしければ右寄せが推奨される。

45. UIコンポーネントガイドライン 基本編
無限スクロール

46. アクションコストが低く、集中力が持続し没頭感を高める
無限スクロールが効果的な事例は、
ユーザー生成型コンテンツ（TwitterやFacebook）
ビジュアルコンテンツ（PinterestやInstagram）
スクローリングやフリックなどのジェスチャーコントロールとあうためモバイルフレンドリーともいえます。
デザイン的なwebページでは採用されることが多い一方でAmazonの検索結果画面などでは下記の理由からページ
ネーションが採用されていることも忘れてはいけない
・文章を読んでいる途中で何度も読み込みが発生する
・途中でのブックマークができず、再読込時には最初からやり直しになってしまう
・読み込まれていない文章はページ内検索でヒットしない
・ページの終わりが見えず、フッターに到達できない

47. アクセシビリティ課題にどう取り組むかが課題
ユーザー満足度は高く、実装コストが十
分かけられる場合は選択できる
・戻るボタンでどのスクロール位置に戻るのか
・大量にスクロールした場合のブラウザパフォーマンス
・音声読み上げソフトが必要なユーザーにとっての意図し
ない挙動
の解決が難しい。

48. UIコンポーネントガイドライン 基本編
ページネーション

49. ユーザーの行動が目的志向のサイトやアプリにあう解決策
ページネーションなら、何の項目がどの
ページ数にあったかといった形でユー
ザーは記憶できる
「もっとみる」「無限スクロール」などで同じ体験を実現
すると実装コストが高くなってしまいます。
例えば「⁠もっとみる」をタップして表示された一覧項目の
中から一つをタップし次の画面に遷移して前画面に戻った
場合、「もっとみる」を開いた状態の画面に戻らないと自
分がどこにいたのかを見失ってしまう場合があるからで
す。

50. UIコンポーネントガイドライン 基本編
ナビゲーション

51. メインエリアが複数構造であれば横、シンプルなら縦配置
メインエリアがシンプルな構成であれ
ば、ある程度縦スクロールを許容するこ
とができるため、縦配置のナビゲーショ
ンでも問題ない
しかし、メインエリアが複数カラムからなる複雑な情報構
造の場合はメインコンテンツエリアを広く取りたいため、
幅を最大限活用するためにも横配置が適しています。

52. スマートフォンの場合メニュー数が5つ以上になる場合は縦配置
横方向に配置せざるを得ない場合はメ
ニューを画面の外に並べてスクロールで
選択してもらう
MaterialDesignではガイドラインにも記載されているた
め，Androidアプリなどではよく利用されています。
画面外のメニュー項目は気が付きにくいといえますが、カ
テゴリなど項目が多くあることをユーザーが推測しやすい
ものはそうでないものと比べてスクロールされる可能性も
高まります。

53. すべての画面で共通して閲覧したい情報や機能が配置される
固定表示エリアの幅を狭くすることが難
しい場合は、開閉式にしてコンテンツエ
リアの広さを確保する
多くはメニューやユーザー情報ですが、管理画面ではその
他にも配置したい情報が多いため、固定表示エリアが分厚
くなる傾向にある。
管理画面ではメインとなるコンテンツエリアも情報量が多
く、固定表示エリアが分厚くなるほど、コンテンツエリア
が狭くなり操作性が損なわれてしまいます。

54. 多層構造は三階層以上になるのは避ける
第一階層はタブ、第二階層はサイドナビ
にするなど表現を変える
一覧から詳細へなどの下の階層へ入っていくような遷移
はアイコンが
階層が関係ないページへの遷移や別ウインドウで開く
ページはアイコンが右
とすることでより直感的なアイコンの配置になると考えら
れます。

55. UIコンポーネントガイドライン 基本編
ステップ

56. 「タスクが完了するまでの手順」を示したもの①
全体の流れが把握できることで、時間が
予測できず後回しにされることを防ぎ、
サイトの離脱率を下げる
直線型のステップはパソコンで非常に見慣れたものです
が、スマートフォンで表示する場合には適していません。
放射型であれば十分な大きさでステップタイトルを表示す
るため、今自分がどのステップにいるかが一目でわかりま
す。
一度に1つのステップを表示するため、ユーザーが現在のス
テップに集中することができます。

57. 「タスクが完了するまでの手順」を示したもの②
放射型はステップが増えても横幅に影響
されず手直しのコストを抑えられる
直線型になると端末ごとの調整も必要かつ、ステップこと
のラベル調整も大変で、手間がかかるといえます。
解像度の低い端末への配慮や、ローカライズ（英語など多
言語への対応）も考えるとさら厳しい状況になります。

58. UIコンポーネントガイドライン 基本編
テーブル

59. UIコンポーネントガイドライン 基本編
カード

60. UIコンポーネントガイドライン 基本編
タブ