
デザインレビューのガイドラインを作りました -レビューフロー編-
こんにちは。hacomonoのプロダクトデザイナーのかんちゃんです。
組織に所属しているデザイナーの方であれば、レビューのガイドラインが欲しいと思った経験はありませんか?
この記事は発足して2年弱のデザイン組織でデザインレビューのガイドラインを作成した経緯の記録の第3弾「レビューフロー編」です💡
中小規模のデザインチームでレビューに課題を感じている方々の参考になればと思い、「心得編」「レビュー観点編」「レビューフロー編」の全3編に分けて投稿しています。
これまでの経緯
hacomonoのデザイン組織は発足して2年と少しが経ったところです。
少しずつメンバーが増えてきて、「さあ、これからデザイナーの力を発揮していこう!」と意気込んだところで「組織が拡大していくにつれてデザインのアウトプットにムラができる」という壁にぶつかったのがそもそものきっかけでした。
課題を深ぼった結果、デザインレビューのガイドラインを作ることになりました。
課題の深掘りについては心得編にまとめていますので、ぜひご覧ください。
レビューフローとは?
今回定めたレビューフローは、デザインレビューを「いつ」「どのように」行うのかを明文化したドキュメントになります。
どのように進めたのか
過去の心得編やレビュー観点編と同様に、定例の時間を活用して複数回にわたってディスカッションを行いました。
事前調査:30分×2回程度
ディスカッション:20分程度×2回
まとめ&清書:30分×1回


浮き彫りになった課題
レビューフローについて意見を交わしていくと、業務中のメンバーの迷いポイントは主に3点であることが発覚しました。
レビューを行うかどうかの判断
レビュアーの設定方法
レビューイがレビューをお願いするタイミング
それぞれの項目でどのようなことをお話ししたのか解説していこうと思います。
レビューを行うかどうかの判断
おそらくレビュールールを設定する際に多くの人がぶつかる壁ではないでしょうか?
▼実際に上がった声の例
・marginや文言の微調整など粒度の小さいアウトプットの場合、デザインレビューは実施するべきか?
・PJチームで不要と判断したら、スキップして良いかも
・コンポーネントの新規追加や、正しい使われ方をしているかは第三者チェックが必要そう
・品質担保の観点で、リリースされるデザインは全てレビューを実施しても良いのでは?
こちらの件は、チーム内でボーダーを明確にできるイメージが最後までつかなかった為、原則全てのデザインでレビューを行い運用しながらやらなくてもいいラインを見つけていこうという運びになりました。
メンバーの実体験と照らし合わせてアップデートしていきます。
レビュアーの設定方法
こちらは、レビュアーを誰にお願いするか?というご意見でした。
ディスカッションをする中、サービス仕様について比較的詳しいメンバーの目を通したいという意見がメンバーで一致した為、策定時は2名のメンバーのレビューを必須としその他メンバーのレビューは任意にすることとしました。
レビューイがレビューをお願いするタイミング
こちらも多くのご意見をいただきまして、要約すると下記でした。
▼実際に上がった声の例
・エンジニアレビューの前?後?好きなタイミングでもいい?
・実施の回数は最低1回とか?上限は?
上記を踏まえた作成の要件
レビューで出てきたFBがそもそも論に巻き戻りすぎることを防止できないか
レビューの出しているデザインはUX5段階でいうところのどこに当たるのか関係者に意識してもらう
タイミングのイメージがわかる書き方
hacomonoの業務フローに出てくるどんな情報とリンクしているのか?
要件をクリアするにあたって、下記のプロセスを参考にさせていただきUX5段階をベースにhacomonoの要素を取り込んだフロー図の作成を行うこととしました。
作成してみた
上記の解題をもとにガイドラインに項目を追加し、下記のようなアウトプットになりました。


まとめ
いかがでしたか?
レビューフロー編で個人的にうまくいったのは、PRDとUX5段階モデルとの紐付けを行うことで、課題の所在がチーム全体でわかりやすくなったことだったと思っています。
逆にうまくいかなかったことをあえて書くなら、やってみないとわからないことが多々あり今後も継続したアップデートが必要なところでしょうか。
また全てのガイドラインに通ずる事ですが、ルールとしてガチガチに固めてしまうとデザイナーの制作体験が落ちる可能性があるのでちょうどいい運用の形の模索は続きそうです。
以上で3編にわたって書いたレビューガイドラインを作成した話は終わりになります。プロジェクト業務と並行して実施した為決して簡単な取り組みではありませんでしたが、チームでレビューと深く向き合う良いきっかけだったように思います。
ここまで付き合ってくださったメンバーのみなさん、本当にありがとうございました!
もしこの記事を読んで、取り組みに興味を持っていただけたら過去の記事も見てみてくださいね。
さいごに
株式会社hacomonoでは一緒に働く仲間を募集しています。
採用情報やhacomonoプロダクトデザインチームの詳細もぜひご覧ください!