大阪勉強会「クラスメソッドのデザイン・体験づくり事情大公開スペシャル 」で登壇しました〜受託開発の中でデザイナーが実施したユーザーテスト奮闘記〜

こんにちは。CX事業本部改め、リテールアプリ共創部のスギヤマです。普段はモバイルアプリケーションやLINEアプリケーション開発に携わっております。

ノウハウを学ぶ勉強会in大阪のテーマは「デザイン・体験づくり」

今回の「クラスメソッドの最新開発ノウハウを学ぶ勉強会 in 大阪」では、「クラスメソッドのデザイン・体験づくり事情大公開スペシャル」と称し、クラスメソッドの受託開発における提案について詳しくお話いたしました。

概要

今回のテーマは「デザイン・体験づくり」です。 弊社CX事業部では新規サービスの立ち上げや既存サービスの拡大に伴って、モバイルアプリやWebアプリの受託開発のUI/UXデザインを行なっております。開発前にデザイナーが顧客の要望や課題を把握して、顧客体験を考えた上でアプリデザインを行なっております。 その中で培った技術・知見や最近のデザイン事情などを今回は登壇者の方々に惜しみなく発表していただきます。

登壇内容

https://classmethod.connpass.com/event/305278/

スギヤマからは「受託開発の中でデザイナーが実施したユーザーテスト奮闘記」としまして、実際の現場での奮闘をご紹介しています。

アジェンダ

・ゴールの確認

・プロジェクトの概要とサービスについて

・なぜユーザーテストが必要だったのか

・計画フェーズ

・実施フェーズ

・分析フェーズ

・抽出した改善案と今後の展望

・デザイナーチームの紹介

ゴールの確認

受託開発である弊社が、普段どうやってデザイン領域の提案をしているかの例を詳らかにご紹介する。

ソロテストの「奮闘ポイント」の共有

受託開発では多くの制約があります。今回実施までの大変だったポイントを紹介。

小さく始められる「気軽ポイント」の共有

ミニマムにタスクを絞り込みつつも効果的なテストを実現しました。うまくいったポイントを紹介。

プロジェクトの概要とサービスについて

「某スーパーAのLINEの会員証サービス」について

LINE上で表示するポイントカードサービス

某スーパーAにてお買い物の際、お手持ちのスマートフォン１つでスーパーのAポイントを貯めて使うことができるサービスです。

さらに別会社Bのポイントカードをあらかじめ登録すると、Bポイントも貯めて使うことができます。一度のバーコード読み取りでA、B両方のポイントを貯めることができます。

一回のバーコード読み取りでA社B社両方のポイントが貯まるという機能は、他ではなかなか見られないものです。

アプリのイメージ画面

サービスの開発期間とテストの実施時期

開発期間のざっくりとしたイメージ

2021年4月から開発開始。2022年4月にリリース。リリースから1年経過した2023年6月にテスト（赤の部分がテスト期間となります）を実施しました。

なぜユーザーテストが必要だったのか

どうしてユーザーテストが必要だったのはの背景について3つのポイントにまとめました。

暗闇から脱するために

① ユーザーを知る

実際の４月お問い合わせ数割合（ピンク＝女性、青＝男性、緑＝不明）

メインユーザーは50~60代の女性です。また問い合わせ数もこのレンジが最も多くなっています。

この年代のユーザーがどのようにスマートフォンを利用しているのか、私たちは把握していませんでした。周囲に同年代のユーザーがいない中で、メインユーザーについての理解が不足していました。

そのため、このユーザーの特徴を深く理解しなければ、潜在的な問題も見逃してしまう可能性がありました。

奮闘ポイント

ウォーターフォール開発はお客様の手動で開発が進みます。どうしても構造上、開発要件とビジネス要件が優先され、サービスのユーザー視点が抜けがちになるため、必要性を進言することが肝要となります。

② 問い合わせの発生

実際の４月・５月お問い合わせ種類の割合

定期的に寄せられる「登録ができない」「つまづいた」といった問い合わせが複数ありました。新規登録はサービスの入り口であり、そのスムーズな進行は重要です。問題があれば、ユーザーがサービスを利用する前に離脱する可能性が高まります。この問題に対処するために、早急に登録プロセスにおける課題を特定し、改善する必要があります。

奮闘ポイント

2022年春に直接UIについて詳細クレームが挙げられました。これはピンチですが、チャンスでもあります。外圧的動きはお客様への説得材料とすることができます。

① リリース後の検証

リリースから1年が経過し、2023年3月、保守の契約についての計画が浮上しました。サービスにおいて単に新規追加を行うだけでは不十分です。ユーザー調査なしに、開発者都合の新規機能追加だけでは、改善は難しいのではないかと考えました。ユーザーの声を取り入れ、本当に必要な問題点を見極める必要があります。

計画フェーズ

どのような計画を立てたのか３つにまとめています。

１人で行うミニマムテスト計画

①プロジェクトマネージャーとの連携

実際のプロダクトマネージャーとの計画立案のようす

リリース１年目、お客様と弊社メンバーが一同に介し、付箋を使って振り返りをするワークショップを行いました。この会議において、各メンバーが自身の目標計画を発表する機会がありました。この中で、私はユーザーテストの重要性をメンバーに訴えました。

その後プロジェクトマネージャーと連携してお客様にユーザーテストの実施を打診しました。

気軽ポイント

普段から問い合わせなどの内容が共有され問題点が共有されていたこと。またプロジェクトマネージャーがユーザービリティテストの重要性をあらかじめ理解してくれていたため、計画の打診がスムーズに進みました。

②身近な人を巻き込んだテスト

実際の募集Slack

エンドユーザーをお客様から取り計らっていただくことは難しかったため、チームメンバーの家族や社内で50代以上の方を募集し、テストに協力してもらいました。お客様の事情により難しい状況でも、弊社内での協力を得ることでユーザーテストを実施しました。

気軽ポイント

「スーパーAでアプリを使って買い物をする」という、比較的簡易なテスト計画であったため、容易に実施することできました。ユーザビリティテストではこのリクルーティング部分が最も難しいと感じます。たとえば「家（高額な商品）を買う人が対象のフロー」「離婚歴がある方を対象にしたフロー」といったユーザーを集めなければいけない場合は、受託会社だけでユーザーを集めるのは至難の業。お客様にご協力いただく必要があります。

実際に集まったユーザー

私たちは社内でテストに参加できる人員を募集しました。結果、外部から2名（チームのご家族の60代女性）、社内から5名が手を挙げ、最終的に3名の方にテストを実施することになりました。

• 第１回　Oさん（50代　男性）
• 第２回　Xさん　(60代 女性)
• 第３回　Iさん　(50代 男性)　で実施

奮闘ポイント

本当ならば4名を予定していたのですが、急遽テストをする店舗がテスト数日前に閉店してなくなってしまうというアクシデントがありました。このテスト店舗は外部の60代女性にご協力をいただく予定でしたので、大変残念でした…。

③ツール・予算はミニマムに

予算の制約があったため、多額の費用をかけることや他のサービスを利用することはできません。ユーザーテストを最小限のリソースで実施するため、テストの撮影にはスマートフォンのみを活用しました。ミニマムな体制で最大限の効果を追求しました。

報酬にはQUOカードを用意。経費の関係上、報酬は現金ではなく金券である必要があります。今回は社外の60代女性にもお願いしていたため、AmazonポイントなどではなくQUOカードとしました。

気軽ポイント

お客様から予算をいただけたらラッキーですが、なかなか難しいのが現実。今回は1000円✕人数を部門長から部門経費として出していただき、交通費はユーザーの近所のテスト場所とすることで節約しました。

実施フェーズ

計画が終わり、いよいよ現地での実施です。3つにまとめました。

透明人間がゆく

①3つのストーリーの作成

3つのストーリーと補足

テストシナリオは、大きく3つに分類しました。「店舗でサービスを見つけるまで」「新規登録を終えるまで」「実際に店頭でサービスを使うまで」の3つのストーリーを作成し、これらを基にテストを進行しました。

課題抽出中のMiroの画面

こちらは撮影動画の課題抽出を行なった付箋画面です。「赤：店舗でサービスを見つけるまで」「黄色：新規登録を終えるまで」「緑：実際に店頭でサービスを使うまで」ごとに付箋が整理されています。

②透明人間作成

テストの様子

評価者は透明人間として振る舞い、ユーザーの動向を見守りました。

参加者にはシナリオのタスクを達成してもらうよう指示し、テストの検証はビデオ撮影によって行いました。背後で透明人間として沈黙し、撮影に専念します。

もしも参加者がどうしてもタスクをこなせない場合は「ストップします」と言ってもらいます。そして、タスクを完了できないことは大きなユーザビリティの問題です。参加者には事前に「できなくても全く問題ないすべてはこちらに原因がある」と説明しています。

思考発話法の実施

ユーザにタスク（課題）を提示し、その実行過程において考えていることを話しながら操作してもらう手法を実施しました。ユーザの行動と発話から、インターフェース上のどの部分に問題があるのか、なぜその問題が起きたのかを詳細に把握できます。

③インタビューとアンケート

スコアと自由回答のアンケート

テストの最後には、参加者に対して軽いインタビューを行いました。また、事前に用意した5段階評価のアンケートにも回答してもらいました。これにより、ユーザーの直接的な意見や感想を収集し、テスト結果をより深く理解することができました。

分析フェーズ

ここからプロジェクトマネージャーやエンジニアに合流してもらい、分析を行なっていきます。

他のメンバーも加えた分析

動画を見ながら記録をしていく

①動画を時間でメモ

動画を時間ごとに観察し、ユーザーの行動や起こった事象を客観的にメモします。具体的な行動に基づき、「◯◯した」といった客観的な事実を記録します。気になる箇所にはマーク「★」を付けておき、後で見返す際に効率的にチェックできるようにします。

奮闘ポイント

１人でやるのはなかなか大変。またどこを取り出すか、属人化する恐れがあり。２人以上でチェックをしたほうが良さそう。

②課題感をブレスト

動画のユーザー行動メモが完成したら、プロジェクトマネージャーや開発エンジニアを巻き込み、動画を共有します。さまざまな視点から、自由に課題を出し合いました。ブレストの原則に従い、異なる視点からアイデアを出し合い、問題点を広く理解しました。

ブレインストーミングの4原則（アレックス・F・オズボーン）

・判断・結論を出さない（批判厳禁）

・粗野な考えを歓迎する（自由奔放）

・量を重視する（質より量）

・アイディアを結合し発展させる（結合改善）

③課題を構造ごとに選り分け

話し合って出た課題をグルーピングします。濃い付箋がグループごとのタイトル＝課題名です。

次に発生頻度ごとに分けていきます。

インパクト分析を利用します。課題の性質を理解するために、ニールセンのユーザビリティ定義である「効果」「効率」「満足度」を評価しました。

左上が最も重大であり、必ず解決するべき問題です。右下に行くに従って、できれば解決するべき問題となります。この選り分けを参考に、お客様への課題提案としていきます。

オーム社 ユーザビリティエンジニアリングより引用

各タスクがUX構成要素5段階モデルのどこに属するかも把握します。これは課題解決の難易度や、どの程度お客様にご協力いただく必要があるか、あるいはこちらだけで解決が可能か、の判断の材料となります。

近代科学社 人間中心設計入門より引用

抽出した改善案と今後の展望

抽出された課題の一部

エラー画面がわかりにくい

ユーザーの次の行動を促すようなエラー画面に修正が必要。

→改善対応を実施

クレジットカードの番号が入力しづらい

番号入力で戸惑うケースが見られたため、よりよい入力フォームが必要。

→改善対応を計画中

仮登録の機能がわからない

仮登録と本登録というステータスが存在するが、仮登録では何もできないと認識されてしまった。新規登録してすぐ仮登録中の機能がうまく伝わっていないため情報を整理する必要がある。

→改善対応を計画中

誰がやっても簡単にできるように

今回かかった時間を算出しました。属人化しないように・今後改善が繰り返されるように内容をチームで共有しています。

各項目ごとにフローを整理。かかった時間をまとめてメニュー化しています。

やってみてどうだったか

• ３人では少ない。ヤコブの法則（5人テストすれば85%の問題が発見できるという法則）に従い５人は確保すべきだったリクルーティングは最も難しい課題。
• ３人のユーザーの状況が厳密には違った。事前に状況をもう少し詳細に定義する必要があった。やったあとに気がついた。場数が必要かも。
• 事前準備や情報共有はもっと丁寧に行うべきだった。たとえ時間がかかってもお客様との連携はしっかりと。

まとめ

奮闘ポイントをふまえて

受託開発で体験設計提案をするなら、タイミングが大事。また普段から「やりたい」という意志や課題感を周囲やお客様にアピールしたい。

気軽ポイントをふまえて

プロジェクトマネージャーなど理解のあるスタッフと話し合えるとラッキー。また制約が多くてもミニマムにすることで実現し、実績としてつなげることも。できる範囲でもやってみることが大事。

さいごに

いかがでしたでしょうか。普段の仕事の雰囲気が少しでも伝われば幸いです。

またクラスメソッドではデザイナーの募集もしております！一緒に開発をしてみたい、いろいろなサービスやプロジェクトに携わってみたい！という方はぜひ採用ページもご覧ください。

クラスメソッド採用ページ

https://careers.classmethod.jp/