局所的なレビューに意味はない。全体最適を作るためのUIレビュー

こんにちは、セブンデックスでUIデザイナーをしている季山です。

私は現在セブンデックスのUIデザインのクオリティ担保のため、自分が担当していないプロジェクトも含めレビューに入っています。
元々はそれぞれのデザイナーのタイミングでレビューをしていたのですが、「世の中に良い体験を送り出すためには、UIレビューの運用を確立させる必要がある！」と思い、そこからどのようにレビューを入れていくのが良いかを模索してきました。

今回は私がUIデザインのレビューをどのようにやっているかを紹介します！

目次

1. プロセスレビュー
2. アウトプットレビュー
3. ①正解を出そうとしない
4. ②ユーザー目線をもつ
5. ③部分での最適解でなく、全体の最適解
6. ナレッジまとめ

プロセスレビュー

PJの開始時にデザインフェーズのプロセスを見ながら、どこでどんなアウトプットを出すのか、どのタイミングでレビューを入れるかなどを話します。

レビューを始めた当初は最終アウトプットとなる表層のみを見ていたのですが、表層のレビュー以前に「そもそもこの情報設計じゃない方が良くない？」となり手戻ることが何回か発生してしまいました。
この経験から、表層のレビューだけでは良い体験を作ることはできないという当たり前のことに気づき、最初にどのタイミングでどれくらいレビューを入れるかを決めるようにしています。

また、レビューのタイミングだけでなく、プロジェクトの特性やクライアントの体制、プロジェクトメンバーの経験・特性などを踏まえ、
「ここで一回ユーザーテストを入れた方が良さそう」
「PJにおいて重要なポイントになるところなので、特に力を入れた方が良いフェーズ」
「ここのFIXは現場メンバーだけじゃなく決裁者も巻き込むことが必要そう」
など、プロジェクトを円滑に進めるためプロセスに対するレビューもすることがあります。

アウトプットレビュー

デザイナーが作成したUIに対し、よりクオリティを上げるためには何をすべきか、ブラッシュアップの方向性を伝えるor時には一緒に模索します。

この時の基本スタンスはabyk先輩のレビューの入り方（https://note.com/ye610wmagic/n/n9c6316ee0ed5）を踏襲していて、自分は「マクロ視点」という他者であることを徹底しています。
その上で、具体的には以下のことに気をつけています。

①正解を出そうとしない

その場で解を出す行為はデザインの意思決定者が（100%でないにしても）私になってしまうので絶対に避けるべきですし、レビューを受ける側の学びも減ってしまいます。

なので、違和感がある点に対して「これは違和感ないけど、なにが違うと思う？」と声をかけたり、思考がまとまっていなかったら一緒に論点を整理したりなど、
基本的には問いを投げてかけて考えてもらうor一緒に考えながら進めるようにしています。

とはいえ、ネクストアクションが明確な状態でレビューを終える必要があると思っているので、考えすぎて頭が固まってそうだなと思った場合は一緒に手を動かして思考を広げる手伝いをしたりします。

正解を出そうとしないというのはレビューをする立場になって実は一番苦労したことでした。。
（自分の気質的にもつい一緒に最後まで考えたくなってしまうんですよね、気をつけます。）

②ユーザー目線をもつ

レビューの初手はデザイナー目線ではなく、使ってみた率直な感想を伝えるところから始めています。
具体的に「ここがこうなっているから、ユーザーが混乱してしまう」ではなく、「何する画面かよくわからなかった」のようなイメージです。
（自分も過去に言われたから人にも言ってやろうと思っているわけでは決してございません。）

また、その時にユーザー目線のつもりが自分目線になっていないかも注意が必要です。
ユーザーに成り切るために、どういうサービスで誰が使うのか、ユーザーは何をしたくてこの画面に来たのかをしっかり確認するようにしています。

同じプロジェクトのレビューをし続けていると、時には自分もユーザー目線から離れてしまう時もあります。
そういう時は、プロジェクト外のメンバーにも見てもらうことで、ユーザー目線を取り戻しにいくようにしています。

ユーザー目線での課題を明らかにした上で、なぜそうなっているのかをデザイナー目線で分解していきます。

③部分での最適解でなく、全体の最適解

UIに限らず、作り手は作り込めば作り込むほど視野が狭くなってしまいがちですよね。
レビュワーとしてマクロの視点を提供するために、全体の最適解を考えられているかを常に念頭に置いています。

よくあるのは、画面単位でのレビューや一部機能改修のレビューなど、「この画面どうですか？」「この部分どうですか？」のように点でレビュー依頼をされることです。
UIは見るものではなく使うものなので、前後のフローが重要になります。静止画ではなく動的に捉えられるように、遷移はそのほかの画面も見せてもらうようにしています。

また、私が特に気をつけているのはサービスの思想・コンセプトを捉えることです。
一般的に良しとされるデザインでも、サービスが実現したい世界に合っていなければ良い体験につながりません。
私の意見が入ることでそこから離れていってしまうことは絶対にあってはならないので、必ず前提情報として確認しています。

ナレッジまとめ

レビューの後は、受けた人にレビューの内容をまとめてNotionに貯めていくようにしています。

レビューをしていく中で、表出課題は異なっていても本質は同じ話をしていることはかなりあります。
これは別の人に対してだけでなく、同じ人に対しても起こることなので、ナレッジを貯めることと学びを最大化することを目的に始めました。

見返した時にわかるように書くというのは前提で、個別事例だけを残すのではなく抽象化して転用できる状態になっていることを重視しています。
書いてもらったNotionを見て「本質的なポイントはこっちですね」という話を改めてすることもあるので、やって良かったなと思っています。

これは始めたばかりなので、暇な時に眺めたり辞書的な使い方ができるように絶賛模索中です。

今やっているUIレビューについてまとめてみました。

今回は書いていませんが、アウトプットのレビューをする中でクライアントとの関わり方の話やプロジェクトの進め方の話など、デザイン以外の話もすることも多く、それも含めて私から伝えられることがあれば伝えたいという気持ちでやっています。

「UIを作る」というところにフォーカスしすぎず、良い体験を世の中に送り出すため、またUIデザイナーがBCSらしいパフォーマンスを発揮していくための一助になれるように、これからも模索していきます！

セブンデックスにご興味がある方は、ぜひカジュアル面談にもお申し込みください！

【インターネットnote】https://note.com/karen_7/n/n516e4f24f705