この記事はLAPRAS Advent Calendar 2024の15日目の記事です🎅🏼
はじめに
こんにちは、LAPRAS株式会社のソフトウェアエンジニア、でうぎです。
この記事では、自社のサービスエンジニア採用のLAPRASのUX改善策を見出すために、行ったワークショップについて共有できればと思います。
UX改善ワークショップを行った背景としては、漠然とUX改善したいなと思っていた自分が、ある日に社内でワークショップを主催することをきっかけに、テーマをUX改善に決めたことです。
(自分にとっては漠然と思っていたものが言語化もできたよい機会でした)
ワークショップを開催する前に、自社のプロダクトがUXピラミッドを基準にして、どのレベルかを評価してみました。
結果、｢レベル3-使いやすい(Usable)｣を強化しつつ、｢レベル4-便利である(Convenient)｣を増やす必要があると思いました。
そのため、このワークショップは｢使いやすい｣と｢便利である｣にフォーカスされています。
UXピラミッドについてはこちらをご参考ください。
ワークショップの流れ
ワークショップの流れとしては、自社のプロダクトを実際に使いながらペインポイントを洗い出す。
それをもとに改善策をブレインストーミングして、優先度を決めることになっています。
前半
前半はドッグフーディングしてペインポイントを洗い出す流れになります。
1. 改善したいユースケースやフローを決める
サービス全体のUXを改善するには範囲が広いので、まずは改善の対象とするフローやユースケースを決める必要があります。
私たちの場合、一番頻度が高い以下のようなユースケースにしました。
｢自社の求人にマッチする候補者を人材プールから探して、興味通知、またはスカウトメッセージを送信する｣
2. 時間とゴールを決める
改善したいユースケースやフローを決めたら、より具体的なゴールと制限時間を決めます。
後述しますが、一人ひとり交代で行うので一定したゴールと制限時間を設けた方が同じところに集中しやすいと思ったからです。
例えば、｢制限時間は00分｣、｢ゴールは〇〇求人にマッチする候補者を探し、興味通知Xつ、スカウトX通を送る｣のようにします。
ゴールを達成した、または制限時間になったらプロダクトの操作は終了となります。
3. ペインポイント、気付きの洗い出し
では、ゴールに向かってプロダクトを使っていく時間です。
1人はドライバーになり、他の人はオブザーバーになります。
全員1回はドライバーになるように交代して行います。交代タイミングはゴール達成 or 制限時間になったときです。
(人数が多ければ、一つのグループで最大4人程度が適切です。オブザーバーする時間が長くなるほど集中が切れてしまうからです。)
ドライバーになった人はできる限り、自分の考えを言葉で表現しながら進めます。
もし、ドライバーが言葉にせず、無意識的に操作をしたことについて、オブザーバーは、なぜその操作をしたかなどの疑問が生じた場合、流れが途切れない範囲であればドライバーに質問しても良いです。
オブザーバーの人は思ったこと、気づいたことをメモに書き出し[1]ます。
4. ペインポイントのグルーピング
全員ドライバーを終えたら、オブザーバー時に書き出したメモを一人ひとり共有しながらグルーピングしていきます。
メモ内容を共有する際に、他の人は似たような意見があったら同じグループにメモを移す、また更に気づいたものがあればメモを追加します。
グルーピングは抽象的すぎないように注意が必要です。目安になる大分類としては「UI、機能の正確性、機能の便利さ、性能」のようにして、もう一段掘り下げた感じでグルーピングします。
グルーピングの例としては
- 〇〇をするためには画面を何度か行き来することになる (機能の便利さ)
- 〇〇機能の結果が不正確 (機能の正確性)
- ボタン押してからローディングの時間が長い (性能)
- 〇〇ボタンが押しづらい (UI)
5. グルーピングしたペインポイントのランク付け
洗い出したペインポイント全てに対して改善できると理想ですが、現実問題ではそうにはいきません。
グルーピングされたものの中で、ランクを付けて上位5つを選び[2]ます。
(選ぶものの数はグルーピングされた数やチーム規模などによって異なるので、感覚値で決めると良いと思います)
後半
ここからは実際にどう改善していくかを考える流れになります。
前半だけでもかなり疲れたり、時間がかかったりすることもありますので、前半と後半を別の日に分けることも良いかと思います。
6. 改善策のブレインストーミング (発散)
前半でランク付けして選んだペインポイントに対して改善案をブレストします。
特定のブレストのやり方に合わせる必要はなく、チームのスタイルに合わせて行えば良いかと思います。
ただし、基本的にはブレストの4原則は踏襲すること加え以下も行うことを推奨します。
- 実現可能性はこの段階で考えないこと
- 自分と同じアイディアを他の人が先に書いたとしても、自分も書くこと
7. 改善策のグルーピング (収束)
ペインポイントのグルーピングごとブレストした改善策を更にグルーピングします。
この段階では「〇〇を△△する機能を作成」「〇〇のUIを〇〇に修正」など、かなり具体的な内容としてグルーピングされます。
ここでグルーピングされた改善策についてはランク付けはせず、全て次の段階へ進めます。
8. 優先度を決める
グルーピングした具体的な改善策を「効果軸」と「不確実性」を軸で配置して、「予想コスト」を丸の範囲で表現します。
目的としてはどこから取り組むべきかを決めるための目安をつけることです。
マトリクスの例 (内容をマスキングした私たちのワークショップの結果です)
配置やコスト見積もりは今までの経験に依存した感覚値で大丈夫です。
前回の改善策のグルーピング名が抽象的過ぎてしまうと、マトリクスへの配置や予想コストを見積もりに迷いが生じることや、後でみたときに「これ、なんのことだったけ🤔」となる可能性があるため、注意が必要です。
ただ、改善策は洗い出したペインポイントからさらに深堀りしたものになっているので、この段階で抽象的すぎな表現になることはあまりないかと思います。
取り組む順番としては、不確実性が低い&効果が高いものの中で、コストが低いも順になります。
配置してみてから気づいたことですが、不確実性が低いものはコストが小さい、不確実性が高いものはコストが高くなる傾向がありました。(当たり前かも？😅)
ここまでがワークショップとしての終わりです。
その後 (とても大事)
ワークショップで順番を決めた改善策はBacklogなどで管理しながら、実際に改善に取り組みます。
まだ開発に着手してないものに対しては、リファインメントしたり、ユーザーの行動や成果の計測値を足したりすることで、より実現可能なレベルまで具体化を進めます。
その過程で、ワークショップの最後ステップで作ったマトリクスの配置を変えるなど、常に最新化をして優先度を調整していきます。
まとめ
ユーザーテストやユーザーインタビューがしたいけど、対象者の募集やコスト的な課題があるときにはドッグフーディングは良い方法だと思います。
ですが、単純に進めてしまうと改善ポイントがまとまらなかったり、優先度決めが難しくなったりすることもあると思います。
ドッグフーディングや実務で自社のプロダクトを使ってるけど、どう改善していけばいいか悩んでいる方がいらっしゃいましたら、このワークショップを一度試してみるのはいかがでしょうか？
- 自社のプロダクトのUXを自己評価する
- ペインポイントを洗い出す (自社内でのユーザーテスト)
- 改善策をブレインストーミングする
- 不確実性、予測効果、予想コストを基準で改善する順番を決める
Discussion