この記事の要点
- 画面を公開する前に見る確認項目を8分野に分け、1項目ごとに「見るもの」「どう確かめるか」「閾値」「出典」の4つの欄を用意しました。閾値（合格ラインの数字）は、規格や提供元の公式文書（一次資料）にあるものだけを書き、合否の線が公表されていない項目は数字を置かず「目安」（判断の材料）と書いています
- デザインQA（Design QA）は、実装された画面が設計どおりに見えるか、使う人が迷わず操作できるかを、公開する前に確かめる工程です。実装後に、デザイナーなど公開の責任を持つ人が、出来上がった画面と設計時のデザインファイル（画面の設計図）を見比べる作業を指します
- QAテスト（品質保証のテスト）は「動くか、仕様どおりか」を見ます。デザインQAは「設計どおりに見えるか、迷わず操作できるか」を見ます。片方が通っても、もう片方は別に確かめる必要があります
デザインQAという言葉の短い定義は、用語集の「デザインQA」にまとめています。この記事は、画面を公開する前に見る確認項目のほうを扱います。
デザインQAとは何か
デザインQA（Design QA）は、Design Quality Assurance を縮めた言い方で、日本語にすると「デザイン品質保証」です。実装された画面が設計どおりに見えるか、使う人が迷わず操作できるかを、公開する前に確かめる工程を指します。
QA（Quality Assurance、品質保証）は、あらかじめ決めた品質を製品が満たしているかを確かめる活動の総称です。その頭に「デザイン」が付くことで、確かめる対象が「動くか」から「見え方と操作」に移ります。
英語圏と日本での使われ方
Design QA は、英語圏では以前から使われている一般語です。カナダの開発会社 Rangle は2018年の記事で、デザインQAを「デザイナーが設計に込めた意図が、出来上がった画面に反映されているかを確かめること」と定義しています。クロアチアの開発会社 Infinum は社内の手順書で「デザインで定義したとおりに実装されているかを、デザイナーが確認する方法」と書いています。同じ手順書は、フォント、余白と揃え、ボタン、操作の状態（押している最中や押せないときの見え方）、画像など12の分類で確認項目を並べています。
日本でも同じ意味で使われています。スタディサプリの開発チームは2023年の記事で、エンジニアが実装したアプリの画面をデザイナーがレビューする工程をデザインQAと呼び、角の丸みや影の細部、状態ごとの見え方を確かめていると書いています。
綴りは「Design QA」と2語で書きます。英語圏では工程の名前は語を分けて書くのが普通で、1語に詰めた「DesignQA」は製品の名前に見えるためです。2語で書く規則の例外は、ドメイン名のようにスペースを使えない場所だけです（design-qa.com のように小文字とハイフンでつなぎます）。
「設計どおりか」から「出してよいか」へ
UIXHERO（このサイト）では、この語をもう1段広げて使っています。UIXHERO の使い方には2つの段があります。
- 設計どおりに実装されていて、明らかに操作を妨げる不備が無いかを確かめること
- その画面を公開してよいかどうかを判定すること
この記事の確認項目は、1つめのためのものです。2つめの判定に使う観点は、記事の後半で扱います。
QAテストとの違い
QAテストは、品質保証のテストです。プログラムが動くか、仕様どおりかを確かめます。
| QAテスト | デザインQA | |
|---|---|---|
| 問い | 動くか。仕様どおりか | 設計どおりに見えるか。迷わず操作できるか |
| 見るもの | 機能、データ、エラー処理、性能 | 余白、文字、押せるもの、色とコントラスト、配置と揃え、状態の表示、入力、画像（8分野） |
| 主に確かめる人 | QA担当、開発者 | デザイナー、または画面を出す責任を持つ人 |
| 通らないとどうなるか | 動かない。壊れる | 動くが、読みにくい。押せない。迷う |
| 行う時期 | 実装後から公開前 | QAテストと並行、または直後（どちらも実装後から公開前） |
QAテストが通った画面でも、ボタンが小さすぎて指で押せない、文字の色が薄くて読めない、入力を間違えてもどこが違うのか分からず直せない、といった問題は残ります。逆に、見た目が設計どおりでも、送信を押すとエラーになって先へ進めない画面は出せません。2つは別の問いなので、どちらか一方で置き換えられません。
用語としての違いは 品質保証（QA） にまとめています。設計の途中で案を評価する デザインレビュー とも時点が違い、デザインQAは実装が終わった後に行います。
チームが「この作業は終わり」と言うための条件表を、完成の定義（Definition of Done、DoD）と呼びます。完成の定義（DoD） に「デザインQAが完了していること」を入れる方法もあります。そうすると、この工程は誰かが気づいたときにやる作業ではなく、実装のたびに行う手順になります。
出す前に見る確認項目
ここからが確認項目です。8分野に分けました。1項目ごとに、見るもの、どう確かめるか、閾値、出典の4つの欄を用意しています。
タップして拡大表示クリックして拡大表示
閾値の読み方を先に決めておきます。
- 閾値は、合格ラインの数字のことです。規格や提供元の公式文書（一次資料）にあるものだけを書いています。引いている先は、WCAG（Web Content Accessibility Guidelines。W3C が定めるウェブアクセシビリティの指針）の 2.2 版、Apple の Human Interface Guidelines（iPhone などのアプリの設計指針。以下 Apple HIG）、Google の Material Design 3（Android などの設計指針。以下 Material 3）、Nielsen Norman Group（ユーザビリティの調査会社。以下 NN/g）、MDN Web Docs（Mozilla が運営するウェブ技術の資料。以下 MDN）、Baymard Institute（ウェブの使い勝手を調べている調査会社）です。NN/g の創設者 Jakob Nielsen が1994年に公開した「ユーザビリティ10原則」は、「Nielsen（1994）の◯番」のように番号を付けて書きます
- 「目安」と書いた項目は、一次資料に合否の線（数字、または WCAG が定める合否の条件文）が無いものです。出典に挙げた資料は、線ではなく考え方の根拠です。守る・守らないを決める線ではなく、見落としを減らすための判断の材料として使ってください。当サイトの解説ページを参照先にした項目は、出典の欄に「当サイト」と書いています
- WCAG の各基準には A、AA、AAA の3段階があります。この記事では A と AA を満たすべき基準、AAA を余裕があれば満たす基準として扱います
- 出典に出てくるそのほかの資料は、W3C WAI（Web Accessibility Initiative。W3C のアクセシビリティ部門。以下 WAI）のチュートリアルです
- 「コンポーネント」は、ボタン、入力欄、カードのように、画面を組み立てる単位のことです
- 出典は、いずれも2026年9月16日に一次資料を読んで確認したものです
単位の読み方
- CSS pxは、ブラウザが画面の細かさに関わらず使う単位です。画面の粒（物理的なピクセル）の数とは一致しません。開発者ツールに出る数字はこれです
- WCAG に出てくる ptは印刷の単位で、1pt は 1.333 CSS px です。18pt は 24px、14pt は 18.7px に当たります。WCAG の注には約 18.5px とありますが、この記事では 18.7px を使います
- Apple の pt と Google の dpは、画面の密度に依らない単位です。この記事では、どちらも CSS px と同じ大きさとして読みます。Material 3 の資料も、iOS の 44pt を換算せずにそのまま dp の数字と並べています。sp は Android で文字サイズに使う単位です
- アプリの中の数値（pt、dp、sp）は、この記事の道具では読めません。作り手にデザインファイル上の数値を出してもらい、その数字と比べます
確かめるときに使う道具と操作
表の「どう確かめるか」に出てくる操作は、次の道具でできます。いずれも無料です。
- 開発者ツールは、ブラウザに付いている検証用の画面です。Chrome なら右クリックの「検証」か F12 キーで開きます。Elements（要素）の画面で要素を選ぶと、幅と高さが出ます。文字サイズ（font-size）、行間（line-height）、書体（font-family）、太さ（font-weight）は、Computed（計算済み）の欄で読みます。値を書き換えて試すときは、Styles（スタイル）の欄で数字をクリックして打ち直します。HTML の中身（alt や disabled）は、Elements の画面のタグに書かれています
- 大きさを読むときは、要素を選んだときに出る幅と高さを読みます。これは枠線の内側までの大きさで、内側の余白（padding）は含み、外側の余白（margin）は含みません
- 間隔（隙間）を測るには、開発者ツールで要素を選び、Computed の欄にある枠の図で、外側の余白（margin）を読みます。隣り合う2つの要素の間隔は、間にある margin の合計です。読み取れないときは、画面を撮り、GIMP（無料の画像編集ソフト）の Measure（ものさし）ツールで測ります。Mac の高解像度の画面で撮った画像は、先に幅を 1/2 に縮めます
タップして拡大表示クリックして拡大表示
- 幅を 320px にするには、開発者ツールの端末表示（Chrome では「デバイスのツールバー」）で幅に 320 と入力します
- 通信を遅くする、止めるには、開発者ツールの Network（ネットワーク）の画面にある回線速度の設定で、遅い回線や Offline（オフライン）を選びます。同じ画面に、通信ごとの所要時間が出ます
- コントラストチェッカーは、2つの色から色の濃さの差（コントラスト比）を計算する道具です。Chrome の開発者ツールでは、文字の色の欄を開くと背景との比が出ます。枠線やアイコンのように文字ではないものは、画面を撮り、色を拾う機能（スポイト）で2色を取り出して、WebAIM の Contrast Checker（無料のウェブ上の道具）に入れます
- 画面を白黒にするには、Chrome の開発者ツールの Rendering（レンダリング）の画面で、Emulate vision deficiencies（視覚の状態を再現する設定）の Achromatopsia（色の区別がつかない状態）を選びます。Mac なら「システム設定」の「アクセシビリティ」にある「ディスプレイ」の「カラーフィルタ」でも白黒にできます
- 画像を表示しないには、Chrome の「設定」の「プライバシーとセキュリティ」にある「サイトの設定」で、画像を表示しない設定にします
- 画面の読み上げは、Mac なら VoiceOver（command キーと F5 キーで入切）、Windows ならナレーター（Windows キーと Ctrl キーと Enter キー）を使います
- 線を重ねるには、画面を撮り、GIMP でガイド（等間隔の縦線）を重ねます。Mac の高解像度の画面で撮った画像は、先に幅を 1/2 に縮めます
1. 余白
タップして拡大表示クリックして拡大表示
| 見るもの | どう確かめるか | 閾値 | 出典 |
|---|---|---|---|
| まとまりの中と外の間隔 | 見出しで区切られた区画どうしの間隔と、区画の中のコンポーネントどうしの間隔を測り、前者が広いか。例：ラベルと入力欄が内側のまとまり、フォーム全体が外側のまとまり | 数値の閾値なし（目安）。近くにあるものは同じまとまりとして見られる（近接の原則） | NN/g「Proximity Principle」（Harley, 2020） |
| 画面の端と囲みの端 | 幅 320px にして、文字やコンポーネントが、画面の端や、カードや枠などの囲みの内側に触れていないか | 数値の閾値なし（目安） | 当サイト：余白（Whitespace） |
| 間隔の値の種類 | 同じ役割の間隔を数か所測り、値が1種類に揃っているか | 数値の閾値なし（目安）。関係する要素の間隔が一定だと、目で追いやすい | Material 3「Grids & spacing」 |
2. 文字
| 見るもの | どう確かめるか | 閾値 | 出典 |
|---|---|---|---|
| フォントの数 | 開発者ツールで見出しと本文を選び、Computed の欄の font-family を読み比べる。見出し用と本文用の2つに収まらないなら、理由を言えるか | 数値の閾値なし（目安）。書体を増やすと、情報の階層が見えにくくなる | Apple HIG「Typography」 |
| 本文の文字サイズ | ウェブは開発者ツールで本文の font-size を読む。アプリは作り手にデザインファイル上の数値を出してもらう | ウェブはブラウザの既定 16px を下回らないこと（既定値を線にする）。iOS アプリは 17pt を基準に、11pt を下回らないこと。Android アプリは 14sp が基準 | MDN「font-size」／Apple HIG／Material 3 |
| 行間（広げても崩れないか） | 開発者ツールの Styles の欄で line-height を文字サイズの 1.5 倍に書き換え、重なりや欠けが出ないか | 1.5 倍に広げても内容と機能を失わないこと（AA） | WCAG 1.4.12 |
| 行間（元の値） | 元の line-height を font-size で割る。normal と出たら行間が指定されていない状態なので、1.5 未満として扱う | 1.5 以上（AAA） | WCAG 1.4.8 |
| 行長（1行の文字数） | パソコンの幅（例：1280px）で見て、本文でいちばん長い行を1つ選び、文字数を数える | 日本語は1行 40 字以内（WCAG 1.4.8、AAA）。英語は 50 から 75 字（Baymard, 2022） | WCAG 1.4.8／Baymard「Readability: The Optimal Line Length」 |
| 拡大したときの崩れ | ブラウザの拡大を 200% にして、文字が重なったり切れたりしないか | 200% まで、内容と機能を失わないこと（AA） | WCAG 1.4.4 |
3. 押せるもの
タップして拡大表示クリックして拡大表示
| 見るもの | どう確かめるか | 閾値 | 出典 |
|---|---|---|---|
| 押せる範囲の大きさ | 開発者ツールでボタン、リンク、アイコンを選び、出てくる幅と高さを読む（枠線の内側までの大きさ。周りの margin は含めない） | 24×24 CSS px 以上（AA）。44×44 以上で AAA | WCAG 2.5.8／2.5.5 |
| 24×24 に満たないものの例外 | 前の行で 24×24 に満たなかったものだけ見る。隣も 24×24 に満たないなら、中心どうしの距離を測る。隣が大きいなら、中心から隣の枠までの距離を測る | 中心どうしが 24px 以上、または中心から隣の枠までが 12px 以上なら可（AA）。満たなければ不合格 | WCAG 2.5.8 の例外 |
| アプリの場合の大きさ | スマートフォンのアプリなら、作り手にデザインファイル上の数値を出してもらい、OS ごとの数字と比べる | iOS は 44×44pt が合格線。28×28pt はやむを得ない場合の下限で、理由を言えないなら不合格。Android は 48×48dp | Apple HIG／Material 3 |
| 押せるものどうしの隙間 | 隣り合うボタンやアイコンの間の隙間を測る | ウェブは 8px 以上（Material 3 の 8dp を CSS px に読み替え）。iOS アプリは、枠のあるボタンどうしで約 24pt（各ボタンの周りに約 12pt ずつ）、文字だけのものどうしで約 48pt（同 24pt ずつ）。iOS の数字は Apple HIG が「約」と書いているので目安 | Material 3／Apple HIG |
| 押せると分かる見た目 | 画面を撮り、文字の部分を塗りつぶす。それでも押せる場所が分かるか。色、形、下線、影のどれで見分けているか | 数値の閾値なし（目安）。押せる印が弱いと、利用者が作業を終えるまでの時間が延びる | NN/g「Flat UI Elements」（Moran, 2017）／当サイト：アフォーダンス |
| 5つの状態 | 通常、ホバー（マウスを載せた）、フォーカス（Tab キーで選んだ）、押下（押している最中）、無効（押せない）の5つが見た目で区別できるか。ページを途中までスクロールしてから Tab キーを押し続け、選ばれている場所が上下の固定された帯に隠れないか | フォーカスの印が見えること（AA）。固定ヘッダーなどに完全に隠れないこと（AA）。Material 3 はこの5つにドラッグ中を加えた6つを定義 | WCAG 2.4.7／2.4.11／Material 3「States」 |
| ホバーで出る内容 | ツールチップや補足が、マウスを載せると出るなら、その上にマウスを動かしても消えないか。載せたまま 10 秒ほど置いて消えないか。Esc キーで閉じられるか | 閉じられる、その上にマウスを載せられる、勝手に消えない、の3条件（AA） | WCAG 1.4.13 |
4. 色とコントラスト
| 見るもの | どう確かめるか | 閾値 | 出典 |
|---|---|---|---|
| 本文のコントラスト | 文字色と背景色の比をコントラストチェッカーで測る | 4.5:1 以上（AA） | WCAG 1.4.3 |
| 大きな文字のコントラスト | 開発者ツールの Computed で font-size と font-weight を読み、大きな文字に当たるか決めてから、コントラストチェッカーで比を測る | 3:1 以上（AA）。「大きな文字」は、font-weight が 700 以上（太字）なら 19px 以上、太字でなければ 24px 以上。WCAG の 14pt と 18pt を切り上げた当サイトの決め | WCAG 1.4.3 |
| UIコンポーネントとアイコン | 入力欄の枠線、ボタンの輪郭、アイコン、フォーカスの印の色をスポイトで取り、比を測る。枠線は外側の地色との比（内側の色とも接するなら、比の小さいほう）。アイコンは面積のいちばん広い色 | 3:1 以上（AA）。無効状態のものは対象外 | WCAG 1.4.11 |
| 色だけで伝えていないか | 画面を白黒にして、エラー、必須、選択中、リンクが分かるか | 色を唯一の手がかりにしないこと（A） | WCAG 1.4.1 |
| 無効に見えて有効なもの | 薄い色のボタンを開発者ツールで選び、disabled（無効）の印が付いているか見る。押して確かめない | (1) 無効ではなく、比が 3:1 未満なら不合格。(2) 無効ではなく、比は足りているが薄く見えるだけなら、基準では不合格にならないので、目で見つけて直す。無効と指定されたものは対象外 | WCAG 1.4.3／1.4.11 の適用除外 |
5. 配置と揃え
タップして拡大表示クリックして拡大表示
| 見るもの | どう確かめるか | 閾値 | 出典 |
|---|---|---|---|
| 列（グリッド）に乗っているか | 画面を撮り、いちばん多くの要素が並ぶ左端を1本目にして、いちばん狭い列の幅の間隔で縦線を重ね、どの線にも乗らない要素を数える。乗らない要素があれば、作り手に理由を聞く | 数値の閾値なし（目安） | 当サイト：グリッドシステム |
| 同じ役割は同じ見た目か | いちばん押してほしいボタン（送信、購入など）、リンク、見出しが、画面をまたいで同じ大きさ、色、位置か | 数値の閾値なし（目安）。同じ意味のものが違う見た目になっていないこと | Nielsen（1994）の4番「一貫性と標準」 |
| 狭い幅での崩れ | 開発者ツールの端末表示で幅を 320px にし、横スクロールが出ないか、内容が欠けないか | 幅 320 CSS px で、横方向のスクロール無しに読めること（AA） | WCAG 1.4.10 |
| 長い文字列での崩れ | 名前、住所、件名に全角 40 字を入れ、はみ出しや重なりが出ないか。100 字ほどの切れ目のない URL も入れる | 数値の閾値なし（目安） | 当サイト：状態と例外を先に設計する |
6. 状態の表示（読み込み中、空、エラー、成功）
タップして拡大表示クリックして拡大表示
| 見るもの | どう確かめるか | 閾値 | 出典 |
|---|---|---|---|
| 読み込み中 | 2段で見る。(1) 回線を遅くして押し、結果が出るまでの間に画面に何が出ているか見る。(2) 遅くしない状態で押し、その通信の所要時間を Network の画面で読む | (2) の時間が 1 秒を超えるなら、(1) で動いていると分かる表示が出ること。10 秒を超えるなら進み具合が出ること。0.1 秒までは即時と感じる | NN/g「Response Times」（Nielsen, 1993） |
| 空の状態 | データが0件の状態（作ったばかりのアカウント、0件の検索）で、一覧や検索結果に何が出るか。なぜ空か、次に何をすればよいかが書かれているか | 数値の閾値なし（目安） | 当サイト：Empty State（空状態） |
| エラーの状態 | 3つ試す。(1) 開発者ツールで通信を止めて送信する。(2) 必須の欄に通らない値を入れて送信する。(3) 見る権限の無いページの URL（作り手に用意してもらう）を開く | (2) は、どの欄がなぜ駄目かを文字で示すこと（WCAG 3.3.1、A）。(1) と (3) は、原因と次にすることを、起きた場所の近くに文字で出すこと（NN/g） | WCAG 3.3.1／NN/g「Error-Message Guidelines」（2023） |
| 成功の状態 | 送信、保存、削除のあとに、済んだことが画面で分かるか。読み上げを入にして保存を押し、完了の知らせが読み上げられるか聞く | 完了の知らせが、フォーカスを移さずに読み上げにも伝わること（AA）。見た目が変わらない操作ほど、利用者は完了に気づけない | WCAG 4.1.3／Nielsen（1994）の1番「システム状態の可視化」 |
7. 入力
| 見るもの | どう確かめるか | 閾値 | 出典 |
|---|---|---|---|
| ラベル | 全ての入力欄に、常に見えるラベルがあるか。ラベルをクリックすると入力欄にカーソルが入るか | 入力を求める全ての箇所に、ラベルか説明があること（A） | WCAG 3.3.2／WAI「Labeling Controls」 |
| プレースホルダー | 入力欄の中の薄い文字だけで、何を入れるかを伝えていないか。1文字入れて薄い文字が消えたあとも、何を入れる欄かがラベルなどで分かるか | 数値の閾値なし（目安）。プレースホルダーをラベルの代わりにしない。入力を始めると説明が消えて思い出せなくなり、入力前の薄い文字は入力済みと見間違えられる | WAI「Form Instructions」／NN/g「Placeholders」（Sherwin, 2014） |
| エラー文 | わざと間違えて送信し、どの欄が、なぜ間違いかが文字で出るか。直し方が書かれているか | 間違った項目を特定し、文字で説明すること（A）。直し方が分かるなら提案すること（AA） | WCAG 3.3.1／3.3.3 |
| 必須の示し方 | 必須の印（アスタリスクなど）の意味が、フォームの前に説明されているか。必須と任意の区別が色だけになっていないか | 印の意味は、フォームの前に書く。色だけで区別しない（A） | WAI「Form Instructions」／WCAG 1.4.1 |
8. 画像
| 見るもの | どう確かめるか | 閾値 | 出典 |
|---|---|---|---|
| 代替テキスト（内容） | ブラウザの設定で画像を表示しない状態にし、内容が通じるか | 意味のある画像には、同じ目的を果たす文字を付ける（A） | WCAG 1.1.1／WAI「An alt Decision Tree」 |
| 代替テキスト（飾り） | 開発者ツールの Elements で画像の alt の中身を読み、飾りの画像が空（alt=""）になっているか。その画像を消しても本文の意味が変わらないなら飾り | 飾りの画像は空の alt にして、読み上げから外す（A） | WCAG 1.1.1／WAI「An alt Decision Tree」 |
| 解像度 | 開発者ツールで画像を選ぶと、表示サイズと元の大きさ（Intrinsic size）が出る。元が表示サイズの縦横2倍に満たないか | 表示サイズの縦横2倍以上（3倍の画面まで見るなら3倍以上）。高解像度の画面は 1pt を縦横2倍か3倍のピクセルで描くため | Apple HIG「Images」 |
| 画像の中の文字 | 文字をマウスでなぞって選べるか試す。選べない、または拡大するとぼやけるなら画像。画像なら、拡大や読み上げで扱えないので、文字に直せないか検討する。ロゴやマーク、画面の写真のように、見た目そのものが必要なものは対象外 | 文字で表現できるなら、文字の画像ではなく文字を使う（AA） | WCAG 1.4.5 |
| 切れと縦横比 | 幅 320px にして、人の顔や商品が切れていないか。縦横比が変わってつぶれていないか | 数値の閾値なし（目安） | 当サイト：画像とメディア |
見た目と操作の層と、判断の層
上の8分野は、どれも道具を使えば、人によらず同じ答えが出る項目です。ボタンの押せる範囲は大きさを測れば分かり、文字と背景の明るさの差（コントラスト比）は計算で出ます。この記事では、これを見た目と操作の層と呼びます。
一方で、確認項目を全部通した画面でも、「何の画面か一目で分かるか」「次に押すものが1つに絞れているか」といった問いには、まだ答えが出ていません。申し込みや問い合わせを受ける画面なら、「この会社に任せて大丈夫だと思えるか」も同じ種類の問いです。道具では測れないので、人が見て判断します。UIXHERO はこの問いの集まりを判断の層と呼びます。判断の層の問いに画面が答えられているかを見る作業を、UIXHERO では UI検品と呼び、その6つの観点を公開しています。後述のサービス「UIXHERO Design QA」は、この UI検品を第三者として引き受けるものです。
タップして拡大表示クリックして拡大表示
6つの観点は次のとおりです。観点ごとの説明は UI検品の6観点 にあります。
- Clarity（明瞭さ）：何の画面か、次に何をすればよいかが分かるか
- Flow（導線）：画面から画面への流れがつながっているか
- Action（行動）：申し込みや問い合わせを、迷わず実行できるか
- Trust（信頼）：根拠や実績が伝わり、安心して任せられるか
- Friction（摩擦）：途中で手が止まる場所が無く、最後まで進めるか
- Feasibility（実装性。壊れにくさ）：実装したあとに文字量や画面幅が変わっても崩れない、壊れにくい作りか
2つの層には順番があります。見た目と操作の層が整っていないと、判断の層の問いに答えられません。文字が読めない画面では「何の画面か言えるか」を試せませんし、ボタンが押せない画面では「次の一歩が見つかるか」を試せません。この記事の確認項目は、文字が読めない、ボタンが押せないといった明らかな不備を先に片づけるためのものです。 それを済ませてから、判断に進みます。全部通っても「出してよい」にはなりませんが、通っていなければ判断に進めません。
自分で見きれないときの頼み先
8分野を1人で全部見るには、ブラウザの開発者ツール、コントラスト比を測る道具（コントラストチェッカー）、実際のスマートフォンやパソコン、そして時間が要ります。作った本人は設計を覚えているぶん、画面に書いていないことまで頭の中で補って読んでしまい、見落としが出ます。
UIXHERO は、判断の層の判定を第三者として引き受けるサービスを「UIXHERO Design QA」の名前で提供しています。工程の名前と同じ語を使っていますが、こちらはサービスの名前です。UIXHERO Design QA（サービスの案内） に、6つの観点と判定の仕組みをまとめています。AI が作った画面を主な対象にしていますが、観点は人が作った画面にも同じように使えます。
まとめ
- デザインQA（Design QA）は、実装された画面が設計どおりに見えるか、使う人が迷わず操作できるかを、公開する前に確かめる工程です。綴りは2語で書きます
- QAテストは「動くか」を、デザインQAは「設計どおりか、迷わず操作できるか」を見ます。片方では、もう片方を置き換えられません
- 確認項目は8分野に分け、閾値は一次資料にある数字だけを書きました。合否の線が無い項目は「目安」です
- 確認項目を全部通しても「出してよい」にはなりません。判断の層は別にあり、見た目と操作の層はその手前の不備を片づけます
次に読む
- UI検品の観点「Clarity（明瞭さ）」とは — 判断の層の最初の観点。利用者に聞かなくても、画面を見るだけで確かめられる3つの手順
- AIが作った画面は、出していいのか — 動いた画面と、出してよい画面の差を実例で
- 完成の定義（DoD） — デザインQAをチームの手順にするための用語
参考にした資料
いずれも2026年9月16日に一次資料を読んで確認しました。
WCAG 2.2（W3C）
- 1.1.1 Non-text Content
- 1.4.1 Use of Color
- 1.4.3 Contrast (Minimum)（pt と CSS px の換算の注も）
- 大きな文字の線を 19px と 24px に切り上げたのは当サイトの決めです（WCAG は 14pt と 18pt）
- 1.4.4 Resize Text
- 1.4.5 Images of Text
- 1.4.8 Visual Presentation
- 1.4.10 Reflow
- 1.4.11 Non-text Contrast
- 1.4.12 Text Spacing
- 1.4.13 Content on Hover or Focus
- 2.4.7 Focus Visible
- 2.4.11 Focus Not Obscured (Minimum)
- 2.5.5 Target Size (Enhanced)
- 2.5.8 Target Size (Minimum)
- 3.3.1 Error Identification
- 3.3.2 Labels or Instructions
- 3.3.3 Error Suggestion
- 4.1.3 Status Messages
W3C WAI チュートリアル
Apple Human Interface Guidelines
- Accessibility（コンポーネントの既定と最小の大きさ、コンポーネントの周りの余白、文字の既定と最小の大きさ）
- Typography（書体の数）
- Images（解像度の倍率）
Google Material Design 3
- Accessibility designing（押せる範囲の大きさと隙間。iOS の 44pt を 44dp と同列に扱う注も）
- Grids & spacing（間隔の一定さ）
- Typography（本文の基準サイズ、ブラウザの既定 16px）
- States（6つの状態）
Nielsen Norman Group（NN/g）
- Nielsen, J. (1994). 10 Usability Heuristics for User Interface Design
- Nielsen, J. (1993). Response Times: The 3 Important Limits
- Sherwin, K. (2014). Placeholders in Form Fields Are Harmful
- Neusesser, T. & Sunwall, E. (2023). Error-Message Guidelines
- Harley, A. (2020). The Principle of Proximity in Visual Design
- Moran, K. (2017). Flat UI Elements Attract Less Attention and Cause Uncertainty
そのほか
- MDN Web Docs. font-size（ブラウザの既定 16px）
- MDN Web Docs. length（pt と px の定義）
- Baymard Institute (2022). Readability: The Optimal Line Length
- WebAIM. Contrast Checker（道具として紹介）
- O'Leary, J. (2018). Systemizing Visual Design QA. Rangle.
- Infinum. Design implementation checklist. Development Processes Handbook.
- スタディサプリ Product Team Blog (2023). デザインをそのままの形でユーザーにお届けするためのデザインQA
この記事は、UIXHEROがAI（Claude）と協働で制作しています。確認項目の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆はAIが担っています。
