Design QA
← サービス概要へ
REVIEW FRAMEWORK / 採点基準

UIレビューの採点基準を、6観点62項目まで公開しています

Design QA が「この画面を出していいか」を判断するときに使う基準です。 6観点それぞれの下に、実際にレビュアーへ投げる設問が並んでいます。 ここに置いてあるのは要約ではなく、判定に使っている規約そのものです。

UIレビューを外に依頼するとき、いちばん困るのは「その人が良いと言った根拠が分からない」ことです。 セキュリティ診断が OWASP や ASVS という公開基準への準拠で信頼を立てているのと同じで、 UIの第三者判定も、基準が公開されていて誰でも追試できることでしか立ちません。 判定する人の肩書きではなく、方式のほうを見てください。

v0.5.0draft
最終改訂2026-08-05
全項目6観点・62項目(採点する設問 59/Feasibility の実装メモ 3
採点5観点を05点(0.5点刻み)/Feasibility は非採点=所見のみ
策定・運用4px合同会社 / UIXHERO
ライセンスCC-BY-4.0引用・採用・機械利用は自由。上記の帰属表示を残すこと。
Based on the UIXHERO Review Framework (design-qa.com). © 4px LLC.
機械可読/review-framework.json =このページの表示元。全項目・設計メモ・改訂理由まで入った規約の全文です

改訂履歴

基準は改訂され続けています。これは方式が生きている証拠です。 変えているのは思いつきではなく、実際に判定を回して「答えられない設問があった」「同じ事実を二重に減点していた」 といった穴が見つかったときで、改訂の理由は版ごとに規約の中に残してあります。 下は各版の見出しだけで、理由の全文はJSONの meta.changelogに入っています。

v0.5.02026-08-0559 subchecks(C13/F11/A11/T13/R11)
v0.4.02026-07-3058 subchecks(C13/F11/A11/T12/R11)
v0.3.02026-07-3055 subchecks実装・判断軸深掘り文書の承認による(※実装数の実測は56=C13/F10/A11/T11/R11。この行の「55」は誤記で、パイロット第1巡§2-1で判明)
v0.2.02026-07-30否定疑問7問を肯定形(Yes=良い)に統一・Clarity/ActionとClarity/Frictionの担当分界を文言に反映・Clarityに可読性(読めるか)を明示(A11y受け皿)

6観点と、その下の全項目

レビュアーは1問ずつ Yes / No で答え、No には画面からの引用を必ず添えます。 引用のない指摘は集計から捨てます。設問の下にある小さなラベルは、回答様式・「見ても分からない」ときの扱い・ 観点をまたぐときの担当分界・その問いの出典(UXの原則)です。

Clarity 明瞭さFlow 導線Action 行動Trust 信頼Friction 摩擦Feasibility 実装性
01

Clarity明瞭さ

設問 13

画面の目的、情報、次にすべき行動が分かりやすいか

C1

この画面が何のための画面かが、見た瞬間に分かるか

C1-1

先ほどあなたが答えた「この画面の目的」は、画面の中の文字(見出しやタイトル)にそのまま書かれていますか

Yes / No⚠ 見ても分からない=減点mental model
C1-2

3秒だけ見て閉じたと想像してください。何のサービス・何の業務の画面か、言えますか

Yes / No⚠ 見ても分からない=減点selective attention
C1-3

一番大きな文字は、ここで何が得られるかを具体的に言っていますか(雰囲気の言葉ではなく)

Yes / No⚠ 見ても分からない=減点occam's razor
C1-4

一番大きな文字と、一番大きな画像・イラストは、同じことを言っていますか

担当分界:画像・データの内容そのものが文字と食い違っているかは、ここ(Clarity C1-4)が一次担当です。Trust T3-1では同じ事実を二重に減点しません

Yes / No⚠ 見ても分からない=減点dual coding theory
C2

最も重要な情報が視覚的な優先順位の一番上にあり、かつ無理なく読める見え方になっているか

C2-1

この画面を開いて最初に目が行くのはどこですか。そこは、この画面が一番見てほしい場所だと思いますか

回答様式:まず「最初に目が行った場所」を記述し、そのうえで「そこはこの画面が一番見てほしい場所だと思うか」にYes/Noで答えます。集計に使うのはYes/Noのみです

Yes / No⚠ 見ても分からない=減点visual hierarchy
C2-2

一番強く目立っている要素は、1つだけに絞られていますか

Yes / No⚠ 見ても分からない=減点attention economy
C2-3

上から順に読んでいったとき、大事な順に並んでいましたか

Yes / No⚠ 見ても分からない=減点f shaped patternz shaped pattern
C2-4

この画面で一番重要な情報は、目に留まりやすい位置(画面の最初か最後)に置かれていますか

担当分界:真ん中に埋もれているかの一事実だけを見ます。下端で見切れている・スクロールしないと見えないはFlow F2-1が一次担当です

Yes / No⚠ 見ても分からない=減点serial position effect
C2-5

文字の大きさは無理なく読める程度ですか。また、文字と背景の明るさの差は十分にありますか

Yes / No⚠ 見ても分からない=減点figure ground relationship
C2-6

状態や重要度の違いは、色以外(形・文字・アイコン)でも区別できますか

Yes / No⚠ 見ても分からない=減点dual coding theory
C3

ユーザーが次に取るべき行動が何か、画面から読み取れるか

C3-1

この画面で自分が何をできるのか、見て分かりますか

担当分界:ここは「できると分かるか」まで。主たる行動が1つに特定できるか・実際に迷わず押せるかはAction A1-1が一次担当です

Yes / No⚠ 見ても分からない=減点affordance
C3-2

「次はこれかな、あれかな」と迷った候補は2つ以内に収まりましたか

担当分界:次の一手の候補の数を見ます。画面内に並んだ選択肢の数はFriction R2-3が一次担当です

Yes / No⚠ 見ても分からない=減点hick's law
C3-3

この画面ではできないこと(グレーになっている・今は選べない)が、理由込みで分かりますか

Yes / No⚠ 見ても分からない=減点constraints
02

Flow導線

設問 11

ユーザー導線が自然につながっているか

F1

前の画面からの流れが自然につながっているか

F1-1

いま自分が全体のどのあたりにいるか(何番目か・あと何回か)が画面から分かりますか

Yes / No⚠ 見ても分からない=減点goal gradient effect
F1-2

(渡した1つ前の文脈を読んで)押した言葉と、たどり着いたこの画面の見出しは、同じ言葉で書かれていますか

Yes / No⊘ 写っていない=分母から除外priming
F1-3

1つ前の画面と同じサービスだと、見た目(色・ロゴ・言葉づかい)で分かりますか

Yes / No⊘ 写っていない=分母から除外familiarity bias
F2

次の一歩への導線が迷わず見つかるか

F2-1

次に進むための入口は、スクロールせずに見えていますか

担当分界:見切れ(下端で切れている・スクロールしないと見えない)はここが一次担当です。画面内の位置(真ん中に埋もれている)はClarity C2-4が見ます

Yes / No⚠ 見ても分からない=減点inattentional blindness
F2-2

押せる場所と、ただの文字・飾りが、見た目で区別できますか

Yes / No⚠ 見ても分からない=減点signifier
F2-3

進む入口が複数あるとき、どれがおすすめか分かりますか

Yes / No⚠ 見ても分からない=減点default bias
F2-4

いま選んでいるもの・開いているものが、一覧側のどれなのか画面から分かりますか

Yes / No⚠ 見ても分からない=減点visual hierarchy
F3

戻る・やり直す・離脱後の復帰が、いずれも成立しているか

F3-1

間違えたときに、取り消す・前に戻る手段が画面上にありますか

Yes / No⚠ 見ても分からない=減点defensive design
F3-2

前に戻ったとき、入力した内容は消えずに残りそうですか。そう思える手がかりが画面にありますか

Yes / No⚠ 見ても分からない=減点user is not wrong
F3-3

一度この画面を離れて戻ってきたとき、どこまで進んだか分かる手がかりがありますか

Yes / No⚠ 見ても分からない=減点zeigarnik effect
F3-4

この画面をやめる・閉じる手段が見えますか

Yes / No⚠ 見ても分からない=減点psychological reactance
03

Action行動

設問 11

CTA、入力、登録、問い合わせなどの行動が迷わず実行できるか

A1

主たる行動(CTA)が1つに定まり、迷わず実行できる形になっているか

A1-1

一番押してほしいボタンはどれだと思いますか。1つに特定できましたか

回答様式:まず「一番押してほしいと思ったボタン」を引用で示し、そのうえで「1つに特定できたか」にYes/Noで答えます。12体の指した先が割れた場合は、Yesが揃っていてもIssue候補として別掲します

担当分界:「何ができる画面か分かるか」はClarity C3-1が一次担当です。ここでは主たる行動が1つに特定できるかを見ます

Yes / No⚠ 見ても分からない=減点von restorff effect
A1-2

そのボタンは、指で押すのに十分な大きさ・間隔がありますか(特にスマホ画面で)

Yes / No⚠ 見ても分からない=減点fitts's law
A1-3

ボタンの文字を読んで、押したら何が起きるか分かりますか

Yes / No⚠ 見ても分からない=減点mapping
A1-4

一番押してほしいボタンと、その隣のボタンの見た目の差は、はっきり分かるほどありますか

Yes / No⚠ 見ても分からない=減点weber's law
A2

入力・登録が、必要最小限の手数で完了できるか

A2-1

入力欄の数は、この画面の目的に対して必要な数に見えますか。それぞれの欄について「なぜこれを聞くのか」が分かりますか

担当分界:入力を「実行できるか」を見ます。手数・ステップが多すぎるかはFriction R1-1が一次担当です

Yes / No⚠ 見ても分からない=減点sludge
A2-2

書かなければいけない欄と、書かなくてよい欄の区別がつきますか

Yes / No⚠ 見ても分からない=減点cognitive load
A2-3

入力の形式(例=電話番号にハイフンが要るか)は、間違える前に示されていますか

Yes / No⚠ 見ても分からない=減点postel's law
A2-4

入力すべきことが一度に全部並んでいますか、段階に分かれていますか。あなたにとってどちらが良かったですか

選択肢:一度に全部並んでいる / 段階に分かれている

回答様式:どちらの形かを選び、そのうえで「あなたにとってその形は良かったか」にYes/Noと理由を添えます。集計は後半のYes/Noを使います

選択+Yes/No⚠ 見ても分からない=減点progressive disclosure
A3

行動の結果(成功・失敗・次に何が起きるか)が予測できるか

A3-1

押した後に何が起きるか、押す前に書いてありますか(すぐ課金される/確認画面が出る、など)

Yes / No⚠ 見ても分からない=減点expectation bias
A3-2

押した後に反応が返ってきそうだと分かりますか(読み込み中・完了の表示)

Yes / No⊘ 写っていない=分母から除外feedback
A3-3

取り消せない操作(削除・送信・課金)の前に、立ち止まらせる確認や警告がありますか

Yes / No⊘ 写っていない=分母から除外intentional friction
04

Trust信頼

設問 13

信頼、安心、根拠、実績、保証が適切に伝わっているか

T1

主張に対する根拠(実績・数字・第三者の声)が近くにあるか

T1-1

一番大きく書かれた主張のすぐ近くに、その裏づけ(数字・事例・第三者の声)がありますか

Yes / No⚠ 見ても分からない=減点gestalt principles
T1-2

書かれている数字に、いつ・どこで測ったものかが添えられていますか

Yes / No⚠ 見ても分からない=減点evidence based design
T1-3

推薦や口コミは、誰が言ったか(名前・所属・顔)まで分かりますか

Yes / No⚠ 見ても分からない=減点対象=toC LP・EC・認証・決済authority bias
T1-4

「多くの企業が導入」のような言い方に、具体的な社名や件数が伴っていますか

Yes / No⚠ 見ても分からない=減点対象=toC LP・ECbandwagon effect
T2

お金・個人情報に関わる箇所で安心材料が提示されているか

T2-1

支払う金額は、追加費用込みで最終いくらになるか分かりますか

Yes / No⚠ 見ても分からない=減点対象=toC LP・EC・認証・決済anchoring effect
T2-2

申し込んだ後にやめる方法・条件が、申し込む前に書いてありますか

Yes / No⚠ 見ても分からない=減点対象=toC LP・EC・認証・決済sludge
T2-3

入力する個人情報が何に使われるか、その欄の近くに書いてありますか

Yes / No⚠ 見ても分からない=減点対象=toC LP・EC・認証・決済framing effect
T3

表現が事実と釣り合っており、画面内の表記が一貫しているか

T3-1

見た目の作り込みと、書いてある中身の充実度は釣り合っていますか

担当分界:画像・データの内容そのものの誤りはClarity C1-4が一次担当です。ここでは作り込みの水準と情報量の釣り合いだけを見ます

Yes / No⚠ 見ても分からない=減点aesthetic usability effect
T3-2

「残りわずか」「今だけ」などの表示に、実際の根拠(在庫数・期限日)が伴っていますか

Yes / No⚠ 見ても分からない=減点対象=toC LP・ECscarcity
T3-3

断る側の選択肢は、受ける側と同じくらい素直な言葉で書かれていますか

Yes / No⚠ 見ても分からない=減点対象=toC LP・EC・認証・決済confirm shaming
T3-4

同じものを指す数字は、画面の中で食い違わずに揃っていますか

担当分界:数字の整合だけを見ます。同じものを指す言葉(名称・ラベル)のゆれはT3-5が、出来事の順序・前後関係の成立はT3-6が一次担当です

Yes / No⚠ 見ても分からない=減点
T3-5

同じものを指す言葉(名称・ラベル)は、画面の中で揃っていますか

担当分界:言葉(名称・ラベル)の統一だけを見ます。数字の食い違いはT3-4が、出来事の順序・前後関係の成立はT3-6が一次担当です

Yes / No⚠ 見ても分からない=減点
T3-6

画面に書かれている出来事の順序・前後関係は、互いに成立していますか(例:後工程が「完了」と書かれているなら、その前工程も「完了」と書かれている)

担当分界:出来事の順序・前後関係が成立しているかだけを見ます。数字の食い違いはT3-4が、言葉のゆれはT3-5が一次担当です

Yes / No⚠ 見ても分からない=減点
05

Friction摩擦

設問 11

迷わず・詰まらずに、最後まで進めるか

R1

目的までのステップが、必要なものだけに絞られているか

R1-1

目的を果たすまでの操作は、これ以上減らせないところまで削られていますか

担当分界:手数・ステップが多すぎるかを見ます。入力そのものが実行できるかはAction A2-1が一次担当です

Yes / No⚠ 見ても分からない=減点sludge
R1-2

価値が分かった後に登録を求める順になっていますか

Yes / No⚠ 見ても分からない=減点対象=toC LP・EC・認証・決済reciprocity
R1-3

一度書いた情報は、後の場面でも引き継がれると分かりますか

Yes / No⚠ 見ても分からない=減点tesler's law
R2

理解できた上で、一度に受け止められる量・選べる数に収まっているか

R2-1

一画面に載っている情報は、一度に受け止められる量ですか

Yes / No⚠ 見ても分からない=減点miller's lawmagical number rethinking
R2-2

画面の言葉は、この分野に詳しくない人でも意味が分かるものですか。分からない言葉は何個ありましたか

回答様式:分からなかった言葉の個数と、その語を列挙します。0個=Yes相当・1個以上=Noとして集計します(ドメインユーザーは0個、初見は5個という差そのものが判定材料)

個数⚠ 見ても分からない=減点jakob's law
R2-3

選ぶものが並んでいる場合、その数は無理なく選べる範囲に収まっていますか

担当分界:画面内に並んだ選択肢の数を見ます。次の一手の候補の数はClarity C3-2が一次担当です

Yes / No⚠ 見ても分からない=減点paradox of choicehick's law
R2-4

要素の間に、目を休められる余白がありますか。無理なく読み進められる詰まり具合ですか

Yes / No⚠ 見ても分からない=減点gestalt principles
R3

エラー・空状態・待ち時間に、次へ進める手当てがあるか

R3-1

エラー表示があるなら、何をどう直せばよいかまで書いてありますか

Yes / No⊘ 写っていない=分母から除外defensive design practice
R3-2

データが0件のとき、次に何をすればよいか案内がありそうですか

Yes / No⊘ 写っていない=分母から除外reactive onboarding
R3-3

時間のかかる処理で、待っていることと、あとどれくらいかが伝わりますか

Yes / No⊘ 写っていない=分母から除外doherty thresholdlabor illusion
R3-4

この画面で一番嫌だった瞬間はどこですか。最後に見た印象はどうでしたか

回答様式:自由記述のみ。スコアの分母には入れません(Round A→Bの乖離を説明する材料として使います)

自由記述⚠ 見ても分からない=減点非採点peak end ruletime and memory
06

Feasibility実装性

非採点 / 所見のみ

実装・運用上、壊れにくいUIになっているか

01

文字量・データ量が増減しても崩れない構造か

02

レスポンシブ・多言語・アクセシビリティでも成立し続けるか

03

運用(更新・追加)で一貫性を保ち続けられる作りか

実装性Feasibility)は、静止画の検品では採点しません。

文字量が増えたとき・画面幅が変わったとき・データが増えたときに崩れるかは、動かしてみないと分からないためです。 静止画1枚から確実に言える範囲だけを、下の3項目として所見に書きます。スコアは作りません (サイト上のレーダーチャートでこの軸だけ破線になっているのは同じ理由です)。

D-1

ボタン内の文字に、1行で収まる余裕がありますか

Yes / No⚠ 見ても分からない=減点
D-2

テーブルの列幅に余裕がありますか

Yes / No⊘ 写っていない=分母から除外
D-3

長い文字列(施設名など)が入っても、レイアウトが保たれますか

Yes / No⚠ 見ても分からない=減点

画面種別と、分母の決め方

設問は全画面に一律で当てません。受付のときに画面種別を1つ決め、その種別に当てはまらない設問は分母から外します。 業務画面に「購入をためらわせる要素があるか」を聞いても意味がないためです。

toB業務画面社内・取引先向けの業務画面(一覧・台帳・管理・入力)。利用者は既に登録済みで、売る/申し込ませる要素を持たない
toC LP・EC一般消費者に価値を訴え、申し込み・購入まで運ぶ画面(LP・商品ページ・料金ページ)
認証・決済登録・ログイン・支払い・個人情報の入力を扱う画面。金銭と個人情報の取り扱いが伴う

記号の使い分け

N/A画面種別に非該当(appliesTo 由来・分母から除外)
画面に写っていないので判断できない(unknown:exclude・分母から除外)
見ても分からない(unknown:penalize・減点として数える)

回答様式

yes_noYes / No / 判断できない の3択(判断できないの⊘⚠振り分けは unknown 属性で書記が機械的に行う)
choice選択肢から1つ選び、そのうえでYes/Noと理由を添える
count個数を答え、語を列挙する。0個=Yes相当・1個以上=Noとして集計する
free自由記述のみ。スコアの分母に入れない(excludeFromScore: true)

証拠の規約

No には画面からの引用を必須にしています。ただし「無いことの指摘」は、存在しないものを引用できません。 そこで引用の代わりに「探した場所」を書かせます。この2様式のどちらも満たさない指摘は、集計から捨てます。

EV-1あることの指摘

画面に写っている文字列を「」で括って引用する

例:C1-4 | No | 見出しと写真が食い違う | 「根切り底 掘削状況」 | …

EV-2無いことの指摘

引用欄に「探した場所=」で始めて、探した場所を画面の文字列で列挙する

例:F3-4 | No | 閉じる手段が無い | 探した場所=「施工写真台帳」「取り込み」「台帳を作成」 | …

スコアの決まり方

観点スコアはレビュアーに直接付けさせません。観点ごとに「最も重い問題の重要度(Severity)」だけを答えてもらい、 そこから機械的にスコアを導きます。人が点を付けると、指摘の重さと関係なく点が動いてしまうためです。5観点のスコアが出たあと、総合判定(要再構築/要修正/出してよし)は審査担当(人間)が決めて署名します。

重要度の定義

Critical受付時に記録した「この画面の目的(1行)」が達成できない/事業KPIを直接毀損する。最優先で直す
Major受付時に記録した目的は達成できるが、迷い・離脱・不信を生む。優先して直す
Minor体験は成立している。余力があれば直す磨きの範囲

重要度からスコアへの割り当てと、12体の回答の集約規則は非公開です(2026-08-05確定・実測で検証ずみ)。 規則の全文は完全版の鑑定書に収録しており、/sample-reportからメールアドレスと引き換えにお受け取りいただけます。

スコアの読み方

0 点評価不能/該当機能が成立していない
1 点破綻。この観点でユーザーが目的を達成できない
2 点重い。この観点が事業目的の妨げになっている
3 点要改善。出す前に手を入れたい箇所がある
4 点軽微。出せるが改善余地あり
5 点問題なし。この観点で出して良い

指摘の確からしさ

High一般原則・複数の根拠から、ほぼ確実に問題と言える
Medium問題の可能性が高いが、文脈やデータで検証したい
Low仮説。実データ(計測・ユーザーテスト)での確認を要する

この基準の使い方

自分の画面に自分で当てて構いません。そのために公開しています(CC-BY-4.0・帰属表示を残せば引用も再利用も自由です)。 ただし自己診断は、何回やっても第三者の証明にはなりません。 発注元や決裁者に「出していい」と示す必要があるときは、同じ基準を12体のレビュアー(AIもしくは人間)が それぞれ独立の盲検で当て、最終判定を審査担当(人間)が署名する形でお引き受けします。

プランと価格を見るこの基準で書いた鑑定書の実物

このページの内容は public/review-framework.json(v0.5.02026-08-05)から生成しています。 表示は要約せず、各設問の文言をそのまま出しています(規約内部の設計メモのみ、JSON側に置いています)。

Design QA
UI判断の言葉と知見
掲載数値はすべて 2026-08-06 時点
© 2026 UIXHERO