第4弾です。
前回と前々回で、Product Manager視点の問題の発見と定義に関して解説してみたので、今回はその次ステップである、解決策について書いてみたいと思います。
PM Responsibility Recap
ではいつも通りおさらいとしてPM Responsibilityのリストを載せておきます。(太字が今回のフォーカスです)
- 顧客や会社の抱える問題が何か突き止める
- 顧客や会社の抱える問題はどうやって解決されるのが最適か突き止める
- 定義された解決策が実際にその問題を解決することを確かめるために必要な最小限のProduct(MVP)と、MVPから理想のProductに発展させるためのロードマップを定義する
- エンジニアのチームによるMVPの実装を意思決定面からサポートする(実装時にわかった障壁をどう克服するか)
- アナリティクスのチームによるMVPの実験/検証計画の策定の意思決定面からサポートする
- 実験結果とInsightをチームに共有し、それらに基づき次のステップを定義する
- マーケティングチームによるGo To Market Strategyの策定をサポートする
- 実験からの学びに基づいたPivotを含め、Product Roadmapを次に進める
Solution Hypothesis & Ideal Experience
前回のFoundational UX Researchで、リサーチしたテーマに関する問題とその問題の大まかな特性を把握したのですが、その問題や、問題の特性を知ることで、その問題がどんな風な解決策で解決されそうか大まかなアイディアが湧いてくると思います。
例えば、仮に前回で使用した例の飛行機の遅延というテーマで行なったRippleやFoundational UX Researchで、「ビジネス顧客は時間を気にするので、自身で飛行機の遅延を体験するとその航空会社の便は遅延確率が高いと主観的に思い込んでしまい、リスク回避として次回より他社の航空会社を使いやすくなる」と「非ビジネス顧客は遅延による時間のストレスに加えて、多くの顧客が遅延した際の急なゲートや荷物の受け取り口の変更が分かりにくて自身で周りの色々な機関に聞き回らなくてはいけなかった経験から『もうこの航空会社使わなーい』となってしまう」というのが主なInsightだったとします。
前者であれば、購入から搭乗までのサイクルの中でその航空会社/選んだ便の遅延確率の統計を告知することで、一回の遅延イベントのみで「この航空会社はよく遅れる」という印象を得てしまうことを回避できるかもしれません。
後者であれば、顧客に航空会社側から遅延による変更情報を顧客が必要と思っているであろう時にプッシュで知らせることで、顧客の混乱を和らげることができるかもしれません。
とりあえず、今回は便宜的に後者を取り扱うProductの仮説にしてみましょう。
- 顧客に航空会社側から遅延による変更情報を顧客が必要と思っているであろう時にプッシュで知らせることで、顧客の混乱を和らげることができるかもしれない
Product Managerとしては、仮説ができるとだいたい2つのことを考えます。
- この仮説はどうすれば正しいと検証できるか
- この仮説が正しかった場合、理想の顧客体験はどうあるべきか
1.に関して、仮に(たぶん現実にそんなことはないのですが、説明の便宜上 笑)この航空会社は若者をメインターゲットにした格安航空で、自社のアプリがあり、だいたい20%のユーザーがそのアプリを使っていて、かつユーザーの分布が全体とアプリ使用ユーザーでだいたい一緒とということにしておきましょう 笑
その際、一番簡単な実験は、アプリの通知機能(Notification)を使って、変更のゲートや荷物の受け取り口を通知機能、Eメール、SMSで通知し、通知した場合としない場合で遅延便以降の継続利用率に統計的な差異があるかどうかの検証かもしれません。
2.に関しては、アプリの非利用ユーザーに、人に聞いてもらうという手間を取らせずにいかに変更情報をユーザーの知りたいタイミングで伝えるかです。もし1.の実験で最強の結果が出て通知機能がみんなが欲しかった機能だということになれば、いかにアプリの利用率をあげるかにフォーカスをおいてもいいかもしれませんし、その場合、チェックインカウンターや搭乗ゲートの周り等、空港の顧客の導線上にQRコードを載せたバナースタンドやポスター等を置くのも一つの解決策かもしれません。アプリの利用率がなかなか上がらなかったり、そもそも実験が成功したけども最強の結果とまでは言えない程度の効果だったのであれば、他の方法、例えばゲートのディスプレイを利用したり、降機時にCAさんにタブレットを持たせたり首から掛けてもらって、荷物受け取り口をそこに表示しておくなどで、同じく顧客の導線上に情報が必要なタイミングで顧客の目にうつるようにするのが一つの解決策かもしれません。
1.と2.の大まかな方向性が見えてきたら、Product Requirements Documentと呼ばれるドキュメントにします。
PRD (Product Requirements Document)
PRDは、そのProductの全ての要件を記載したドキュメントである。読む人にWhat(そのProductが何をするべきか)を伝えるものだが、デザイナーやエンジニアが彼らの専門性を用いて最適なデザイン、アーキテクチャを思いつけるようにするためHowの部分(そのProductがどのようにそれをするのか)はあえて明記しない
Product Managerに「Product Managerって何する人なの？」と聞くと、「PRDを書く仕事だよ」と返ってくることがあります。実際に文字通り「書くこと」が仕事なわけではないのですが、PRDを書く際に必要なプロセスを辿るとそのProductに関してやるべきProduct Managerの仕事が大体網羅されるので、そう言われることがあるみたいです。
PRDには色々なフォーマットがあって、会社によってレイアウトや内容が違いますが、大まかには、
- このドキュメントを誰がレビューするべきか
- 解決しようとしている問題は何なのか、なぜその問題は解決されるべきなのか
- その問題はどうやって解決されるべきか
- その問題の解決はどうやって計測されるべきか
- 解決策のデザインとデザインドキュメントへのリンク
- デザイン上のそれぞれの機能の優先順位
- エンジニアチームの大まかな実装計画とエンジニアのスペックドキュメントへのリンク
- アナリティックスチームの大まかな実験計画と実験スペックドキュメントへのリンク
- マーケティングチームの大まかなGTM計画とGTMドキュメントへのリンク
みたいなことが書かれています。
全ての項目を一気に書くのではなく、わかったところで徐々に追記していくというのが一般的なスタイルだと思います。上記Hypothesis Solution & Ideal Experienceがわかると上記3つから4つは記載できるのではないかと思います。
5つ目からは具体的にどうやってそのProductを作るかの部分なのですが、Wikipediaの定義にもあるようにHowの部分にあたるので、Product Managerは各チームが各項目を定義するのをサポートし、彼らが定義したものをまとめて記載し、彼らの作ったドキュメントへリンクする感じです。
UX Design
上記4つが記載できたら、UX Designerと両方のUX(顧客体験)について議論し、具体的にどういうデザインになるかを定義していきます。ここで議論する内容は必ずしもUIデザイン(スクリーンがどんな色でどんな形でどんなイラストやロゴやコピーを使うかか等)だけではなく、顧客のUX全体を定義します。
デザインに関してはDesignerがリードしていくので、Product ManagerはDesginerの提案するデザインに、各機能がその問題を解決するのに最適か、顧客がどんな人たちかの知識からフィードバックをしていきます。
Product ManagerとしてはDesginerの提案するデザインがかっこいいか、美しいかというのも大事なのですが(ユーザーが使ってくれるか、興味を持ってくれるかに影響するので)、それ以上にそのデザインがユーザーの抱える問題を解決するかに重点を置きます。一番避けたいのはかっこいいけど問題を解決するかが怪しいデザインを採用したことによって、実験が失敗した際、失敗の原因がデザインの悪さからきてるのかと仮説が間違っていたのかの判別が難しくなってしまうことです。
Prototype & Usability Testing
こういったことを防ぐために予算がカツカツじゃない場合はUX Researchのチームと組んでUsability Testingを行います。
ユーザビリティテストもしくはユーザテストとは、ユーザー中心設計のインタラクションデザインにおいて、ある製品を評価するために実際にユーザーにその製品を試してもらう手法のことである。他の方法では得られない、「ユーザーたちが実際にどのようにシステムを扱うか」という直接的な知見が得られる。
上記定義通り、実際にエンジニアがデザインを実装する前に、紙芝居のような形でデザインを数人のユーザーに見せて、彼らがその機能をどのように使うか、使いながらどんなことを考えているかを学びます。Product ManagerやDesignerの意図した通りに使っているか、見落としていたケースがないか、ユーザーがその機能を使っている時に考えていることや感じていることは意図通りか、そうでない場合、それは解決しなくていいのか、解決するならどうデザインを変更するか等のInsightを得るのが目的です。
基本的にはUsability Testingを行ってから、さらに数回、デザインサイクルを回してデザインを改善し、エンジニアのチームにそのデザインを渡します。
さて、今回は解決策の定義までなので、ここまでにします。
エンジニアとの関わり以降を次回書いてみようかなーと思ってます。
