デザインレビューシステム〜正しいデザインを正しく作ったか〜

こんにちは。デザイナーのたかはし（@tmtgtk）です。かれこれ社会人8年目のデザイナーとなりました。広告制作会社からスタートし、事業会社、スタートアップを数社渡り歩いた僕が、何らかの知見をシェアできないかなと思い立ち、初めてnoteを書いてみようと思います。

いきなりですが、デザイナーのみなさん、「デザインレビュー」って普段どうしてますか？

・上司に見てもらいフィードバックしてもらう・デザインチームの複数人で集まってスクリーン見ながら・エンジニアさんやディレクターさん含めたプロジェクトメンバーで・デザイナーが自分ひとりなので、誰もレビューしてくれない…

などなど、様々なケースがあるかと思います。一方、デザインレビューのよくある問題で、

・その都度上司の言うことが変わる・その時の参加メンバーによってツッコミどころが全然違う（立場が上だったり声の大きい人の意見が通りがち）・エンジニアさんやディレクターさんと共通言語で話せない・デザイナーが自分ひとりなので、とりあえずレビューなしでリリース

なんてことがありませんか？
そこで、今回僕が提案したいのは「デザインレビューシステムを作ろう」ということです。

デザインレビューシステムって？

デザインレビューシステムとは、読んで字のごとく、デザインレビューをシステム化（と言ってもプログラムは不要）したもの。上述した問題をなくすために、システム化つまり属人的な要素を排除し、レビュー項目を明文化して「型」を作りましょうという提案です。武道でもまず「型」をマスターしますよね。デザインにも守破離が必要だと思ってください。

デザインレビューをシステム化するとどんないいことが？

ざっくりとメリットをあげるならば、

・デザインプロセスにおいて無駄が減る（オペレーションの効率化と高速化）・アウトプット品質のブレがなくなる・デザイナーでない人とも「どんなプロセス、基準でデザインしているか」を知ってもらうことで共有言語で話せる・レビュー文化の構築（ひとりからでもOK）

といったところでしょうか。
では具体的なデザインレビューシステムをごらんください。↓↓

デザインレビューシステムの2大構成要素

プロセス評価
正しいデザインを作るためには、正しく作る必要があります。作るプロセスのチェックです。
こちらは主にリーダー、マネージャーがメンバーのデザインプロセスをさらに改善したいときにするイメージかもしれません。しかし、チームメンバーやクライアントがいた場合も、有効な評価方法です。というのも、アウトプットだけをみたところで、どういう理由で、どういうステップを踏んで、て案となるアウトプットに至ったかが理解できないと、アウトプットが望ましいものかどうか判断しようがないからです。

アウトプット評価
一見プロセスが正しいように見えても、必ずしも正しい成果物が作れるとは限らないのがデザインの難しいところです。こちらはできあがったものが正しいかどうかをチェックします。
こちらはチームメンバーや上司、案件の受け入れ先などステークホルダーを含めた方がおこなうこととなります。

よくありがちなのが、「アウトプット」だけがレビューされ、プロセスは個々のデザイナーに任されているケースです。しかし実際は、プロセスまでレビューすることこそが重要です。なぜならば、素晴らしいアウトプットはそれに見合ったプロセスを踏んでいるケースがほとんどだから。

ここでは、あくまでアプリデザインの場合の一例を挙げます。各々の現場によって、システム化すべきレビュー項目は変わってくるはず。要不要を見極めて参照していただき、オリジナルのレビューシステムを作り、調整、運用してみてください。

プロセス評価（正しい方法で作ったか）

共感
・ユーザーテストによる定性、定量結果を元に仮説設計したか
・アナリティクスなどのデータを参照したか
・要件や仕様、達成すべき課題を言語化したか
・ユーザーが体験するであろうストーリーを可視化したか

仮説設計
・課題の重要度、影響度を明確にしたか
・対象となるユーザーのニーズ（ウォンツ）を明確にしたか
・仮説を言語化したか
・仮説に定性、定量データを活用したか

タイムマネジメント
・最小の時間で最高のアウトプットを出すために適切な粒度でタスクを切り分けたか
・関係者とスケジュール感（緊急度）の共有はできているか

悲劇の予防・回避
・ユースエラー（想定内の間違い、想定外の記憶抜け、うっかりミス）のリストを作成したか
・上のリストを元に予防、回避策を施したか

拡散・収束思考
・要件に応じて拡散思考、収束思考をしたか
・上記の形跡を残しているか
・思考の際に照会した参照ソースやボツ案、そのボツ理由も記録したか

アウトプット評価（正しいものを作ったか）

課題解決手法
・課題と解決手法の対応関係を言語化したか
・メンバー、意思決定者への説得力はあるか
・前例があるか（あれば提示）

アウトプット形式、使用サービス、完成度
適した形式、サービスを選択したか
・形式（手書きスケッチ、ワイヤーフレーム、モックアップ、プロトタイプ）
・使用サービス（Figma, Sketch, Abstract, Zeplin, Adobe XD, illustrator, Photoshop）
・完成度（粗々のアイデアベースの状態、十分発散した状態、発散したのち収束させた状態、収束した上で推薦案を決めた状態）

使い勝手
・ユーザーの意図→行動選択→実行結果までがスムーズか
・オリジナル or OS標準のUI Kitを使ったか（コンポーネント、色、タイポグラフィ、スペーシング、ジェスチャー）
・「モーダル」と「モードレス」を踏まえて利便性を持たせたか
・メンタルモデルのトップダウン処理に即しているか

（トップダウン処理とは、「私たちが、すでにもっている知識や、その時々に頭に思い浮かんだ考え（期待や仮説）を先行させて、見ているもの・聞いている音・読んでいる文を理解する方式のこと」）

レイアウト四原則
・近接、反復、整列、コントラスト、の原則が守られているか

アクセシビリティ
・情報や機能は理解しやすいか
・色覚マイノリティへの配慮は十分か
・ページロードとランタイムの時間は許容範囲か

ユーザー負荷
各負荷を必要最低限まで最小化したか
・認知負荷（不必要な認知負荷を与える箇所がないか）
・知覚負荷（考えたり、記憶したり、スキーマと関連付け）
・視覚負荷（フォーカスすべきものがしやすいか）
・動作負荷（ポインタ操作や指のジェスチャーが成功しやすいか）
・学習負荷（学習のハードルが高くないか）
・選択負荷（選択肢を必要最小限の数に絞って見せているか）
・決断負荷（決断させるタイミングは最適か、判断材料は与えているか）

実現可能性
・エンジニア側の実装コストを把握できているか（費用対効果の納得感）
・デバイス、OSの違いによる仕様制限を把握できているか
・APIやDB構成など関連する仕様と整合性があるか
・リリーススケジュールをメンバー間で共有しているか

情緒性
・意図した気持ちよさ、楽しさ、ワクワク感がきちんと担保されているか

品質管理
・品質をチェックする時間を確保しているか
・リリースされる状態のものを実際に触り、想定通りか確認したか
・想定通りでなければ、その旨を共有、修正したか

成果評価
・課題解決度を評価するための、定量もしくは定性指標、またその計測期間を定めたか

さいごに

ここでの例は以上となります。繰り返しになりますが、各々の現場、レビュー対象によって、レビューの際に評価すべき項目は変わるので、あくまで参考例であることをご了承ください。また、上記のすべての項目を1回のレビューで行うケースはあまりないでしょう。現場に応じてレビューする頻度やレビュー対象のボリューム感も異なります。

デザイナーにとって、晴れない霧の中を歩くような不安な気持ちでデザインすることほど辛いことはないです。あらかじめデザインレビューをシステム化、型化することで、どんなプロセス、どんなアウトプットが評価されるのかを、デザイナーもそうじゃない人も明確に認識し合い、同じゴールを目指しましょう。ありがとうございました。