UX/UI改善に貢献するユーザーテストとは？基礎知識から実施のプロセスまで解説

Slide 1

Slide 1 text

UX/UI改善に貢献するユーザーテストとは？基礎知識から実施のプロセスまで解説 2023 / 11 / 29 NCDC株式会社 NCDC Online Seminar

Slide 2

Slide 2 text

自己紹介 2 建設業向けアプリのUX/UIデザイン、業務システムのUI改善などのプロジェクトのほか、NCDCのUXデザイン方法論の策定メンバーとしても活躍。複雑な機能を持つ業務システムのUI設計では、業務フローの理解からユーザーヒアリングまで多くの情報をインプットして分析を行うなど、ユーザーに寄り添って考える情報設計を得意としている。経歴東京造形大学絵画専攻卒業東京デザインプレックス研究所 UI/UXコース修了数年間にわたり現代アート事業や広告制作プロダクションに従事し、クリエイティブデザインやイラスト制作に携わる。その後、関心を抱いたUX/UIデザインや人間中心設計（HCD）などを学び、 NCDCにUX/UI デザイナーとして入社。 UXデザイナー伊藤玄哉

Slide 3

Slide 3 text

NCDCのご紹介

Slide 4

Slide 4 text

Business 事業領域の推進 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • コンサルティング • 新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI / AR • クラウドインテグレーション 4 NCDCのサービス体系

Slide 5

Slide 5 text

本セミナーについて l 受講対象 l サービスやプロダクトの要件定義・設計・開発の担当者の方 l サービスやプロダクトの要件定義・設計・開発を推進する意思決定を行う方 l 概要 l ユーザーテストに関する以下の内容について解説します。 l 基礎知識 l 実施プロセスの流れと内容のポイント l その他リサーチプロセス l まとめ 5

Slide 6

Slide 6 text

はじめに UX/UI改善に貢献するユーザーテストとは？

Slide 7

Slide 7 text

ユーザーテストとは？ 7 ユーザーテストとは？ユーザーにサービスやプロダクトを体験してもらい、要件と設計についての問題を発見して改善のためのフィードバックを得る手法です

Slide 8

Slide 8 text

ユーザーテストで得られる情報の例 8 ユーザーテストを⾏うことで得られる情報は？サービス・プロダクトの要件や設計の改善箇所・内容に関するユーザーの生の声や現象例）このメニューの言葉の意味がわかりません例）ここでもっとあの情報が見られたらいいのに

Slide 9

Slide 9 text

他のテストとの比較 9 他のテストと異なる点は？単体・結合テストやUAT（User Acceptance Test）はサービスやプロダクトが仕様通り動くか発注者や設計開発者が評価する手法サービスやプロダクトをユーザーに触ってもらい、その結果から要件や設計についての改善内容を抽出する手法対してユーザーテストは…

Slide 10

Slide 10 text

他のテストとの比較 10 ヒートマップ分析・アクセス解析ではユーザーがwebサイト上のどこを⾒ているか、触っているか、どこで離脱したかがわかりますユーザーテストでは、上記に加えてなぜ⾒て触ったか・なぜ離脱したか分析できます A/Bテストでは、AとBのサービスを⽐較した時に、どちらのサービスが多く選ばれたかがわかりますユーザーテストでは、AとBそれぞれのサービスについて⾏うことで、なぜ選ばれたかについて分析できます

Slide 11

Slide 11 text

ユーザーテストの効果 11 ユーザーテストを行う人数と発見される問題数の関数曲線 5⼈のユーザーに対してテストを⾏うことで、要件や設計に潜在する80%の問題を発⾒できるというデータがあります出典：Nielsen Norman Group

Slide 12

Slide 12 text

このウェビナーを通して 12 • 基礎的な知識 • ノウハウに基づく計画・準備・実施・分析改善のやり方 • さまざまなリサーチプロセスソフトウェアのUX/UIに関する改善点をリリース前に発⾒するユーザーテストに関する以下の内容をお伝えします

Slide 13

Slide 13 text

基礎知識 UX/UI改善に貢献するユーザーテストとは？

Slide 14

Slide 14 text

一般的なソフトウェア開発プロジェクトにおけるユーザーテストのタイミング 14 要件定義基本設計詳細設計製造テストユーザーテストが有効ソフトウェア開発の基本設計までに実施することで⼿戻りなくリリース後のUX/UIに関するリスクを軽減できます。ユーザーテストを行うには遅い • リリース後の改修フェーズでもユーザーテストは有効です。 • アジャイル型開発の場合は同じ考え方をスプリント（デザインから開発までの周期単位）計画・イテレーションに適用できます。 • 一般的なウェブサイトについては企画戦略やKPI計画の要請に基づき常時実施可能です。

Slide 15

Slide 15 text

UXデザインプロセスにおけるユーザーテスト 15 NCDCのUXデザインプロセスにおいては、作成した要件や設計の評価を⾏う最後の⼯程となり、結果に応じて前⼯程を反復して要件や設計をブラッシュアップします。 ໨తͷڞ༗ ΧελϚʔ δϟʔχʔ Ϛοϓ࡞੒ ػೳཁ݅ ࡞੒ ϖϧιφ ΠϯαΠτ ෼ੳ 1 2 3 4 5 ϓϩτ λΠϓ࡞੒ Ϣʔβʔ ςετ 6

Slide 16

Slide 16 text

l ユーザーテストは以下の要素から構成されますテスト会場 • オンライン会議室を含む、テストを実施する空間記録デバイス • Web会議室の録画や、モバイルデバイス用書画カメラなどテストシナリオ • 参加者に依頼するプロトタイプの操作内容プロトタイプ • サービスやプロダクトを体験できる試作品モデレーター • テスト進行担当者。通常はテスト設計者が兼任ユーザーテストの構成要素 16 参加者（被験者） • プロトタイプを体験する人物 • ユーザーと同じ属性

Slide 17

Slide 17 text

プロトタイプについて 17 プロトタイプとは？媒体の種類やその時点での精度を問わず、サービスやプロダクトのユーザーにとっての接点（User Interface）の試作品精度：低精度：高ペーパープロトタイプデザインモックアップ

Slide 18

Slide 18 text

l プロブレムマトリクス l 画面とその操作タスクごとに成否を一覧化して問題箇所を明示する資料 l 事象・発言一覧 l 画面とその操作タスクごとに得られた出来事やユーザーの発言を整理し、問題内容を示唆する資料 l 事後アンケート・インタビュー l 内容について理解してもらった上で直接意見を収集した資料ユーザーテストの成果物について 18 画面と操作タスクごとに成否を一覧化して明示するプロブレムマトリクス

Slide 19

Slide 19 text

実施プロセスの流れと内容のポイント UX/UI改善に貢献するユーザーテストとは？

Slide 20

Slide 20 text

l ユーザーテストは以下のプロセスから実施されます。ユーザーテスト実施の流れ 20 プランニングプロトタイプ作成参加者の確定テストシナリオ・タスク準備パイロットテストテスト実施分析・改善内容の導出プロジェクトごとの状況・制約に応じた計画を立てます。テストに必要なプロトタイプを作成します。テストの参加者の属性を定義し、スケジュールします。参加者に依頼するテスト内容の文章を作成します。プロトタイプやシナリオに問題がないか内部テストします。思考発話法を用いてテストを実施します。得られた情報を分析し、改善内容を導出します。

Slide 21

Slide 21 text

l ユーザーテストを実施する上で一番肝要となる2点について解説します。テスト実施の一番のポイント 21 思考発話法 • 参加者の方がプロトタイプを操作しながら思った事・感じた事を漏らさず発話してもらい記録することで、改善内容を検討する際のフィードバックとする手法です。 • モデレーターは操作中の参加者に発話を適宜促し、できるだけ多くの情報を得られるように働きかけます。ラポール（⼼理的信頼関係）形成 • 思考発話法を促進するための考え方です。 • テストの内容や趣旨について丁寧に説明したり、参加人数を絞ることで緊張感を緩和します。

Slide 22

Slide 22 text

l 以下の観点でユーザーテスト計画を立てます。ユーザーテストのプランニング 22 テスト回数基本的には2回行って問題点の洗い出しとその改善検証をすることを推奨します。テスト時期実施自体は1〜2日程度が基本。設計修正期間を含めるのを忘れずに計画します。参加者人数基本は5人にテストを行うのが有効ですが、1〜2名でも充分な効果が見込めます。プロトタイプ精度テスト実施時に実現するプロトタイプの精度を事前に決めます。テスト場所こちらから訪問する/参加者に訪問してもらう場合に応じて対応します。テスト範囲機能が多い場合は優先順位をつけてテスト範囲を策定します。

Slide 23

Slide 23 text

ソフトウェア開発にユーザーテストを取り入れた要件定義のスケジュール例 23 1st Month 2nd Month 3rd Month 1 2 3 4 1 2 3 4 1 2 3 4 Kick Off ワイヤーフレーム作成ビジュアルデザイン作成機能一覧作成テスト2 分析調整ユ " ザ " テスト 1 WF プロトタイプ作成ユ " ザ " テスト 2 ヴ . ジ 0 アルプロトタイプ作成ユーザーテストプランニングテスト1 分析 l 一般的なソフトウェア開発に改善内容の抽出と、その改善の検証を行う 2回のユーザーテストを取り入れたスケジュールの一例になります。 l 開発の規模やスコープによりますが、最短3ヶ月でUX/UIに関するリスクを最小化した要件定義が可能です。要件整理

Slide 24

Slide 24 text

l ユーザーテストの参加者は、基本的に「実際のユーザーと同じ属性の人物に参加してもらう」ことが重要です。 l 例えば「大型ホームセンター店員向け商品発注アプリ」のユーザーテストの参加者としてどちらの方が適正でしょうか？ユーザーテストの参加者について 24 • ホームセンターのアルバイトの方 • 20代 • ホームセンターのマネージメント職 • 40代

Slide 25

Slide 25 text

l 参加者の属性を定義の上、下記の仕方で募集しスケジュールを設定します。 l 一般的なビジネスユーザー&コンシューマーユーザー l モニター募集サービスや社内で近い属性の人物 l 専門的な業務を行う特定のビジネスユーザー l セキュリティの規定にも依存するが、基本は社内の近い属性の人物ユーザーテストの参加者応募・その他 25

Slide 26

Slide 26 text

l 参加者に触ってもらうプロトタイプを作成します。 l 作成のスピード感やコストを重視した実装を伴わないデザインツールによるデザインプロトタイプがトレンドです。 l デザインプロトタイプとは、画面デザイン上のボタンなどにリンクをつけて、擬似的に実装したのと同じ挙動をもたせた紙芝居のようなものです。 l 実装レベルのプロトタイプを作成しても構いません。プロトタイプ作成 26

Slide 27

Slide 27 text

l 参加者にプロトタイプの操作を依頼する上で必要な、仮の状況設定であるシナリオと、操作の内容であるタスクの文章を作成します。 l 以下は「大型ホームセンターの商品発注アプリ」のテストシナリオと操作タスク例です。テストシナリオ・タスク作成 27 シナリオ（仮の状況設定）ホームセンターのマネージャーであるあなたは日常的にたくさんの商品を発注しています。今までエクセルによる発注票で商品発注を行っていたところ、新しく商品発注アプリが導入されました。このアプリを使って次の業務を行ってください。操作タスク1 今まで取扱のなかった商品を新しく発注して下さい。操作タスク2 在庫切れになった商品の追加発注を行なって下さい。

Slide 28

Slide 28 text

l シナリオやタスクの文章ははあくまでユーザーが行う事として表現されてなくてはいけません。 l NG例：在庫数表示が空になっている商品の詳細画面から外部発注サイトに遷移してください l OK例：在庫切れになった商品の追加発注を行なって下さい。テストシナリオ・タスク作成のポイント 28

Slide 29

Slide 29 text

l 用意したプロトタイプやシナリオ・タスクが問題なく機能するかを確認するためにプロジェクトメンバー間で本番同様の環境で事前テストを行います。 l パイロットテストは以下の観点で行います。 l プロトタイプの表示内容や遷移にミスがないか l シナリオ・タスク文章の内容が狙い通りに伝わるか l テスト実施にかかる時間はどれくらいか l 通常、テストは1時間以内に終わらせる必要があるため l タスクの文章が参加者にヒントを与えすぎていないかパイロットテスト 29

Slide 30

Slide 30 text

l テストは以下のプロセスに沿って実施します。テスト実施の流れ 30 環境セッティング事前説明オープニング事前インタビューテスト事後インタビューエンディングテストするソフトウェアのデバイスに応じて行います。録画する旨やテストの趣旨、思考発話の依頼を伝えます。参加者の方を迎えます。関連する業務や日常行動についてインタビューします。シナリオとタスクを提示し、操作してもらいます。サービスの内容についてインタビューします。疑問点があれば解消し内容をまとめます。

Slide 31

Slide 31 text

l モバイルアプリのユーザーテストを実施する際の環境セッティング例テスト実施のセッティング例 31 8 投影撮影 Web会議ツールで画⾯共有録画・録⾳ 1 3 2 4 5 10 9 7 6 # 名称用途 1 参加者テスト参加者 2 モデレーター進行 3 シナリオ・タスク文章操作の依頼 4 プロトタイプ用デバイス操作実施 5 書画カメラ手元の撮影 6 録画共有用デバイス録画と画面共有 7 机 8 椅子 9 オーディエンス 10 共有用デバイスプロジェクター等

Slide 32

Slide 32 text

l 用意したシナリオやタスクは印刷して提示し、いつでも確認してもらえるようにします。 l 事前説明では、以下の内容を丁寧に説明して参加者の不安・緊張感を取り除きます。 l あくまでサービス・プロダクトのテストであり、参加者を試すテストではない l 収録する音声や映像はプロジェクトに関係する限られた人数のみ視聴する l 思考発話の依頼と共に、独力でタスク達成可能かどうかを確認したいため、途中質問には応えられない旨 l 事前インタビューでは、サービスやプロダクトに関係する普段の行動について軽く会話を行い、シナリオやタスクへの導入をスムーズにします。 l 事後インタビューでは事前に質問を設計し、要件の内容について詳細なフィードバックを収集してもよいです。テスト実施のポイント 32

Slide 33

Slide 33 text

l ユーザーテストの結果得られた各種資料から改善箇所と内容を導出します。 l プロブレムマトリクスで参加者が独力でタスクを達成できなかった箇所と達成するのに時間を要した箇所の画面を特定して、そこで得られた発話・事象の内容を分析・検討します。分析・改善内容の導出 33 言葉の意味がわからなかったもっとこういった情報が表示されてほしい間違えて隣のボタンを押したプロブレムマトリクス問題のあった画面発話・事象

Slide 34

Slide 34 text

l 独力でタスクを達成できなかった箇所の改善を最優先にして、発話や事象の内容から改善内容を列挙し、画面設計や機能要件一覧に反映します。分析・改善内容の導出 34 言葉の意味がわからなかったもっとこういった情報が表示されてほしい間違えて隣のボタンを押した改善内容1 表示する文言の内容を修正する。改善内容3 データベースに項目を追加し、より詳細な情報を表示できるようにする。改善内容2 ボタンの色 or 配置間隔 or サイズを修正する。機能要件一覧

Slide 35

Slide 35 text

その他リサーチプロセス UX/UI改善に貢献するユーザーテストとは？

Slide 36

Slide 36 text

l ユーザーテストを実施することができない場合、UX/UIの専門家による要件・設計の評価を行うヒューリスティック評価で、リリース前の評価を代替することができます。 l UXデザインの専門家が、優れたUXを実現するための経験則（ヒューリスティック）に則って設計について質的分析を行い、改善するためのアイデアを導出する手法です。その他リサーチプロセス 36 制御と⾃由現実世界の⼀致状態の可視性柔軟性と使⽤効率代表的なヒューリスティック（経験則）

Slide 37

Slide 37 text

l ユーザーテストの結果、サービスやプロダクトのコンセプトや要件に根本的な見直しの余地がある場合、アンケートやユーザーインタビューを駆使したリサーチにより、ユーザーニーズの再検討が有効な場合もあります。その他リサーチプロセス 37 ユーザーテストの結果コンセプトの見直しが必要アンケートコンセプトが有効なユーザー属性を定量的に調査ユーザーインタビュー絞り込んだ属性のユーザーの行動や思考を深掘り UXデザイン、要件定義得られた情報をもとにニーズを仮説し要件定義

Slide 38

Slide 38 text

まとめ UX/UI改善に貢献するユーザーテストとは？

Slide 39

Slide 39 text

まとめ 39 l ユーザーテストはサービスやプロダクトの要件や設計についての問題点を発見して改善のためのフィードバックを得る手法。 l 一般的なソフトウェア開発に取り込む場合、基本設計の前半までにユーザーテストを終え、要件や画面設計に反映する期間が必要。 l プロトタイプの精度はプロジェクトに応じて柔軟に調整してよい。 l テスト実施の際は思考発話法を用いて参加者からフィードバックを得る。

Slide 40

Slide 40 text

補足 40 l ユーザーテストは大量のサンプルによる定量評価ではありません。 l ユーザーテスト実施のための社内合意形成の際は本日解説したユーザーテストの性質を踏まえて企画してみてください。 l A/Bテスト、ヒートマップ解析、アクセス解析、パフォーマンス測定、アンケート調査といった定量評価の手法とは親和性があり組み合わせが有効です。 l ユーザーテストで得られる情報はあくまで参考情報であり、ユーザーが「こんな機能は必要ない」と言ったとしても「ではやめましょう」という話ではありません。 l 得られた発話や事象から、「なぜこの機能が有用じゃないと言ったのか？」「何が足りないのか？」「どうすればよいのか？」を考えることが重要です。

Slide 41

Slide 41 text

No content