新人デザイナーが初めての改修でリサーチをした話

2022.01.18 Design Study Morning Vol.6 登壇資料

Transcript

1. 新人デザイナーが 初めての改修で リサーチをした話 上田 利瑳子 / GMO PEPABO inc. 2022.01.18 Design Study Morning Vol.6 1
2. 2 自己紹介 ホスティング事業部　マーケティングチーム 2021年 新卒入社 上田 利瑳子 （uepon） • アニメ・漫画・温泉・ビール・キャンプ 好き • 先月、3歳のかわいい息子と誕生日ディズニー • 人生初LT☺ • Twitter : @rimmmonga
3. 3 主に担当しているサービス ムームードメイン ロリポップ！レンタルサーバー サーバーを使ってウェブサイトやブログが作れるサービス （昨年11月で20周年🎉） 欲しいドメインが簡単に検索・取得できるサービス
4. 最初に 4 • デザイナーが小さくリサーチを始めるプロセス • スピーディーにユーザビリティテストを実施するには • 簡易版でもユーザビリティテストを実施することで得られるもの 今回の話から得られるかも？🐯
5. テーマ「改修事例とそのプロセス」ですが 何を改修したの？ 5
6. よくあるユーザーさんの希望 6 サーバーを借りてサイトを作りたい！ 好きなドメインをとって設定しちゃいたい 🙂
7. 従来の仕様 7 サーバーとドメインは別に申し込まないといけない… 運用元は同じなのに、別々になっているの面倒だなぁ 😥
8. 現在 8 ロリポでサーバーを申し込む時に、 欲しいドメインも一緒にとれるようになった！ 😄
9. ロリポップのサーバー申し込み画面 9
10. 10 何を改修したの？ 二次リリース 初期リリース 「ムームードメインの新規ユーザー登録が必要で す」既にムームードメインのアカウントを持っている 人にやさしくない仕様 😢 ムームードメインのアカウントを持っている人は、 すぐにID連携して利用できるように 🎉 👆こっちの改修を担当しました！ 󰢧(私)
11. 施策開始後、やったこと 11
12. 改修プロセス 12 施策全体を通じてやったこと • 全体を俯瞰して変更が必要な点の把握と洗い出し • 仕様の把握 • スケジュール立て・工数見積もり • 申し込み画面の改修（UI検討〜実装） 👈 主に話すのはココ！ • 入力フォームのUI検討・修正 • メールの変更点洗い出し・修正 • エラー画面の変更点洗い出し・修正
13. 改修プロセス 13 「申し込み画面の改修」でやったこと • デスクリサーチ • 競合調査・自社サービス調査 • 要件定義 • 改修のスコープ決め • UIプロトタイプ作成 • レビュー・ヒューリスティック評価 • 簡易ユーザビリティテスト 👈 主に話すのはココ！ • ブラッシュアップ・デザインFIX • コーディング（エンジニアさんと分担しつつ実装）
14. 改修プロセス 14 最初からユーザビリティテストありきだった？ • いやいや、違います！ • 「レビューだけじゃ判断しにくいね」という場面に出くわしたから • もしそのままGOしてしまったらこうなる未来が見えた…😇 • せっかく実装しても使ってもらえない機能になる😨 • お問い合わせ頻発・最悪クレームの可能性も😡 • デザイナーの自己満UI爆誕💣 • つまり…途中で「ユーザビリティテストをした方がいい」状況になった！
15. 改修プロセス 15 レビューだけじゃ判断しにくかったポイント • エラーメッセージに関する懸念😥 • システム側の事情で複雑なエラーパターンが生じた • 「このエラーメッセージで本当に通じるんだろうか？？」 • エラーの状況をうまく伝える・行動を促すのが難しい… • 「ボタンの有り・無し」どっちがいいか判断できない😥
16. サービスをまたいだ仕様による、複雑なエラーパターン 16 👇デザイン案に対するコメント
17. ログインボタンがないことに対する不安 17 👇デザイン案に対するコメント
18. 「ユーザビリティテスト やった方がいいね！」 18 そして翌日やることに󰝋💨
19. ちょっと待った！ 19 とは言え・・・ユーザビリティテストってそう簡単にできないよね？？ • スケジュール大丈夫？リリース間に合う？ • すんなり「やりましょう」ってなった？ • 関係者の人達に説得できたの？
20. ふり返ってみると・・・ 20 結論：あまり時間をかけずに「簡易版」で実施したのでなんとかなった • 準備〜振り返りまで 6h程度の工数（1営業日以内）で実施できた󰢏 • もともと見積もっていた施策全体の工数の範囲内でおさめることができた • リリーススケジュールを遅らせたりなどせず、関係者に共有する程度で実施できた • 先輩デザイナーが「4h程度でできるね」と見積もってくれた（結果＋ 2h）
21. ユーザビリティテストのプロセス 21 ユーザビリティテストの過程でやったこと󰝋 • テスト設計 • 社内リクルーティング • ユーザビリティテスト実施 • 発話思考法を使用 • 分析 • 振り返り • ドキュメントまとめ
22. 実際にこんな感じで やりました 22
23. 23 テスト設計＠Notion
24. 24 社内リクルーティング＠Slack
25. 実施：プロトタイプ 25
26. 実施：プロトタイプ 26 連携ボタンの有り・無し 2パターンの各評価を得るため、 1案につき2名ずつ実施（一人1案）
27. 結果記述・簡易分析 27
28. どんなことが明らかになった？例 1 28 エラーメッセージを見た後の行動が（想定外のもの含めて）明らかになった • ユーザーは「🤔💭 ムームードメインへのリンクがあるだろう」と想定して、リンクを探す行動をする → リンクが見つからず、困惑した動きを見せる • 内容を読まずに「🤔💭 ID・パスワードの入力ミスエラーか」と想定（誤解）して再入力しようとする（ エ ラーメッセージ＝入力ミス という先入観があり、そもそも読まれない ）→混乱する • 「🤔💭 ムームードメインで個人情報を登録しなきゃいけないなら、今回はやめておこう」 →後から別にムームードメインでドメインを取得しようとする
29. どんなことが明らかになった？例 2 29 成功メッセージの意味が伝わっていなかった • 「下記の注意事項の確認に進んでください。 」の「注 意事項」が何を指すか分からず、どこを見ればよい のか混乱していた人がいた
30. どんなことが明らかになった？例 3 30 連携ボタンの有り・無しはどちらでも問題なさそうだった（確信）
31. “簡易版”でも 多くの判断材料が得られた！ 31
32. ちょっと待った！ 32 色々やってるけど… • これ本当に1日以内で全部できたの？？ • やり方を調べたりドキュメント準備とか大変そう。 • 残業した？！？！
33. ふり返ってみると 33 スピーディーにできた理由は・・・ • 社内リクルーティング（午前）→ 当日午後に参加できる人を募った（ 15分程度） • テスト対象者：4名（検証のために最低限必要な人数） • 既にあるテンプレ（先輩たちの知見・ドキュメント）を使いまわした • プロトタイプ準備コストがほぼかからなかった • 機能開発系は普段のレビューからプロトタイプを用意してるので、微調整だけで済んだ
34. 「簡易版」って何だろう 34 どこが「簡易版」なの？ 今回、簡易にしたポイント • 「5人の評価者で発見できるユーザビリティの問題の検出率は約 84%」（Nielsen and Landauer, 1993） → 4人 • テスト前後の調査協力者への インタビュー実施 → 2〜3分程度 • 発話の録音・書き起こし → その場で記録 • 「UXメトリクス」を用いた 分析方法もある → 今回は使わず https://u-site.jp/usability/evaluation/usability-test より引用
35. リリース後、 結果どうなった？ 35
36. 改修その後 36 リリース後、数値でも改善が見られた🎉 • そもそも「対象ユーザーは少ないだろう」ということで、 二次リリースに回された範囲の改修だったが … • リリース後、ドメイン同時取得率が 3.4%上昇 🎉（リリース前後の各1ヶ月間で比較） • 対象ユーザーにこの機能を利用してもらえていると言えそう 🕊
37. 37 Thank You! Thank You! noteにも違う視点から書いてるのでよかったらぜひ見てください🎉 「新人デザイナーが小さく始めるUXリサーチ」