ベイジにデザイナーとして入社し、6年目となる。だんだんとチームメンバーが増え、他のメンバーの育成にも関わることが増えてきた。その仕事の1つに、他メンバーが制作したものにデザインレビューをする機会がある。
私自身、レビューをする中で、進め方やどこまで相手に伝えるべきかを悩んでいた。そんなときに、デザインマネージャーの田渕さんと1on1する機会があり相談してみた。そこで、デザインレビューのポイントをいくつか教えてもらったので、紹介しようと思います。
1. レビュー相手のアウトプットに責任をもつかどうか？
後輩とどのように関わるかによって、私がアウトプットに責任を持つべき場合と、持たなくてもよい場合があるとアドバイスをもらった。
アウトプットに責任を持つべき場合とは、後輩がまだ一人でプロジェクトを完遂できない可能性があるとき。私もプロジェクトメンバーの一人としてアサインされ、サポートをするような関係性で進めるときだ。この場合は、担当デザイナーがアサインされていつつも、その人を支えて成功に導いてあげる責任のある立場となる。つまりアウトプットへの責任も伴うし、それを成し遂げるためにプロセスから介入する必要もある。
一方、アウトプットに責任を持たなくてもよい場合とは、後輩がすでに一人でプロジェクトを推進する実力があるときなどに、そのクオリティをさらに向上させるためのヒントを与える存在、つまり相談相手や壁打ち相手としてサポートをするような関係性で進めるときだ。この場合は、担当デザイナーに最終的な意思決定を委ねるので、クオリティアップのために間接的に関わるが、直接的には管理する必要はない。
例えば、Slackの「デザインレビュー」専用のチャンネルにデザインをポストし、それに対して多くのメンバーがコメントを入れたりヒントになるようなリファレンスをポストしたりするようなやり方などである。
このように私の責任の有無によってタスクや工数が変わる。つまりそれぞれの立場によってどのようなレビューができるのかを考えていく必要がある。
2. クオリティの判断軸
次に、レビューの判断軸として、そのアウトプットがクライアントに提出できるものかを判断する線引きがあると教えていただいた。
判断する指標としては二つある。「チームメンバーの視座に左右されるような指標」と、「クライアントの要件や要望に左右される指標」だ。
限られた工数とスケジュールで効率よく進めるためには、後者の指標を要所でクリアしていき、前者の指標はよしなのタイミングで柔軟にクリアしていくと良いとのこと。たとえばアウトプットが「今っぽくない、野暮ったい」と感じるものであっても、クライアントに提出できる場合もあると教えていただいた。
レビューする際には、プロジェクトにおけるビジュアルデザイン要件を指標に判断する。要件にも「ベイジ要件クリア」「クライアント要件クリア」のふたつの視点があり、それらをかけ合わせて判断していく。この軸に沿って考えてみると以下のようになる。
ベイジ：NG、クライアント：OK （＝提出できる）
ベイジ要件からするともっと細部を工夫したいが、クライアント要件には沿っている。さらに納品まで時間もあり細部をブラッシュアップする余地もある。進行を優先することで他への影響を抑えるので、提出できると判断できる。
ベイジ：NG、クライアント：NG（＝提出できない）
ベイジ要件がどうであれ、クライアント要件から見てまだブラッシュアップが必要な場合。クライアントにとって不利益があったり、これまでの提案の文脈から外れていたり、打ち合わせの内容を反映できていない場合がこれに当たる。この場合はクライアントには提出できないと判断することになる。
このようにクオリティの判断軸を意識することで、プロジェクトの現実的な落とし所を見極め、進行していくと良いということを学んだ。
3. 適切な工数でメンバーが稼働するように
「後輩のアウトプットに責任をもつ」場合、具体的にどのようなポイントに気をつけてデザインをディレクションをしていくのか。
ひとつは「適切な工数でメンバーが稼働する」がある。結果的に提案日までにデザインが完成したとしても、メンバーが遅い時間まで残業したり、無限に何案も作ったりしていたとしたら、そのやり方は良くない。デザイナーをディレクションをする立場としては、その人ができる範囲で、最も良いアウトプットを引き出してあげる必要がある。
それを実現するためには、私側のやり方として「自分も手を動かしてビジュアルをデザインする」ことも考えられる。
ただ、メンバーの成果物に必要以上にレビューをして修正を加えたり、私が実際に手を動かしてビジュアルデザインをしすぎると、メンバーのモチベーションも下がるし、スキルも上がらず、チームの将来にとってネガティブな影響が蓄積してしまうだろう。
では、田渕さんはどのようにしているのかと聞いてみたところ、「自分自身もゴールを見据えた上で、デザイナーが100点のものを作れるようプロセスをデザインしている」とのこと。自分自身もアウトプットのゴールを見据えるためや、プロセスをデザインするためには以降のポイントをおさえることで効率の良いクオリティアップを目指せるという。
4. 先にゴールのイメージを共有する
制作に入った後ではなく、まず最初にゴールのイメージを共有する。デザインツールを触る前にお互いにアウトプットのイメージが見えていないなら、着手すべきではない。
そのために、例えば対象のページをデザインする前にお互いにリファレンスを出しあって認識合わせをすると良い。
身近な例で考えてみると、友人に「お腹すいたから何かほしい！」と言われ、何も認識合わせをせずにオムライスを出したとする。友達は「え…、ごはん系じゃなくて甘いものがよかった…」となる場合もあるだろう。
「甘いものが食べたい」「スイーツが食べたい」と認識合わせをした上であれば、ケーキを出そうと思うだろう。さらにそのケーキがどんな種類のものであったとしても大きな問題は起こらないはずだし、お気に入りの店舗を探す余裕も出てくるかもしれない。
つまり早い段階で理想像・方針を共有しておくと大きなズレを防ぐことにもつながるし、絞った方向性の中で様々な可能性を試す余裕もできるのだ。
5. ウェブサイトの「ストーリー」を握る
もう一つは、私はプロジェクトの要件を満たす「ストーリー」をできるだけしっかり描くことができると良い。
アウトプットをコントロールするためにはアウトプットしてもらったものをディレクションしているだけでは抜本的なジャンプアップには繋がりにくい。大事なのはデザイナーが作業を始める前にどれだけストーリーを共有できるかにかかっている。ストーリーの筋が悪いと、前提となる全体の戦略からのずれも生じてしまうからだ。
デザインするデザイナーにも一緒に考えてもらうと尚良いだろうが、田渕さんは、先輩がストーリー、後輩がルックを作るといった役割分担でやるとスムーズに進むととおっしゃっていた。
今思えば、私も先輩と組んでいたときに、見た目の話の前に、ストーリーについてアドバイスやアイデアをもらうことがあったなと思い出した。
さいごに
これまで、レビューの際には「伝え方」や「言い方」に気を遣っていた。しかし、田渕さんのお話を聞いて、もっと前段階でやることやレビューのポイントがあると学んだ。これまでのやり方にとらわれず、成果が出るレビューの仕方を模索していきたいと思う。
