UIデザインのチェックリスト125項目｜画面設計・操作性・公開前確認

UIデザインの品質は、見た目の美しさだけでは判断できません。利用者が現在地を理解できるか、目的の操作を見つけられるか、入力ミスから回復できるか、異なる端末でも問題なく利用できるかなど、複数の観点から確認する必要があります。

画面を長時間制作していると、担当者自身が操作方法や情報の意味を覚えてしまい、初めて利用する人が迷う場所を見落としやすくなります。そのため、提出前やデザインレビュー前には、共通のチェックリストを使って画面を見直す方法が有効です。

本記事では、UIデザインを確認するための項目を25の大分類と125の小項目に整理しています。Webサイト、Webアプリ、管理画面、スマートフォン向けサービスなど、幅広い画面設計へ応用できます。

1. 画面の目的と成功条件を確認する

UIデザインを確認する前に、その画面が何を達成するために存在するのかを明確にします。目的が曖昧な状態では、どの情報や操作を優先すべきか判断できません。

1.1 画面の目的を一文で説明できるか

画面の目的は、「顧客情報を管理する」のような広い表現ではなく、「担当者が顧客の契約状態を確認し、必要な連絡を行う」のように具体化します。目的が一文で説明できれば、画面に必要な情報を判断しやすくなります。

複数の目的が混在している場合は、中心となる目的と補助目的を分けます。検索、編集、分析、設定を一画面に詰め込むより、利用者の行動に合わせて画面を分けた方が分かりやすくなる場合があります。

1.2 主要な利用者が明確になっているか

同じ画面でも、初めて利用する人と毎日利用する担当者では、必要な説明や操作密度が異なります。対象利用者の役割、経験、利用頻度、利用端末を明確にします。

管理者、一般担当者、閲覧者など、複数の役割が存在する場合は、それぞれが必要とする情報を整理します。全員へ同じ情報と操作を表示すると、不要な機能が増えて理解しにくくなります。

1.3 利用者が完了すべき行動を定義しているか

画面を見た利用者が、最終的に何を完了すべきかを定義します。商品登録、申請承認、問い合わせ返信など、具体的な行動として整理することが重要です。

完了条件が明確であれば、主要ボタンの文言や配置も決めやすくなります。利用者が画面を閉じた時点で、目的が達成されたかどうかを確認できる状態を作ります。

1.4 事業上の目的と利用者の目的が一致しているか

事業側が登録件数を増やしたい場合でも、利用者が必要としない入力項目を増やすと途中離脱につながります。事業目的を達成するためには、利用者側の負担も考慮しなければなりません。

両者が衝突する場合は、必須項目を減らす、後から追加情報を入力できるようにするなど、段階的な方法を検討します。短期的な数値だけでなく、継続利用や信頼への影響も確認します。

1.5 成功を測る指標が設定されているか

UIデザインの良し悪しを判断するために、完了率、操作時間、入力エラー率、離脱率などの指標を設定します。見た目の好みだけでは、改善結果を正確に比較できません。

画面公開後に計測できるように、重要な操作や完了状態を整理します。計測項目を増やしすぎず、画面の目的と直接関係する指標へ絞ることが重要です。

2. 利用者の行動順序を確認する

画面上の情報と操作は、開発側のデータ構造ではなく、利用者が考え、判断し、行動する順序に合わせます。作業の流れが不自然だと、画面を何度も往復する必要が生じます。

2.1 利用開始の入口が明確か

利用者がどこから画面へ移動してくるかを確認します。主要メニュー、通知、検索結果、外部リンクなど、入口によって利用者が期待する内容は異なります。

入口ごとに必要な説明や初期状態を検討します。通知から移動した場合は対象項目を直接表示し、主要メニューから移動した場合は一覧を表示するなど、文脈を維持します。

2.2 操作の順序が自然に並んでいるか

入力フォームでは、利用者が情報を確認する順序に合わせて項目を配置します。氏名、連絡先、契約情報など、関連する項目をまとまりとして並べます。

データベースの項目順をそのまま画面へ反映すると、利用者の思考順序と異なる場合があります。実際の業務や申し込み手順を観察し、自然な順序へ変更します。

2.3 不要な画面移動が発生していないか

一つの作業を完了するために複数の画面を往復する場合は、必要な情報を同じ画面で確認できないか検討します。画面移動が増えると、現在の入力内容や検索位置を失いやすくなります。

一方、画面移動を減らすためにすべてを一画面へ集約すると、情報量が増えすぎます。利用目的が同じ情報はまとめ、異なる目的の機能は適切に分離します。

2.4 戻る操作で状態が維持されるか

詳細画面から一覧へ戻ったとき、検索条件、並べ替え、ページ位置が初期化されると、対象を探し直す必要があります。反復作業が多い画面では大きな負担になります。

戻る操作の後に、利用者が直前の作業位置へ復帰できるか確認します。ブラウザの戻る操作と画面内の戻るリンクで、結果が大きく異ならないことも重要です。

2.5 作業中断後に復帰できるか

長い入力フォームや複雑な設定では、途中保存や自動保存を検討します。通信切断や別画面への移動によって、すべての入力内容が失われる設計は避けます。

復帰時には、保存された時刻や未完了の項目を表示します。利用者がどこまで作業したかを理解し、すぐに続きから開始できる状態を作ります。

3. 情報の優先順位を確認する

画面内の情報には、主要情報、補助情報、詳細情報があります。すべてを同じ大きさや色で表示すると、利用者が最初に何を見るべきか判断できません。

3.1 最も重要な情報が最初に見えるか

画面を開いた直後に、利用者が判断に必要な情報を確認できるかを見ます。注文管理であれば注文状態、金額、顧客名などが主要情報になります。

内部識別番号や更新履歴など、利用頻度の低い情報を上部へ置くと主要情報が埋もれます。情報の表示順を業務上の確認順序へ合わせます。

3.2 主要操作が視覚的に明確か

一画面で最も重要な操作は、位置、色、形、文言によって他の操作と区別します。ただし、複数のボタンを同じ強さで表示すると、優先順位が失われます。

主要操作は、画面の目的に対して一つまたは少数へ絞ります。補助操作や取り消し操作は、枠線や文字のみの形式にして視覚的な強さを抑えます。

3.3 補助情報が主要情報を妨げていないか

説明文、更新日時、作成者などの補助情報は必要ですが、主要な内容より目立たせてはいけません。文字サイズ、色、配置を調整して強弱を付けます。

補助情報を薄くしすぎると読めなくなるため、重要度を下げる方法を色だけに依存しないようにします。余白や配置によって区別する方法も有効です。

3.4 強調表現を使いすぎていないか

太字、背景色、記号、大きな文字を多数使用すると、画面全体が強調されている状態になります。結果として、どの情報も目立たなくなります。

強調が必要な理由を一つずつ確認します。通常の情報へ戻しても意味が伝わる場合は、強調を削除して画面全体の静けさを保ちます。

3.5 詳細情報を段階的に表示できるか

低頻度の詳細情報をすべて初期表示すると、主要作業が見えにくくなります。折りたたみ、タブ、詳細画面などを使い、必要なときに確認できるようにします。

ただし、重要な条件や料金を隠してはいけません。表示を省略するかどうかは、利用者が判断に必要とするかを基準に決めます。

4. 画面構造と見出し階層を確認する

画面構造は、利用者が情報のまとまりと現在地を理解するための土台です。見た目だけでなく、HTML上の構造も意味のある順序にします。

4.1 画面名が明確に表示されているか

各画面には、内容を簡潔に示す画面名を表示します。「管理」「詳細」のような広すぎる名称では、何を扱う画面か分かりません。

複数の対象を切り替える画面では、対象名も画面名の近くへ表示します。別の顧客や店舗を誤って編集する危険を減らせます。

4.2 見出しの順序が飛んでいないか

大見出しの直後に小さすぎる見出しを使うなど、階層を飛ばすと構造を理解しにくくなります。見出しレベルは内容の親子関係に合わせます。

文字を大きくする目的だけで見出し要素を使用してはいけません。装飾はCSSで行い、HTMLでは内容の意味に合った見出しを選びます。

4.3 一つの領域に適切な見出しがあるか

入力項目や一覧を複数のまとまりに分ける場合、それぞれに内容を示す見出しを付けます。枠線だけでは、まとまりの意味が伝わらない場合があります。

見出しは、「詳細情報」のような曖昧な表現より、「配送先情報」「支払い情報」のように具体化します。利用者が必要な場所を短時間で探せるようにします。

4.4 関連する情報が同じ領域にまとまっているか

項目名、入力欄、説明、エラー文は一つのまとまりとして配置します。離れた位置に置かれていると、どの説明がどの項目に対応するか分かりません。

同じ業務で使う情報も近くへ配置します。確認と操作のために画面上下を何度も往復する必要がないかを確認します。

4.5 HTMLの意味構造が適切か

主要内容にはmain、移動領域にはnav、独立した節にはsectionなど、役割に合った要素を使用します。一般的な箱要素だけで構成しないようにします。

適切な構造は、読み上げ機能や検索エンジンによる内容理解にも役立ちます。見た目が同じでも、意味を持つHTMLを優先します。

実装例：意味のある画面構造

<header class="page-header">  <h1>注文情報</h1>  <p>注文内容、配送先、支払い状態を確認できます。</p> </header> <main>  <section aria-labelledby="order-summary-title">    <h2 id="order-summary-title">注文概要</h2>  </section>  <section aria-labelledby="shipping-title">    <h2 id="shipping-title">配送先情報</h2>  </section> </main>

5. ナビゲーションを確認する

ナビゲーションは、利用者が現在地を理解し、目的の機能へ移動するための仕組みです。項目数や画面幅に合わせて形式を選びます。

5.1 現在地が分かるか

選択中のメニュー項目へ、背景、文字の太さ、線などを使って現在地を示します。色だけに依存せず、複数の表現を組み合わせます。

HTMLでは、現在ページのリンクへaria-current="page"を設定します。読み上げ環境でも現在地を理解できる状態にします。

5.2 メニュー名が具体的か

「管理」「その他」「機能」のような名称では、移動先を予測できません。「注文管理」「顧客一覧」「請求設定」など、内容を具体的に示します。

同じ対象へ異なる名称を使わないことも重要です。メニュー、画面名、説明文で用語を統一します。

5.3 主要項目が多すぎないか

主要メニューへすべての機能を並べると、目的の項目を探しにくくなります。利用頻度と業務のまとまりを基準に分類します。

低頻度の設定や管理者向け機能は、設定領域へ分けます。一般担当者が日常的に使う項目を優先して表示します。

5.4 階層が深すぎないか

目的の画面へ到達するまでに複数の階層を移動する場合、分類方法を見直します。日常的に使う機能は浅い階層へ配置します。

深い階層が必要な場合は、パンくずや親画面への戻り先を表示します。現在の位置と上位階層を確認できるようにします。

5.5 画面幅に応じて形式が変わるか

広い画面では左側メニュー、狭い画面では開閉メニューや下部ナビゲーションが適する場合があります。単純にメニューを縮小してはいけません。

形式を変更しても、項目名と順序はできるだけ維持します。端末を切り替えた利用者が、同じ機能を見つけられるようにします。

6. 文字の読みやすさを確認する

文字は、UIデザインにおける主要な情報伝達手段です。書体、サイズ、太さ、行間、行長を組み合わせて読みやすさを確保します。

6.1 本文の文字サイズが十分か

本文や入力値を小さくしすぎると、長時間の利用で疲労が増えます。広い画面に多くの情報を表示したい場合でも、読める大きさを維持します。

小さな文字へ情報を押し込む代わりに、不要な情報を減らす、詳細へ分けるなどの方法を検討します。文字サイズだけで密度を調整しないようにします。

6.2 見出しと本文の差が明確か

見出しと本文のサイズや太さが近すぎると、情報のまとまりを理解しにくくなります。文字だけでなく、前後の余白も調整します。

見出しを極端に大きくすると、業務画面で表示できる情報量が減ります。画面の用途に合った段階を少数設定します。

6.3 行間が適切か

行間が狭いと上下の行が重なって見え、長文を読みづらくなります。反対に広すぎると、一つの文章としてのまとまりが失われます。

本文、一覧表、ボタンなど、用途ごとに行間を調整します。すべての文字へ同じ行間を適用しないようにします。

6.4 一行が長すぎないか

広い画面で文章を横幅いっぱいに表示すると、次の行へ視線を移しにくくなります。説明文には最大幅を設定します。

一覧表や数値表示は横幅を活用できますが、文章は適度な行長に制限します。内容の種類に合わせて幅を変えます。

6.5 文字拡大で崩れないか

ブラウザの拡大や端末の文字設定を変更した場合でも、文字が切れたり重なったりしないか確認します。固定された高さを多用すると問題が起きやすくなります。

ボタンや入力欄は、文字が大きくなった場合に高さも広がる構造にします。文字を省略する場合でも、全文を確認する方法を用意します。

7. 配色と明度差を確認する

色は、ブランド表現だけでなく、状態や重要度を伝えるために使います。装飾目的で色数を増やさず、役割ごとに整理します。

7.1 文字と背景の明度差が十分か

本文、補助文字、入力値、ボタン文言が背景から明確に区別できるかを確認します。薄い灰色の文字を広く使用すると読みにくくなります。

通常状態だけでなく、無効、選択中、エラー時の文字も確認します。無効状態であっても、項目名や理由を読める必要があります。

7.2 主要色の役割が統一されているか

主要色が、保存、選択中、リンクなど複数の意味で無計画に使われていないか確認します。同じ色にはできるだけ同じ役割を持たせます。

主要色を装飾へ使いすぎると、主要ボタンが目立たなくなります。重要な操作と現在地を中心に使用します。

7.3 状態色だけで情報を伝えていないか

成功を緑、エラーを赤だけで示すと、色を識別しにくい利用者へ意味が伝わりません。文字、記号、形を組み合わせます。

一覧表では、状態名を必ず表示します。色は状態を素早く見分ける補助手段として利用します。

7.4 色の種類が多すぎないか

分類ごとに異なる色を使うと、利用者が意味を覚えられなくなります。色を使う対象を状態、重要度などへ限定します。

担当者や分類の数が多い場合は、色だけで区別せず、名称や記号を使用します。似た色が増えることも防げます。

7.5 明るい表示と暗い表示で確認したか

暗い表示では、白い背景を黒へ反転するだけでは十分ではありません。文字、境界線、影、状態色を個別に調整します。

両方の表示で主要操作や入力欄を認識できるか確認します。暗い表示で影が見えない場合は、境界線や表面色の差を利用します。

実装例：役割ごとの色管理

:root {  color-scheme: light dark;  --color-primary: #315da8;  --color-on-primary: #ffffff;  --color-background: #f5f6f8;  --color-surface: #ffffff;  --color-text: #202124;  --color-text-subtle: #60646c;  --color-border: #d7dae0;  --color-error: #b42318; } @media (prefers-color-scheme: dark) {  :root {    --color-primary: #a9c7ff;    --color-on-primary: #082d63;    --color-background: #111318;    --color-surface: #1b1d22;    --color-text: #f1f1f3;    --color-text-subtle: #c3c5cc;    --color-border: #454850;    --color-error: #ffb4ab;  } }

8. 余白と情報密度を確認する

余白は、要素の関係と区切りを示します。感覚だけで設定せず、共通の段階を使って整理します。

8.1 関連する要素が近くにあるか

項目名と入力欄、見出しと本文など、関連する内容は近くへ配置します。関係のない内容との間には、より広い余白を設定します。

すべての間隔を同じにすると、情報のまとまりが分かりにくくなります。内部の間隔と、まとまり同士の間隔を分けます。

8.2 画面端の余白が十分か

文字やボタンが画面端に近すぎると、窮屈に見え、スマートフォンでは操作しにくくなります。画面幅に応じた外側余白を設定します。

広い画面では、内容の最大幅を設定して中央へ配置する方法も有効です。余白を無制限に広げるのではなく、内容の読みやすさを基準にします。

8.3 部品内部の余白が統一されているか

同じ種類のボタンや入力欄で、内部余白が異なっていないか確認します。わずかな差でも、一覧で並ぶと不揃いに見えます。

文字量によって部品の高さが変わる場合は、最小高さを設定します。固定高さによって文字が切れないように注意します。

8.4 表示密度が利用者に合っているか

毎日使う業務画面では、比較的高い密度が求められる場合があります。一方、一般利用者向け画面では、十分な余白と説明が安心感につながります。

標準表示とコンパクト表示を切り替えられる仕組みも検討できます。ただし、表示方式ごとに操作領域や読みやすさを確認します。

8.5 余白の値が増えすぎていないか

画面ごとに異なる余白値を追加すると、一貫性が失われます。小、中、大などの段階を定義し、共通変数として管理します。

例外値が必要な場合は、理由を確認します。似た値が複数存在する場合は、既存の段階へ統合できないか検討します。

9. 配置と整列を確認する

整列された画面は、視線移動が少なく、情報を比較しやすくなります。左端、中央、右端など、揃える基準を明確にします。

9.1 要素の開始位置が揃っているか

見出し、本文、入力欄、ボタンの左端が不揃いだと、画面が落ち着かなく見えます。明確な縦の基準線を作ります。

字下げを使う場合は、親子関係を示す目的に限定します。装飾目的の不規則な位置調整を避けます。

9.2 数値が比較しやすく揃っているか

金額、数量、割合などは右揃えにすると桁を比較しやすくなります。小数点や通貨表記も統一します。

数値と文字が混在する列では、内容に合わせて揃え方を決めます。同じ列内で左揃えと右揃えを混在させないようにします。

9.3 ボタン群の配置が一貫しているか

保存、キャンセル、削除などのボタン順序が画面ごとに変わると、誤操作につながります。製品内で共通の並び順を決めます。

危険な操作は主要操作から距離を取ります。小さな画面では、折り返し後の順序も確認します。

9.4 異なる高さの部品が不自然に並んでいないか

入力欄、選択欄、ボタンを横並びにした際、高さが異なると視覚的なずれが生じます。共通の高さや基準線を設定します。

説明文が付く項目と付かない項目を横並びにする場合は、上端を揃えるなど、内容の違いを考慮します。

9.5 格子状の配置が崩れていないか

複数のカードや数値を並べる場合、列幅と間隔を共通化します。一部だけ幅が異なる場合は、情報上の理由があるか確認します。

画面幅が変化したときも、極端に細い列や大きな空白が発生しないようにします。柔軟な列幅と最小幅を設定します。

10. ボタンと操作部品を確認する

ボタンは、利用者が処理を実行するための重要な部品です。見た目だけでなく、文言、状態、操作結果を確認します。

10.1 ボタン文言から結果を予測できるか

「実行」「決定」だけでは、押した後の結果が分からない場合があります。「変更を保存」「請求書を送信」など、対象と結果を示します。

短い文言が適する場面でも、影響の大きい操作は具体化します。確認画面でも同じ文言を維持します。

10.2 主要ボタンが多すぎないか

一つの操作領域に強調されたボタンが複数あると、利用者が選択に迷います。最も重要な操作だけを強く表示します。

補助操作は、枠線付きや文字のみの形式へ変更します。すべての操作を同じ大きさや色で表示しないようにします。

10.3 操作領域が十分な大きさか

記号だけの小さなボタンは、指で押しにくくなります。見た目の記号が小さくても、実際に押せる領域を確保します。

隣接するボタン同士の間隔も確認します。削除と編集など、影響の異なる操作を近づけすぎないようにします。

10.4 操作状態が用意されているか

通常、カーソル通過、キーボード選択、押下、無効、処理中の状態を設計します。通常状態だけでは実装時にばらつきが生じます。

キーボード選択状態は、カーソル通過状態と区別します。現在どの部品を操作できるかを明確に示します。

10.5 記号だけのボタンに説明があるか

ごみ箱や鉛筆の記号でも、文脈によって意味が異なります。読み上げ用の名前と、必要に応じて補足表示を設定します。

危険な操作では、記号だけにせず文字を併記する方法が安全です。対象名を含めた具体的な操作名を付けます。

実装例：状態を持つボタン

.button {  min-height: 2.75rem;  padding: 0.625rem 1.125rem;  font: inherit;  font-weight: 700;  border-radius: 0.625rem;  cursor: pointer; } .button-primary {  color: var(--color-on-primary);  background: var(--color-primary);  border: 1px solid var(--color-primary); } .button:focus-visible {  outline: 0.1875rem solid currentColor;  outline-offset: 0.1875rem; } .button:disabled {  cursor: not-allowed;  opacity: 0.48; }

11. 入力フォームを確認する

入力フォームでは、利用者が正確な情報を少ない負担で入力できることが重要です。項目名、形式、エラー、保存状態を一体として確認します。

11.1 項目名が常に見えるか

入力例を項目名の代わりに使用すると、入力後に項目の意味が分からなくなります。項目名は入力欄の外側へ表示します。

入力例は、形式を示す補助情報として使用します。項目名と入力例の役割を分けます。

11.2 必須と任意が明確か

必須項目と任意項目が混在する場合は、それぞれを明示します。記号だけでなく文字でも意味を示します。

必須項目が多すぎる場合は、本当に最初から必要かを確認します。後から入力できる情報は、初回フォームから分離します。

11.3 入力形式を事前に確認できるか

文字数、使用可能な文字、日付形式などを、入力後のエラーだけで伝えないようにします。入力前または入力中に確認できる説明を付けます。

条件が多い場合は、最も重要な内容を近くへ表示し、詳細説明を別に用意します。長い説明でフォームを埋めないようにします。

11.4 適切な入力形式が指定されているか

メールアドレス、電話番号、日付など、内容に合った入力形式を使用します。スマートフォンで適切なキーボードが表示されるようにします。

自動入力や貼り付けも考慮します。独自部品によって標準的な入力機能を妨げないようにします。

11.5 入力内容が失われないか

送信エラーや画面移動によって、入力内容がすべて消えないか確認します。修正が必要な項目以外は保持します。

長いフォームでは、自動保存や途中保存を検討します。保存状態と最終保存時刻を利用者へ伝えます。

12. 検索と絞り込みを確認する

情報量の多い画面では、検索と絞り込みの設計が作業効率へ大きく影響します。検索対象、条件、解除方法を明確にします。

12.1 検索できる対象が分かるか

検索欄の近くへ、注文番号、顧客名、メールアドレスなど、検索対象を示します。「検索」とだけ表示すると入力内容を判断できません。

複数種類を検索できる場合は、代表的な例を表示します。長すぎる説明を入力欄内へ詰め込まないようにします。

12.2 頻繁に使う条件が見つけやすいか

状態、期間、担当者など、利用頻度の高い条件を優先して表示します。低頻度の条件は、詳細条件として展開できるようにします。

条件の並び順も、利用者が考える順序へ合わせます。内部データの順序をそのまま使用しないようにします。

12.3 適用中の条件が見えるか

検索結果だけが変わり、条件が見えなくなると、なぜ件数が少ないか判断できません。適用中の条件を一覧の近くへ表示します。

条件は個別に解除できるようにします。「すべて解除」も用意し、初期状態へ戻れるようにします。

12.4 検索結果がない場合の案内があるか

結果がない場合に空白だけを表示すると、不具合に見えることがあります。条件に一致する情報がないことを明確に伝えます。

条件の変更、入力間違いの確認、すべての条件解除など、次の行動を案内します。

12.5 検索状態を共有・復元できるか

検索語や条件をURLへ反映すると、同じ結果を共有しやすくなります。戻る操作後にも検索状態を復元できます。

すべての一時状態をURLへ含める必要はありません。再現する価値がある条件を選びます。

13. 一覧表とデータ表示を確認する

一覧表は、大量の情報を比較し、対象を選び、操作するために使用します。必要な列、揃え方、操作方法を整理します。

13.1 必要な列だけが表示されているか

一覧で判断に必要な情報を優先し、詳細画面でしか使わない項目を削減します。列が多すぎると横幅が不足します。

利用者によって必要な列が異なる場合は、表示列を変更できる機能を検討します。初期表示では、多くの利用者が必要とする列を選びます。

13.2 列見出しが具体的か

「情報」「状態」などの広い名称では、内容を判断できません。「支払い状態」「最終更新日」のように具体化します。

短くするために専門的な略称を使う場合は、利用者が理解できるか確認します。必要に応じて補足説明を用意します。

13.3 並べ替え状態が分かるか

どの列を基準に、昇順または降順で並べているかを示します。記号だけで方向が分かりにくい場合は、読み上げ用の説明を設定します。

並べ替え後も検索条件とページ位置を維持します。複数条件による並べ替えは、必要性を慎重に判断します。

13.4 一括操作の対象が明確か

複数行を選択した場合、選択件数と対象操作を表示します。何も選択していない状態では、一括操作を無効にします。

削除や状態変更では、確認画面に件数と代表的な対象名を表示します。一部が失敗した場合の結果も設計します。

13.5 狭い画面で読めるか

横長の表をスマートフォンへ縮小すると読めなくなります。重要な列だけを残し、詳細は展開または別画面で表示します。

横方向へ移動させる場合は、移動できることを示します。対象名などの識別列を固定する方法もあります。

一覧表の確認基準

14. カードとダッシュボードを確認する

カードやダッシュボードは、独立した情報や主要な数値をまとめるために使います。装飾目的で乱用せず、判断と行動につながる構造にします。

14.1 カードのまとまりに意味があるか

カードは、他の内容から独立して扱える情報へ使用します。連続した文章や一つのフォームを細かくカードへ分割しないようにします。

枠や影を付ける理由を確認します。見出しと余白だけで十分に整理できる場合は、カードを減らします。

14.2 数値に期間と単位があるか

「120」という数値だけでは意味を判断できません。「今月の新規注文120件」のように、対象期間と単位を表示します。

前期間との比較を示す場合は、具体的な比較対象を明記します。増減だけを色で示さないようにします。

14.3 数値から詳細へ移動できるか

未処理件数や期限超過件数を表示する場合、対象一覧へ移動できるようにします。状況を確認した後、すぐに作業を開始できる導線が必要です。

数値自体をリンクにする場合は、操作可能であることを分かりやすくします。文字リンクを併記する方法もあります。

14.4 グラフの種類が目的に合っているか

時間変化には折れ線、分類比較には棒など、確認したい内容に合った形式を選びます。見た目の印象だけで選ばないようにします。

分類数が多い円形グラフは比較しにくくなります。正確な値が必要な場合は、表や数値も併記します。

14.5 更新時刻が分かるか

ダッシュボードの数値がリアルタイムか、前日までの集計かを表示します。更新時刻が不明だと、古い情報を現在の状態と誤認する可能性があります。

手動更新が必要な場合は、更新操作と最終更新時刻を近くへ配置します。更新中の状態も表示します。

15. 状態表示と進行状況を確認する

Webアプリでは、読み込み、処理中、完了、失敗などの状態が頻繁に変化します。利用者が現在何が起きているかを理解できるようにします。

15.1 読み込み中であることが分かるか

通信中に画面が停止したように見えると、利用者が同じ操作を繰り返す可能性があります。進行表示や読み込み中の文言を表示します。

短時間の処理で毎回大きな表示を出すと、画面がちらつきます。処理時間や範囲に応じて表示方法を変えます。

15.2 処理対象が分かるか

一括処理では、「処理中」だけでなく、何件中何件を処理しているかを表示すると安心できます。対象名や処理内容も確認できるようにします。

長時間処理では、画面を閉じても継続するかを説明します。処理完了後の通知方法も設計します。

15.3 完了結果が具体的か

「完了しました」ではなく、「12件の注文を発送済みに変更しました」のように対象と結果を示します。

重要な処理では、完了後に次の行動も案内します。詳細確認、一覧へ戻る、別の登録を続けるなど、利用者の流れに合わせます。

15.4 一部失敗を表現できるか

一括処理で一部だけ失敗した場合、全体を成功または失敗として表示してはいけません。成功件数と失敗件数を分けます。

失敗した対象と理由を確認し、再試行できるようにします。成功済みの対象を重複処理しないようにします。

15.5 状態名が業務に合っているか

「状態A」「処理済み」のような曖昧な名称では、次に何をすべきか判断できません。「顧客の返信待ち」「社内確認中」のように具体化します。

内部処理上の細かい状態をすべて表示する必要はありません。利用者の行動に関係する単位へ整理します。

16. エラーと回復方法を確認する

エラーは完全に防ぐことができないため、発生後に利用者が回復できる設計が必要です。問題、原因、次の行動を具体的に示します。

16.1 エラー内容が具体的か

「問題が発生しました」だけでは対応できません。「メールアドレスの形式を確認してください」など、修正方法を伝えます。

内部の技術情報をそのまま表示しないようにします。必要な場合は、問い合わせ用の識別番号だけを表示します。

16.2 エラー位置が分かるか

入力エラーは、該当欄の近くへ表示します。画面上部の概要だけでは、修正場所を探す必要があります。

長いフォームでは、最初のエラーへ移動できるようにします。概要から各項目へ移動するリンクも有効です。

16.3 入力内容が保持されるか

送信失敗後にすべての入力内容が消えると、利用者の負担が大きくなります。問題がある項目以外は保持します。

機密情報など、再表示できない内容がある場合は、事前に説明します。再入力が必要な項目を明確にします。

16.4 再試行方法があるか

通信エラーでは、再試行ボタンや後から続ける方法を用意します。画面を再読み込みするだけに依存しないようにします。

再試行時に同じ処理が重複しないことも重要です。支払い、登録、送信などでは特に慎重に確認します。

16.5 問い合わせ方法が示されているか

利用者だけでは解決できない場合、問い合わせ先や管理者への依頼方法を案内します。単に「管理者へ連絡してください」で終わらせないようにします。

問い合わせ時に必要な情報を自動で含める方法も有効です。利用者へ技術的な内容の転記を求めないようにします。

17. 空の状態と初回利用を確認する

データが存在しない状態は、異常ではなく、初回利用や検索結果なしで頻繁に発生します。空白だけでなく、理由と次の行動を示します。

17.1 初回利用の空状態が設計されているか

最初にデータがない場合は、何を登録すればよいか説明します。主要な登録操作を近くへ配置します。

長い説明だけを表示せず、短い案内と操作を組み合わせます。必要に応じて例やひな型を提供します。

17.2 検索結果なしと初回状態を区別しているか

検索結果がない場合は、登録を促すより条件変更を案内する方が適切です。同じ空表示を使い回さないようにします。

適用中の条件を表示し、解除方法を示します。入力間違いの可能性も案内します。

17.3 権限不足による空表示を避けているか

閲覧権限がない場合に空白だけを表示すると、データがないのか判断できません。権限が必要であることを説明します。

機密機能の存在自体を知らせない方がよい場合もあります。情報の性質に応じて表示方法を決めます。

17.4 読み込み失敗を空状態として表示していないか

通信失敗とデータなしは異なる状態です。失敗時には、エラーと再試行方法を表示します。

空状態の部品を共通化する場合でも、理由ごとに文言と操作を変更できるようにします。

17.5 空状態が画面の目的を説明しているか

初回画面では、機能の価値と利用方法を簡潔に説明できます。ただし、宣伝文を長く表示して主要操作を埋もれさせないようにします。

利用者が最初の行動を判断できることを優先します。登録後には表示されない内容なので、必要な情報へ絞ります。

18. 確認画面と重ね表示を確認する

確認画面や重ね表示は、重要な判断や補助操作に使います。多用すると画面の流れを分断するため、必要性を確認します。

18.1 重ね表示を使う理由があるか

短い確認や補助入力には適していますが、長いフォームや複雑な作業には向きません。内容量と作業時間を確認します。

別画面にした方が戻る操作や共有がしやすい場合もあります。見た目の流行だけで重ね表示を選ばないようにします。

18.2 見出しから目的が分かるか

「確認」のような曖昧な見出しではなく、「注文をキャンセルしますか」のように具体化します。

本文には、実行後の影響を記載します。取り消し可能かどうかも明確にします。

18.3 閉じる方法が分かるか

閉じるボタン、キャンセル操作、Escapeキーなど、閉じ方を設計します。背景を押すだけに依存しないようにします。

入力内容を含む場合は、誤って背景を押しただけで閉じない方が安全なことがあります。内容の重要度に合わせます。

18.4 キーボード選択が内部へ移動するか

重ね表示を開いたとき、キーボード選択を内部へ移動します。背後の要素へ移動できないようにします。

閉じた後は、開いたボタンへ選択を戻します。利用者が元の作業位置を見失わないようにします。

18.5 危険な操作が明確に区別されているか

削除や公開停止は、通常の保存操作と異なる見た目にします。ただし、赤色だけに依存しないようにします。

確認画面には、対象名や件数を表示します。一般的な確認文を毎回表示するだけでは、内容を読まなくなる可能性があります。

実装例：標準ダイアログ

<button id="delete-open" type="button">
 注文を削除
</button>

<dialog id="delete-dialog" aria-labelledby="delete-title">
 <form method="dialog">
   <h2 id="delete-title">注文を削除しますか</h2>
   <p>削除後は元に戻せません。</p>

   <button value="cancel">キャンセル</button>
   <button value="confirm">削除する</button>
 </form>
</dialog>

19. 動きと画面反応を確認する

動きは、操作と結果の関係を理解させるために使用します。装飾目的で増やさず、作業速度を妨げないようにします。

19.1 動きに明確な目的があるか

領域の開閉、項目追加、画面切り替えなど、何が変化したかを伝える目的で使います。意味のない回転や拡大を避けます。

動きを削除しても情報が伝わることが重要です。色や文言でも状態変化を確認できるようにします。

19.2 動きが長すぎないか

長い動きは、反復作業の効率を下げます。小さな変化は短く、広い領域の移動は少し長くするなど調整します。

同じ種類の部品で時間が異ならないようにします。製品内で共通の時間段階を定義します。

19.3 開始点と終了点が自然か

選択した項目から詳細が開くなど、元の対象との関係が分かる動きにします。関係のない位置から突然表示しないようにします。

複雑な変形を使わなくても、透明度や短い移動で十分な場合があります。性能への影響も確認します。

19.4 読み込み表示がちらつかないか

短時間の処理で読み込み表示を即座に出すと、画面がちらついて見えます。一定時間を超えた場合だけ表示する方法を検討します。

読み込みが長い場合は、仮の内容領域を表示し、配置が大きく変わらないようにします。

19.5 動きを減らす設定へ対応しているか

端末やブラウザで動きを減らす設定が有効な場合は、不要な動きを停止または短縮します。

完全に停止した場合でも、操作結果を理解できるか確認します。動きだけに依存した案内を作らないようにします。

20. レスポンシブ表示を確認する

異なる画面幅では、単純に縮小するのではなく、情報の優先順位と配置を変更します。狭い画面でも主要操作を完了できるようにします。

20.1 最小幅から最大幅まで確認したか

特定の端末寸法だけでなく、画面幅を連続的に変化させて確認します。中間幅で崩れる問題を発見できます。

横向きや分割表示も考慮します。端末名だけで切り替え位置を決めないようにします。

20.2 狭い画面で主要情報が先に表示されるか

補助情報より、主要情報と主要操作を優先します。重要な内容を折りたたみ領域へ移さないようにします。

広い画面で横並びだった内容は、自然な順序で縦並びにします。読み順と操作順を確認します。

20.3 横方向へのはみ出しがないか

意図しない横移動が発生していないか確認します。長い文字列、画像、表、固定幅の部品が原因になりやすくなります。

表など、横移動が必要な領域は、画面全体ではなく該当部分だけを移動可能にします。

20.4 固定領域が画面を圧迫していないか

上部、下部、左側をすべて固定すると、狭い画面で本文領域が小さくなります。必要な固定領域だけを残します。

キーボード表示時に、入力欄や保存ボタンが隠れないかも確認します。安全領域も考慮します。

20.5 画像やグラフが適切に変化するか

画像が重要部分を切り落としていないか確認します。画面幅に応じて切り抜き位置を変更する場合もあります。

グラフでは、文字や凡例が読めるか確認します。複雑なグラフを狭い画面へそのまま縮小しないようにします。

画面幅別の確認例

21. アクセシビリティを確認する

アクセシビリティは、特定の利用者だけでなく、すべての人の操作性に影響します。設計段階から確認し、完成後の追加作業にしないようにします。

21.1 キーボードだけで操作できるか

主要メニュー、入力、保存、確認画面をキーボードだけで操作します。選択順序が画面の読み順と一致しているか確認します。

操作不能な独自部品がないか確認します。標準のボタンやリンクを優先します。

21.2 選択位置が明確に見えるか

キーボードで選択されている要素には、十分に見える輪郭線を表示します。見た目を整えるために削除しないようにします。

背景色が変わる場所でも認識できる輪郭線を設定します。カーソル通過状態とは区別します。

21.3 画像に適切な説明があるか

意味を持つ画像には、同等の内容を伝える説明を設定します。装飾画像は読み上げ対象から除外します。

画像内の文字だけで重要情報を伝えないようにします。本文としても同じ情報を提供します。

21.4 色以外でも状態を理解できるか

エラー、成功、選択状態を、文字、記号、形でも示します。色を除いた状態で画面を確認する方法も有効です。

グラフでは、線種、記号、直接ラベルを利用します。凡例の色だけで判断させないようにします。

21.5 読み上げ順序が自然か

視覚的な配置とHTML上の読み順が大きく異ならないか確認します。CSSによる位置変更だけで順序を入れ替えると問題が起きる場合があります。

動的に追加された通知やエラーも読み上げられるようにします。ただし、すべての変化を強く通知しないようにします。

22. 文言と内容設計を確認する

UI上の文章は、利用者の判断と操作を支えます。短くすることだけを目標にせず、意味が具体的に伝わるか確認します。

22.1 用語が統一されているか

同じ対象を「利用者」「会員」「ユーザー」と呼び分けると、別の意味に見える可能性があります。製品内で用語を統一します。

業務上異なる意味がある場合は、その違いが伝わる名称を使います。開発内部の名称をそのまま表示しないようにします。

22.2 操作文言が具体的か

ボタンやメニューは、利用者が何をできるかを示します。「次へ」だけでは移動先が不明な場合は、「入力内容を確認」などに変更します。

短さより予測可能性を優先します。影響の大きい操作では対象名を含めます。

22.3 エラー文が責任を利用者へ押し付けていないか

「不正な入力です」のような表現は、利用者を責めている印象を与えます。問題と修正方法を中立的に説明します。

システム側の問題を利用者の操作ミスとして表示しないようにします。通信失敗などは正確に案内します。

22.4 説明文が長すぎないか

重要な情報を簡潔にし、詳細は必要な場合に確認できるようにします。長文を入力欄の間へ大量に配置しないようにします。

文章を削るだけでなく、見出し、箇条書き、例を使って読みやすくします。重要な条件を省略しないようにします。

22.5 日付・数値・単位が統一されているか

日付形式、時刻表記、通貨、桁区切りを製品内で統一します。画面ごとに異なる形式を使わないようにします。

対象地域や言語に合わせた表示も必要です。内部形式をそのまま利用者へ見せないようにします。

23. 一貫性とデザインシステムを確認する

画面数が増えるほど、部品や規則の一貫性が重要になります。見た目だけでなく、動作、文言、状態表示を共通化します。

23.1 同じ役割の部品が同じ見た目か

保存ボタン、入力欄、状態表示など、同じ役割の部品を画面ごとに作り直していないか確認します。

微妙な色や余白の違いも、一覧で見ると不揃いに見えます。共通部品を利用します。

23.2 同じ操作が同じ場所にあるか

保存操作が画面によって上部、下部、右側へ変わると、利用者が探す必要があります。共通の配置規則を決めます。

例外的な配置が必要な場合は、利用者の作業順序に理由があるか確認します。

23.3 状態表現が統一されているか

同じ「完了」を、ある画面では緑、別画面では青で表示しないようにします。文字、色、記号を共通化します。

状態名も統一します。「完了」「処理済み」「終了」が同じ意味なら一つに揃えます。

23.4 設計用の値が共通化されているか

色、文字、余白、角の丸みを共通変数として管理します。画面ごとの直接指定を減らします。

変数名は、見た目だけでなく役割を表す名称にします。値が変わっても用途を理解できるようにします。

23.5 利用規則が文書化されているか

部品を用意するだけでは、使い方は統一されません。主要ボタンの数、危険色の用途などを文章で定義します。

正しい例と避けるべき例を用意します。新しい担当者が判断しやすい状態を作ります。

実装例：共通変数

:root {
 --space-small: 0.5rem;
 --space-medium: 1rem;
 --space-large: 1.5rem;

 --radius-small: 0.375rem;
 --radius-medium: 0.75rem;

 --font-size-body: 1rem;
 --font-size-heading: 1.25rem;
}

24. 実装への引き継ぎを確認する

デザイン資料だけで意図が伝わらなければ、実装時に解釈の違いが生じます。状態、画面幅、文言、操作結果を明確に共有します。

24.1 すべての状態が用意されているか

通常状態だけでなく、読み込み中、空、エラー、無効、選択中を共有します。実装担当者へ判断を任せすぎないようにします。

表示条件も説明します。どの操作やデータによって状態が変わるかを明確にします。

24.2 画面幅ごとの変化が示されているか

デスクトップとスマートフォンの完成画面だけでなく、中間幅での変化も説明します。どの位置で列やメニューが変わるかを共有します。

固定値だけでなく、内容に応じた柔軟な規則を示します。文章が長い場合の動作も確認します。

24.3 部品名が実装側と対応しているか

デザイン上の部品名と、実装上の名称を揃えると意思疎通がしやすくなります。同じ部品を異なる名前で呼ばないようにします。

状態や種類の名称も共通化します。主要、副次、危険など、役割が分かる名前を使います。

24.4 画像と記号の書き出し条件が明確か

画像形式、寸法、解像度、透明背景の有無を指定します。不要に大きな画像を配信しないようにします。

記号は可能な範囲でベクター形式を使用します。色を実装側で変更できる構造か確認します。

24.5 実装後の確認範囲が決まっているか

デザインとの見た目の差だけでなく、キーボード操作、入力、通信状態を確認します。実装確認を一回の画像比較で終わらせないようにします。

修正担当者と完了条件を事前に決めます。設計側の問題が見つかった場合は、実装だけを無理に合わせずデザインを更新します。

25. 公開前レビューと優先度を確認する

公開前には、すべての問題を同じ重要度で扱わず、利用不能、安全性、主要操作への影響を優先します。確認結果を記録し、公開判断を明確にします。

25.1 主要な利用経路を最初から最後まで確認したか

登録、購入、申請など、中心となる利用経路を実際に操作します。個別画面が正しくても、画面間のつながりに問題がある場合があります。

正常な条件だけでなく、入力エラー、戻る操作、通信失敗も確認します。完了後の通知や移動先も対象です。

25.2 複数の端末とブラウザで確認したか

主要な端末とブラウザで、表示と操作を確認します。開発環境だけで正常に見える状態を避けます。

キーボード、タッチ、ポインターなど、異なる入力方法も確認します。端末固有の入力補助を妨げていないか見ます。

25.3 問題の優先度を統一しているか

利用不能や情報漏えいは公開前に必ず修正します。軽微な余白差と同じ扱いにしないようにします。

以下の基準をチーム内で共有し、判断理由も記録します。

25.4 修正後に再確認したか

修正した事実だけでなく、問題が解決したかを確認します。変更によって別の画面や状態が崩れていないかも見ます。

共通部品を変更した場合は、代表的な利用画面を複数確認します。影響範囲を記録します。

25.5 公開判断と未対応項目を記録したか

公開する場合でも、未対応の問題、影響、対応予定を記録します。問題が存在しないことにして公開しないようにします。

公開後に確認する指標や問い合わせ状況も決めます。実際の利用結果を次回の改善へ反映します。

公開前チェックを管理する実装例

const releaseChecklist = [
 {
   category: "主要操作",
   items: [
     "登録を完了できる",
     "保存結果が表示される",
     "戻る操作で状態が維持される"
   ]
 },
 {
   category: "異常状態",
   items: [
     "入力エラーを修正できる",
     "通信失敗後に再試行できる",
     "空状態から次の操作へ進める"
   ]
 },
 {
   category: "アクセシビリティ",
   items: [
     "キーボードだけで操作できる",
     "選択位置が見える",
     "色以外でも状態を理解できる"
   ]
 }
];

function countIncompleteItems(groups, completedItems) {
 return groups.reduce((total, group) => {
   const incompleteCount = group.items.filter(
     (item) => !completedItems.has(item)
   ).length;

   return total + incompleteCount;
 }, 0);
}
 

おわりに

UIデザインのチェックでは、配色や余白などの視覚的な完成度だけでなく、利用者が目的を達成できるか、操作結果を理解できるか、問題発生後に回復できるかを確認することが重要です。通常状態だけを確認しても、実際の利用環境で発生する問題を十分に発見できません。

チェックリストは、すべての項目を機械的に満たすための規則ではありません。対象利用者、画面の目的、操作頻度、情報量に応じて重要度を調整し、判断理由を記録するための道具として使用します。

繰り返し見つかる問題は、個別画面だけで修正せず、共通部品、設計用の値、利用規則へ反映します。チェック結果をデザインシステムと制作工程の改善につなげることで、画面数が増えても一貫性と使いやすさを維持できます。