UIUXデザイン-KIDSNAシッター編（後編）

2022年10月20日 10:23

こんにちは！
私はKIDSNA シッターで、デザインに携わっているAMIです。
こちらは、KIDSNAシッターに携わるデザインと開発メンバーで行ってきたUIUX改善の一部を紹介する記事の後編となっております。

前編の記事はこちらから

カスタマージャーニーマップを使いこなそう！💭

UX改善を目的としたUIを作成するには、プロダクト自体の改善点だけでなく、ユーザーの利用シーンや文脈に沿ったユーザー目線での必要機能の検討が不可欠になります。
KIDSNAシッターでは、プロダクトのコアな機能を改修する際にデザイナーがカスタマージャーニーマップを使って機能改善の提案を行っています。
特に、ジャーニーマップを作るだけで終わるのではなく、その後にどうやって提案や実装に結びつけるのかを意識して動いてきました。
今回はそのやり方やコツなどをnoteの記事にまとめました！

💡どのように行なったか

①まずはAS-ISとTO-BEの繋がりを見える化する
②改善案を切り出し、別のフォーマットにまとめる
③ 第三者が"評価できる"改善案にする
④実際に開発フローに組み込み、検証の環境を構築する

①まずはAS-ISとTO-BEの繋がりを見える化する

実際にジャーニーマップを作ったデザイナーには意味が理解できますが、他職種や第三者にそのまま展開する際は「見るべきポイント」をおさえることが重要です。特に忙しい意思決定者は全てに目を通す時間などないので、情報が整理されていないと「これって結局何が言いたいの？」「根拠はあるの？」と頭の中に疑問が先に出てしまいます。そうなると、せっかくのデザインプロセスに沿った提案が信頼できないと感じられてしまうかもしれません。
そうならないためにも、以下のポイントをおさえることを心がけています。

・AS-IS の根拠を示す

カスタマージャーニーマップの軸となるのがAS-ISで導き出された「ユーザーの不」の部分です。ここでユーザーが大きく課題を感じる点を示すのと同時に、その根拠となる利用文脈がどのインサイトを元にしているのかを最初に明らかにします。

・TO-BEの改善案があると、ユーザーはなぜ嬉しいのかを示す

ユーザーの「不」を解決した状態を描くTO-BEのジャーニーマップですが、
ただこう解決したらユーザーは嬉しい！と言うだけでなく、一連の体験の中で「ユーザーは何を大事にしているのか」「何がユーザーにとってうれしい価値なのか」に触れておきます。
ここで触れておくことで、なぜこの改善案がUX 改善に有効だと考えられるのかが繋がりやすくなります。

②改善案を切り出し、別のフォーマットにまとめる

TO-BEモデルのカスタマージャーニーマップから改善案が出たら、整理するためにもスプレッドシートなど他の場所に書き移すことをおすすめします。
ジャーニーマップは通常、複数枚作ることが多いですから、改善案だけをまとめて見たい時に一箇所にまとまっていると良いです。
事業がスクラム運営を行なっていれば、中身によっては直接プロダクトバックログに書いてしまっても良いかもしれません。

③第三者が"評価できる"改善案にする

カスタマージャーニーマップに限らず、デザインプロセスの中で施策をブレストして多くの案が出たら、その案をまずは評価できる形にしてみましょう。ここでいくつかポイントをご紹介いたします。

・4象限マトリックスの形にする

これは施策の優先順位をどこから評価したら良いか分からない時や、開発メンバー以外の事業ステークホルダーと新規機能追加などを進めたい際におすすめのフレームワークです。
この4象限マトリクスのうち、コストが低くユーザーへの価値も高い「High ROI」は経営としても重視されがちですが、このポジションの施策はあまり多く出ることはないと思います。特にプロダクト開発で重要なのは、コストが低くすぐに取り掛かれてユーザーへ小さくても価値を提供できる「Quick Win」です。
施策を考える際には、「Quick Win」の施策を多く出すことも同時に意識すると、まずはやってみるという次のアクションにも繋がりやすいでしょう。

・自由に並べ替えできる形にする

施策の優先度や重要度を最終的に決めるのはデザイナーではありませんが、今回はユーザー価値の調査やCJMなどデザインプロセスを通し、何がどのくらいユーザーに効果的な施策なのか？を仮説立てて、優先度の判断材料になるような指標を作ることは重要だと考えます。今回はそれをユーザー価値＝CJMによる価値 としました。定性的に以下の指標で施策を評価します。

1.ちょっと便利　　　　　＝ CJMで改善によって少し満足度が向上した箇所
2.あったら嬉しい　　　＝ CJMで改善によって満足度が向上した箇所
3.ないと困る(離脱する)　＝ CJMで大きくペインだった箇所

第三者へ展開する際には、この指標はあくまでデザインプロセスに沿ったユーザー価値の仮説だということを説明しておきましょう。
また、そう言える根拠として定性・定量的なデータがあれば参照できるようにすると第三者がデザイナーと同じ目線に立って議論することが易しくなるでしょう。
他の指標も適宜追加し、並べ替えできるようにしておくと次のアクションに繋がりやすいと思います。

④実際に開発フローに組み込み、検証の環境を構築する

今回は③のステップでネクストアクションが決まったので、普段運用しているプロダクトバックログに起票し、全体の優先度と共に整理して施策に着手していきました。
要件定義を進めていく際には、ユーザー価値の仮説をどう検証するのかを念頭に入れておくことが重要です。
その施策がどのKPIと紐づくのかはプロダクトバックログで全員が認識できますが、リリース後にその施策の効果があったのかどうかをどの数値や定性的データで見るのかを確認しておきましょう。
特にスクラム開発では、仮説検証のためにMVP(Minimum Viable Product)を構築しスプリントを回していくので、検証結果によって次の改善や、さらなる施策の優先度を決める判断材料にもなるデータが必要です。
この点は、事業チームの中でも課題として捉え、日々より良い方法を探っています。
データ分析の手法については、また別の機会にご紹介したいと思います！

まとめ

前編では、KIDSNAシッターでの『競合アプリ調査』と『価値分析』の行い方の2点をご紹介し、こちらの後編記事では『カスタマージャーニーマップ〜仮説検証』までをご紹介しました。