『UX戦略 ――ユーザー体験から考えるプロダクト作り』を読んで、自分のサービスの失敗経験をまとめてみた

このエントリーをはてなブックマークに追加
CurioCityという、趣味で作った論文共有サービスをリリースしたのですが、なかなかよいユーザー体験を提供できないと悶々としておりました。

たまたま見つけた、『UX戦略 ――ユーザー体験から考えるプロダクト作り』という本を買って、自分のプロダクトづくりの失敗点と、改善点を明確にするために反省点を忘備録として書いておきます。



ちなみにCurioCityのそもそものコンセプトは、「学部生、院生が書いた論文を読みたいユーザーが、ネット上にアップロードされた論文を読み、オモシロかったら著者に出会えるサービス」でした。




1. ユーザーテストで得られた課題を無視していた。

このサービスは、「論文をアップロードしてくれる人」と、「論文を読みたい人」をユーザーとして、最初に想定していました。

ところが、最初のユーザーテストの段階で、論文をアップロードすることにためらう人が多かったのです。「自分の論文なんて稚拙だから、アップロードしたくない」という人が多かったのです。

サービスその後、サービスをリリースした後に、一部の方を除いて、学部生の自発的な論文アップロード数が伸び悩んでおりました。

この原因として、サービス作成者が検証をした事実を認めずに、直観だけで突き進んでしまったことに大きな問題があったのかなと思います。

一度サービスのモックアップを作成した段階で、実はかなり作りこんでしまったせいで、「人は論文をアップロードしたい」という仮説が違うということを、これだけの投資時間を0からやり直すのはもったいないという心理が働いてしまい、後戻りできない状況になってしまったことなのかなと思います。
サンクコストに弱い男です汗

2. ユーザーのペルソナ、ゴールとニーズを鮮明に把握していなかった。

このサービスは本来、論文をアップロードするユーザーと、論文を見たいユーザーの二つのペルソナを想定してサービスを考えるべきだったのですが、論文を見たいユーザーのみにフォーカスが当たっていて、アップする側のペルソナを考えていなかったのかと思います。ユーザーの姿が見えないから、サービスリリース後の改善策がわからない。なぜ人は論文をアップロードするのか、そういう動機が見えていなければ、何もできないことに気づきました。ペルソナが二つ必要だったんですね。

UX戦略には、ユーザーのプロフィール、ライフスタイル、ニーズとゴールを最初に複数定義し、インタビューを行うことで、需要があるかどうかを調査すべきで、もしユーザーにサービスが提供するだろう価値にニーズを持っていなければ、考え直すべきだと書いておりました。

自分の中ではちゃんとテストしたつもりだったのですが、問題はユーザー調査のデザインだったのかと思います。調査の結果が意味のあるデータになるようなデザインにできていなかったというか。また対象も間違っていたというか。

それは、事前に仮説をもって、ユーザーに対してインタビューできていなかったことにつながるのかと思います。

3. サービスは構想段階がすべてで、それがしっかりしてないとどんな機能を入れても意味のないものになる

総じて、今回の一番の課題は、だれにとって、どのような価値が、どのような手段によって得られるのか不鮮明だったことでした。
ユーザーが誰か、ユーザーの課題は何か、何ができればゴールなのか、を明確にしていないため、進むべき方向性がわからないまま、無駄な機能拡張が続いてしまったのだと思います。

「サービスは構想段階が命」と言われていて、「当たり前だろ」と思っていても、いざ自分がサービスを作ろうとすると、自分の確信に対して疑問の目を向けることが難しいことをひどく痛感しました。ゴールが見えない→サービスに不安感が積もる→無駄なサービス拡張をする→もっとダメなプロダクトになる→焦るみたいなプロセスになるんですね。

4. 競合サービスもちゃんと見る

収益性の確保はそこまで考えていなかったので、競合サービスを見る必要はないかなと思っていたのですが、あるコアとなるUXをどのような機能を実装して達成しているのかは、参考にすべきだと思いました。UX戦略では、競合サービスのUXをスプレッドシートで比較して、どのサービスは何が強くて、何が弱くてということを表にしてまとめています。
また、インフルエンサーという、直接は競合しないけど参考になるリストも作って、機能面を掛け合わせて付加価値を生み出すということもやっております。

5. 早めに失敗して、ピボットする

最初の「論文をアップロードしたくない」という事実を見て、ピボットすべきでした。論文をアップロードしたいのは、誰なのか。学部生のままでいいのか等議題に含めるべきでした。リリース後に論文をアップロードしてくれる人は院生が多かったので、例えば院生を対象にすべきなのか等です。失敗という事実からなるはやでピポットして、サービスの方向性に整合性を持たせるべきでした。一回リリースしてしまうと結構ピボットが大変なんですよね。

6. キーとなる体験を定義する

ユーザーにとって、このサービスを使ってどんな経験ができていればよいのかを、二つのセグメント(論文をアップする人+論文を見る人)をもっと言語化すべきでした

7. ストーリーボードを作成する

どんなフローでユーザーが優れたUXを得られるのか、わかりやすく図式化できていればよいなと思いました。これやってたら広告とかでもいい感じだろうし。

8. ファネルマトリックスを作成する

ペルソナ決めて、UX定義したら、今度はサービス内での具体的な行動指標を取るべきだったのかと思います。ファネルマトリックスには、縦軸にユーザー定義、横軸にユーザーの工程、期待される行動、ビジネス上の課題、測定指標、要求機能、検証によってわかることを記入します。

ユーザーの定義
- 潜在顧客:サービスが必要かもしれないユーザー
- 見込み客
- 顧客予備軍
- 販売顧客
- 常連客
- 推薦者
ユーザーの工程
期待される行動
ビジネス上の課題
測定指標
要求機能
検証によってわかること

まとめ

「構想くそなサービス作るやついんのかよ」とおもってたんですけど、自分がサービス構想から開発までやってると、どうしてもサンクコストが働いてしまうため、仮説が正しいのかを常に自分にCritical thinkingする必要があるなと強く思いました。無駄な機能拡張を止めるためには、何よりもまずサービス構想からUXを考えるべきだと思いました。



おすすめ記事


CurioCityというICU生向けアカデミックSNSをリリースしました。

0 件のコメント:

コメントを投稿