1.0UX TIMEShttps://uxdaystokyo.com/articles大本 あかねhttps://uxdaystokyo.com/articles/author/akaneohmoto/rich600338<blockquote class="wp-embedded-content" data-secret="NA5VJ5EaW1"><a href="https://uxdaystokyo.com/articles/agile-development-usabilitytesting/">アジャイル開発にはユーザビリティテストが不可欠</a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="https://uxdaystokyo.com/articles/agile-development-usabilitytesting/embed/#?secret=NA5VJ5EaW1" width="600" height="338" title="“アジャイル開発にはユーザビリティテストが不可欠” — UX TIMES" data-secret="NA5VJ5EaW1" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" class="wp-embedded-content"></iframe><script> /*! This file is auto-generated */ !function(d,l){"use strict";l.querySelector&&d.addEventListener&&"undefined"!=typeof URL&&(d.wp=d.wp||{},d.wp.receiveEmbedMessage||(d.wp.receiveEmbedMessage=function(e){var t=e.data;if((t||t.secret||t.message||t.value)&&!/[^a-zA-Z0-9]/.test(t.secret)){for(var s,r,n,a=l.querySelectorAll('iframe[data-secret="'+t.secret+'"]'),o=l.querySelectorAll('blockquote[data-secret="'+t.secret+'"]'),c=new RegExp("^https?:$","i"),i=0;i<o.length;i++)o[i].style.display="none";for(i=0;i<a.length;i++)s=a[i],e.source===s.contentWindow&&(s.removeAttribute("style"),"height"===t.message?(1e3<(r=parseInt(t.value,10))?r=1e3:~~r<200&&(r=200),s.height=r):"link"===t.message&&(r=new URL(s.getAttribute("src")),n=new URL(t.value),c.test(n.protocol))&&n.host===r.host&&l.activeElement===s&&(d.top.location.href=t.value))}},d.addEventListener("message",d.wp.receiveEmbedMessage,!1),l.addEventListener("DOMContentLoaded",function(){for(var e,t,s=l.querySelectorAll("iframe.wp-embedded-content"),r=0;r<s.length;r++)(t=(e=s[r]).getAttribute("data-secret"))||(t=Math.random().toString(36).substring(2,12),e.src+="#?secret="+t,e.setAttribute("data-secret",t)),e.contentWindow.postMessage({message:"ready",secret:t},"*")},!1)))}(window,document); //# sourceURL=https://uxdaystokyo.com/articles/wp-includes/js/wp-embed.min.js </script> https://uxdaystokyo.com/articles/wp-content/uploads/2023/12/この仕事は今週までにできる.png600450アジャイル開発にはユーザビリティテストが必要 2023年7月に書籍『ユーザビリティテスト実践ガイドブック』を出版しました！なぜ、ユーザビリティテストの本を今更記載したかというと、ユーザビリティテストがなかなか実施されない、そもそも正しく認識されていない現状にあるからです。 以下のグラフは、プロダクト開発をしているマネージャークラスを対象にしたイベントでのアンケート調査結果です。ユーザビリティテストを毎回実施しているのは参加者全体の約2%で、なんと！48.8%という約半数が「行ったことがない、ほとんど行わない」という結果だったのです。 アンケート結果：ユーザビリティテストの取り組み状況 ユーザビリティテストでできる事とできない事 ユーザビリティテストでは、プロダクトが使いやすいかどうかを確認することが出来ますが、ユーザーが本当に欲しいものが何かを把握できるわけではありません。 例えば、かき氷のユーザビリティテストをやったとします。食べやすさや美味しさなどをテストできたとしても、寒い日のユーザーが温かいものが欲しいと思う欲求をテストすることはできません。つまり、ユーザビリティテストは、プロダクトの使いやすさを中心に品質をチェックすることはできますが、欲しいものをチェックすることはできません。 ただし、ユーザビリティテストでできる事は多くあります。 ユーザビリティテストでできる事 UIの迷い方から新しいヒントを得る開発前に過不足なデザインが明らかになる使いやすいか、わかりやすいかどうかが見える ユーザビリティテストで「できること」と「できないこと」 このようにユーザビリティテストで問題を見つけることが出来ますが、行われていない実態は、ユーザビリティテストが正しく理解されていないことにあります。 ユーザビリティテストに対する誤認 ①時間とコストがかかり、面倒だと思っている②正しいテストが行われていない（間違ったテストマインド）③ターゲットを被験者にしなければならないと思っている（廊下テストを知らない） 一般的に、ユーザビリティテストは時間とコストがかかり、面倒だと認識されがちです。しかし、実際には早い段階で組み込み、設計や開発の途中でユーザーからのフィードバックを得ることで、最終的な変更や修正が少なくなり、時間とコストの節約につながります。 ユーザビリティテストの目的と効果を理解していないままテストを実施されている事もよく見られます。ユーザビリティテストは単なる機能の確認ではなく、ユーザーの生の声や表情、感情に基づいてサービス設計やユーザー体験を向上させるものです。 被験者が特定のターゲットユーザーでなければならないという誤解もありますが、誰もが問題なくサービスを使えるかを検証するための廊下テストがあります。これはコストをかけず、短時間で実施できる方法で、ユーザビリティの大枠の問題が解決できるテストです。 ユーザビリティテストが正しく行われない実態と思考 １．テストのクオリティばかりにフォーカスして改善されない ユーザビリティテストでは、よく数値やメトリクスにフォーカスし、テストのクオリティに重点を置く傾向も見られます。テストをうまくやることに集中するあまり、ユーザーの感情や意見が見過ごされがちです。 ユーザーがどのようにサービスを受け止め、どのような体験をしているかを理解することが、本当の改善につながります。 ２．すぐにわかる問題も、高価で無駄なコストをかけてテストしている  問題を発見するために、高価で時間のかかるユーザビリティテストを行うという組織もあるでしょう。しかし、これがサービスリリース前の最終確認だけになると、本質的な改善がおざなりになりがちです。テストのコストと効果を考え、効率的なタイミングで実施することが必要です。 ３．テスト分析して貴重なユーザーの生の声を捨ててしまっている ユーザビリティテストから得たデータを分析する際、多くの組織が数値的な結果に偏りがちです。しかし、データだけでなく、ユーザーの生の声や表情、感情こそが重要な情報源です。これらを無視せず、分析に組み込むことで、より深い洞察が得られ、プロダクトの改善につながります。 無駄のない開発ができているか？ 無駄なく開発するLEAN UXはアジャイル開発を行う上でも重要な考え方です。以前の記事でもご紹介しましたが、LEAN UXを実施するためにも、組織がユーザビリティテストを行う文化に変わっていく必要があります。 これは、単にプロジェクト単位での実施ではなく、組織全体での意識の転換が求められます。ユーザビリティテストが開発プロセスの中心に据えられ、絶え間ない改善のサイクルが築かれることが肝要です。 テストを完璧に行いたいけれど、同時にコストを下げたいというような話も耳にします。無駄なく効果的なユーザビリティテストを行うためにも目的を持って、小さく、細かく、テストを行うことが無駄がない開発に繋がります。 ユーザビリティテストの気づき ユーザビリティテストで使うプロトをどれにするか悩む場合があります。アニメーションによってUIや情報が異なる場合には、動的なプロトタイピングが有効です。必ずしもUIをデジタル上で作らなければならない訳ではなく、ペーパープロトだとしてもアニメーションの動きも用意すれば可能ですが、被験者が一般人で操作の感覚やクリックから遷移のタイミングなどを観る際には動的なプロトタイプがおすすめです。 動的なプロトタイプが有効な場合 例）住所等の入力フォーム 例 ） 全部入力されなければボタンがアクティブにならないフォーム 個人情報の登録フォームでは、住所を入力する際に「市区町村」と「市区町村以降」で入力欄が分かれているものがありました。 「市区町村以降」の入力項目も必須であることに気が付くことが出来ず、なぜ「次へ」のボタンがグレーアウトのままで進められないのか分からず、困った経験をしました。このように、すべての項目を入れないければアクティブにならないUIは動的UIでテストしましょう。 テキスト表示 例）ケーキの予約フォーム 人の思考　早い思考（システム１）と遅い思考（システム２）をベースに以下を考えてみましょう。 「ご購入の5日前（受取日含まず）」という表現は、購入日が今日だとしたら、「今日から5日前は何日だろう？」と頭で考えてしまいます。システム１の表現にするとどうなるでしょうか？動的な表記ができる場合とそうでない場合で考えてみましょう。 動的なサイトの場合：23日以降のご注文が可能です 動的なサイトではない場合：受け取りは5日後になります  上記のような表記であれば、カレンダーをイメージさせずに伝えることが出来ます。 受け答えの文言 あるお店の予約サイトで、以下のような案内を目にしました。 「＊月＊日なら予約できます。」 「＊月＊日であれば予約できます。」 この表示を見たときに、ユーザーはどのように感じるでしょうか？［お店側（企業側）の都合に合わせなさい］といったような設計になっていると感じるのではないでしょうか？ これを、以下のような表現だったらどうでしょうか？ 「＊月＊日でご予約できますが、いかがでしょうか？」 このように、言葉ひとつ変えただけで印象はかなり変わります。また、長々と説明が書かれているようなサービスもありますが、そのような企業視点のサービス（企業側のマインド）は良くありません。 例）グリーンビーンズのサイト 例　グリーンビーンズ（購入画面） イオンのショッピングサイト、グリーンビーンズで使えるクーポンをいただいたので割引を使って買い物をしようとしました。商品を選び終え、購入の手続きでクーポンを利用しようとしたところ、「4,000円以上でないと、クーポンは使用できません」と表示されました。よく見るとクーポンにも小さく記載されていましたが、UIでも事前にわかるようにしておくべきです。しかも、違う商品を選んでも対象でないことがあとから表示されます。 どの商品が対象か不明で配達指定日が一週間後だったので結果的に諦めてしまいました。 ユーザーは既に時間をかけて商品を選択しています。無駄な時間をかけずにスムーズに買い物ができるようにするには、購入時に注意書きを表示するのではなく、商品選択の際に明示的にクーポンに関する情報を記載しましょう。 例）みずほ銀行の手続きアプリ：ログインができない 例 ） みずほ銀行のアプリ：ログインができない みずほ銀行に登録している情報を変更するために、アプリをインストールしました。初めにログインを行うことを想定していましたが、アプリを起動してみるとログイン画面ではなく、いきなり上記のような画面が表示されました。手続きの項目を見ても、どこから変更すればよいのかが分からず戸惑いました。 上記でご紹介した事例は、他のサービスでも良く起こる例です。ユーザビリティテストの「分かるかテスト」「できるかテスト」を行うことで、ユーザーがこのサービスを戸惑うことがなく、スムーズに操作することが出来るかどうか、問題点がないかを事前に確認することが出来ます。 テストは測るもの。計測しなければ間違っているかも分からない マラソンを例に考えてみましょう。自分がフルマラソンを走っているとします。しかし、腕時計はしておらず、周りにも時計はありません。さらに、今、自分が何キロ地点を走っているのかが分からない状態だったらどうでしょうか？ ユーザビリティテストは、メジャーや時計と一緒です。計測するものがなければ、正しく判断することが出来ずプロダクトは失敗に終わってしまいます。 ユーザビリティテストは、メジャーや時計と一緒 アジャイル開発 アジャイル開発は、短い期間でサービスを開発し、その過程でユーザーのフィードバックを重視します。より良いサービスを早く出していくためには、ユーザー視点を持つことが大切です。 ユーザビリティテストは、早い段階で行うことで、ユーザーのニーズに合致したサービスを迅速に開発し、継続的な改善を行うことが可能となります。 組織でも理解が必要 12月14日に、「デジタルプロダクト開発のための ユーザビリティテスト実践ガイドブック」の書籍イベントを開催します。 書籍に記載されていることをベースに、ユーザービリティテストを組織に導入するための導き方を参加者でディスカッションする勉強会です。 書籍を持っていない方でも、ユーザビリティテストがどのようなものか、組織導入すると、どのようなメリットがあるのか？ 知識だけでなく、現場での悩みをみんなで共有してシェアして、解決のヒントを得る会にできればと考えています。 イベント概要 ユーザービリティテストの組織導入～著者と考える、導入のための「問い」や「心得」～ 【日時】 12/14 (木)　19時30分～　※オンラインで開催します。 【会場】 マイナビ出版 会議室東京都千代田区一ツ橋2丁目6番3号 一ツ橋ビル 2階 【参加申し込みについて】 組織・チームでの参加をおすすめいたします。代表者1名のお申し込みで3名まで当日参加可能です。 参加にはお名刺の提出が必要になります。 【学べる内容】 ユーザビリティテストを組織に導入するための考え方・ヒント実行の糸口の発見他の企業の実態と傾向・対策ユーザビリティテスト実行へのモチベーションアップ お申し込みはこちらから▶ ユーザビリティテスト実践ガイドブック 本書は、具体例や図を使用しながら、実際にある使いにくいWEBサイトやアプリをモデルにした事例をたくさん紹介しています。 また、最小のコストでユーザビリティテストを行う方法も満載です。プロダクト開発中はどうしても企業視点になりがちです。 書籍を読むことで、ユーザー視点に立ち返るきっかけとなるので、ぜひ本書を読んでいただき、ユーザビリティテストを取り入れていただきたいです。 アマゾンのレビュー 《ご紹介した事例について》本記事で取り上げさせていただいたWebサイトやアプリは、他のサービスでも同様の課題が見受けられ、今回はたまたま事例として取り上げさせていただきました。決して貶すつもりはなく、むしろ日本のUIが向上する一助になればとの思いから題材にしました。関係者の方には、ご迷惑をおかけすることもあるかもしれませんが、ご参考にしていただければ幸いです。