“なんとなくOK”を卒業する ― デザインレビューの視点を洗練させるには

はじめまして。ウォンテッドリーでMobile Tech Leadを務めている久保出と申します。

この記事は、2025年夏のウォンテッドリーのアドベントカレンダー20日目の記事として執筆しました。主な対象読者として、モバイルおよびフロントエンド領域でUI実装やデザインレビューに関わるエンジニアを想定しています。特に、業務でデザイナーと協働する機会は多いものの、レビューの際にどのような視点を持てばよいか分からずに悩んでいる、そんな方の一助となれば幸いです。

そのOK、本当にOKですか？

デザイナーから上がってきたデザインに対して、「いいと思います」や「大丈夫そうです」と返したものの、いざ実装を進めてみると「どうも想定と違っていた」と感じることは珍しくありません。私自身、日々メンバーとUIレビューのやりとりを行う中で、“なんとなくOK”というフィードバックが、後の手戻りや認識のズレを引き起こす場面に何度も立ち会ってきました。

この記事では、私がデザインレビューの際に意識している観点や問いを言語化し、共有します。レビューの質を高めることで、プロダクト開発をより洗練させていく、そのためのヒントをお伝えできればと思います。

UIの目的と必要性を問い直す

UIはプロダクトの目的達成に貢献するための手段であり、その一つひとつに存在理由があるはずです。そのため、デザインを確認する際には、「なぜこのUIなのか」「そのUIは本当に必要か」という2つの問いを常に心の中で持つようにしています。

例えば、ユーザーが毎回入力しなくてもよい情報が求められていないか、導線が不必要に複雑化していないか、あるいは目的に対してUIが過剰な構成になっていないか、といった点を確認します。背景が曖昧なまま進行してしまうと、後の検証フェーズで問題が顕在化し、手戻りが発生するリスクを高めてしまいます。

具体的な例を挙げると、最小限の工数でA/Bテストを行ってフォームの入力率を改善したい、という目的に対して、リッチな選択式入力フォームがデザインされた場合、実装コストが見合っておらず、目的と手段が不一致となります。このような場面では、施策の目的に立ち返り、デザインを見直す必要があります。

表現の一貫性と用語の意図を汲む

プロダクトのUIにおいて、言葉や見た目の構成に一貫性があることは、ユーザーの学習しやすさや信頼感に直結します。私は、同義語の使い分けや文末表現の統一、語調の整合性、さらには他の画面との用語の使われ方などを確認し、既存の画面との間に違和感がないかを検知するようにしています。

具体的には、同じ意味を持つアクションに対して「フォロー」「追加」「登録」のように異なる言葉が使われていないか、文末が「〜です」「〜する」のように混在していないか、といった観点です。もちろん、ボタンのサイズや配置、余白、アイコンのスタイルなどが、デザインシステムに準拠しているかも合わせて確認します。

UIの一貫性が損なわれていると、ユーザーは「なんだか使いづらい」「思っていた動きと違う」と感じやすくなります。そうした小さな違和感の積み重ねが、フラストレーションを生み、場合によってはプロダクトから離れてしまう一因になります。

一方で、似た表現であっても意味が異なる場合は、見た目や機能の上で明確に区別しなくてはなりません。たとえば、「いいね」と「ブックマーク」は混同されがちですが、それぞれの役割は異なります。そのため、見た目のデザインだけでなく、命名やデータ設計といった実装レベルでも、明確な意図を持たせることが大切です。

デザインされていない状態をどう扱うか

UIデザインでは、すべての状態が網羅的に表現されているとは限りません。データロード中やエラー表示、想定を超える長い文字列、多言語対応による文章の折り返しなど、デザインに含まれていない状態は多々あります。

こうした課題は、デザイナーに全パターンのデザイン作成を依頼することでも解決できますが、デザイナーの負担を増やしてしまいます。そこで、不足しているパターンについて質問を投げかけて、隠れた要件を洗い出したり、「この条件の場合は、このように表示するのはどうでしょう？」といった提案をしたりすることで、より建設的で、チーム全体として最適な課題解決ができるようになります。

たとえば、エラー状態のデザインが存在しない場合でも、「既存のこの画面のスタイルを流用する方針でいかがでしょうか？」と提示することで、意思決定の往復を減らすことが可能です。

実現性とユーザー体験のバランスを取る

レビューの段階では、見た目の完成度だけでなく、実装の観点や実際のユーザー体験も踏まえて検討することが重要です。対象のUIがプラットフォームや開発環境に適した構成になっているか、既存のデザインシステムで無理なく実装できるか、そして操作したときの快適さが保たれているか、などを総合的に判断します。

たとえば、スクロール可能な要素が入れ子になった構造は、モバイル端末においては実装難易度が高い上に、操作性が低くなり、ユーザー体験に悪影響を与えます。こうした実装上の難しさやリスクも考慮した上でレビューを行うことで、手戻りを少なくできます。

対話を通じて、デザインをより良くする

デザインレビューは、単なる成果物のチェック作業ではなく、プロダクトの品質とチームの認識を高めるための、とても重要な工程です。レビューの質は、出てくるフィードバックそのものだけでなく、どのように問い、どう対話を進め、どのように意思決定するかという、一連のプロセスに大きく依存します。

私が日々のレビューで意識しているのは、次のようなことです。

レビューに入る前の段階で、背景情報を揃えます。施策の目的や対象ユーザー、既存仕様との関係などをデザイナーと共有し、判断の軸を合わせておくことで、論点がブレるのを防ぐことができます。
気になった箇所について、なぜこのデザインになっているのかを問いかけます。これにより、単なる違和感の指摘ではなく、デザインの意図を深く理解しようとする対話が生まれ、主観的な評価に終始することを避けられます。
デザインに対する提案は、制約と実現可能性を考慮して提示します。そのために、時にはPoC（Proof of Concept）のような実際に動くものを用意すると良いでしょう。これにより、レビューの往復回数を減らし、より迅速なフィードバックループが作られます。

デザインレビューは「評価の場」ではなく、関係者全員で「デザインを洗練させていく場」と捉えることが重要だと考えています。