自社プロダクト開発してるなら絶対デザインレビューやった方がいいよという話
akippa株式会社でデザイナーをしている西田と申します。
弊社のデザインチームでは去年から開発の過程にデザインレビューを取り入れはじめたのですが、私の中のやってよかったアワード2022で見事1位にランクインしました（拍手！）
ちなみにそれまではリソースの都合だったりスピード感最優先な案件続きだったりで、正直なところ「デザインレビューは貴族のたしなみ」ぐらいに思っていました。潤沢なリソースを持ち時間的余裕に満ちた者にのみ許される、特権階級向けな取り組みだと思っていたわけです。
ところが、今では似たような環境になりがちであろうスタートアップやベンチャーで自社プロダクトを開発しているチームにこそ欠かせないプロセスなのではないかと思っています。
今回はそんなデザインレビューについて、レビューする側/される側のそれぞれの心得や、推すしかないと思っている理由についてゆるくご紹介します。
レビュイー（される側）としての心得
1. ターゲット・目的を共有する
しょっぱなからそもそもですが「ユーザーがどう使うか？」の答えはユーザーしか持っておらず、正解はリリース後にしか分かりません。ぴえん。
ですがそれでもデザインの最適解を探るために、レビュアーには徹底的に己を消し、ターゲットになりきってデザインを体験し、目的を達成できるかを確認してもらいます。
そのためには達成したい目的、ターゲット、利用シーンなどをできる限り高い解像度で共有しておく必要があります。
2. 意図を余すことなく伝える
レビューはあくまでみんなで一緒にデザインするための場なのですが、それを実現するために、レビュイーはまずこのデザインに至った経緯や自分の判断を具体的に伝えます。
細かいディテールや言葉についてもとにかく掘り下げて共有することが重要で、例えば私は「思いついたけどやらなかったこと」なんかも話すようにしています。
そうすることで、参加者全員が同じ目線で同じ課題に取り組めるようになります。
レビュアー（する側）としての心得
1. ターゲットを主語にする
チーム間でレビューを行う場合、レビュアーも基本的には作り手側の立場であるため、どうしても作り手側の視点や都合に囚われがちです。
（余談ですが私は学生時代に映像を勉強していた影響で、今だに映画を見る際はワンカットの長さなど細かいディティールばかりが気になってしまい、ストーリーに全然集中できません……）
しかし、その目線だけで開発を進めた場合、たいてい生み出されるのは「開発者が満足できるもの」でしかありません。作るべきは「ユーザーが満足できるもの」なので、レビュー時には己を忘れてユーザーになりきることが重要です。
2. いいね！は全力で伝える
やはり自分が作ったデザインに対して物言いが入ると、それがどれだけいいフィードバックだったとしても、まるで自分が否定されたように思えてしまって気分が落ち込むことがあります。レビュイーも人間だもの。
そのため、レビュアーは懸念点や改善点を指摘をするだけではなく、少しでもいいと思うポイントがあれば、心の「いいねボタン」を無限連打しつつ、言葉に出して具体的に伝えましょう。これはもはや責務です。全うせよ。
自社開発のチームにこそおすすめしたい理由
以前、特に非デザイナーのメンバーは、デザインに対して多少の違和感があっても「専門外だからよくわからないし、まあ、こんなものなんだろう」という感じで済ませてしまいがちだったようです。
形としては一緒に開発しているものの、自分の担当領域外には干渉しない。チームというよりはただの集合体、グループだったように思います。
でもデザインを軸に率直な意見を交換し、メンバー全員が意思決定に参加する場を設けたことで、プロジェクトに対しての理解も深まり、皆が役割を超えてより強い当事者意識を持って取り組めるようになりました。
また、ディスカッションを重ねることによって良質なコミュニケーションの機会がグッと増え、メンバー同士のリスペクトも一層深まったと感じます。
信頼できる仲間と視点を合わせ、一丸となって取り組む。やっと本当の意味での協業ができるようになってきました。
つまり、もともとは単純にアウトプットの質を高める目的で始めたデザインレビューですが、気がつけばオーナーシップとかチームビルディングなどの、自社プロダクトの開発における重要な課題に対してもかなりいい効果をもたらしていたというわけです。なんなのデザインレビュー。最高かよ。
さっそく始めたくなったあなたへ
もしこれを読んでデザインレビューに興味を持っていただけた方がいれば嬉しい限りです。具体的な手法などはこちらをかなり参考にしています。よろしければぜひチェックしてみてください！