見出し画像

UIデザイナーがデータ分析について勉強してみた

会社にはデータを見る専門の人、いわゆるDX専門の人はいないのですがいろんな部署で「データちゃんとみれるようになろう!」という気運が高まっているのを最近ひしひし感じます。
自分の業務でも、UXデザインにデータを活かしたい。難しい統計学ではなくデータ分析の基本の考え方についてまずは勉強してみました。

前提:データ分析のタイプ

まずは一口にデータ分析といってもどういうジャンルがあるのか調べました。データアナリストのレイさんのnoteの記事がとても参考になりました。データ分析にも様々な方向性や分野があるそうです。

・サービスグロースに強いデータアナリスト
・インフラ整備に強いデータアナリスト
・UXデザインに強いデータアナリスト
・マーケティング調査に強いデータアナリスト
・AIや予測モデルに強いデータアナリスト(こちらはデータサイエンティストの領域になりですが)

未経験からデータアナリストになった私が取り組んだ10のコト より

私が携わるプロダクトの開発の現場に必要なのは「UXデザインに強いデータアナリスト」になりそう。

どのタイプでも共通する大事な考え方と手順

先述の記事の中でどのタイプでも共通で必要なコアとなる考え方として紹介されていた、問題解決・分析に関する本を読みました。

データから仮説を立てるのではなく、仮説→データ

「まずデータを見る」をやめようデータの中に答えなんかないとはじめに書いてありました。
最初に問題(目的)を明確にし、その要因について仮説を立て、それをデータで検証し、方策を立てることで課題解決につながります。

問題解決のためのデータ活用のプロセス

  • (表面的な現象)

  • 1.目的・問題の定義
    現象、なんとなく思いついた方策、要因、を切り分けて考え、本来の問題(目的)を定義する。目的・問題が明確になったらそれに沿った指数は何か考える。

問題、要因、方策を整理する。案外ポテトチップス以外の要因が大きい可能性も・・・また栄養バランスや意志の弱さを問題とすべきシーン場合も考えられます
  • 2.現状を把握して評価する
    事実や結果のデータを見て「現状把握」の解像度をあげる。
    「評価」のために必要なのはズバり比較。どの尺度で評価するかによって結論は変わるので「どれが正解なんだろう?」は捨てる。複数の尺度で見ると立体的に評価できる。

  • 3.要因を特定する
    ロジックツリーなどを用いて要因候補を挙げて(仮説を立てる)、それぞれの指数を特定し、データ上で相関があるか確認する。

  • 4.それに対する方策を考える

方策は要因に対して行わないと意味がない。
斬新なアイディアを考えると ロジカルに考えるは違う。
  • 5.実行する

  • 6.実施後の効果測定

参考にした本はこちらの2冊。とってもわかりやすい。
どちらかだけ読むなら1冊目がおすすめ。データ分析以外にも課題解決全般の手助けになる内容でした。2冊目はデータの扱い方の実例が多め。


どっちが大切? デザインリサーチ(定性調査)とデータ分析(定量調査)

デザイナーといえばデザインリサーチ。これはインタビューやユーザーをじっくり観察するような定性調査のことです。データ分析(定量調査)とどちらが重視されるべきなのでしょうか?社風や事業形態によるのかなぁ。
という漠然とした疑問を常々抱いていたのですが、色んな事例や書籍を読むと以下のようなやり方で2つを掛け合わせていました。

デザインリサーチでヒントを得る→データ分析

  • データがない、数値化しにくいものをインタビューやコメントからよみとる

  • 仮説を立てたり優先度をつけるため、まずは数人にインタビューをとる

  • インタビューをもとにデータ分析に用いる指数やアンケートの項目を決め、その調査結果を定量調査にかける

データ分析→デザインリサーチで確かめを行う

  • データ分析から求められた結論をもとに現場関係者やターゲット顧客へのヒアリングを行い乖離がないか確認する

  • 分析をもとにした方策の効果を測定するために数人のユーザーでテストをしてもらう

どっちが重要か、正確か、ではなくデザインリサーチとデータ分析を両軸で回していくことが大事みたいです。

↑書籍以外にこの記事もすごく参考になりました。方向性や課題の優先度づけなど、色々な調査の仕方と改善プロセスがイメージできました。


プロダクト開発に特化したフレームワーク

前職で携わっていたWEB集客やECサイトなどは分析のフレームワークやキーとなる指数がありましたが、SaaS系のプロダクトの分析にもそういう手法や考え方があるのではと調べてみました。

ノーススター・メトリック North Star Metric(NSM)

企業の最終的な目標となりがちな「売り上げ」からブレイクダウンしてKPIを設定していくと、ユーザーの「プロダクト体験」の評価が抜け落ちてしまいます。
そこで、プロダクトが目指すユーザーの成功に関係が深い指数をNSMとして定義し、そこからKPIを設定してプロダクト開発に活かすというものです。
DropboxやFacebook、Uberなどで採用されてるとのこと。

NSMの決め方

プロダクトはタイプ別に以下の3つに分類され、NSMもそれぞれにあったものになります。

  • Attention
    より多くの「時間」をプロダクトに費やしてもらう
    プロダクト例: Facebook、Netflix
    NSM案:コンテンツ再生時間、月10時間以上滞在したユーザー数

  • Transaction
    商品購入など「トランザクション」をより多く実行したもらう
    プロダクト例: Airbnb、amazon
    NSM案:商品購入回数、マイル獲得回数

  • Productivity
    より多くの「タスク数」を効率的に実現してもらう。
    プロダクト例:salesforse、Adobe
    NSM案:レコード登録数、ファイル作成数

KPIの設定

NSMを因数分解して「広がり」「深さ」「頻度」「効率」の4軸でKPIを設計します。するとそれぞれのKPIによって対応する機能を評価することができるようになり、必要な新規機能や改修が見えてくるというわけです。

期待できる効果

  • サービス成長のための本質的なKPIの設定が可能になる

  • 追うべき指数が明確になり、チームで共通認識を持って取り組める

  • 無意味な開発・分析に割いていた工数の削減になる

自社プロダクトについてWAUやDAUなどTransactionタイプの数字を今は重視しています。パッとみたかんじ自社プロダクトはProductivityのタイプに該当しそうに感じました。AU数は継続率→事業収益に大きく影響しそうなのでもちろん重要ですが、開発チームとしてはProductivityの視点を持ってもいいかも。
NSMを設定するにはビジョン、顧客価値、事業収益それぞれの視点がいるようなので設計はそう簡単ではなさそう。今のチームでNSMのワークショップとかできると理解が深まりそうです。

参考にしたページ


背景とまとめ

きっかけは、自己流データ分析での反省

実は勉強の前にとりあえずまずはやってみよう!と、プロダクトの各画面のトラッキングデータや利用ログなどすぐ見れるものをワーっと見てみました。気になるところはセグメントを絞ったして、それなりに「ふむふむ」「意外とこっちが使われてるんだー」とか気づきはあったのですが、以下のような結果に・・・

  • 自分の分析手腕にも自信がないため「〜な傾向がありそう」くらいにしか言えなかった

  • とりあえず直近の期間を参照したが、プロダクト的にシーズンオフに該当する期間が含まれていたため参考にならなかった

  • 読み取れるものは沢山あるように見えたが、今すぐ解決したい課題の答えは見つからなかった

どうしたら有益なデータ活用ができるのだろうか・・・そこで色々調べ始めました。勉強してから振り返るとまさにとりあえず手元のデータを開いて思いつきの仮説を並べていました。

職能関係なく活用できると便利

データ分析は敷居が高そうに感じますが、今回勉強してみて、数字に強くなく難しい計算方法を知らない私でも、プロダクトの課題解決にデータを活用できるイメージが持てました。

認識のズレが起きにくかったり、説得力をもたすことができたり数字は言葉にはない利点があります。
同じデータでも見る人ごとの尺度や持っている課題によって、違う見解や気づきを得ることができるでしょうし、さまざまな立場の人が数字を挟んでディスカッションできるようになると分析もより立体的で有意義になるはずです。



この記事が気に入ったらサポートをしてみませんか?