1.0UX TIMEShttps://uxdaystokyo.com/articles大本 あかねhttps://uxdaystokyo.com/articles/author/akaneohmoto/rich600338<blockquote class="wp-embedded-content" data-secret="XHzSnviOIh"><a href="https://uxdaystokyo.com/articles/usabilitytesting-not-uat-quality-verification-research/">ユーザビリティテストはUATとも品質検証ともリサーチとも違う</a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="https://uxdaystokyo.com/articles/usabilitytesting-not-uat-quality-verification-research/embed/#?secret=XHzSnviOIh" width="600" height="338" title="“ユーザビリティテストはUATとも品質検証ともリサーチとも違う” — UX TIMES" data-secret="XHzSnviOIh" 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/03/usability-test.png1486916UX DAYS TOKYO2023では、GDS(英国デジタル庁）のローラ氏が、ユーザビリティテストのワークショップをやるということで、ユーザビリティテストの話をするのですが認識ギャップがあり、そのギャップはよくないと感じたので記事にしました。 ギャップ内容は以下です。 ユーザビリティテストは、ユーザーリサーチの文脈の方が理解がしやすいのではないか？ユーザビリティテストは（直接、自分はやっていないけど）他の部署や管理下で既ににやっていると思っている→　もしやっていないのであれば、それはパッケージにユーザビリティテストが組み込まれていないだけ、そんな場合でも、品質管理や検証でやっているはず古い技術で、既に周知されているものだと思っている １つずつ見ていきます。 まず、ユーザビリティテストとユーザーリサーチは明らかに違います。確かに、ユーザビリティテストでリサーチ的な質問をしたり、エスノグラフィー的な調査力も必要になります。しかし、リサーチは、プロダクトの事前調査・プロダクトの精度を上げるため、既存のプロダクトの問題発見のために行います。 一方、ユーザビリティテストはUIを作った時に、使えるか・わかるかをベースに使いやすさや便利さを検証するテストです。リサーチと内容も違いますし、リサーチの分野に溶け込ませてしまうのは危険です。 次の「2」の内容ですが、他の部署で行っているから自分の範疇でないという認識です。リーダ格の方であれば、ユーザビリティテストでの使いやすさの重要性に気づき、認識しているはずです。それを同じ自分のプロジェクトを他部署で管理しているから大丈夫とあぐらをかくような認識ではプロダクトは失敗します。 そして、ユーザビリティテストは品質検証やUATとも全く異なるのにも関わらず同じという認識です。UATなどの検証はあくまで技術がちゃんと動くかの検証で、ユーザーの使い勝手など考慮していません。UATは、主にプロダクト開発の最後に行いますが、ユーザビリティテストは、ペーパープロトでもできるように、デザイン設計の初期段階からも実施できます。 最後の「3」は、ユーザビリティテストは知っているものだと思い込んで、そのやり方だけに依存している可能性です。テストを行えば一定の問題を発見することはできますが、ユーザビリティテストは奥が深く、同じ食事でも職人によって味が変わるようにユーザビリティテストの結果も変わってきます。その奥深さを理解しないのはかなり危険です。 日本では実施が当たり前なのか？ 日本で、ユーザビリティテストは本当に実施されているのでしょうか？2022年7月に行った人材系サービスのオンラインセミナーで、事前アンケートを約50名で実施し、以下の様な結果が出ました。 「ユーザビリティテストは行ったことがない・ほとんど行わない 」48.8％・「たまに行う」48.8％で、「毎回やる」が、1名という結果でした。 ユーザビリティテストはたまに行うものではなく、常に行わなけれなりません。この結果から、多くのプロダクトで、ユーザビリティテストが出来ていない結果が浮き彫りになりました。 本当のスキルアップは研ぎ澄ませること リスキリングに力を入れるべきだという風潮があります。学びにフォーカスされることはとは素晴らしいことです。しかし、リスキリングという言葉はどこか新しい事柄を学ぶというニュアンスが強い感じがします。 知っている事と出来る事は違います。言葉として知っていても、使っていない、正しく理解していない、深く学ぼうとしないのは危ないマインドです。また、本当のスキルアップは、やり方を覚えることでなく、研ぎ澄ませることです。 正しいユーザビリティテストを実施しているか？ ユーザビリティテストは決して難しくも、多くのお金が掛かるものではありません。しかし、なぜか？お金も時間もかかる。という認識が強いようです。ユーザビリティテストは実施されて当然ですが、その効果を正しく認識せず、お金も時間も掛かるのでカットしてしまっている傾向にあるようです。 中には、ユーザビリティテストをやっているが、解釈が間違っているケースもあります。それは、ユーザーの言葉はすべて正しいと思い込んでユーザビリティテストを実施しているケースです。 ノーマン氏もユーザビリティテストを弟子と師匠関係のようにと伝えていますが、決してユーザーの言いなりになれ。とは言っていません。それくらいの心構えでユーザーを受け入れなさいという意味でしかありません。解釈違いで大きく方向性が変わってしまいます。 ユーザビリティテストを実施するれば格段によくなる ユーザビリティテストを実施して、何が問題なのか？それを見極められる能力が付けば、日本のプロダクトは格段によくなります。元々、おもてなしの国ですし、その精神も能力もあります。 ただ、見極める力をアップしようとせず、やり方だけいにフォーカスしてしまうのは危険です。 深いユーザビリティテストとは？ 復路に気がつくユーザビリティテストの実施をしよう！ Yahoo!の乗り換えアプリはとっても便利です。私もよく使うのですが、ある日、帰りの路線を調べようとしたら、復路を設定するのに前の前のページに戻らなければ、出発と到着の地点を引っくり返す⇔ボタンが表示されないことに気が付きました。 「アレ？面倒じゃない？」と感じました。 ところが、Googleでは、路線の検索結果ページに、地点を引っくり返す⇔ボタンがありました。「できるからOK。」というところに留まらず、ユーザビリティの向上を目指す視点はとても大切です。 「知ってしまえばそんなこと。」コロンブスの卵マインドも危険です。また、優先順位が低いとして実装しないというのもナンセンスです。もちろん、どんなことも一気に作業することはできず、優先順位は存在します。 しかし、その優先順位の付け方をどうすべきかの判断力も身につけてほしいところです。ユーザビリティテストは既に知っている、やっているとするのでなく、今のスキルをレベルアップしてください。 （左）乗り換え案内は、復路の検索のために前画面に戻る必要がある。（右）Googleはその場で、発着を変更できる ユーザビリティテストで重要なのは、「何を見るのか。何が問題なのか。」それらの察知能力です。その能力は、POを含めプロダクトマネージャーはもちろん、リーダーという地位の方、できるデザイナーは身につけていなければなりません。 でなければ、どんなに良い戦略でも、戦術が間違っていたら何にもなりません。ユーザビリティテストはその戦術が上手に機能するかをチェックするためのものです。 繰り返しですが、やり方を知る学びでなく、観察眼が必要な、奥の深いユーザビリティテストの世界に足を踏み入れてください。ローラ氏のワークショップで奥深いユーザビリティテストを学びましょう！ 4.1（土）10:00-18:00　英国デジタル庁（GDS）ヘッドデザイナーから学ぶ、実践的なユーザビリティテストマスタークラス