まずユースケースからデザインを始めよ

Hiroki Shimada
5 min readMar 18, 2018

--

ユースケース駆動デザイン

製品や機能を作る際の失敗の主な原因は、「ユースケースの存在しないものを作ってしまう」ことだろう。完全に存在しないわけではなかったとしても、少数の人により特定の状況でのみ使われるといった「細い」ユースケースしか存在しないときは、たいていその製品や機能は使われずに終わる。多くの人にとって使い道が確実に存在するような製品をつくることが、ある意味プロダクトマーケットフィットを達成することとも言えるだろう。

「作ってみたら実はユースケースが存在しなかった」ということを避ける最も良い方法は、当然ながら「ユースケースを先に想定し、そこに合わせて製品の要件を決定し、デザインする」ことである。これをユースケース駆動デザインと呼ぶことにする。

当たり前のことを言っているようだが、これを実際に行なうのは難しい。プロダクトマネージャは、「これを機能に組み込むのは当たり前」「もともと組み込むつもりだった」といった自分の中での暗黙の了解に基づいて製品設計してしまいがちだし、デザイナは「デザイン理論」や「長年培った感覚や癖」にもとづきデザインをしてしまう。実際のところ、機能のユースケースというのは、作ったあとに後付で考えられることが多い

また、この本に代表されるような、ユースケース駆動開発というソフトウェア開発形態もあるが、これはどちらかといえばコード設計の話なので、プロダクトデザインの観点ではあまり関係がないことを注意したい。
また、ユースケースというのはもともとソフトウェア工学の言葉で、オブジェクト指向においてユーザーとシステムのやりとりを示す言葉であるが、ここでは、「製品や機能がユーザーによってどのような状況・目的の下で、どのように使われるか」を示す言葉と捉えて頂きたい。

ユースケースは計測可能である

シンプルに言えば、ユースケース駆動でデザインを行なうというのは、検索機能をデザインするときに「検索クエリを先に考える」ということだ。もっと深掘りをすれば、「どんなものをどういう目的で検索したくて、その結果どんなクエリを作るか」ということになる。多くの場合、「検索機能は当然あるべきだ」という固定観念からそれが作られる事が多いが、検索クエリやユーザーの目的によっては検索機能以外のソリューションの方が適している可能性もある。

この記事で定義されているような「ユーザーフロー」「タスクフロー」という概念 に近いようにも見えるが、ユースケースというのは厳密には「製品が、ある特定のユーザーに使われた実際の事例(ケース)」を表すものと考える。このケースが集まって、その中に共通のパターンが見つかれば、ある意味それは主流なユースケースということになる。

そのような意味で、ユースケースは計測可能である。利用ログや実際にサービス内で生成されたデータを見ることで、どういった使われ方をしているのかを知ることができる。計測をしなければ、 UXデザイナが考えたユーザージャーニーどおりにユーザーが動いてくれるかはわからない。

例えば、デザイナやプロダクトマネージャは、下記のような質問に即座に答えられなければいけない。

  • 検索機能を作る時は、「どういう検索クエリを想定しているのか?」
  • フィルタ機能を作る時は、「どういうフィルタ条件で絞り込むことを想定しているのか?」
  • メッセージ機能を作る時は、「だいたいどのくらいの長さのメッセージを想定しているのか?」
  • ファイルアップロード機能を作る時は、「どんなファイル(履歴書なのか?画像なのか?容量はどれくらいか?)をアップロードすることを想定しているのか?」
  • タスク管理ソフトのラベル機能を作る時は、「そのラベルを通じて、何を分類することを想定しているのか?ラベル名はどんなものになることを想定しているのか?」

この質問の結果によって、各機能の最適な形やデザインは変わるはずだ。そして、上の例はすべてユーザーの利用ログ等から計測可能なものだ。こういった問から始めないと、存在しないユースケースを想定したデザインができてしまう。また、ユースケースを考えると必然的にそのユースケースの状況とユーザーの目的を知りたくなる。利用の目的といったものはデータからだけでは行うことができないため、必要に応じてユーザーにヒアリングを行わなければいけない。

初期のプロダクト開発においては、ユースケースのデータ(利用ログ)が貯まっていないため、ユースケースは完全に推測に頼らなければいけない。だからある程度アタリをつけて、「この機能はおそらく◯◯といった状況下で使われるから、△△といった内容が入力される」といった仮説を立てる必要がある。だから、製品をリリースしてみてそれを検証し、仮説と大きく相違していればデザインを変更する、といったことが求められる。しかし、明確にそういった仮説を立ててデザインを行うということ自体、それほど簡単ではないので、実践できているデザイナやプロダクトマネージャは多くはないだろう(特に専任のプロダクトマネージャがいないスタートアップで、創業者が製品デザインをしている頃)。

--

--

Hiroki Shimada

CEO at Polyscape Inc. / Producer & Director of MISTROGUE / ex CEO at LAPRAS Inc. / MSc in Artificial Intelligence at University of Edinburgh