小さくはじめるUX改善
はじめに
UXという言葉がバズワードとして世の中に浸透してきたこともあり、多くの組織でUX改善の取り組みが行われています。
しかしその手法や支援する会社が増える一方で、実際に「UX改善によって成果をあげた」という事例が、あちこちから聞かれることはあまりないように感じます。
UXの改善活動に取り組んでいる組織自体は増えているはずなので、実際には成果をあげている組織もたくさんあると思われますが、それが正しく評価されていない、もしくは世の中に発信されていない、ということなのかもしれません。
大きな取り組みも小さな取り組みも、多くの成功事例が世の中に出ることが、UXをバズワードとしてではなく、実際に人々の生活をより良くする取り組みとして認知させる一番の方法だと思いますので、もっと世の中にアピールされると良いなと感じています。
そんな思いもあり、先ず手始めに私が業務の中で取り組んでいることをまとめてみようと思い記事にしました。
UX改善のはじめ方
UX改善を行う際、一番手取り早いのはUX改善を支援している会社に依頼することです。しかし多くの費用がかかる上に、実際に実行してみないと上手くいくかどうかわからないという不安もありハードルは高いと言えます。
UX改善にはトップダウンで取り組む方法とボトムアップで取り組む方法がありますが、特にボトムアップで取り組む場合には、予算や時間などのコストが十分にとれないことがほとんどで、なかなか成果を出しづらい状況になっているような気もします。
自分の場合、基本的にはボトムアップ型のアプローチで支援しているので、この記事のタイトルも“小さくはじめるUX改善”としてみました。
現場主導のUX改善
現場主導で行うボトムアップ型のUX改善は多くのコストをかけて取り組めば良いというものではなく、直接的な担当者とその周りにいる決裁者が課題を正しく理解し、進むべき方向性を共有することが最も大切だと考えています。
この記事は「小さくはじめられること」と「先ずは関係者の理解を得るための素材づくりを行うこと」に重きを置いているため、本格的な開発が始まるステップ（記事中のステップ3とステップ4）の内容はかなり薄くなっています。
現場主導のUX改善は「ステップ1とステップ2のアウトプットで如何にステークホルダーを巻き込めるか？」が肝になります。
この記事が「UX改善に取り組んでみたいが何から手をつけて良いかわからない」「先ずは小さくはじめてみたい」と考えている人の参考になれば幸いです。
ステップ１: プロジェクト方針の共有
初期検討段階としてコアチームメンバーで認識の共有と課題の顕在化を行います。この段階では具体的な解決策は議論せず、プロジェクトメンバーの認識を統一させることを目的とします。
キックオフ
まずはじめに、コアチームのメンバーでキックオフミーティングを行います。「時代変化に伴う現状把握」「利益獲得機会の減少要因」「将来的な危機感の共有」「中長期の体験価値方針の仮説」などをテーマにして、チーム内で現状の認識を共有します。
アウトプットとしては、リーンキャンパスやインセプションデッキ等、チームに馴染みやすいツールやフレームワークを用いてドキュメントに残します。
受益者理解
キックオフ（もしくはその後のミーティング）時に作成したドキュメントを元に受益者理解を進めます。関係者や身近なカスタマーにヒアリングを行い、コアチームメンバーの認識が各受益者とずれていないか？を確認します。この場合の「受益者」とは顧客としてのエンドユーザーだけではなく、プロダクト／サービスに関わる受益者全てを指します。
この段階での情報収集がとても大切で、リアルな声を集め、それを分類し、課題を顕在化させ、プロジェクトの全体像を把握するための全ての情報がテーブルに並べられている状態を目指します。
カスタマージャーニーマップの作成
受益者理解で得られた情報を元にカスタマージャーニーマップを作成します。カスタマージャーニーマップで、ユーザーがプロダクトやサービスを利用する前後も含め、全過程を可視化します。このマップを使用してAs-Is（現状）とTo-Be（あるべき姿・理想の状態）を明確にするとともに、関係者間での認識を統一させます。しかしこれはあくまでも認識を統一させるためのものです。
カスタマージャーニーマップを作ってプロダクト開発に進んでしまうシーンをよく目にしますが、ここからが本当のスタートです。
ステップ２: 提供価値の設定と検証
具体的なアクションを議論します。常に仮説を立てた上で、ユーザーインタビューなどを行い、MVP（Minimum Viable Product）を探ることを目的とします。
ユーザーストーリーマップの作成
ユーザーストーリーマッピングでは、ユーザーがプロダクトやサービスを利用して行う作業をステップごとに細かく分解します。ステップごとの課題を全て洗い出し、課題の優先度を決めていきます。
どのステップの、どのポイントにユーザーの負があるか？競合他社も含めて、解決できる課題と解決できない（されていない）課題を明確にし、自社にとってバリューとなるポイントを探り、仮説を立てます。
バックログ運用（課題ごとの目的・達成基準・優先度・進捗を管理）
ユーザーストーリーマップで出た課題はバックログと呼ばれる作業リストで管理します。各課題に応じての仮説を元にアクションプランを検討します。仮説検証は、ユーザーインタビューや簡易モックアップなどで行います。
ステップ３: 開発
プロダクト／サービス開発
MVPの検証を終えた段階で本格リリースに向けたプロダクト／サービス開発に着手します。機能やコンテンツの追加はあくまでもMVPを強化する（補助する）ものから実装します。この段階でも常に仮説を立てた上で、実装後の効果検証を繰り返します。
ステップ４: マーケット展開
広告出稿、コンテンツ更新、イベント開催等
PMF（Product Market Fit）を目指しプロダクトやサービスに応じた施策（広告出稿やコンテンツ追加、リアルイベントの実施等）を行います。
さいごに
世の中にはたくさんのビジネスフレームワークがあり、使われ方も様々です。新しいフレームワークを試して改善していくことは素晴らしいことですが、それよりも何よりも“チームで認識を共有しながら信じてやりきる”ことが大切です。
あと最近よく思うのが、プロダクトやサービスの開発をしていると知らず知らずのうちに「仮想敵」や「リアルな敵」を作ってしまいがちです。しかし無駄な敵を作ったり、プロジェクトの周辺にある様々な事情に振り回されることなく、解決したい課題や達成したい未来にフォーカスして取り組むことが、より良いプロダクトやサービスを作るために大切なことだと思っています。
自分も、真摯に課題に取り組む姿勢を忘れないようにしたいと思います。
本記事に関して、もし気になることや「これは違うよ」といったご意見など、何かございましたらお声がけいただけますと幸いです。よいプロダクトやサービスをつくりましょう！
この記事が気に入ったらサポートをしてみませんか？