デザインレビューで悩んでいる人へ、コツを教えます【抽象化→具体化がカギ】
こんにちは、シンヤです！
今回は、デザインレビューへ悩んでいる人へ、コツを教えます【抽象化→具体化がカギ】というテーマで、お話しいたします。
大抵の悩みは「抽象化→具体化」が出来ていないから起こる
結論から言いますと、大抵の悩みは「抽象的な考えを具体化できていない」から起こります。
わかりやすく言うと、「何に悩んでいるのか言語化できない」から悩むのです。
頭の中にモヤモヤした霧みたいなのがかかっていて、気持ち悪くなったことはありませんか？
それです😁
それは「デザインレビュー」でも同じです。
何のレビューをお願いすればいいか分からない
お願いの仕方がわからない
デザインの意図をうまく伝えられない
こんな感じですかね。
デザインレビューでありがちなお悩みって🙂
つまり全部、
→抽象的な考えを具体的に相手に伝えられない
からこそ起こる悩みです。
みんなアウトプットの仕方を知らない
これは個人的な考え方ですが、日本の学校教育ってインプットに偏りがちで、アウトプットの方法を教えてくれなかった気がします。
とにかく「頭に詰め込め」的な教育ですね。
デザインレビューとは、相手に自分の意図を伝える「アウトプット」です。
抽象的な課題を、相手に具体的に伝える技術が求められます。
ですが、アウトプットのやり方をみんな教わっていないので、抽象的な考えを具体的に相手に伝える方法を知らないのです。
大体ここで、事故が起きる気がします。
つまり、「意図を正確に伝えられていない」ということですね😌
デザインレビューで大切な事3つ
つまり、適切なアウトプットができればいいわけです。
そんな方法知っていたら苦労はしないかもしれません。
安心してください、ちゃんとしたレビューの方法をお教えいたします😄
言うまでもないと思いますが、デザインレビューで「人格攻撃」や「否定から入る」のはNGです。
デザインレビューで大切なのは、主に以下の3つだと僕は考えています。
・利益の追求
・言語化
・信頼
大抵の場合、「利益の追求」「言語化」が出来ていなくて、お互いの信頼関係だけで抽象的なレビューをしているから、事故が起きている気がします。
自分のデザインが「どんな利益を生むか」を把握し
どこをレビューしてほしいか「言語化」する
これがみんな足りていないのです。
利益を言語化したものが「KPI」です。
つまりこれは、KPIを理解せずに作業している人が、多すぎるということです😰
レビューまでのフローをPDCAで整理してみる
プロダクトというのは、いくつもの工程を挟んで世の中にリリースされます。
デザインレビューとは、その工程の一環です。
基本的にプロダクトとは、「仮設検証の繰り返し」を行っていきます。
仮設検証しつつプロダクトを伸ばしていくには、自分が担当している工程が、PDCAでどの部分を担っているのかを把握するのは、非常に重要なことです。
一般的なデザインのPDCAサイクルは、
1. Plan = 仮説を出す
2. Do = デザインを作る
3. Check = 成果物を確認する
4. Act = 施策の効果を確認する
となります。
デザインレビューは、3番目の「Check」の工程になります。
このPDCAには、各工程で重要な指標となるものがあります。
具体的には、以下の通りです。
1. Plan = 仮説立案
2. Do = 生産性
3. Check = 定量的な効果観測
4. Act = 結果の分析
つまりこれは、Checkの工程である「デザインレビュー」は、評価軸となるものは必ず「定量的なものでなければならない」ということです。
そうしないと、Planの工程で出した仮説を検証できなかったり、Actの段階で正常な結果の分析ができなくなります。
にもかかわらず、みんな「定性的」で「抽象的」な意見しか言わない。
だからうまくいかないのです。
---以下がダメなレビューの例です---
Aさん（レビューされる人）
すいません、ここのボタンを見てください
Bさん（レビューする人）
うーん、なんかいけてないね。もうちょっとここ作り込めない？
みなさん、どこがダメだかわかりましたか？
Aさん：ボタンの何をレビューしてほしいか「言語化」できていない
Bさん：デザインを変えて「どんな利益が期待できるか」説明できていない
ざっくりいうと、こんな感じです。
---以下がいいレビューの例です---
Aさん（レビューされる人）
ボタンのクリック率を上げるために、影を入れて文字を少し大きくしました。
いかがでしょうか？
Bさん（レビューする人）
いいですね。
今別の施策を走らせているから、1週間後にテストしましょう。
この場合、Aさんが、
利益となる「クリック率」を上げるために
ボタンの影を入れて、文字を太くしたと「言語化」した
と説明できているので、Bさんは特に気になることもなく、今走らせている施策の次に、Aさんのデザインを試してみようという判断ができました。
抽象的なことを具体化させる3つのコツ
ここから、デザインレビューで大切な、抽象的なことを具体化させるコツを、3つお話しいたします。
それは、主に以下の3つです。
「KPI」を理解する
「スコープ」を定める
「文章力」を高める
です。
以下に詳しく解説いたします。
---
「KPI」を理解する
KPIを理解せずに作業する人が多いというのは、冒頭でも説明した通りです。
KPIとはつまり、「定量評価できる目標」と言い換えることができます。
つまりKPIを理解していないとは、「そもそも何のためにデザインを作っているのか、理解していない」ということと同じです。
作業に着手する前に、必ずKPIを理解しましょう。
そうすれば、
何のために作るデザインなのか
作った後どのように使われるのか
どうやって「仮設検証」をするのか
がわかります。
上記が分かれば、レビューを依頼するときに、デザインの意図を説明しやすくなるはずです。
---
「スコープ」を定める
デザインとはほぼ必ず、「何らかの仮説を検証するために」作られます。
つまり、必ず「作る目的」があるわけです。
レビューをするなら、その目的を達成できるかどうか、スコープを定めて行いましょう。
スコープがブレると、前提の仮説が崩れてしまうので、仮設検証をすることができなくなります。
「デザインを変えたけど、効果が出ているかどうかわかりませんでした」となるのは、目に見えています。
例えば求人サイトを運営していて、KPIが「応募数の増加」だとしたら、
---以下がダメなレビューの例です---
後で求人を見た後に応募してほしいから、「お気に入り」のボタンをもっと大きくできないかな？
---以下がいいレビューの例です---
応募数を増やしたいから、「応募する」ボタンをもう少し大きくできないかな？
違いがお分かりでしょうか？
ダメなレビューの場合「お気に入り」に求人を溜めて、そこから応募してもらおうという考えかもしれませんが、
・お気に入りに入れた求人が、応募までいくとは限らない
・「お気に入り数増加」と「応募数増加」は、全然スコープが違う
・「お気に入り」に求人が入れられたら、応募数が増加するかは、別で仮設検証しないとわからない
という感じで、「応募数増加」というスコープから、ずれたレビューをしてしまっています。
---
「文章力」を高める
知的労働であるIT技術者の場合、テキストで会話することが非常に多いです。
レビューもテキストでお願いすることになると思います。
ということは、「文章力」を上げると、お互いにレビューがしやすくなります。
文章力を高めるには、
本を読む
文章を書く
の2つしかないです。
本を読むのもいいですが、一番効果的なのは、「文章を書く」です。
アウトラインを考える
これは仕事の進め方になりますが、着手する前は必ず「作業のアウトライン」を考えましょう。
つまり、事前にどんなタスクをこなすのか、想像しつつ作業を進めるということですね。
これができる人とできない人では、仕事のスピードに雲泥の差が出ます。
以下に、作業のアウトラインを考える人と考えない人での、仕事の進め方の例を書きます。
---アウトラインを考えない人---
今日はPush通知でアンケートを送るタスクをこなそう。
なら、まず文章から考えないとな。
こういう感じですね。
これ、仕事の進め方としては完全に遠回りです。
---アウトラインを考える人---
今日やる予定のPush通知でアンケートを送るタスクだけど、
まず「いつ送るか」が書いてないし、ユーザーへのメリットも決まってないし、自動で送るか手動で送るかも決まってないな。
企画側に相談して、まずこれを決めてもらうか。
みたいな感じですね。
着手する前に、実際の作業をイメージして、まだ企画が決まっていないものを定義しています。
アウトラインを考えないやり方だと、企画で決まっていない項目があるので、着手した後間違いなく手戻りが発生します。
仕事をしている人は、みんな忙しいのです。
1から10まで指示を事細かに出している時間はありません。
だからこそ、着手する前にアウトラインを考えて、足りないことを補間しながら作業を進めるのです。
これができないから、「言われたことしかできない人は使い物にならない」と言われるのです。
アウトラインを考えると、必ず着手前に「施策のKPI」を理解することができます。
レビューする際にKPIを理解することが大切なのは、先ほど語った通りです。
本は役に立たない
文章力を高める方法に、「本を読む」と書いておいて恐縮ですが、
レビュースキルの場合大抵の本は役に立ちません。
デザインレビューに関する本は、いくつかあります。
例えば、こちらの本とかですね。
なぜ役に立たないかというと、「アウトプットのやり方までは教えてくれないから」です。
つまり、「抽象的なことしか書いていない」ということです。
スキルを習得するには、以下の2つの工程を挟みます。
1. 知識を吸収する
2. アウトプットをする
本を読めば「1. 知識を吸収する」はできますが、大体の本は「2. アウトプットをする」まで考慮して設計されていません。
「知っている」のと「できる」のでは、実現難易度に雲泥の差があります。
ちなみに上記の本の内容は、端的に訳すと
→クリティカルシンキング（批判的思考）をもつ
です。
クリティカルシンキングは、レビューを行う上でもとても大切なことです。
仕事のアウトラインを考える際にも、とても役に立ちます。
上記の本は、どちらかというとPM向けですね。
「みんなではじめる」とある通り、一人ではできないことが多く書いてあります。
一人一人のレビュースキルが足りないのに、チーム戦の技法を取り込もうとしても、うまくいかないでしょう。
デザインレビューでのアウトプットのやり方は、「抽象的なことを具体化させる3つのコツ」で説明した通りです。
復習のために、もう一度こちらに書きます。
1. 「KPI」を理解する
2. 「スコープ」を定める
3. 「文章力」を高める
自分の好きなサービスのKPIを考えると、レビュースキルが鍛えられる
気が僕はしています。
例えば僕は、Netflixでいつも動画を見ているので、休眠会員の解約サポートキャンペーンのKPIを考えたりしてました。
好きなサービスの裏側にある意図を考えて、
なぜこの施策を行ったのか？
なぜこのデザインなのか？
どんな戦略を展開しているのか？
という抽象的なことを考え、自分で具体化させていく訓練は、レビューする方される方両方にとって、とてもいい訓練だと僕は思います。
まとめ
まとめますと、
・レビューの悩みは、抽象的なものを具体化できてないから起きる
・具体化できないのは、アウトプットのやり方を知らないから
・デザインレビューで大切なのは、「1. 利益の追求」「2. 言語化」「3. 信頼」
・レビューのコツは、「1. KPIを理解する」「2. スコープを定める」「3. 文章力を高める」
・本も内容が抽象的なので、レビューという観点では役に立たない
・自分の好きなサービスのKPIを考えると、レビュースキルが鍛えられる
以上になります。
レビューって難しいですね。
する方もされる方も。
僕もレビューする立場になって、「意図をうまく伝える」というのが結構難しいなぁと感じています😅
そういえば、元メルペイのデザイナー「スワン」さんが独立して、YouTuberになってましたね。
勉強のために僕もスワンさんの動画を、これから観ようと思います😀
仮想通貨の会社にいたこともあるので、改めてお金について勉強します💰
ではでは、またね〜🤗
この記事が気に入ったらサポートをしてみませんか？