スタッフの藤原です。5/25に開催したUX DAYS TOKYO主催のイベント「セルフユーザビリティテスト検定講座」に参加してきました。
実は今回で2回目の参加なのですが、改めて参加すると気づかなかった学びが得られ、さらに復習もできて、とても良い機会になりました。
-
- 質疑の様子
-
- 受講の様子
参加者にはプロマネ・デザイナー・エンジニア・ディレクターと様々な職種の方がいました。
イベント後の懇親会で他の職種の方とお話ししていると、自分の仕事では得難い視点が得られたり、仕事が違えど悩んでいる課題は同じなんだなぁと共感できたり、モチベーションに繋がるとても良い刺激をもらえました。
ユーザビリティテストの価値
冒頭でユーザビリティテストの重要性を説明してもらいました。ユーザビリティテストを実施しないと、ボタンを押しても反応しなかったり、意図した検索条件で絞り込みができない等、サービスとして使えないレベルの課題を残したままリリースしてしまい、ユーザが不信感を抱いてしまうという話でした。
テスト自体は準備・実施共に時間がかからず、さらに費用もほとんどかからないという手軽さにも関わらず、レイアウトのズレや文言の不一致という局所的なものから、画面遷移が分かりづらいという総体的なものまで、改善すべき課題を見つけられます。
時間もお金もかけずに、自分たちが気づかなかった課題を見つけられるユーザビリティテストは、非常に効果的な取り組みだなと感じました。
「システム１」と「システム２」を考慮する
ベストセラーである「Don’t Make Me Think」から引用をしながら「ユーザがシステムをどう見るのか」という説明がありました。その中でも印象に残った話は、人間が物事を理解し処理する際には「システム１」と「システム２」という脳の思考モードが存在するという話です。こちらの理論は、ダニエル・カーネマン氏が提唱しました。
書籍 Don’t Make Me Think
「システム１」というのは、一目で理解することができるものに働きます。具体例は、子どもが泣いている写真でした。もちろん参加者はその写真に何が写っているか瞬時に理解できました。
泣いている子どもの写真、システム1で理解できる
一方、「システム２」というのは、理解するために労力を要するものに働きます。具体例は「17×24=?」という数式でした。確かに暗算して一生懸命考えるという労力を使わないと答えが出てこないです。
システム2を利用しないといけない
二つの思考モードをしっかり理解した上で、製品・サービスは可能な限り「システム１」で理解できるように設計して、考えずに利用できる状態にするべきだという話がありました。
「なるほど！」と一番感じた部分はここでした。「インターフェースデザインの心理学」という書籍でも説明されているのですが ”良いシステムは考える必要がなく、やりたいことが容易に達成できる” と言われています。
分かりやすいだけでなく適切な誘導を
ユーザに対して分かりやすい誘導をすることは重要です。しかし、間違った誘導では本末転倒です。
実際に間違っている箇所は、都道府県の入力値
ユーザが誤った入力をした時のエラー画面です。修正が必要な箇所だけ赤枠で囲い、他の箇所はグレーアウトすることで、どこを直すべきか瞬時にわかるように設計されています。エラーメッセージを表示するだけではない、とても良い工夫です。しかし、重大な問題が発生しています。
実は、今回修正すべきは赤枠の箇所ではなく、青枠で囲われた都道府県の箇所です。
分かりやすいことはもちろんですが、大事なことは「適切に分かりやすく伝える」ことだなと感じました。
エラーをただ分かりやすくしようと思って、赤文字で「エラーです」と表示するなんてナンセンスですよね。何がいけないのか、どうすれば解消する問題なのかを適切に分かりやすく伝えてこそ、エラーメッセージは初めて価値のあるものになります。
実際の自分の仕事でも、ああやらかしてしまっているな、自分・・・と反省する良い機会にもなりました。笑
そのためにもユーザビリティテストを通じて、伝えたい情報が適切にユーザまで届いているか検証し、こういった凡ミス含めて課題を発見していく必要があるのだな、と感じました。
デザイン思考でテストをする
話題を変えて、デザイン思考におけるテストの話がありました。
一例として、Uberが実施しているペーパープロトタイプによるテストが講座の中で紹介されました。僕は「Uberが作るプロトタイプだから、さぞ質の良いものだろう！！」と思いましたが、実際はまるで子どものお絵描きのような、手書きのペーパープロトタイプでした。見た目はお世辞にも良いと言えるものではありません。
Uberのペーパープロトタイプ
しかし、これで良いのだそうです。「どんなアイディアもカタチにしてテストをする」ことが非常に重要です。
普段の仕事の中でも、形にして初めて発見できる課題は非常に多いと感じています。僕はエンジニアとして働いていますが、機能を作成したらそもそもの認識がずれていて修正が必要になったり、デザインを当ててみると今まで意識していなかった画面のレイアウトに課題を発見したりします。
「ヒアリング段階で仕様をしっかり固めておくべきだ」という意見もあります。しかし、話し合いを1〜2週間行い、結果として作成に4週間かかるよりも、大方決まったらカタチにして、できるだけ短い期間で課題を洗い出した上で作成する方が効率的だと感じました。
カタチにすることで課題が見えてくるため、「カタチにしてテストをする」ことを大切しようと思いました。さらに、この考えは個人で主張するのではなく、チーム全体が同じ認識を持っている必要性もあるのだなと反省しました。
実践、ユーザビリティテスト！
模擬ユーザビリティテストを実施している
前半で「ユーザビリティテストとは何か」を座学で学び、検定試験を実施した後に、ユーザビリティテストを実践しました。
3人1組のグループに分かれて、モデレータ・被験者・記録者の役割を行いました。1周目は共通のタスクでしたが、2周目はモデレータがタスクを設定して、被験者がテストを行いました。僕は被験者と記録者をやったのですが、被験者の発言量がユーザビリティテストの成功の鍵だと思いました。
モデレータが『被験者から「考えていること」や「感じていること」をどれだけ多く引き出せるか』は重要です。しかし、それ以上に『被験者がどれだけ心を開いて、主体的に発言してくれるか』が重要だと感じました。被験者がテストの意味や目的を理解できるような準備をする必要があります。
ワークを実施した際のグループの中に「テストを行うためのタスク設定が難しい」と悩んでいる方がいました。というのも、タスクを設定する際には、きちんとコンテキストを理解する必要があるからです。
2周目のタスクのテーマが「スキー板を郵送する」でしたが、実態に即したタスクを設計する必要があります。自分たちのグループでは、長野県にスキー板を送るというタスクを設定しました。しかし、本来の利用シーンを考えると、スキー板に加えてウェアやブーツも送る必要があるし、そもそも長野県に送るのではなく特定のスキー場に送るはずです。
そう考えると、検討すべき事項が非常に多くて、ユーザビリティテストにおけるタスク設計の難しさを感じました。
最初に設定したタスクが漠然としたものだと、せっかく行ったユーザビリティテストで、見つけられるはずの課題を見落としてしまいます。実際に利用するイメージが湧くように、利用者のコンテキストを理解した上で、タスク設計することが重要なのだなと、ここでも改めてコンテキストのワークショップの重要性を感じました。
たった20分でできる課題の洗い出し
ユーザビリティテストは、とにかく費用が少なく済みます。さらに「セルフ」であればほとんど費用はかかりません。
時間も1時間、もっと短ければ20~30分程度で終わる取り組みです。そのコストで得られるメリットを考えたら、ここまで費用対効果の高い取り組みは無いだろうなと感じました。
しかし、簡単にできるからと言って、テスト自体が簡単というわけではありません。テストにおけるタスクを適切に設計することは難しかったです。他にもモデレータは誘導しない質問を行う必要がありますが、「自分はこう思うのですが、どう思いますか？」という質問を僕はしてしまいました。
イベントの最後にも登壇者の菱井さんが言っていましたが、慣れるまでは非常に苦労するので、何よりもまず実施することが非常に重要なのだなと、改めて認識できました。
今回学んだことを踏まえて、引き続き社内でのユーザービリティテストを推進していこうと思います！
