UIデザインレビューの進め方と、レビューで見ている観点

メディフォンのデザイン室の小川です。 本記事では、弊社のプロダクトデザインで行っているUIデザインレビューについてお話しします。

はじめにお伝えしておくと、UIデザインレビューのやり方に正解は1つではなく、体制や文化によって最適な形は異なるものだと考えています。この記事で紹介する内容も、あくまで一例として捉えていただければと思います。

この記事では、UIデザインレビューをいつ行うか、受ける側・する側がそれぞれ何をするか、レビューを受けた後の進め方、レビューの観点を紹介します。

デザイン室におけるAI活用の取り組みについては、前回のデザインブログ記事「Claude Designを使ってスライドの品質を整える」でも紹介しています。ご興味があれば、あわせてご覧ください。 

Claude Designを使ってスライドの品質を整える｜メディフォン株式会社【公式】

デザイン室の小川です。 本記事では、Claude Designを使ったスライド作成の方法を紹介します。 デザイン室のコミュニケーションデザインの仕事は多岐にわたります。 営業資料、セミナー資料、社内イベントのスライド。これらも立派なデザイン制作物です。 理想として、すべてのクリエイティブはデザイン室が制作できると良いのですが、 ...

https://note.com/mediphone/n/nc64bc0ac8a6b

なお、弊社ではUIデザインはFigmaを使って作成しているため、その前提で読み進めてください。
※FigmaはFigma, Inc.の登録商標または商標です。

UIデザインレビューのタイミング

UIデザインレビューのやり方が異なるという話と同じく、レビューをいつ・どの粒度で行うかも、案件の規模や複雑さによって変わります。

弊社のUIデザインプロセスには、大きく分けて

• ワイヤー作成
• UIデザイン作成

の2つがありますが、UIデザインレビューを行うのはUIデザイン作成後のみとなります。 ワイヤー作成後もレビューを行いますが、これは設計やユーザーフローに関するレビューが中心となるため、UIデザインレビューとは別観点のレビューとなります。 
本記事では、UIデザイン作成後のUIデザインレビューを紹介します。

レビューを受ける側

セルフレビュー

UIデザインができても、すぐにはレビューに出しません。 まずセルフレビューをします。 
セルフレビューにはチェックリストを使います。

チェックリスト
チェックリストは、デザインに問題がないか、抜け漏れがないかを確認するためのリストです。 
項目は大きく「全体の構成・画面遷移」「データ」「UI全般」の3つに分かれていて、画面遷移やナビゲーション、リストやテーブルのデータ表示、日時フォーマットやテキストの細部まで、抜け漏れなく確認できるようになっています。

▲チェックリスト。一部抜粋

内容には、UIの表示パターンを網羅するためのUIスタックのような一般的な項目もあれば、UIがデザインシステムに沿っているか、権限やユーザー種別によって操作・画面がどう変わるかといった、事業ドメインならではの観点も含みます。 プロダクトで使う言葉のガイドラインや用語集など、確認すべきルールへのリンクを集約するハブにもなっています。

過去の経験で足りない項目を継ぎ足していった、秘伝のタレ的なものです。

良いレビューをしてもらうための準備

より良いUIデザインレビューをしてもらうためには、レビューを受ける側が行っておくとよいことがいくつかあります。
要件などの情報を記載する
UIデザインのもととなる要件を記載したりリンクを貼ったり、その他レビュー時に把握しておくとよさそうな関連情報があればそれも載せておきます。

▲外部リンク用のヘルパーコンポーネントを使って情報をまとめた例

UIデザインにメモを記載する
メモ用のヘルパーコンポーネントを用意しています。バリアントには、

• 補足
• 仕様
• 検討

などの種類があり、用途に応じて使い分けUIに付箋のように貼っていきます。

▲メモ用のヘルパーコンポーネント

「補足」メモには、UIデザインだけでは伝わらない、そのデザインにした背景や、検討したけれど却下したことなどを記載します。「仕様」メモには、仕様に関する情報を記載します。「検討」メモには、悩んでいることや相談したいことを書きます。

レビューする側

続いて、レビューする側の話です。

デザインレビューはPdMも行いますが、本記事ではデザイナー目線でのUIデザインレビューを紹介します。

前提として、UIデザインレビューは、レビューする側の好みや思いつきを一方的に伝える場ではないと考えています。そのため、次のようなことを意識しています。

• 感情的にならず、「なんとなく」の感覚だけで判断しない
• 一方的な希望の押しつけを避け、相手が思考・検討できる余白を残して伝える
• その判断に至った背景や根拠・理由をセットにして説明する
• 不明な点や理解が追いつかない部分があれば、自身で判断せずに質問・確認を行う
• 良いと感じた箇所も評価として伝える

こうすることで、レビューが一方的な指示ではなく、より良いデザインに向けた対話になります。
良いレビューに関しては、書籍『みんなではじめるデザイン批評』（アダム・コナー、イリザリー著／BNN刊）が参考になります。 余談ですが、社内でも何度かこの書籍を使った勉強会を行いました。

なお、UIデザインレビューはFigmaのコメント機能を使います。

レビュー時の主な視点

セルフレビューのチェックリストが抜け漏れを潰すためのものだとすれば、ここからのレビューは観点について議論する場だと考えています。主に次のような視点で見ます。
要件を満たすか
このデザインは要件を満たすか。前提として、要件を満たしていない場合は必ず対応する必要があります。
わかりやすいか
ライティングまで含めた、UIとしてのわかりやすさをレビューします。要件を満たしたうえで、使いやすいか、迷わず使えるかを確認します。ユーザー視点で考えつつも、私たちはユーザーではないので、難しいところです。ただし、レビューは絶対ではないので、気になるところがあれば素直に指摘します。
使う場面や目的に合っているか
ユーザーが実際にどんな場面でこの機能を使うのかを想像し、そこに至るまでの流れやその後の流れが自然か、迷わず目的を達成できるかを確認します。「わかりやすいか」が個々の画面の理解・操作しやすさの視点で見るのに対して、画面の前後のフローを含めた体験全体を見ます。
仕様の問題がないか
UIとしては良いが、仕様の観点で難しいところはないか、実現可能性が低いところはないかを確認します。仕様についての理解度はその人個人の知識によるところがありますし、PdMやエンジニアの方が理解が深いこともあります。ただ、仕様を知っていても、その観点でUIを見られるかはデザイナーの得意領域だと思います。なので、デザイナーもこの観点でレビューします。
デザインシステムの使い方が適切か
デザインシステムにUIコンポーネントが存在するものは、原則コンポーネントを使用してUIをデザインします。コンポーネントには、どのような用途で使うことを目的としているかが決められています。その目的に沿った正しいコンポーネントが選択されているかをレビューします。

レビューを受けた後にすること

レビューコメントの対応は絶対ではないので、対応するかどうかは、基本的にレビューを受ける側に委ねられています。
ただし、実際には判断に迷いやすいので、レビューする側も、コメントによっては「対応を任せる」「どちらでも良い」など選択を委ねる旨を記載し、それ以外は対応したほうが良いという判断で運用しています。

レビューコメントに対して確認や質問がある場合は、以降はFigmaのコメント機能を通じてやり取りを続けます。

ちなみに、コードレビューのコメントのようにMUST、NITSなどを使う方法も検討したことがありますが、弊社ではそこまでしなくても問題なく運用できていると思ったため、対応していません。レビューされた側が判断に迷うような現場では、検討しても良いかもしれません。

おわりに

ここまで紹介してきたのは、冒頭でお伝えしたとおり、あくまで弊社の一例です。体制や文化が変われば、最適なやり方も変わると思います。私たち自身も、より良いやり方を模索しながら、レビューのやり方を継続的にアップデートしています。最近では、レビューにAIを活用することも試みています。

やり方は変わっても、わかりやすく使いやすいUIを目指すことと、健全な対話としてレビューを続けることは、変わらず大事にしていきたいと思っています。

この記事が、みなさんのUIデザインレビューの参考になれば幸いです。