「ユーザー課題」ってなに?3つのパターンと見つけ方

使いやすいデザインの第一歩は課題を定義すること

Erika Ito
Product Run
9 min readJun 28, 2018

--

Pivotal Labsでは、ユーザー中心設計とデザイン思考を使ってプロダクトのリサーチやデザインを進めています。毎回プロジェクトによって業界やビジネスの形態は異なりますが、どんなプロダクトでも機能を作り始める前に、必ず「ユーザー課題の定義」から始めます。解決したい課題がはっきりしていると、「誰がどんなときにそのプロダクトを使うのか」が明確になり、「本当に必要な機能」をデザインすることができるからです🚀

ユーザーの課題は、主にデプスインタビューをする中で探していきますが、解決するべき課題を見つけるのは意外と難しい作業です🤔

そこで今回は「ユーザー課題」のパターンを3つ、具体例と一緒に紹介します。今後ユーザー課題を探す際、参考になると嬉しいです😎

「ユーザー課題」3つのパターン

  1. ユーザーが自覚していて、何かしら対処している課題
  2. ユーザーが自覚しているが、諦めている課題
  3. ユーザーが自覚していない課題

では、詳しく見ていきましょう!

1. ユーザーが自覚していて、何かしら対処している課題

これは、一番見つけやすく、比較的解決もしやすいタイプの課題です。その分、既にレッドオーシャン、もしくはすぐにレッドオーシャン化してしまう可能性が高いとも言えます。戦略とスピード感が、より大切になる領域ではないかと思います。

このタイプの課題であるサイン1
ユーザーインタビューの中で、ユーザーから「ここが面倒臭い」とか「ここの効率が悪い」などのコメントが出てきたとき。

このタイプの課題であるサイン2
あるツールを工夫して、本来の目的と違った使い方をしているとき。
(ユーザー自身は「ツール本来の目的と違った使い方をしている」と思っていない場合もあります。)

リサーチのコツ
ユーザーが「何を達成したいのか?」「何故そんな使い方をしているのか?」をよく観察し、さらに質問をして、ユーザーの思考プロセスまで理解するようにしましょう。そうすることで、より目的に合ったツールを開発することができるようになります。

具体例
Sketch:Web業界では、長らくPhotoshopでUIを作ることがスタンダードでした。当たり前のように使われていましたが、本来Photoshopは写真を加工するためのツールです。当時を振り返ってみると、「書き出し面倒だな。。」などと思いながらも、Photoshopをできるだけwebに適した設定に工夫して作業をしていました。そんな課題に目をつけたのがSketchですね。アセットの書き出しやすさやファイルの軽さなど、 UIデザインに最適化したツールにして、リリース直後からデザイナーの心を掴みました。

2. ユーザーが自覚しているが、諦めている課題

これも比較的見つけやすいですが、一つ前のタイプと比べると解決が難しい課題です。ユーザーが課題を自覚しているのに対処していないということは、ユーザーが1人で完結できない作業、もしくは技術的に解決がしにくい課題であることが考えられるからです。その分、良い解決策を提示できれば、ライバルが現れにくいとも言えます。

このタイプの課題であるサイン1
インタビューの中で、ユーザーから「そういう決まりだから、そうしている」や「なんでそうしているか分からない」というコメントが出てきたとき。

このタイプの課題であるサイン2
客観的に見て、明らかに非効率なもの。例えば、同じ作業を複数箇所で繰り返している、複数人が同じ作業をしているのに人によって進め方が違う、記憶に頼って作業を進めているのでよく間違いが発生している、などは良いサインです。

リサーチのコツ
対象ユーザーの作業だけでなく、全体の流れや登場人物を俯瞰して理解することがより重要になります。インタビューでは、流れの始まりから時系列に順を追って聞き出し、ユーザーの作業範囲は全体のどの部分なのか、また、流れの最終的なゴールは何なのか、を明らかにするように心がけると良いと思います。

具体例
クラウドサイン:「契約を結ぶ」というのはとても時間のかかる作業です。時間がかかる理由としては、まだ紙ベースでのやりとりが基本となっているからだと思います。ここまでネットが普及しているのに、なかなか紙から抜け出せないのは、おそらく登場人物が多いことや、法的な制約など、複数の要因が複雑に絡み合っているからではないでしょうか。多くの人が「非効率だな、、」と思ってはいるものの、個人レベルではどうしようも無い、という状態です。そんな課題を果敢に解決しようとしているのが弁護士ドットコム社のクラウドサインだと思います。おそらく、「何故、契約書が必要か」「契約作業はどんな流れなのか」についての法的な知見も生かして開発されたのではないかと思います。個人的に応援しているプロダクトの一つです。

3. ユーザーが自覚していない課題

ユーザーが「今使っているものがベストだし、改善したいとも思っていない」課題です。使ってみないと良さがわからないことが多いため、ただ解決策を提示するだけでなく、「これが必要だったんだ」「使ってみよう」と思わせるような「伝え方・広め方」まで先回りで考慮しながら開発を進める必要があります。

これは見つけるのも難しい、解決も難しい、市場に広めるのも難しい、、今回紹介した中で1番難易度が高い課題です。その分、世の中的に「イノベーティブだ」と言われるプロダクトは、このタイプの課題を解決したものが多いのではないかと思います。

このタイプの課題であるサイン
これは、前出の課題と比較しても分かりやすいサインが無いことが多く難しいのですが、人の行動を注意深く観察をすることがより重要になると思います。「他の業界や市場では解決できていることが手付かずでそのままになっている」ものは、このタイプの課題である一つのサインです。

また、自分の業界や得意分野とは全く違う世界に触れ、「それまで別々だったものを組み合わせたらどうなるだろう?」とか「この新しい技術はどうやったら活きるだろう?」などと思考実験を繰り返すと、ふとした時に非効率な部分に気が付いたり、それまでは技術的に解決が不可能だと思われていたことに対する解決案が浮かんでくるのかもしれません。

具体例
Amazon:インターネット技術の進歩に目をつけ、さらに、当時の人々が自覚していなかった課題を解決した良い例です。Amazonがリリースされた1994年以前にも「本屋に行ったけど欲しい本が売り切れだった」などの課題はあったはずですが、それが当たり前すぎて「家にいながら本を購入したい」と考える人はいなかったのではないでしょうか。

「使ってみないと良さが分からないもの」というのはこのタイプの課題を解決しているプロダクトに多くみられる傾向ではないかと思います。

課題の優先順位付けのコツ

今回は話をまとめるために、課題タイプをかなり単純化してまとめました。でも実際のプロダクト開発は、もう少し複雑です。具体的には、リサーチをする時期や人によって「課題自覚度」に差が出たり、1人の人が課題をいくつも抱えていていたりします。そのようにリサーチを通して課題がいくつも見つかった場合には、プロダクトの戦略を決めて、「どのユーザーのどの課題から解決するか?」の優先順位をつける必要があります。最後に、優先順位づけの際の軸となるポイントを2つ簡単に紹介します。

ターゲットユーザーの優先順位づけ
同じ課題でも、人によって「自覚度」が違うことはよくあります。(例えば、IT企業に務めていてパソコン操作に慣れている人にとって紙の契約書は「自覚している課題」だが、市役所に務めている人にとって紙の契約書は当たり前すぎて「自覚していない課題」、など。)どの層をターゲットとするかによって、解決策や広めかたの戦略は変わってきます。

道筋として、少数の「課題を自覚しているユーザー」をターゲットにして解決策を洗練させてから徐々に「課題を自覚していないユーザー」への広め方を模索していく方法が考えられます。
早めにターゲットユーザーを絞り、道筋を明らかにすることが大切です。

解決しやすさによる優先順位づけ
また、ターゲットユーザーを絞っても、その人たちが複数の課題を抱えている場合も多くあります。抱える課題の中にも、自覚しているものから自覚していないものまで、様々な種類がありえます。そういった場合、戦略として、まずは「ユーザーが自覚している、解決が簡単な課題」から解決していく、といった戦略が考えられます。

解決が簡単な課題から1つずつ解決していくメリットは、リリースまでの時間を短縮できることや、そこで得た学びを、より解決の難しい課題に活かすことができるところです。

まとめ

このように、リサーチをしてユーザーの課題を見つけることは「本当に必要なプロダクト」をデザインするための第一歩です。さらに、課題の定義をする際には戦略や実現可能性も加味する必要があります。デザイナーだけでなく、技術に強いメンバーやビジネスに詳しいメンバーも一緒に三位一体となって課題の定義を進めることが大切です✨

Pivotal Labsでは、定期的にワークショップ型イベントを開いたり、ブログでプロダクト開発やチームビルディングなどについて紹介していきます。

イベントの最新情報:
Meetupグループに参加すると、いち早く案内が届きます😎📩

公式ブログ:
Product Runも是非フォローお願いしますっ🙌🏻🗒

--

--

Erika Ito
Product Run

Product Designer at VMware Tanzu Labs (former Pivotal Labs) in Tokyo. Ex Medium Japan translator. | デザインに関すること、祖父の戦争体験記、個人的なことなど幅広く書いています😊