UX検証プロセス資料

スタディストのプロダクト開発におけるUX検証プロセスについての資料です。

関連リンク
・https://cocoda.design/yumiko02/p/p6909f53fa1bd
・https://studist.tech/ux-validation-process-framework-67817bf62cb2

Transcript

1. 株式会社スタディスト リサーチ&デザイン室 UX検証プロセス資料
2. Contents 1. 前置き 2. UX検証プロセス 3. 運用例 4. UX検証プロセス制作の裏側 UX検証プロセス
3. 1.前置き
4. 特に意図なく、とりあえず 
 社内リリース・ベータ版公開を 
 選んでいませんか？ 
 UX検証プロセス Question
5. 社内リリース? UX検証プロセスの型化による狙い UX検証プロセス 再現性を持って、最適なリリース手法を判断できるようにする クローズドベータ版？ オープンベータ版? 正式リリース？
6. 2.UX検証プロセス
7. UX検証プロセスの使い方 
 • 価値ある機能をより早くユーザーに届けるため、 UX検証プロセスの全体像と実施方法をまとめた資料です。 • 必要なUX検証はどれかを判断するため参照します。 • チームでUX検証の共通認識を持つためにも活用します。 UX検証プロセス
8. UX検証の全体像（各検証フェーズの位置づけと目的） UX検証プロセス 検証内容 対象 目的 A コンセプト検証 顧客（数社） 解決策（コンセプト）の妥当性評価。基本的に資料ベースで行う。 B ユーザビリティ検証 社内 or 顧客 実際のユーザーが解決策を使用する際の問題点や改善点を発見する。Figmaや 検証環境で行う。 C 社内リリース 検証リリース 社内 メインのユースケースを社内で検証するケース 先行リリース 社内 社員に早めに触ってもらい機能を理解してもらうことで 営業活動などに活かしてもらう。（顧客へのDemoに使ってもらうなど） 先行開発 社内 お試しで作って、正式開発に移行するかを評価してもらう D クローズド β版 検証リリース 顧客（数社） 実際の顧客の運用に乗るか、運用する価値があるかを検証する 先行リリース ニーズの 強い顧客 何らかの理由で早く使いたいユーザーに正式リリース前に機能を開放する。不完 全な機能や制約のある状態でも十分に顧客価値が出るときのみ実施。 E オープン β版検証 顧客全体 機能の利用者の母数が稼げるかの確認（つまり、多くのユーザーが使いたい機 能かを評価）
9. Concept verification コンセプト検証

10. A. コンセプト検証の目的と実施条件 UX検証プロセス 目的 実施条件 注意事項 事例 解決策（コンセプト）の妥 当性評価 課題仮説と解決策案は存在する が、その妥当性に不確実性があ る場合 • 課題仮説が未設定 の際は現状分析 フェーズに戻る • 社内での検討議論の中でコンセプト の妥当性に確信・合意が持てている 場合は次の検証に進む マニュアルテンプレート機能
11. A. コンセプト検証：実施ガイド • ゴールイメージ ◦ 想定した課題の存在確認と、提案コンセプトによる解決可能性の実証 ◦ コンセプトによる問題解決に対する運用上・機能上の課題を把握する • 完了条件 ◦ 提案コンセプトに対する顧客からの強い期待を得る ◦ 以下の要素の明確な把握 ▪ 顧客組織内の主要関係者とその役割 ▪ コンセプト案採用時の業務フローと具体的なオペレーション ▪ コンセプト案採用時に顧客が直面する課題とその影響 ▪ 不足する機能やその代替手段 /運用回避方法 • 検証方法 ◦ 課題を抱えていそうな顧客最低 3社にコンセプトをご説明しフィードバックを得る UX検証プロセス
12. A. コンセプト検証スケジュールの例 UX検証プロセス Week 1 2 3 4 検証準備 検証 顧客にコンセプトの説明 （1時間×3社） 3社以上にご協力の 依頼と調整 課題を抱えている 顧客像を選定 1stスコープの決定 インタビュー設計 説明用資料作成
13. ユーザビリティ検証 ユーザビリティ検証

14. B. ユーザビリティ検証の目的と実施条件 UX検証プロセス 目的 実施条件 注意事項 事例 実際のユーザーが解決 策を使用する際の問題 点や改善点を発見する 新機能やUI変更の導入する場合 基本的に行う すべての新機能や機能改善
15. B. ユーザビリティ検証：実施ガイド • ゴールイメージ ◦ 主要なシーンにおいて、ユーザーが問題なく目的を達成できる ◦ 優先度の高い改善項目が明確になる • 完了条件 ◦ 計画したテストシナリオを必要人数行う ◦ 発見された課題に対する改善案を作成する ◦ 次のアクションアイテムが明確化されている • 検証方法 ◦ 社内で管理部の方などにお願いして実施 ◦ ターゲットとなる顧客にお願いして実施 UX検証プロセス
16. B. ユーザビリティ検証スケジュールの例 UX検証プロセス Week 1 2 3 検証準備 実装 検証 ユーザビリティ テストを実施 検証計画・ 評価者を選定 対応案の検討 スケジュール調整 タスクを設計 Figma or 簡易実装で プロトタイプを用意 問題点や改善点の 抽出
17. α version verification 社内検証

18. C. 社内リリースの目的と実施条件 UX検証プロセス 種類 目的 実施条件 注意事項 事例 社内検証 メインのユースケースを 社内で検証する （技術検証含む） メインのユースケースを社内で確 認できる場合に行う。 技術検証など実データでの検証 が必要な場合。 Figmaや検証環境でのユーザビリティ テストで十分な場合は不要。 社内フィードバックが欲しい場合はスプ リントレビュー等を利用する。 準備・説明コストがかかるので必要性を 見極めて実施する。 PDFからドラフト生 成 社内先行 リリース 早めに触ってもらい 機能を理解してもらうこと で営業活動等に活かして もらう。 先行して顧客に動きを見せる ニーズがある場合、実際に操作 したほうが理解・提案しやすい場 合。 説明は資料で十分な場合が多いため、 必要性を見極めて実施する。 編集履歴(差分表 示） 先行開発 お試しで作って、正式開 発に移行するかを評価し てもらう 自分たちが実際に使うことで実 現性や価値を評価したい。 主に新技術導入で行う 目的やゴールを明確にしたうえで実施 する。期間を区切ってやるなど、負債に ならないようにオーナーシップを明確に して実施する 初期のドラフト生 成、Chatbot、AI関 連機能
19. C. 社内検証：実施ガイド • ゴールイメージ ◦ 実装機能が想定した課題解決と価値提供を実現できることの確認 • 完了条件 ◦ 機能性の検証 ▪ コア機能の正常動作確認 ▪ 主要ユースケースにおける操作性評価 ▪ クリティカルな不具合の非検出 ◦ 内部評価の完了 ▪ 社内テストユーザーからのフィードバック収集 ▪ 想定シナリオに基づく一連の操作検証（検索などデータ量が必要な場合） ▪ パフォーマンスと安定性の確認 • 検証方法 ◦ 社内インタビュー：想定シナリオに基づく利用時のフィードバックを受けたい場合 ◦ 社内アンケート（googleフォーム、slack）：不具合等の検出が目的の場合 UX検証プロセス
20. C. 社内検証スケジュールの例 UX検証プロセス Week 1 2 3 4 5 検証準備 社内周知 検証 実装 社内運用 （検証期間は内容によって変動） 社内に事前周知 検証計画を立てる 修正方針の検討 フィードバックを収集 社内環境に 適用 社内環境から 機能を閉じる アンケート /インタビュー設 計 インタビュー日程調整 社内版実装 随時修正内容を反映
21. Closed beta ver. verification クローズドβ版検証

22. D. クローズド β検証の種類 UX検証プロセス 種類 目的 実施条件 注意事項 事例 検証 実際の顧客の運用に乗 るか、運用する価値が あるかを検証する 顧客価値や運用実現 性に不確実性がある 場合 検証設計、検証実施時の顧客 フォローなど計画的に行う ポータルページ 機能 先行リ リース 顧客に運用の準備をし てもらう。 先んじて機能の価値を 早く得てもらう。 一部のユーザーが強 い要望がある。 早く使える様になって いることのビジネス価 値がある（新規顧客へ の魅力づけなど） 正式リリースまで期間や懸念が 少ない場合は正式リリースを優 先。 正式リリースの見込み・予定が 立っているものに対して行う。 マニュアルテンプ レート機能
23. D. クローズド β版検証：実施ガイド • ゴールイメージ ◦ 顧客の実務環境における機能性と運用性の確認（ 3社程度） ◦ 想定した価値提供の実現性の検証 • 完了条件 ◦ 顧客での安定した運用確認 ◦ 顧客からの具体的な評価収集 ◦ 想定した効果の達成度確認 ◦ 運用上の課題の明確化 • 検証方法 ◦ 顧客環境で〜1ヶ月間ほど試用していただき、フィードバックを得る方法 ◦ 顧客訪問し、1日体験会を開催して検証する方法 UX検証プロセス
24. D. クローズド β検証スケジュールの例： 顧客環境で〜 1ヶ月間ほど検証を行って頂く場合 UX検証プロセス Week 1 2 3 4 5 6 7 8 9 PdM, PdDのタ スク 顧客側 のタスク 開発 タスク 検証計画を立 てる ・顧客と検証についてのご案内MTG ・メール等での各種調整 顧客選定 ご協力の依頼とご案内の予定調整 インタビュー設計 情シスへの確認、部門間調整 社内アナウンス 検討可能かを回答 β版システムの提 供 A社：β版検証 （〜1ヶ月） フィードバックを受ける ※月1回の定例を設ける、googleフォームを用意しアンケートを配布するな ど 検証結果・今後の 計画をご報告 （必要があれば） β版利用終了に 伴う対応 β版実装、QA β版改良、アップデート 必要に応じて仕様 検討 方針検討 顧客環境で運用しながら検証して頂きフィードバックを集めたい場合 B社：β版検証 （〜1ヶ月） C社：β版検証 （〜1ヶ月）
25. D. クローズド β検証スケジュールの例： 体験会を開催して検証する場合（顧客訪問） UX検証プロセス Week 1 2 3 4 5 6 7 8 PdM, PdDの タスク 顧客側 のタスク 開発 タスク 検証計画を立 てる ・顧客と検証についてのご案内MTG ・メール等での日程調整 顧客選定 ご協力の依頼とご案内の予定調整 体験会アジェンダ 検討 情シスへの確認、部門間調整 社内アナウンス 検討可能かを回答 体験会/β版 検証 （1日） 検証結果・今後の 計画をご報告 β版実装、QA 必要に応じて仕様検討 方針検討 検証内容を明確化 マニュアル作成者など現場からのフィードバックを集めたい場合や長期間運用を回さなくても検証可能な機能の場合 体験会/β版 検証 （1日） 体験会/β版 検証 （1日）
26. Open Beta ver.Verification オープンβ版検証

27. E. オープンβ検証の目的と実施条件 UX検証プロセス 目的 実施条件 注意事項 事例 幅広いユーザー層での 機能採用率の検証と普 及可能性の評価 多くのユーザーに影響のある変 更が加わるとき 必要に応じて説明会を開くなど顧客コミュニ ケーションは積極的に行う。 主に大規模な変更を対象とし、中小規模の開 発では通常実施しない。 トレーニング機能、UIリ ニューアル
28. E. オープンβ版検証 • ゴールイメージ ◦ 多様な顧客環境での利用における障害がないことの確認 • 完了条件 ◦ 利用実績の評価 ▪ 目標ユーザー数の達成 ▪ 機能利用率の目標値達成 ◦ 品質・運用評価 ▪ 重大インシデントの非発生 ◦ 改善点の特定 ▪ ユーザーフィードバックの分析 • 検証方法 ◦ Googleフォーム等のアンケート形式でフィードバックを集める ◦ GoogleAnalyticsなどで利用実績を評価 UX検証プロセス
29. E. オープンβ検証スケジュールの例 UX検証プロセス Week 1 2 3 4 5 6 7 8 9以降 PdM, PdDのタ スク 顧客側 のタスク 開発 タスク 検証計画を立 てる 社内周知 ・顧客向け説明会の 企画・案内依頼 （必要に応じて）顧客説明会実施 情シスへの確認、部門間調整 社内アナウンス 顧客説明会参加可否を回答 β版システムの 提供開始 β版検証（ 1ヶ月〜） フィードバックを受ける ※googleフォームを用意しアンケートを配布するなど 検証結果・今後の 計画を社内に周知 （必要があれば）β 版利用終了に伴う 対応 β版実装、QA β版改良、アップデート 1ヶ月間以上検証を行う場合（イメージ） 必要に応じて仕様 検討 フィードバック フォーム作成
30. 3.運用例
31. 「とりあえず社内リリース」にかかるコストを削減 「UX検証プロセスの型」の 活用例 UX検証プロセス 「検証」ではなく「先行リリース」の目的で、ベータ版公開 1 2
32. UX検証プロセス UX検証プロセスの定義 “とりあえず社内リリース ”を 行うことがなくなる 無駄な検証コストの削減につながる フィーチャートグルの設定 社内への説明資料の作成 正式リリース時のデータ移行 社 内 検 証 実施条件 • 技術検証など実データでの検証が 必要な場合に行う • メインのユースケースを社内で 確認できる場合にのみ行う 注意事項 • Figmaや検証環境でのユーザビリティテ ストで十分な場合は不要 • 準備・説明コストがかかるので 積極的には行わない • 社内フィードバックが欲しい場合は スプリントレビュー等を利用する
33. 事例「UX検証プロセス」を共通言語に議論し、リリース方法を決定 UX検証プロセス プロジェクトメンバー全員で 検証プロセスの パターンを把握する 共通言語を持って、 プロジェクトメンバー間で リリース方法を議論 確信を持って、 適切なリリース手法を 選択することができた プロジェクトメンバー 今回の場合は… どのプロセス にしよう？ PdM デザイナー POINT 強い期待を持っている お客さまの存在 一部のユーザーにのみ クローズドベータ版で 先行リリース ↓
34. 「UX検証プロセス」の型化への感想 by プロダクトデザイナー UX検証プロセス これまでは「何となく社内リリースしておこう」 と判断してしまうこともよくあったのですが、改 めて考えると当たり前な「社内リリースを選 ばない方が良いこともある」ということに気 付けたことで、無駄なコストを無くすことがで きて良かったです。 リサーチ＆デザイン室 武波 今までだと、リサーチ&デザイン室の室長であ る磯野さんにレビューをもらわなければ適切 な検証方法を整理できていなかったように思 います。今回の資料を使うことで、 プロジェク トメンバーだけでベストな検証方法を選ぶこ とができ、 属人性を排することができています。 リサーチ＆デザイン室 原口
35. 4.UX検証プロセス制作の裏側
36. スタディストTechブログ https://studist.tech/ux-validation-process-framework- 67817bf62cb2 本資料作成のより詳細な裏側を、事例として公開しています UX検証プロセス Cocoda https://cocoda.design/yumiko02/p/p6909f53fa1bd