こんにちは、デザイナーの藤村です。デザインチームで最近デザインレビューを始めました。とても勉強になるし、やっていてデザインそのものの面白さにさらに気付かされています。チームでTryしている内容をご紹介します。
※ここで言う「レビュー」とは、リリース判断の可否を決める機能のことではなく、デザインをブラッシュアップさせるための、批評とフィードバックそのものを指しています。
開発チームの一員としてのデザイナー
シタテルの開発チームは、デザイナー1名+エンジニア数名+関係者(企画、マーケ、営業、生産など様々)という構成です。デザイナーは特定のサービスに所属しており、これまでデザインのレビューはサービスチーム内でのみ行なっていました。シニアエンジニアが実装判断した上でチームで要件定義を行い、デザイナーが仕様の叩きを作成、フィードバックをもらいながら徐々にビジュアル面を作り込んでいくという流れが主です。
開発チームでのレビューのいいところ
複数の職種で構成されているため、さまざまな視点からの批評を集めることができます。
エンジニアは機能的な破綻がないか、条件による表示を想定できているか、堅牢性を保つことができているのか、と言った視点で批評を返してくれます。お客様と向かいあっている方からは、お客様に対して自身が機能や画面説明ができるのかという視点で、マーケティング担当は有用なデータが取れるのかという視点で、それぞれフィードバックを返してくれます。

エンジニアは機能的な破綻がないか、条件による表示を想定できているか、堅牢性を保つことができているのか、と言った視点で批評を返してくれます。お客様と向かいあっている方からは、お客様に対して自身が機能や画面説明ができるのかという視点で、マーケティング担当は有用なデータが取れるのかという視点で、それぞれフィードバックを返してくれます。

悩ましいところ
一方で、狭義の意味での”デザイン”を批評する環境がありませんでした。機能上は問題ないのに違和感がある、なんだか野暮ったい、画面を使おうとしたとき操作に迷う瞬間がある。。ちょっとした相談はデザイナー同士でしてましたが、お互い忙しそうだと遠慮してしまったり、各々がモヤモヤしながら自分ひとりで格闘していました。
デザインチームでレビューを始めた
シタテルのデザイナーは週に1回情報共有のための定例会を行なっていました。各プロジェクトの進捗を共有することを目的にしていましたが、みんなでデザイン力を上げようということで、他サービスのデザインレビューもやってみることにしました。
意見がほしいときは、以下のテンプレートを使ってGithubにissue化します。見てほしいデザイナーにアサインをして、後はみなさんの意見を待ちます。
レビューの仕方は、わたなべなつきさんの「デザインチームでよりよいコミュニケーションをおこなうための工夫」を参考にさせていただきました。
レビューをしてみる
Zeplinにコメントをしあう形で進めました。1デザインに対して数十に及ぶ場合もありました。私自身もいざコメントをしようとすると、どこに違和感や改善点を見出したのか、なかなか言葉にすることができず思った以上に時間がかかりました。
どうしても、「こうして欲しい」という指示型のコメントになってしまうのです。「ここでは目的と違う認識をしてしまうので再考が必要だと感じました」のように、根本的な問題点を指摘するようにするには、批評者自身もそこまで潜っていかないと見つけることができないんだなと実感しました。デザインをどう見るか、焦点がどんどん精緻化していくので、とても面白く勉強になります。
どうしても、「こうして欲しい」という指示型のコメントになってしまうのです。「ここでは目的と違う認識をしてしまうので再考が必要だと感じました」のように、根本的な問題点を指摘するようにするには、批評者自身もそこまで潜っていかないと見つけることができないんだなと実感しました。デザインをどう見るか、焦点がどんどん精緻化していくので、とても面白く勉強になります。
3週間やってみて
デザイナー定例でみんなで振り返って以下のような感想があがりました。やってみた感覚と共に、もっとよくするためのアイディアも色々出てきました。当たり前のことなんですが、実際にやってみるって本当に大切ですね。