Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

BtoB新規事業を舵取りするためのユーザー調査

1,232 views

Published on

2017/10/04 ユーザーテストLive!『第2回 UT事例発表会』 ── UX先進企業の担当者が語る「活用事例」第二弾 での発表資料です

Published in: Design
  • Be the first to comment

BtoB新規事業を舵取りするためのユーザー調査

  1. 1. BtoB新規事業を 舵取りするための ユーザー調査 株式会社ヴァル研究所 伊藤英明 ユーザーテストLive!『第2回 UT事例発表会』 UX先進企業の担当者が語る「活用事例」第二弾 2017/10/4
  2. 2. アジェンダ • 自己紹介 • PO、UXデザイナーとして関わったサービス 「RODEM」について • 仮説構築フェーズでのユーザー調査 • 仮説検証フェーズでのユーザー評価 • まとめ
  3. 3. 自己紹介 • 株式会社ヴァル研究所 Business Development Dept. UXデザイナー • 自社のメイン商材である の技術をベースにし た新規事業開発の仕事をしています • RODEMのPO(プロダクトオーナー) • 経歴的には、デザイナー(プロダクト、UI) → ユーザビリティエンジニア → UXデザイナー
  4. 4. 自己紹介 • マーケティング/商品企画のためのユーザー インタビューの教科書 共著
  5. 5. 担当サービス「RODEM」
  6. 6. アポイントメント時 どのくらい移動時間がかかる か 知るため、カレンダーに移動 の 予定を入れるために検索 業務で外出するたびに何度も経路検索 を していませんか?
  7. 7. アポイントメント当日 具体的に何時に出発するかを 決めるために検索 業務で外出するたびに何度も経路検索 を していませんか?
  8. 8. 交通費精算時 いつどこに打合せに行った か、 どのくらいの運賃がかかっ た のか、その日のことを思い 出しながら改めて検索 業務で外出するたびに何度も経路検索 を していませんか?
  9. 9. あなたの交通費精算は各駅停車では ありませんか?
  10. 10. • ユーザーはカレンダーに予定を入れるだけ 普段と同じように打合せの予定を カレンダーに登録 担当サービス「RODEM」
  11. 11. 普段と同じように打合せの予定を カレンダーに登録 目的地までの経路や出発時刻を計算 移動予定をスケジュールに追加登録する • システムが移動予定が算出して登録 担当サービス「RODEM」
  12. 12. • 算出されたデータを使って交通費精算ができる 担当サービス「RODEM」
  13. 13. あなたの交通費精算を各駅停車から超特急 に! 87%の工数削減!!
  14. 14. 本登壇の趣旨 • このサービスはなぜこういう形になったのか • 開発の中でどんな調査、評価を行い、どんな決断が あったのか • サービスデザインで舵取りしていったことを振り返りな がらお話します
  15. 15. BtoBサービス開発の難しさ • ユーザーの声は大きく扱われるが、本質的な課題で はないことも多い • 導入までのハードルが多い 例)社内での既存システムや風習に合わないところは 個別対応しているケースが多い
  16. 16. HCDプロセス • システムを使いやすくするためにユーザの立場や視 点に立って設計を行うためのプロセス
  17. 17. HCDプロセス • システムを使いやすくするためにユーザの立場や視 点に立って設計を行うためのプロセス 使われる 現場を確認 お試し案 を作る 何が必要か 考える 使えるかを チェック
  18. 18. HCDプロセス • 仮説構築と仮説検証を繰り返すプロセスでもある
  19. 19. 仮説構築フェーズでのユーザー調査 • ユーザーの課題は何か、その課題を解決するのに 適した手段は何か • BtoBに合わせた調整:課題を聞くのではなく、実態か ら課題を見つける
  20. 20. 開発初期のピボット • 当初は「交通費精算作業の効率化」を目的にしたソ リューションの開発を目指していた • 想定課題は「精算時の面倒事」であった • ビジネスマンの実態を知るためにインタビューを実施
  21. 21. 開発初期のピボット • 当初、想定していた精算時の課題は感じられているも のの、すでに仕方のないこととして受け入れられてい る • 外出に関わる活動の中で、何度も経路を検索している という実態が明らかになった 計画時:移動の予定、所要時間を確認するために検索 当日 :具体的な出発時間を決めるために検索 移動時:乗る電車を確認するために検索 精算時:使った経路にかかった運賃を調べるために検索
  22. 22. 開発初期のピボット • 精算時の面倒事を解消するには計画時の課題まで遡 り解消する必要があることがわかった • ビジネスマンの外出に関わる 「計画時」「移動時」「精算時」 の課題を解決するソリューションを提供することに決 定
  23. 23. ビジネスモデル仮説を立てる • 各種キャンバスを用いる
  24. 24. Problem/Solution Fitの検証 • ターゲットとするユーザの課題に関する仮説と、 その課題を解決するソリューションの仮説を検証 • その製品、サービスは「誰のどのような問題を どのように解決するのか?」を明らかに • これが”MVPの要件定義”となる
  25. 25. Problem/Solution Fitの検証 課題 ソリューション 計画時 アポごとに訪問先の所在地、最寄り駅を調 べて経路を検索。移動時間を踏まえたスケ ジューリングをしなくてはならないのが面倒 → スケジュール登録時に移動ルートも自 動で登録。 正確な計画立案をサポート。 移動時 当日の出発時間や乗る電車を決めるため に再度検索するのが面倒 → 移動中の乗換をリアルタイムアシスト。 急なアクシデントも迂回経路で サポート 精算時 精算のために日にちや経路を思い出したり、 改めて検索しなくてはならないのが面倒 → 交通費精算用の明細リストを自動で作 成することによる面倒な入力作業からの 解放 • 誰のどのような問題をどのように解決するのか?
  26. 26. MVPとは Build-Measure-Learnのフィードバックループ1周を回せる『必要最 低限の労力』+『最低限の実装時間』バージョンの製品」
  27. 27. 仮説検証フェーズでのユーザー評価 • 課題解決の方法性が合っているのか • その手段でユーザーの課題は解決するのか • BtoBに合わせた調整: 課題の解決はもちろんのこと、「ユーザーの普段の行 動」に即する手段を提供する
  28. 28. MVPによる検証時:入力UIの選択 • まず、MVPでは ①:予定を入れる→移動予定が算出される ②:移動予定が精算データになる という体験価値の提供を目指した
  29. 29. MVPによる検証時:入力UIの選択 • ①について、当初の予定ではアプリからの予定 登録を考えていた 打合せの予定を登録 自宅、会社から目的地までの経路や 出発時刻を計算。移動予定を一覧
  30. 30. MVPによる検証時:入力UIの選択 • ユーザーの「既存の体験」を変えないことを重視 B向けサービスであることから、スイッチングコストへの 考慮もあった • ユーザーが普段から使っているカレンダーを予定 登録時の入力UIとすることに決定
  31. 31. 検証を終えて:スマホアプリを公開しない • MVPとしてのRODEMは「カレンダー&リマインダー&ナ ビゲーション&精算システムへのアダプター」だった
  32. 32. 検証を終えて:スマホアプリを公開しない • 主に「ナビゲーション」部分を担うものとして アプリを作った
  33. 33. Problem/Solution Fitの検証 誰の、どのような問題を、どのように解決するのか? 課題 ソリューション 計画時 アポごとに訪問先の所在地、最寄り駅を調 べて経路を検索。移動時間を踏まえたスケ ジューリングをしなくてはならないのが面倒 → スケジュール登録時に移動ルートも自 動で登録。 正確な計画立案をサポート。 移動時 当日の出発時間や乗る電車を決めるため に再度検索するのが面倒 → 移動中の乗換をリアルタイムアシスト。 急なアクシデントも迂回経路で サポート 精算時 精算のために日にちや経路を思い出したり、 改めて検索しなくてはならないのが面倒 → 交通費精算用の明細リストを自動で作 成することによる面倒な入力作業からの 解放 検証を終えて:スマホアプリを公開しない
  34. 34. 検証を終えて:スマホアプリを公開しない • 予定通りの行動はサポートできるが予定外の行動に弱 い • マップアプリを見たり、駅すぱあとで調べたほう がいいという場面が多い • ピンポイントには駅すぱあともRODEMの競合であった という事実 • 駅すぱあと(その他アプリ)からスマホの画面を 奪えない • 課題に対してソリューションがFitしていなかった
  35. 35. リリース直前:コンセプト再定義 • スマホアプリを廃止したことで、RODEMというシステム は完全に「サービスの裏方」になった
  36. 36. リリース直前:コンセプト再定義 • 一定の形態を持たずに変幻自在に姿を変えながら ユーザーに寄り添い助ける存在というコンセプトを再 定義
  37. 37. 現在:改善のための開発 • スクラム開発で仮説構築と仮説検証を繰り返していま す https://www.slideshare.net/itow_ponde/uxpo-170927-80220011
  38. 38. ご静聴ありがとうございました。

×