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.

Poがuxデザインをする上で何を指標にしてきたか

1,856 views

Published on

シン・UX 2017 ~プロダクトマネージャー・プロダクトオーナーにとってのUXのイマとミライ~ 2017/01/21(土)

Published in: Design
  • Hey guys! Who wants to chat with me? More photos with me here 👉 http://www.bit.ly/katekoxx
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Poがuxデザインをする上で何を指標にしてきたか

  1. 1. POがUXデザインをする上で 何を指標にしてきたか 株式会社ヴァル研究所 伊藤英明 シン・UX 2017 ~プロダクトマネージャー・プロダクトオーナーにとってのUXのイマとミライ~ 2017/1/21
  2. 2. アジェンダ • 自己紹介 • PO、UXデザイナーとして関わったサービス 「RODEM」について • プロジェクト内での役割と責任範囲 • HCDプロセスと顧客開発モデル • いくつかの判断ポイントと判断指標 • まとめ
  3. 3. 自己紹介 • 株式会社ヴァル研究所 Business Development Dept. UXデザイナー • 自社のメイン商材である の技術を ベースにした新規事業開発の仕事をしています ※その為、若干スタートアップ寄りの話になります • 経歴的には、デザイナー → ユーザビリティエン ジニア → UXデザイナー
  4. 4. 前置き:RODEMの現在の姿
  5. 5. 前置き:RODEMの現在の姿 • ユーザーはカレンダーに予定を入れるだけ 普段と同じように打合せの予定を カレンダーに登録
  6. 6. 前置き:RODEMの現在の姿 普段と同じように打合せの予定を カレンダーに登録 目的地までの経路や出発時刻を計算 移動予定をスケジュールに追加登録する • システムが移動予定が算出して登録
  7. 7. 前置き:RODEMの現在の姿 • 算出されたデータを使って交通費精算ができる
  8. 8. 本登壇の趣旨 • このサービスはなぜこういう形になったのか • 開発の中でどういう判断ポイントがあったのか • これがどのように決まっていったのかを振り返り ながら話します • 様々な場面で「判断すること」を求められるPOの 助けになる知見を持って帰っていただきたい
  9. 9. プロジェクト内での自分の役割 • UXデザイナーとして ユーザー目線に立った機能、仕様等の検討 ユーザーへの価値提供に責任を持つ • POとして サービス開発の舵取り チームへの説明責任 サービスのスケールに責任を持つ
  10. 10. HCDプロセス • システムを使いやすくするためにユーザの立場や 視点に立って設計を行うためのプロセス
  11. 11. HCDプロセス • システムを使いやすくするためにユーザの立場や 視点に立って設計を行うためのプロセス 使われる 現場を確認 お試し案 を作る 何が必要か 考える 使えるかを チェック
  12. 12. HCDプロセス • 仮説構築と仮説検証を繰り返すプロセスでもある
  13. 13. 顧客開発モデル • 4つのステップで顧客不在リスクの低減を図る 経営プロセス 「顧客発見」 ニーズの発見 「顧客実証」 有償販売と 拡張性の確認 探索フェーズ 実行フェーズ 「顧客開拓」 市場参入 需要開拓 「組織構築」 本格販売 ピボット(軌道修正)
  14. 14. 顧客開発モデル • ビジネスモデル仮説を立てる • Problem/Solution Fitの検証 • Product/Market Fitを実証
  15. 15. 判断の指標としてのP/Sfit、P/Mfit • Problem/Solution Fit 存在する課題と、適切なソリューションが一致して いる状態 →課題解決方法が合っているか? →その機能はユーザーにとって必要なものか? • Product/Market Fit 良い市場を狙っていて、その市場を満足させること ができる製品を持っている状態 →その製品は需要のある売れる製品か?
  16. 16. ビジネスモデル仮説を立てる • 各種キャンバスを用いる
  17. 17. Problem/Solution Fitの検証 • ターゲットとするユーザの課題に関する仮説と、 その課題を解決するソリューションの仮説を検証 • その製品、サービスは「誰のどのような問題を どのように解決するのか?」を明らかに • これが”MVPの要件定義”となる
  18. 18. MVPとは Build-Measure-Learnのフィードバックループ1周を回せる 『必要最低限の労力』+『最低限の実装時間』バージョンの 製品」
  19. 19. Product/Market Fitを実証 • MVPを開発してアーリーアダプター顧客に実際に 販売 • 実際にMVPをもってSIer、販売代理店、エンド ユーザーへ販売を持ちかける • 新規顧客の獲得と既存顧客の維持ができるか (ビジネスモデルとして成立するか)を確認
  20. 20. 両プロセスモデルのハイブリッド
  21. 21. 幾つかの判断ポイント • 開発初期のピボット • MVPによる検証時:入力UIの選択 • 検証を終えて:スマホアプリを公開しない • リリース直前:コンセプト再定義
  22. 22. 開発初期のピボット • 当初は「交通費精算作業の効率化」を目的にした ソリューションの開発を目指していた • 想定課題は「精算時の面倒事」であった • ビジネスマンの実態を知るためにインタビューを 実施
  23. 23. 開発初期のピボット • 当初、想定していた精算時の課題は感じられてい るものの、すでに仕方のないこととして受け入れ られている面 • 外出に関わる活動の中で、何度も経路を検索して いるという実態が明らかになった 計画時:移動の予定、所要時間を確認するために検索 当日 :具体的な出発時間を決めるために検索 移動時:乗る電車を確認するために検索 精算時:使った経路にかかった運賃を調べるために検索
  24. 24. 開発初期のピボット • 精算時の面倒事を解消するには計画時の課題まで 遡り解消する必要があることがわかった • ビジネスマンの外出に関わる「計画時」「移動 時」「精算時」の課題を解決するソリューション を提供することに決定
  25. 25. ビジネスモデル仮説を立てる • 各種キャンバスを用いる
  26. 26. Problem/Solution Fitの検証 課題 ソリューション 計画時 アポごとに訪問先の所在地、最寄り駅を 調べて経路を検索。移動時間を踏まえた スジューリングをしなくてはならないの が面倒 → スケジュール登録時に移動ルートも 自動で登録。 正確な計画立案をサポート。 移動時 当日の出発時間や乗る電車を決めるため に再度検索するのが面倒 → 移動中の乗換をリアルタイムアシス ト。急なアクシデントも迂回経路で サポート 精算時 精算のために日にちや経路を思い出した り、改めて検索しなくてはならないのが 面倒 → 交通費精算用の明細リストを自動で 作成することによる面倒な入力作業 からの解放 • 誰のどのような問題をどのように解決するのか?
  27. 27. 開発初期のピボット このポイントでの判断 UXデザイナーとして ユーザーに対してインタビューを実施、その実態から課題を 明らかにする MVPの要件定義となる「課題解決のためのソリューション」 を設定する POとして MVPの要件定義に沿った開発方針を決める
  28. 28. MVPによる検証時:入力UIの選択 • まず、MVPでは ①:予定を入れる→移動予定が算出される ②:移動予定で精算データになる という体験価値の再現を目指した
  29. 29. MVPによる検証時:入力UIの選択 • ①について、当初の予定ではアプリからの予定 登録を考えていた 打合せの予定を登録 自宅、会社から目的地までの経路や 出発時刻を計算。移動予定を一覧
  30. 30. MVPによる検証時:入力UIの選択 • ユーザーの「既存の体験」を変えないことを重視 B向けサービスであることから、スイッチングコス トへの考慮もあった • ユーザーが普段から使っているカレンダーを予定 登録時の入力UIとすることに決定
  31. 31. MVPによる検証時:入力UIの選択 このポイントでの判断 UXデザイナーとして ユーザーに提供する体験価値のコアが何であるかを見極め、 MVPとして必要な機能を決める POとして サービスのスケールを考えたとき、(ユーザーの価値を損ねる こと無く)どういう仕様であるべきなのか決める
  32. 32. 検証を終えて:スマホアプリを公開しない • MVPとしてのRODEMは「カレンダー&リマイン ダー&ナビゲーション&精算システムへのアダプ ター」だった
  33. 33. 検証を終えて:スマホアプリを公開しない • 主に「ナビゲーション」部分を担うものとして アプリを作った
  34. 34. Problem/Solution Fitの検証 誰の、どのような問題を、どのように解決するのか? 課題 ソリューション 計画時 アポごとに訪問先の所在地、最寄り駅を 調べて経路を検索。移動時間を踏まえた スジューリングをしなくてはならないの が面倒 → スケジュール登録時に移動ルートも 自動で登録。 正確な計画立案をサポート。 移動時 当日の出発時間や乗る電車を決めるため に再度検索するのが面倒 → 移動中の乗換をリアルタイムアシス ト。急なアクシデントも迂回経路で サポート 精算時 精算のために日にちや経路を思い出した り、改めて検索しなくてはならないのが 面倒 → 交通費精算用の明細リストを自動で 作成することによる面倒な入力作業 からの解放 検証を終えて:スマホアプリを公開しない
  35. 35. 検証を終えて:スマホアプリを公開しない • 予定通りの行動はサポートできるが予定外の行動 に弱い • マップアプリを見たり、駅すぱあとで調べたほう がいいという場面が多い • ピンポイントには駅すぱあともRODEMの競合で あったという事実 • 駅すぱあと(その他アプリ)からスマホの画面を 奪えない • 課題に対してソリューションがFitしていなかった
  36. 36. 検証を終えて:スマホアプリを公開しない このポイントでの判断 UXデザイナーとして MVPの利用状況を分析し、P/S fitの検証を行う POとして 現状のソリューションでは移動中の課題解決ができていない という事実を元に、アプリを公開しないという判断を下す
  37. 37. リリース直前:コンセプト再定義 • スマホアプリを廃止したことで、RODEMという システムは完全に「サービスの裏方」になった
  38. 38. リリース直前:コンセプト再定義 • 一定の形態を持たずに変幻自在に姿を変えながら ユーザーに寄り添い助ける存在というコンセプト を再定義
  39. 39. リリース直前:コンセプト再定義 このポイントでの判断 UXデザイナーとして システム、サービスがユーザーへの価値提供を行える形を 模索しコンセプトに落とし込む POとして 他のサービスと戦うこと無く、共生関係においてビジネスが 成立する形を定義する
  40. 40. まとめ • POは様々な場面で「判断すること」を求められる • ユーザーにとって何がいいのか • サービスのスケールにとって何がいいのか • そのためにチームはどう動くべきなのか • その都度「P/Sfit」「P/Mfit」を指標をすることで 必要な判断ができた
  41. 41. まとめ • 私が繰り返しのプロセスに拘る理由
  42. 42. やってみなきゃわからんこともある t. Do or do not. There is no try.」 (やってみるのではない
  43. 43. 仮説が信じられるものになるまで繰り返す ルーク「I don't believe it.」(信じられません) ヨーダ「That is why you fail.」(だから失敗したのじゃ)
  44. 44. ご静聴ありがとうございました。

×