検索結果0件」

    デザインレビューで悩んでいる人へ、コツを教えます【抽象化→具体化がカギ】

    2020/06/07
    デザインレビューで悩んでいる人へ、コツを教えます【抽象化→具体化がカギ】

    こんにちは、シンヤです!

    今回は、デザインレビューで悩んでいる人へ、コツを教えます【抽象化→具体化がカギ】というテーマで、お話しいたします。


    大抵の悩みは「抽象化→具体化」が出来ていないから起こる

    結論から言いますと、大抵の悩みは「抽象的な考えを具体化できていない」から起こります。
    わかりやすく言うと、「何に悩んでいるのか言語化できない」から悩むのです。

    頭の中にモヤモヤした霧みたいなのがかかっていて、気持ち悪くなったことはありませんか?
    それです😁

    それは「デザインレビュー」でも同じです。

    • 何のレビューをお願いすればいいか分からない
    • お願いの仕方がわからない
    • デザインの意図をうまく伝えられない

    こんな感じですかね。
    デザインレビューでありがちなお悩みって🙂

    つまり全部、

    抽象的な考えを具体的に相手に伝えられない

    からこそ起こる悩みです。


    みんなアウトプットの仕方を知らない

    これは個人的な考え方ですが、日本の学校教育ってインプットに偏りがちで、アウトプットの方法を教えてくれなかった気がします。
    とにかく「頭に詰め込め」的な教育ですね。

    デザインレビューとは、相手に自分の意図を伝える「アウトプット」です。
    抽象的な課題を、相手に具体的に伝える技術が求められます。
    ですが、アウトプットのやり方をみんな教わっていないので、抽象的な考えを具体的に相手に伝える方法を知らないのです。

    大体ここで、事故が起きる気がします。
    つまり、「意図を正確に伝えられていない」ということですね😌


    デザインレビューで大切な事3つ

    つまり、適切なアウトプットができればいいわけです。

    そんな方法知っていたら苦労はしないかもしれません。
    安心してください、ちゃんとしたレビューの方法をお教えいたします😄

    言うまでもないと思いますが、デザインレビューで「人格攻撃」や「否定から入る」のはNGです。

    デザインレビューで大切なのは、主に以下の3つだと僕は考えています。

    • 利益の追求
    • 言語化
    • 信頼

    大抵の場合、「利益の追求」「言語化」が出来ていなくて、お互いの信頼関係だけで抽象的なレビューをしているから、事故が起きている気がします。

    • 自分のデザインが「どんな利益を生むか」を把握し
    • どこをレビューしてほしいか「言語化」する

    これがみんな足りていないのです。

    利益を言語化したものが「KPI」です。
    つまりこれは、KPIを理解せずに作業している人が、多すぎるということです😰


    レビューまでのフローをPDCAで整理してみる

    プロダクトというのは、いくつもの工程を挟んで世の中にリリースされます。
    デザインレビューとは、その工程の一環です。

    基本的にプロダクトとは、「仮設検証の繰り返し」を行っていきます。
    仮設検証しつつプロダクトを伸ばしていくには、自分が担当している工程が、PDCAでどの部分を担っているのかを把握するのは、非常に重要なことです。

    一般的なデザインのPDCAサイクルは、

    • Plan = 仮説を出す
    • Do = デザインを作る
    • Check = 成果物を確認する
    • Act = 施策の効果を確認する

    となります。
    デザインレビューは、3番目の「Check」の工程になります。

    このPDCAには、各工程で重要な指標となるものがあります。
    具体的には、以下の通りです。

    • Plan = 仮説立案
    • Do = 生産性
    • Check = 定量的な効果観測
    • 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つのコツ」で説明した通りです。
    復習のために、もう一度こちらに書きます。

    • 「KPI」を理解する
    • 「スコープ」を定める
    • 「文章力」を高める

    自分の好きなサービスのKPIを考えると、レビュースキルが鍛えられる

    気が僕はしています。
    例えば僕は、Netflixでいつも動画を見ているので、休眠会員の解約サポートキャンペーンのKPIを考えたりしてました。

    好きなサービスの裏側にある意図を考えて、

    • なぜこの施策を行ったのか?
    • なぜこのデザインなのか?
    • どんな戦略を展開しているのか?

    という抽象的なことを考え、自分で具体化させていく訓練は、レビューする方される方両方にとって、とてもいい訓練だと僕は思います。


    まとめ

    まとめますと、

    • レビューの悩みは、抽象的なものを具体化できてないから起きる
    • 具体化できないのは、アウトプットのやり方を知らないから
    • デザインレビューで大切なのは、「1. 利益の追求」「2. 言語化」「3. 信頼」
    • レビューのコツは、「1. KPIを理解する」「2. スコープを定める」「3. 文章力を高める」
    • 本も内容が抽象的なので、レビューという観点では役に立たない
    • 自分の好きなサービスのKPIを考えると、レビュースキルが鍛えられる

    以上になります。

    レビューって難しいですね。
    する方もされる方も。
    僕もレビューする立場になって、「意図をうまく伝える」というのが結構難しいなぁと感じています😅

    そういえば、元メルペイのデザイナー「スワン」さんが独立して、YouTuberになってましたね。
    勉強のために僕もスワンさんの動画を、これから観ようと思います😀
    仮想通貨の会社にいたこともあるので、改めてお金について勉強します💰

    ではでは、またね〜🤗

    • デザインレビューで悩んでいる人へ、コツを教えます【抽象化→具体化がカギ】

    広告