事業の成功率を上げるUX/UI検証　理論編

世の中にサービスを公開して、早い段階からPMF（プロダクトマーケットフィット）するには、公開前にどんな検証を行うのが適切か紹介します。
開発時にユーザーインタビューやユーザーテストが必要なのは理解してるけど何を考慮してテスト設計すれば良いのかわからない方、UX/UI検証してるけど思ったほど良い結果が得られず労力と結果が見合わない方におすすめな内容になっています。

私自身、様々なクライアントのサービス開発に携わり、延べ250人以上のユーザーにUX/UI検証の企画、計画、実施、分析、改善を行ってきたので、そこで実施してきたこと、感じたことをお伝えできればと思います。

そもそもなぜUX/UI検証が必要なのか

「UX/UI検証をすればプロダクトの操作性も上がるし、より良い体験をユーザーに届けられるから開発時に実施したい」という名目でUX/UI検証を行う人は多いと思います。確かにユーザーテストを行うことで実際のプロダクトに触ってもらい、開発側が想定していた通りにユーザーが行動し、タスクを達成できるかという観点は非常に重要になります。

しかしUX/UI検証を実施する理由はそれだけではありません。
UX/UI検証をすることでデザイナーにとっても、プロダクト開発全体にとっても非常に重要な以下の３つが叶えられます。

1.検証結果はデザイナーがビジネスチーム・開発チームと戦う武器になる

2.デザイナーの声は届きにくいが、ユーザーの声はチームに届きやすい

3.「ユーザーってこうだよね」という客観的な視点を装った主観的な発言を減らして、適切な決定を促していく

1.検証結果はデザイナーがビジネスチーム・開発チームと戦う武器になる

プロダクト開発をしていく上で、必ず意識する３つの円があります。

Desirability（サービスの魅力性・有用性）、Viability（ビジネスの持続可能性）、Feasibility（開発の実現可能性）の３つの円が重なる部分にイノベーションが存在する。ということを表した図になります。
なのでどれか一つの円が大きくなりすぎたり、それぞれが離れてしまってはイノベーションは生まれないということです。

Desirabilityを主に司るのはデザイナーとなり、Viabilityはビジネスチーム、Feasibilityは開発チームが中心となり、プロダクト開発は進んでいきます。
その際に各チームが注目するポイントは、ビジネスチームはどれだけビジネスとして収益性・持続性があるのか、開発チームは開発難易度はどれだけあり、開発工数と効果は見込めるのかを基本的に重要視しながら意思決定をしていきます。
その２チームと会話する時にDesirabilityを司るデザイナーが「今までの経験上、この体験・デザインが良さそう」だったり、「きっとユーザーはこの体験・操作感が気持ち良いはず」とかデザイナー個人の経験・感覚で会話しても、ビジネス・開発チームからするとそこにどれだけ費用対効果が見込めるのかがわからないため、意思決定ができません。下手すれば効果がわからないため、Desirability観点が疎かになり、とにかくお金の匂いがするビジネス臭の強いプロダクトや現状簡単にできる技術でしか開発しないプロダクトが出来上がり、ユーザーが本当に魅力に感じて、継続的に利用したくなるプロダクトは生まれません。

そんな事態を防ぐためにデザイナーはUX/UI検証を積極的に行い、一番ユーザーのことを理解し、ユーザーの代弁者となる必要があります。検証を実施して、正しい分析をすればユーザーが感じている課題、ニーズ、サービスへの期待をユーザーの代弁者としてデザイナーは発言することができ、ビジネス・開発チームと戦う（会話）ための武器となるのです。

余談ではありますが、Desirability、Viability、Feasibilityを全て兼ね備えた人材を「BTC人材」と呼び、Business、Technology、Creativeのスキルを持つ人材もいます。が、全ての領域に対して100%の力を発揮できるような人材は希少種で、大半はいずれかに偏っているため、チームでの連携が不可欠となっています。

2.デザイナーの声は届きにくいが、ユーザーの声はチームに響きやすい

ユーザーが満足してくれないとサービスはそもそも成り立たないため、プロダクトを使うユーザーの声はチームにとって非常に重要です。それはデザイナーでなくともプロダクト開発をする人間であれば全員が理解しています。
そのためデザイナー個人の感覚で「これが良い！」と発言してもチームは動いてくれません。しかしそこに「ターゲットの20代の学生起業家5人にインタビューしたら、考えたアイデアを評価し、これがあればこのプロダクトを使いたいと言ってました。」という検証結果がでれば、その体験の実現に向けて、多少開発工数と費用が掛かっても、チーム全体が納得し、動いてくれるはずです。

なので「何で自分はこんなにも情熱を注いでデザインしているのに、同じチーム・クライアントは理解してくれないんだ！」と嘆いているデザイナーは、ユーザーの声をまず聞いてみることをおすすめします。そしてフェーズにもよりますが、UX/UI検証するために完璧なデザインをする必要はなく、とにかく早い段階でユーザーにヒアリングしてみることが大切です。きっと自分が想定していた以上に予想外のコメントがあり、それがデザイナーにとって武器になり得る可能性が秘められています。

3.ユーザーってこうだよねという客観的な視点を装った主観的な発言を減らして、適切な決定を促していく

「顧客視点で考えるとこの体験の方が良くない？」という発言をよく耳にします。実際にユーザーインタビューをして声を聞いた上での発言であれば良いと思いますが、ほとんどの場合そのような発言をする人はUX/UI検証もせず、過去の経験から発言していることが多いです。自分の意見に耳を傾けてほしいがために「顧客視点」という便利な単語を使って、会話をしているだけです。
本当にUX/UI検証をし、深く分析している人たちはこのような発言はしません。というのも検証すればするほど、自分たちが想定していなかった発言が出てくるので、自分たちは顧客のことを100%理解しているわけではないことを理解しています。

「顧客視点で考えるとこの体験の方が良くない？」という客観的な視点を装った主観的な発言を減らして、適切な決定を促していくにはUX/UI検証をし、その結果をチーム内に浸透させることが重要です。それを行うことで適切な判断、決定を促していくことができます。

検証方法はプロジェクトのフェーズによって異なる

デプスインタビュー、ユーザーテスト、A/Bテスト、アイ・トラッキング、需要性調査、定量アンケートなどUX/UI検証は様々な方法があります。各手法はどのタイミングで実施しても効果が出るというわけではなく、適切なタイミングで実施することが重要です。

下記のキャプチャを意識するのが良いと思います。

プロジェクト初期は顧客のことをまだまだ理解していない状態のため、何か作ったものを検証するのではなく、「まずは顧客の状況を理解するために、会話をする」ことをおすすめします。その行為を「探索的調査」と呼びます。
アイデアを実際に形にし、ヒアリングすることを「検証的調査」と呼び、通常はプロジェクトの中盤から終盤にかけて実施します。

実際にどのように実践するのかは実践編でご紹介いたします。

Xも最近ちゃんと投稿しはじめたので、よかったらフォローお願いします。毎日サービスデザイン、UX/UI、生成AI関連の情報共有をしています。

Xでもデザイン、生成AIに関する情報を共有しております。
https://twitter.com/yutomi1414