デザインレビューの基準｜UI/UX発注者がモックアップで見るべき5観点

UI/UXデザインを外注し、デザイン会社からモックアップを受け取ったとき、多くの発注担当者が同じ場面で立ち止まります。「Figmaのリンクは開いたけど、何をどう見ればいいか分からない」「前回のレビューでは『いい感じです』と返したが、本当にあれで良かったのか」――そんな迷いです。

デザインの専門知識がないまま承認の判断を求められる立場は、想像以上にプレッシャーがかかります。色やフォントの良し悪しは語れない、ヒューリスティック評価のような専門フレームは聞いたこともない。それでも、自分の判断ひとつで開発が進んでしまう。「なんとなくOK」を出した結果、リリース後に「思っていたのと違う」と気づいたときには、既に実装が終わっていて手戻りコストが膨らむ――この失敗を多くの発注者が経験しています。

ただ、安心してください。発注者に求められているのは「デザインの良し悪しを審美的に判定すること」ではありません。事業要件・ユーザー像・業務フローという、発注者にしか見えない領域からモックアップを評価することです。そのための物差しさえあれば、専門知識がなくても十分にレビューは機能します。

本記事では、UI/UXの発注者が確認ポイントとして押さえておきたい「モックアップを評価する5つの判断基準」を中心に、レビュー段階別の承認対象、「なんか違う」を具体的に言語化するフィードバック手法、承認前のセルフチェックリストまでを解説します。明日のレビュー会議で使える状態を目指して、順を追って整理していきます。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

なぜ発注者は「感覚でOK」を出してしまうのか

「特に問題ないと思います」「いい感じです」――レビューでこのフィードバックを返した経験は、おそらく多くの発注者に共通しています。決して仕事を怠けているわけではありません。判断軸が共有されていない状態で、無理やり判断を絞り出した結果が「感覚OK」なのです。

このセクションでは、なぜそれが起きるのか、そして「感覚OK」を続けるとどんな失敗につながるのかを整理します。

「感覚OK」が手戻りを生むメカニズム

モックアップ段階で曖昧に承認した結果、後工程で気づくパターンには典型例があります。

• リリース後にユーザーから「使いにくい」と指摘されて初めて違和感に気づく
• ステークホルダーへのデモで上司から「これでは業務に使えない」と差し戻される
• 開発が進んだ段階で「主要導線がそもそも要件と合っていない」と発覚する

いずれも「もっと早く気づくべきだった」状態です。デザイン段階での修正は数時間〜数日で済むことが多いのに対し、実装後の修正は工数が数倍〜十数倍に膨らみます。だからこそ、プロトタイピング段階で設計ミスを早期に検知して修正することが、後工程の手戻りを抑えるうえで重要です。

つまり「感覚OK」のコストは、レビュー時点ではゼロに見えても、後から数倍の請求書として返ってきます。

発注者の役割は「審美判定」ではなく「ユーザー目線の代理」

ここで誤解を解いておきたいのが、発注者の役割です。

「色のバランスが綺麗か」「フォントが今っぽいか」「アイコンがおしゃれか」といった審美判断は、本来デザイナーの専門領域です。発注者がこれらを評価しようとしても、語彙も基準も持っていないので「なんとなく」止まりになるのは当然のことです。

代わりに、発注者にしか担えない役割があります。それは「ユーザー目線」「事業要件目線」の代理です。

• このサービスを実際に使うユーザーは、本当にこの画面で迷わず操作できるか
• 自社の事業ゴール（売上・登録数・問い合わせ数）に貢献する設計になっているか
• 現場の業務フロー（営業の動き方・顧客対応の流れ）と矛盾していないか

これらは社内の事情を知っている発注者にしか判断できません。「審美判定の苦手意識」を捨てて「ユーザーと事業の代理人」という役割に立ち位置を変えるだけで、レビューの軸が一気に明確になります。

デザインレビューで発注者が果たすべき役割

役割転換の話を、もう少し具体的にしていきます。レビュー会議の場で発注者が「やるべきこと」と「やらなくていいこと」を整理しておくと、限られた時間で価値の高いフィードバックを返せるようになります。

発注者がやるべきこと・やらなくていいこと

レビュー会議における役割分担は、次のように整理できます。

「やらなくていいこと」を意識的に手放すと、本来見るべき領域に集中できます。専門領域に踏み込んで「もっと青っぽくしてください」と指示してしまうと、デザイナーは事業要件ではなく発注者の好みに合わせて手を動かすことになり、本来のUX品質が下がる結果につながります。

「ユーザー目線」で見るための具体的なシミュレーション方法

「ユーザー目線で見ましょう」と言われても、抽象的すぎて何をすればいいか分からないものです。実務的には、以下の3ステップで「具体的な一人」を画面に重ね合わせると評価しやすくなります。

1. ペルソナを1人決める: 想定ユーザーの中から、最も典型的な人物像を1人選ぶ。「30代後半の小売店オーナー、PCはあまり得意ではない」のように具体化する
2. その人の利用シーンを設定する: いつ・どこで・何のためにこの画面を開くかを思い浮かべる。「閉店後の19時、レジ横でスマホを使って在庫確認をする」など
3. モックアップを最初から最後までなぞる: ペルソナになりきって、起動からゴール完了までの画面遷移を順に追っていく。引っかかった瞬間（「これ何？」「次どうする？」と思った瞬間）をメモする

このシミュレーションを2〜3パターンのペルソナで繰り返すと、「自分が分からない」のではなく「想定ユーザーが分からないかもしれない」ポイントが具体的に浮かび上がります。これが発注者にしかできないレビューの中身です。

モックアップを評価する5つの判断基準｜UI/UXデザインレビューの軸

ここからが本記事の核心です。30分のレビュー会議で発注者が順番に確認できる「5つの判断基準」を提示します。それぞれ「何を見るか」「具体的な質問例」「NGパターン」をセットで示すので、Figmaを開きながらそのまま使ってみてください。

5つの基準は、Jakob Nielsen による「ユーザビリティ10ヒューリスティック」（ユーザーインタフェースデザインのための10ユーザビリティヒューリスティックス - U-Site）を、発注者向けに圧縮・翻訳したものです。10項目を全部覚える必要はありません。発注者の役割（事業・ユーザーの代理）に直結する5つに絞っています。

基準1. 目的との整合性｜事業ゴールに貢献するか

最初に確認すべきは「このモックアップを実装したら、事業ゴールに近づくか」という最上位の問いです。

事業ゴールが「無料登録の獲得」なのに、ファーストビューが製品紹介の動画で埋め尽くされていれば、目的と画面の構造がズレています。「綺麗な画面」かどうかではなく「目的に貢献する画面」かどうかで見ます。

基準2. 導線の最短性｜主要アクションまで何ステップで到達するか

次に、ユーザーが主要アクションに到達するまでのステップ数を確認します。

ステップが1つ増えるごとに離脱率は上がるため、主要アクションまでのステップ数を最小化することが重要です。シミュレーションで実際に画面を順に追って、何タップで完了するかを数え、不要な画面遷移・タップを削れないか確認しましょう。「合理的な理由なく挟まれている画面」があれば、それは差し戻しの対象です。

基準3. 情報の優先順位｜最も伝えたい情報が一番目立つか

3つ目は、画面内の情報設計です。

人間の目は「大きい・色が強い・余白が広い」ものに自然と引き寄せられます。発注者として「最も見てほしい情報は何か」を言語化し、それが画面上で実際に最も目立っているかを確認します。「全部大事」と言いたくなる気持ちを抑えて、優先順位をはっきりさせるのがコツです。

基準4. 状態の明確さ｜ユーザーが今どこにいるか分かるか

4つ目は、ユーザーの「現在地」が常に分かる設計になっているかです。

これはユーザビリティ原則の中でも特に重要な「システム状態の可視性」に該当します。発注者の視点で言えば「自分が操作していて不安にならないか」を確認するセクションです。読み込み中のインジケーター、完了画面、エラーメッセージなど、状態を伝える要素が抜け落ちていないかを点検します。

基準5. エラー・例外への配慮｜失敗してもユーザーが復帰できるか

最後に、ハッピーパス（うまくいくケース）以外の挙動が想定されているかを確認します。

実装段階では「エラー画面はあとで」と後回しにされがちですが、モックアップ段階で例外処理が示されていない場合は、設計が成功パスしか考えていない可能性があります。「もしユーザーが間違えたら、もし通信が切れたら」を1つでも質問しておくと、後工程の大きな手戻りを防げます。

5基準の使い方｜30分のレビュー会議で順番に当てはめる

5つの基準を覚えたら、レビュー会議では次の順番で確認していくのが効率的です。

合計25〜30分。これでひと通りのレビューが終わります。各基準について「OK・要確認・NG」の3段階で判定し、要確認以上のものについては次のセクションのフィードバックフォーマットを使ってデザイナーに伝えます。

ワイヤーフレーム・モックアップ・プロトタイプ各段階で見るべきこと

「5つの基準」は強力ですが、これを全段階で全部適用しようとすると消耗します。デザイン制作は通常、ワイヤーフレーム → モックアップ → プロトタイプという複数段階を踏みます。それぞれの段階で「承認すべきこと」が異なるため、適切な観点で見ることが重要です。

各段階の承認対象マトリクス

段階別に、何を承認し何は見送るかを整理すると次のようになります。

例えばワイヤーフレーム段階で「この緑が気になる」とフィードバックしても、その時点では仮の色なので意味がありません。逆にプロトタイプ段階になってから「全体の画面構成を変えたい」と言えば、大幅な手戻りが発生します。「今この成果物では何を承認するのか」を踏まえてフィードバックを絞ると、レビューの効率が大きく上がります。

レビュー前に「今回は何の承認ですか？」と確認する

実は最も重要な質問が、レビュー会議の冒頭で発注者から発するべき一言です。

「今日のレビューでは、どこまで確定させたいですか？」

デザイナー側にとっても、この確認があるだけでフィードバックの粒度を揃えやすくなります。「今回はワイヤーフレームの情報設計を確定したい」と聞けば、発注者は配色を脇に置いて情報設計に集中できます。

各成果物の違いを詳しく知りたい場合

ワイヤーフレーム・モックアップ・プロトタイプの定義や使い分けを基礎から確認したい場合は、別記事で詳しく解説しています。本記事では「レビュー実務」に集中するため、定義の詳細はそちらに譲ります。

詳しくはモックアップ・プロトタイプ・ワイヤーフレームの違いをご覧ください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

「なんか違う」を具体的に言語化するフィードバックの伝え方

判断軸が分かっても、それをデザイナーに伝えられなければレビューは機能しません。「なんか違う」止まりのフィードバックは、デザイナーにとって最も対応に困るものの1つです。

このセクションでは、フィードバックを「デザイナーが次のアクションに移せる情報」に変換する方法を整理します。

NGフィードバック例 vs OKフィードバック例

まずは対比で具体例を見ていきます。

NGの共通点は「主観的な感覚」を述べているだけで、「何が問題か」「なぜ問題か」が含まれていないことです。OKの共通点は「課題（何が）+ 背景（なぜ）+ ユーザーへの影響（どう困るか）」が揃っていることです。

「課題 + 背景 + ユーザーへの影響」のフォーマット

OKフィードバックは、次の3要素を意識すると自然に書けます。

1. 課題: 具体的に何が気になるか（「カート→購入まで5タップかかっている」）
2. 背景: なぜそれが問題と感じるか（「想定ユーザーは離脱しやすい層なので…」）
3. ユーザーへの影響: そのまま実装するとユーザーがどう困るか（「離脱率が上がる懸念がある」）

そして大事なのが、ここで解決策を指示しないことです。「だからボタンを大きくしてください」と書きたくなる気持ちを抑えて、「どう解決するかはお任せします」と添えるとデザイナーが本来の専門性を発揮できます。発注者は課題と背景の提供者、デザイナーは解決策の設計者、という役割分担です。

個人的な好み（色・フォント）を伝えたくなったときの自問

レビュー中、つい「もうちょっと青っぽくしたい」「このフォントは古い気がする」と言いたくなる瞬間があります。そんなときは伝える前に1つだけ自問してください。

「これは想定ユーザーが困る話か、それとも自分の好みか？」

ユーザー視点で説明できないなら、それは個人的な好みです。個人的な好みをフィードバックに混ぜると、デザイナーは事業要件と発注者の趣味の両方に対応する必要が生じ、結果としてどちらも中途半端になります。

ただし、ブランドガイドライン（コーポレートカラー・指定フォント等）からの逸脱は別問題です。「自社のブランドカラーは緑なのに、青基調になっています」という指摘はユーザー視点とは独立した正当なフィードバックなので、しっかり伝えてください。

承認前のセルフチェックリスト

レビュー会議の最後、または承認メールを返す直前に使えるセルフチェックリストをまとめます。Figmaを閉じる前に、以下のリストを上から順に確認するクセをつけると、感覚OKの再発を防げます。

共通チェック項目（全段階で確認）

10項目すべてに「Yes」と答えられれば、自信を持って承認できる状態です。1つでも「No」「未確認」があれば、レビュー会議で追加確認するか、デザイナーに質問を投げるのが安全です。

段階別の追加チェック項目

共通項目に加えて、段階ごとに以下を追加で確認します。

このチェックリストはブックマークしておき、レビューのたびに見返す運用がおすすめです。最初は時間がかかりますが、3〜4回繰り返すうちに自然と意識できるようになります。

デザインと実装に差異が出たときの対処

承認したモックアップ通りに実装されない、というケースは現実にはよく発生します。技術制約・スケジュール都合・実装側の解釈の違いなど、原因はさまざまです。

このセクションでは「すべて差し戻す完璧主義」と「すべて許容する妥協」の間でバランスを取るための判断軸を整理します。あわせて、レビュー段階で「実装可能性」を確認しておく観点も補足します。

差異が許容できるケース・差し戻すべきケース

実装段階で発生する差異は、種類によって対応を分けます。

判断軸はシンプルです。「5つの基準のうち、どれかに本質的に影響するか」で見ます。影響しない差異は許容、影響する差異は差し戻す、という二分法で考えると判断のスピードが上がります。

承認時に「実装可能性」を確認しておく

実装後の差異を減らす最善策は、レビュー段階でデザイナー・エンジニアと「これは実装できますか？」を確認しておくことです。具体的には、レビュー会議に開発担当者を1人同席させるか、モックアップ承認の前にエンジニアにレビュー依頼を出すフローを組み込みます。

確認しておきたいポイントは次のような項目です。

• このアニメーション・遷移は技術的に実装可能か
• 想定する読み込み速度の中で、この情報量は表示できるか
• バックエンドのAPI仕様と画面の前提が一致しているか
• 想定するブラウザ・OS・端末で同じように見えるか

「承認後に実装で揉める」を防ぐ最大のポイントは、承認前にエンジニアの視点を入れておくことです。

デザインQA（実装段階での確認会）の提案

実装が一通り進んだ段階で、改めてデザイナーと発注者で「デザインQA（Quality Assurance）」と呼ばれる確認会を設けるのも有効です。

完璧を求めすぎると開発が止まりますが、何も確認しないと「承認したのに違うものができた」が再発します。重要な観点に絞って3つのチェックポイントを置く、というバランスが現実的です。

まとめ｜自信を持って承認するために

ここまでの内容を振り返ります。本記事で提示した、デザインレビューにおける発注者の確認ポイントは次のとおりです。

これらが揃っていれば、明日のレビュー会議で「いい感じです」を「導線が冗長で購入完了までに4タップかかるのが気になります」のように具体的に言語化できる状態になります。

発注プロセス全体の中での本記事の位置づけ

本記事は「デザイン会社にUI/UXデザインを発注した後、モックアップを受け取った段階でのレビュー実務」に絞った内容です。一方、発注前段階（要件定義・発注先の選び方・費用相場）については別記事でまとめています。

発注プロセス全体の流れ・費用感・発注先の比較を知りたい場合はUI/UXデザイン発注ガイドをご覧ください。

また、今回扱ったワイヤーフレーム・モックアップ・プロトタイプの違いをより詳しく整理したい場合はモックアップ・プロトタイプ・ワイヤーフレームの違いが参考になります。

デザインレビューは、専門知識の量ではなく「適切な物差しを持っているか」で結果が変わります。本記事の5つの判断基準とセルフチェックリストを手元に、自信を持って承認・差し戻しの判断ができる状態を目指してみてください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。