より良いものにするために。デザインレビューの話

はじめまして、LTS デザインチームのおおきです。IT企業向けWebアプリを作っています。

突然ですが、皆さんデザインレビューしていますか？
LTS デザインチームはメンバー2名のスモールチームですが、チームとしてアウトプットするものは相互にレビュー依頼をすることが多いです。
今回はその目的や実施する中での心得などをご紹介します。

デザインレビューとは？

担当デザイナーがデザインしたものを他のデザイナーがレビューすることです。
私たちのチームではデザインが目的とずれていたり分かりづらい点がないか、を見ると同時に文言や表現の不備がないかもチェックしてチーム内でコミットしてからエンジニアに実装を進めてもらいます。

デザインレビューの目的

デザインの品質を上げる

デザインしているとどんどん入り込み、視点が狭くなることってありませんか？
そんなときに他のデザイナーから新たな視点を得ることで、よりよいデザインになることがあります。

デザインを言語化するスキルを身につける

レビューを依頼する側はデザインの意図を、される側（レビュアー）は感じた違和感を、言葉で説明するスキルが磨かれます。
特に直感的に感じた違和感を言葉で説明するのは訓練が必要です。

サービスのトンマナを揃える

複数のデザイナーで同じサービスをデザインする場合に限られるかもしれませんが、複数人の目を通すことで他の画面と表現や言い回しなど違ったりする部分に気づきやすくなるため、サービス内のトンマナを揃えることができます。

デザインレビューの心得

より良いデザインレビューとするには依頼する側、レビュアーどちらの配慮も必要です。
アンチパターンからそれぞれの心得をまとめていきます。まずは依頼者側から。

依頼者側

レビュアーに「こんなデザインレビューは嫌だな😫」と思われてしまう例
・デザインデータの共有のみでレビューを依頼される
・共有されたばかりのデザインのレビューをその場で求められる
・フィードバックを確認したのかわからない、放置される

こんなアンチパターンを避けるための心得を3つ挙げます。

デザインの目的、前提・制約条件を伝えましょう
目的やケースによってデザインの最適解は変わります。
デザインの目的（どんな目的を持ったデザインなのか？）や前提・制約条件（ステークホルダーからの要件やシステム的な制約など）を事前にレビュアーに伝えることで精度の高いレビューとなります。

レビュアーがデザインを眺める時間を確保しましょう
特に複数のUIデザインをレビューする際は、画面間で整合性がとれているかなども見ていくためにデザインを眺める時間が必要です。
口頭でレビュー依頼をした場合も、フィードバックをその場で求めるのは避けましょう。

フィードバックに対する反応をきちんとしましょう
フィードバックをすべてデザインに反映する必要はありません。
でも、フィードバックをきちんと受け取ったことと、反映しなかった場合はどういう理由で反映を見送ったかをレビュアーに伝えましょう。
納得感を持って進めることができ、互いに気持ちよくデザインレビューに臨めます。

レビュアー側

依頼者に「こんなデザインレビューは嫌だな😫」と思われてしまう例
・結論だけしか伝えられずフィードバックの意図がわからない
・フィードバックの強制力が強い

こんなアンチパターンを避けるには…

解決策よりも意図や理由を伝えましょう
例えば「ここのフォントを大きく」とフィードバックした場合、レビュー依頼した担当デザイナーは「どういった狙いがあるんだろう？フォントサイズは他と同じ方がバランスがいいのにな…」と悩んだりします。

でも、「単調な印象を受けたのでここのフォントを大きく」と理由を添えてフィードバックすれば、「それならフォントサイズを変えるのではなくて、レイアウトを見直したほうがよさそう！」というように、担当デザイナーがよりよいブラッシュアップ案を出すこともできます。

最終的にはレビュー依頼者であるデザイン担当者に判断を任せましょう
担当デザイナーが総合的に判断して、フィードバックをデザインに反映しない場合もありますが、そこは担当デザイナーに判断を任せましょう。

LTS デザインチームでは、反映を強く推奨するフィードバックには目印をつけてわかるようにすることもあります。

今回は私たちLTS デザインチームのデザインレビューについてご紹介しました。
エンジニアやビジネスサイドメンバーにレビューしてもらうことも大切ですが、デザイナーならではの視点からのフィードバックは学びも多いです。
ぜひデザインレビュー文化を広めていきたいです。

---
LTSでは一緒に働く仲間を募集しています。
少しでもご興味がある方はぜひ一度ご連絡ください！