デザイナーチーム内で以前より課題と感じていたデザインチェック体制の構築に取り組んでみましたメモです。
# 前提条件
- 案件は受託制作が中心
- デザイナー5名（内マネージャー1名）
# 組織が抱えていた課題
##1.個人で作業が完結しがち
案件規模により複数人アサインされることもあるが、1案件＝1デザイナーで完結する事が多い。
またマネージャーはいるもののアートディレクター的なポジションが存在しないため、デザインクオリティにバラつきが出やすかった。作業が属人化しており、誰が何を作っているのかお互いにわからない問題もありました。
##2.スケジュールがタイトな場合業務フローに組み込みにくい
受託案件が中心なので、スケジュールがタイトになりがち。
そのため作業工数が増えるデザインチェックを敢えて排してきた経緯もあり、また組織としてのスピード感も重視したいため、レビューできる（して欲しい）案件とできない案件を依頼する側が切り分けて依頼できる仕組みが必要。
##3.実施にあたっての心理的障壁がある
これまで個人の自発性に任されてきており、やや実施までの心理的障壁（面倒くさい）があったため、レビュー依頼～実施までのフローを仕組み化してハードルを下げる必要性があった。
##4.レビュアー、レビュイーの（物理的、精神的）負担
時間的束縛が少ない形態かつ、レビューのボリュームも少なめになるような方法がよい。また対面以外のやり方や、1対1ではなくグループで行なう方法も検討。
# Slackを使用したカジュアルレビューの導入
##1.実施目的
- 作業者が気軽に依頼できるデザインレビューの仕組み化
- まずはデザインレビューを通常の業務フローに導入し、チームとしてアウトプットできる成果物のクオリティを担保する
想定される利用シーン
（例えば…）
「提出までの間にもう少しブラッシュアップしたい」
「明日提出のデザインなんだけどボタンのデザインで迷っている」
「レイアウトがしっくりいかないので誰かと相談したい」
「煮詰まってしまったので客観的な意見が欲しい」
（新人の人は…）
「まだ途中なんですけどこれ大丈夫です……？」の方向性確認
「これで出していいですか？」の最終確認
etc.
- 他のメンバーが作っているデザインに触れる機会を増やしナレッジの共有と相互理解を促進する
##2.依頼方法
Slack上に作ったチャンネル（#design_check）にて @channel を付けて依頼。
##3.ルール
- 依頼者は案件のアウトラインと、デザインの意図・ポイントを必ず伝えること（そのデザインがなにを目的としたものかの共有が大前提）。
- いつまでに欲しいかも伝えること（レビュアーのスケジュールも考慮して依頼）。
- 相談ベース（「ここのボタンどうでしょう？」）とかもありです。
- レビュワー指名もありです。
- 依頼のあったデザインはデザイナー全員が必ず目を通すこと（意見がない場合でもSlack上でハンコ絵文字を押すこと）。
↓↓↓↓↓ こんな感じ ↓↓↓↓↓
- デザインレビュー自体は何かを「決定」する場ではないため、レビュー内容に対する「修正する・しない」の判断は依頼者に委ねます（そのデザインの目的に対する合致度で判断してください）。
##4.その他
デザインレビューの前提となる知識と手法の共有のため、下記の書籍を購入・回覧しました。
また長谷川恭久さんのブログ「could」から下記の記事なども参考にしつつ、レビューの効果が最大化されるよう意識して運用しています。
# 半年ほど運用してみて
##1.デザインを言語化できる
自分のデザインであっても他者のそれであっても、デザインを客観視して言語化し、それを相手に伝える訓練になる。
##2.気づきを得られる
個人の作業では気づきにくい改善点を知ることができ、以降の制作にも活かすことができる。
##3.クオリティがあがる
単純なことですが、同じデザイナーに見られるという意識（無意識）が働くと細部の詰めなどに妥協が無くなる気がします（個人の感想です）。またディレクターやクライントへの提出前に客観的な目を通すことで、いわゆる「ブラッシュアップ」行う機会が1回増えるだけでもクオリティ向上に繋がると思います。
##4.（普通に）褒められると嬉しい
「まず2コ褒め、そののちの改善点指摘」を徹底することが大事。
##5.今後
現在はデザイナーのみの参加ですが、ディレクターが入ってきた場合、あるいは営業さんなど違うカルチャーの人が入ってきた場合、ステークホルダーが参加した場合など、徐々に検証をしながら、「好き」「嫌い」「違和感がある」などといった感覚的なワードに頼らないフラットな目線でデザインレビューを行える文化的土壌を全社的に作れたらよいかなぁと思っております。