デザイナーがサイト問題発見でつまずいたこと 67717374：PIXTA , 56725716：PIXTA

こんにちは、デザイナーの海田です。

ピクスタのデザイナーは、職種に関わらず手広く業務に携わることが多く、私もUIデザイナーでありながら、サイトの改善案の立案を行っています。

分析や改善案立案は、ピクスタに入って初めて行いました。「サイトの分析を行う、それを元にサイト改善案を作る」と一口に言っても工程が多いし、分析スキルは短期間で身につくものではありません。正直、「かなり苦戦しながら、ゆるやかに上達している」という実感があります。

私はサイト改善案作成を以下のプロセスで行っています。

問題を発見する
課題を抽出する
解決策を考える
資料にまとめてチームに共有する

その中でも特につまずいたのが「問題を発見する」パートでした。今回はこのパートを中心に、つまづいたことと学びを、当時の自分に教えるつもりで振り返ろうと思います！

問題発見でつまずいたこと

まず、どこから問題を探せばいいかわからなかった

問題発見をするにあたって、まずぶち当たった壁。問題をどこから探せばいいのかわかりませんでした。

結果、仕方なく目につく問題から探そうとしました。サイトを見たり、GAを覗いて何かわかることはないかと探したり。

確かにこれでも問題は発見できなくもないのですが、時間がかかります。しかも、見つけた問題は「今やるの？」と言いたくなるような重要性に欠けたものだったり、些細なものばかりでした。

👍 KPIツリーから探すと大きな問題を発見できた

KPIツリーから探すと大きな問題を発見できた

チームで運用しているKPIツリーから探すことで、大きな問題を発見できるようになりました。

KPIとはKey Performance Indicator の略であり、「重要業績評価指標」の意味を持ちます。そもそも業績をアップさせるための指標なので、問題発見にもこれを使わない手はありません。

また、KPIツリーはサイトの健康診断だと上司に教わりました。例えば、体が不調になった時、原因がわからないまま闇雲に薬を飲んでも健康にはなれませんよね。健康診断した上で、問題を特定し、適切な処置を行うと思います。サイトも同じでした。

現在、私がKPIから問題を探す時の手順は以下になります。

KPIを見て目標値に達しているか確認
達していない項目があればボトルネックはどこかを探す
その原因は何であるかを考え、仮説を立てる
サイト、GA、SQLなどを確認し、仮説検証する

問題の仮説を思いついたらすぐにGAを確認した

問題の仮説が思いつき次第、すぐにGAを確認する癖がありました。合っているのか、間違っているのか、早く確かめたくて仕方ありません。

しかし、自分のワーキングメモリーは限られており、多くの仮説を頭にとどめておくことができません。仮説が合っていればいいのですが、違っていた場合や、複雑な操作をした後、自分が何をしていたかを見失いがちです。

👍 仮説を作ったら、まず文章に起こす。できれば、どの数値によってその仮説が立証されそうか？までメモした上でGAを見ると、迷子にならなくなりました。

仮説を作ったら、まず文章に起こす。

GAを見ると、色々なことがわかります。時にはエラーを発見し、その特定を優先させなければいけない場合もあります。

メモがあれば、そんな時でも自分の思考にすぐ戻ることができます。仮説を作ることと検証することとを分けて行動するとフローが改善することができました。

問題の仮説が出せず、途方にくれることがあった

問題の仮説を考えたい場面で、自分のイマジネーションに頼っても何も思い浮かばず、途方にくれる事がありました。

👍 このような時は、「なぜユーザーはこの行動をとったのか？」の理由を分解することで、解決の糸口を得られます

例えば、バナーのクリック率が悪かった場合を考えます。

「バナーをクリックしなかったユーザーは、なぜバナーをクリックしなかったのか？」の理由を簡単に分解すると、以下のようになります。

理由の分解

さらに、その理由を更に深ぼるとこのようになります。

理由の分解

このように理由を分解していくことで、気合や運に頼らずとも、楽に問題の仮説を出すことができます。

今回の例では、４つの仮説を考えることができました！

「バナーをクリックしなかったユーザーは、なぜバナーのクリック率が悪いのか？」
1. バナーに気付いていないから
2. バナーに気付いているが、理解をしていないから
3. バナーに気付いていて理解もしているが、メリットが伝わっていないから
4. バナーに気付いていて理解もしていて、メリットも伝わっているが、興味が沸かないから