Design QA が「この画面を出していいか」を判断するときに使う基準です。 6観点それぞれの下に、実際にレビュアーへ投げる設問が並んでいます。 ここに置いてあるのは要約ではなく、判定に使っている規約そのものです。
UIレビューを外に依頼するとき、いちばん困るのは「その人が良いと言った根拠が分からない」ことです。 セキュリティ診断が OWASP や ASVS という公開基準への準拠で信頼を立てているのと同じで、 UIの第三者判定も、基準が公開されていて誰でも追試できることでしか立ちません。 判定する人の肩書きではなく、方式のほうを見てください。
基準は改訂され続けています。これは方式が生きている証拠です。 変えているのは思いつきではなく、実際に判定を回して「答えられない設問があった」「同じ事実を二重に減点していた」 といった穴が見つかったときで、改訂の理由は版ごとに規約の中に残してあります。 下は各版の見出しだけで、理由の全文はJSONの meta.changelogに入っています。
レビュアーは1問ずつ Yes / No で答え、No には画面からの引用を必ず添えます。 引用のない指摘は集計から捨てます。設問の下にある小さなラベルは、回答様式・「見ても分からない」ときの扱い・ 観点をまたぐときの担当分界・その問いの出典(UXの原則)です。
画面の目的、情報、次にすべき行動が分かりやすいか
先ほどあなたが答えた「この画面の目的」は、画面の中の文字(見出しやタイトル)にそのまま書かれていますか
3秒だけ見て閉じたと想像してください。何のサービス・何の業務の画面か、言えますか
一番大きな文字は、ここで何が得られるかを具体的に言っていますか(雰囲気の言葉ではなく)
一番大きな文字と、一番大きな画像・イラストは、同じことを言っていますか
担当分界:画像・データの内容そのものが文字と食い違っているかは、ここ(Clarity C1-4)が一次担当です。Trust T3-1では同じ事実を二重に減点しません
この画面を開いて最初に目が行くのはどこですか。そこは、この画面が一番見てほしい場所だと思いますか
回答様式:まず「最初に目が行った場所」を記述し、そのうえで「そこはこの画面が一番見てほしい場所だと思うか」にYes/Noで答えます。集計に使うのはYes/Noのみです
一番強く目立っている要素は、1つだけに絞られていますか
上から順に読んでいったとき、大事な順に並んでいましたか
この画面で一番重要な情報は、目に留まりやすい位置(画面の最初か最後)に置かれていますか
担当分界:真ん中に埋もれているかの一事実だけを見ます。下端で見切れている・スクロールしないと見えないはFlow F2-1が一次担当です
文字の大きさは無理なく読める程度ですか。また、文字と背景の明るさの差は十分にありますか
状態や重要度の違いは、色以外(形・文字・アイコン)でも区別できますか
この画面で自分が何をできるのか、見て分かりますか
担当分界:ここは「できると分かるか」まで。主たる行動が1つに特定できるか・実際に迷わず押せるかはAction A1-1が一次担当です
「次はこれかな、あれかな」と迷った候補は2つ以内に収まりましたか
担当分界:次の一手の候補の数を見ます。画面内に並んだ選択肢の数はFriction R2-3が一次担当です
この画面ではできないこと(グレーになっている・今は選べない)が、理由込みで分かりますか
ユーザー導線が自然につながっているか
いま自分が全体のどのあたりにいるか(何番目か・あと何回か)が画面から分かりますか
(渡した1つ前の文脈を読んで)押した言葉と、たどり着いたこの画面の見出しは、同じ言葉で書かれていますか
1つ前の画面と同じサービスだと、見た目(色・ロゴ・言葉づかい)で分かりますか
次に進むための入口は、スクロールせずに見えていますか
担当分界:見切れ(下端で切れている・スクロールしないと見えない)はここが一次担当です。画面内の位置(真ん中に埋もれている)はClarity C2-4が見ます
押せる場所と、ただの文字・飾りが、見た目で区別できますか
進む入口が複数あるとき、どれがおすすめか分かりますか
いま選んでいるもの・開いているものが、一覧側のどれなのか画面から分かりますか
間違えたときに、取り消す・前に戻る手段が画面上にありますか
前に戻ったとき、入力した内容は消えずに残りそうですか。そう思える手がかりが画面にありますか
一度この画面を離れて戻ってきたとき、どこまで進んだか分かる手がかりがありますか
この画面をやめる・閉じる手段が見えますか
CTA、入力、登録、問い合わせなどの行動が迷わず実行できるか
一番押してほしいボタンはどれだと思いますか。1つに特定できましたか
回答様式:まず「一番押してほしいと思ったボタン」を引用で示し、そのうえで「1つに特定できたか」にYes/Noで答えます。12体の指した先が割れた場合は、Yesが揃っていてもIssue候補として別掲します
担当分界:「何ができる画面か分かるか」はClarity C3-1が一次担当です。ここでは主たる行動が1つに特定できるかを見ます
そのボタンは、指で押すのに十分な大きさ・間隔がありますか(特にスマホ画面で)
ボタンの文字を読んで、押したら何が起きるか分かりますか
一番押してほしいボタンと、その隣のボタンの見た目の差は、はっきり分かるほどありますか
入力欄の数は、この画面の目的に対して必要な数に見えますか。それぞれの欄について「なぜこれを聞くのか」が分かりますか
担当分界:入力を「実行できるか」を見ます。手数・ステップが多すぎるかはFriction R1-1が一次担当です
書かなければいけない欄と、書かなくてよい欄の区別がつきますか
入力の形式(例=電話番号にハイフンが要るか)は、間違える前に示されていますか
入力すべきことが一度に全部並んでいますか、段階に分かれていますか。あなたにとってどちらが良かったですか
選択肢:一度に全部並んでいる / 段階に分かれている
回答様式:どちらの形かを選び、そのうえで「あなたにとってその形は良かったか」にYes/Noと理由を添えます。集計は後半のYes/Noを使います
押した後に何が起きるか、押す前に書いてありますか(すぐ課金される/確認画面が出る、など)
押した後に反応が返ってきそうだと分かりますか(読み込み中・完了の表示)
取り消せない操作(削除・送信・課金)の前に、立ち止まらせる確認や警告がありますか
信頼、安心、根拠、実績、保証が適切に伝わっているか
一番大きく書かれた主張のすぐ近くに、その裏づけ(数字・事例・第三者の声)がありますか
書かれている数字に、いつ・どこで測ったものかが添えられていますか
推薦や口コミは、誰が言ったか(名前・所属・顔)まで分かりますか
「多くの企業が導入」のような言い方に、具体的な社名や件数が伴っていますか
支払う金額は、追加費用込みで最終いくらになるか分かりますか
申し込んだ後にやめる方法・条件が、申し込む前に書いてありますか
入力する個人情報が何に使われるか、その欄の近くに書いてありますか
見た目の作り込みと、書いてある中身の充実度は釣り合っていますか
担当分界:画像・データの内容そのものの誤りはClarity C1-4が一次担当です。ここでは作り込みの水準と情報量の釣り合いだけを見ます
「残りわずか」「今だけ」などの表示に、実際の根拠(在庫数・期限日)が伴っていますか
断る側の選択肢は、受ける側と同じくらい素直な言葉で書かれていますか
同じものを指す数字は、画面の中で食い違わずに揃っていますか
担当分界:数字の整合だけを見ます。同じものを指す言葉(名称・ラベル)のゆれはT3-5が、出来事の順序・前後関係の成立はT3-6が一次担当です
同じものを指す言葉(名称・ラベル)は、画面の中で揃っていますか
担当分界:言葉(名称・ラベル)の統一だけを見ます。数字の食い違いはT3-4が、出来事の順序・前後関係の成立はT3-6が一次担当です
画面に書かれている出来事の順序・前後関係は、互いに成立していますか(例:後工程が「完了」と書かれているなら、その前工程も「完了」と書かれている)
担当分界:出来事の順序・前後関係が成立しているかだけを見ます。数字の食い違いはT3-4が、言葉のゆれはT3-5が一次担当です
迷わず・詰まらずに、最後まで進めるか
目的を果たすまでの操作は、これ以上減らせないところまで削られていますか
担当分界:手数・ステップが多すぎるかを見ます。入力そのものが実行できるかはAction A2-1が一次担当です
価値が分かった後に登録を求める順になっていますか
一度書いた情報は、後の場面でも引き継がれると分かりますか
一画面に載っている情報は、一度に受け止められる量ですか
画面の言葉は、この分野に詳しくない人でも意味が分かるものですか。分からない言葉は何個ありましたか
回答様式:分からなかった言葉の個数と、その語を列挙します。0個=Yes相当・1個以上=Noとして集計します(ドメインユーザーは0個、初見は5個という差そのものが判定材料)
選ぶものが並んでいる場合、その数は無理なく選べる範囲に収まっていますか
担当分界:画面内に並んだ選択肢の数を見ます。次の一手の候補の数はClarity C3-2が一次担当です
要素の間に、目を休められる余白がありますか。無理なく読み進められる詰まり具合ですか
エラー表示があるなら、何をどう直せばよいかまで書いてありますか
データが0件のとき、次に何をすればよいか案内がありそうですか
時間のかかる処理で、待っていることと、あとどれくらいかが伝わりますか
この画面で一番嫌だった瞬間はどこですか。最後に見た印象はどうでしたか
回答様式:自由記述のみ。スコアの分母には入れません(Round A→Bの乖離を説明する材料として使います)
実装・運用上、壊れにくいUIになっているか
実装性(Feasibility)は、静止画の検品では採点しません。
文字量が増えたとき・画面幅が変わったとき・データが増えたときに崩れるかは、動かしてみないと分からないためです。 静止画1枚から確実に言える範囲だけを、下の3項目として所見に書きます。スコアは作りません (サイト上のレーダーチャートでこの軸だけ破線になっているのは同じ理由です)。
ボタン内の文字に、1行で収まる余裕がありますか
テーブルの列幅に余裕がありますか
長い文字列(施設名など)が入っても、レイアウトが保たれますか
設問は全画面に一律で当てません。受付のときに画面種別を1つ決め、その種別に当てはまらない設問は分母から外します。 業務画面に「購入をためらわせる要素があるか」を聞いても意味がないためです。
記号の使い分け
回答様式
No には画面からの引用を必須にしています。ただし「無いことの指摘」は、存在しないものを引用できません。 そこで引用の代わりに「探した場所」を書かせます。この2様式のどちらも満たさない指摘は、集計から捨てます。
画面に写っている文字列を「」で括って引用する
例:C1-4 | No | 見出しと写真が食い違う | 「根切り底 掘削状況」 | …
引用欄に「探した場所=」で始めて、探した場所を画面の文字列で列挙する
例:F3-4 | No | 閉じる手段が無い | 探した場所=「施工写真台帳」「取り込み」「台帳を作成」 | …
観点スコアはレビュアーに直接付けさせません。観点ごとに「最も重い問題の重要度(Severity)」だけを答えてもらい、 そこから機械的にスコアを導きます。人が点を付けると、指摘の重さと関係なく点が動いてしまうためです。5観点のスコアが出たあと、総合判定(要再構築/要修正/出してよし)は審査担当(人間)が決めて署名します。
重要度の定義
重要度からスコアへの割り当てと、12体の回答の集約規則は非公開です(2026-08-05確定・実測で検証ずみ)。 規則の全文は完全版の鑑定書に収録しており、/sample-reportからメールアドレスと引き換えにお受け取りいただけます。
スコアの読み方
指摘の確からしさ
自分の画面に自分で当てて構いません。そのために公開しています(CC-BY-4.0・帰属表示を残せば引用も再利用も自由です)。 ただし自己診断は、何回やっても第三者の証明にはなりません。 発注元や決裁者に「出していい」と示す必要があるときは、同じ基準を12体のレビュアー(AIもしくは人間)が それぞれ独立の盲検で当て、最終判定を審査担当(人間)が署名する形でお引き受けします。
このページの内容は public/review-framework.json(v0.5.0・2026-08-05)から生成しています。 表示は要約せず、各設問の文言をそのまま出しています(規約内部の設計メモのみ、JSON側に置いています)。