ユーザーの声を集めてデザインすることの難しさ
お久しぶりです。くれちょんです。 前回ブログを更新してから半年…時が過ぎるのは速い…。
今回、Fablic, IncのAdvent Calendar 4日目を担当させていただけるということで先日弊社で開催したカレーのイベントでのLT発表内容をこちらにまとめてみました。
ユーザーの声を集めて開発する
ぼくが今開発に取り組んでいるファッションフリマアプリ FRILでは、ユーザーの声を起点にしながら問題解決となるデザインを進めています。サービスを始めるときには100人の女性ユーザーにヒアリングしてから開発に臨んだり、アプリ内から募集した40名近くの元フリルユーザー・カスタマーサポートスタッフと開発者が気軽にコミュニケーションできるような環境があったり。社内だけでもたくさんのユーザーの声に溢れたサービスになっています。
いつでもユーザーにインタビューができるような、デザイナーが活躍する場としてとても恵まれた環境にいるわけですが、そういったたくさんの意見を拾い集める中で困ったことがありました。
『もっと速い馬が欲しい』問題
ユーザーから問題点や解決策はたくさんあがってきますが、もちろんユーザーもサービス開発のプロではないのでその解決策よりももっと良い解決策があるかもしれませんし、逆にそれをそのまま採用してしまったら困るユーザーが出てくるかもしれません。
また、「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬が欲しい』と答えていただろう。」というようなフォードの有名な話もあったりで、ユーザーの声をただ聞いているだけだとユーザーが本当に求めているものは実現できず最終的にはつまらないサービスになるんじゃないのか？といった懸念もあると思います。
火のないところに煙は立たない
なぜ速い馬が欲しいと答えてしまうのか、本当に求めているものを実現できないのか。そもそもユーザーはなぜ自らが感じた問題を伝えようとしているのか。たくさんのユーザーの声を聞く中で気付いたのは、ユーザーの意見要望はほとんどの場合、問題解決まで進行してしまっていることでした。
問題解決は問題定義に基づく
まずデザインの問題解決のプロセスは、
- 問題発見…問題に気付く（ユーザーの声を集める）
- 問題定義…問題が何であるかを考える（あるべき姿と現状との差を認識する）
- 問題解決…問題を解消する方法を考える（よりよい形をデザインする）
というような発見・定義・解決の流れで進行していきます。
つまり、「速い馬を作ろう」と判断してしまう原因である「もっと速い馬が欲しい」を問題定義ではなく問題発見と捉えることで、ユーザーがなぜそう思ったかを起点に新たな問題定義が生まれ、より本質的な問題定義に近づいたり馬以外の方法でそれを解決できるような柔軟性を持たせたりできます。
ユーザーの期待を超える
ぼくはユーザーファースト開発における問題定義は問題解決プロセスのなかでも一番重要なステップだと思います。問題定義がしっかりしていれば、どれだけしょぼい解決策でも前に進めますし、逆に言うと問題定義が間違っていたらどれだけイケてる解決法も前に進めないと思うからです。
ユーザーの声を聞くことはとても重要ですが、ユーザーが訴える言葉を鵜呑みにせず、その証言を起点に適切な問題定義をしてあげることで、ユーザーが思ってもいなかった期待を超えるデザインを提供できるようになるのかなと思います。
ちなみに件のLTではご紹介できなかったのですが、ぼくがこう考えるようになったのはライト、ついてますか―問題発見の人間学という本がきっかけでした。問題とは何なのか、それはだれの問題なのかという問題解決における問題発見にフォーカスをあてた本で、問題解決を仕事とするデザイナーさんにはぜひおすすめしたい一冊となっております。
共立出版
売り上げランキング: 47,036
