2017年10月12日(木)に開催された【第4回】「セルフユーザビリティテスト検定講座:UXDT」を受講してきました。
今回はスタッフとしてではなくお金を支払って一般エントリーして受講しました。
- 日時:2017年10月12日(木) 19時~22時
- 場所:TAM東京
- 参加人数:約30名
- 講師:大本 あかね(Web DirectionsEast)
参加された方の構成は以下のとおりです。やはり、デザイナーさんとディレクターさんが多かったです。女性が半分ぐらいを占めていて、若干華やかな雰囲気でした。
- デザイナー 11
- ディレクター 6
- マーケター営業 1
- ディベロッパー 8
以下のプログラムで進められました。
- 座学
- テスト
- ユーザビリティテストの実践
ユーザビリティテストについてのアンケート
座学に入る前に、「ユーザビリティテストを取り入れたことがあるか」という質問が講師の大本さんからありました。
結果は数名。なかなかユーザビリティテストを取り入れるのは難しいようです。
私はエンジニアという職業柄ユニットテストは行うのですが、ユーザビリティテストはほぼありません。
テスト内容として、関わったプロダクトを色々な部署の方が一斉に使って意見をExcelに記載していくということはありましたが、これはフォーカスグループであって「ユーザビリティテスト」ではないことも再認識しました。
座学の内容は目からウロコ
まずは講師の大本さんからユーザビリティテストについての説明を受けました。とても内容の濃いものでしたので、全てをレポートするのは難しいのですが、私が印象に残ったところをピックアップします。
ユーザビリティテストの必要性
ユーザビリティテストは開発の後半で行うものだと思っていたのですが、それは間違いで、ユーザビリティテストはどの工程でも行う必要があるとのことです。
ペーパープロトタイプに対してもユーザビリティテストを行うとのこと。この考えは思いつきませんでした。
以前、夫(エンジニアで管理職)とユーザビリティテストについて話していたときに「開発が進んでからユーザビリティテストを行なっても手戻りが発生するだけ。だからムダ。」という言葉を聞いたのを思い出しました。
確かに、開発も終盤になってからユーザビリティテストを行い、その結果を受けて仕様を大きく変えてしまうというのは非常にコストがかかります。が、要件定義など最初の方の工程で行なっておけばコストダウンに繋がるのだと必要性も感じました。
ユーザビリティとは考えさせないこと
私達人間は脳を働かせながら動いていますが、脳の状態には2つの種類があることを知りました。
それは、考えなくてもわかる「システム1」と、考えて答えを出す「システム2」という状態だそうです。計算などは意識的に脳を動かさないとできませんが、表情を読み取るということは無意識のうちにできるような脳の状態だそう。さらに、人は今の自分にとって必要だと思われる情報しか目に入らないそうです。
「使いやすい製品・WEBサイト」は脳を動かさなくても「システム1」だけで「次にどこをやればいいんだっけ」ということがわかり、ユーザビリティテストでは、被験者ができるだけ「システム1」の状態で操作できるかもポイントと解説されていました。
ユーザビリティテストの基本型
ユーザビリティテストの構成は以下が基本になり、可能であればカメラで手元や表情を撮影します。
- 被験者(テストを受ける人)
- 記録者(記録する人)
- モデレーター・司会者(ユーザビリティテストの進行をする。ユーザーにヒアリングする)
被験者は行動(これから何をする)や感じていること(使いにくいなど)や離脱してしまった理由を言葉に出して説明していきます。これがなかなか難しいです。
司会者が被験者に対して「どうしてそこをクリックしたんですか?」とか「迷ってますか?」というように質問をします。決して「ここはこうやって使うんですよ」というような誘導の仕方はしてはいけません。(が、ついやってしまいます…。)そして、記録者は被験者の行動、言動、表情などを記録していき、記録した結果をレポートに纏めていきます。
自分のチームでユーザビリティテストを行う場合、開発者がすぐそばにいるので、気を使って「コンバージョンまでたどり着かなくては」という気持ちになってしまうかも知れません。が、あくまでも正直にテストを行なっていくことで、ユーザビリティの向上に繋がります。
検定テストの実施
一通りユーザビリティテストの説明が終わったところで、検定試験を行いました。
出題範囲は座学で説明されたところです。座学を受けているときに必死でメモをとったのですが、それでもわからない箇所がチラホラ。。。
テストの結果は後日返ってくるとのことで、今から戦々兢々としていました。
ユーザビリティテストの実施
座学と講義が終わったところで、実際にユーザビリティテストを行いました。私のチームは3人で私を含めて全員女性でした。
ユーザビリティテストの課題
とある宅配業者のサイトを使って、「東京から大阪に荷物1箱(25.0cm × 33.0cm× 17.0cm)を送るにはいくらかかるかを調査する」
この課題をクリアするため、被験者となった方が実際にサイトを使って調査をしていきます。ちなみに私はモデレーターとして参加しました。
サイトのユーザビリティテストを行うと、自分が欲しい情報になかなかたどり着かない様子でした。
「なぜ手が止まったんですか?」「どうしようとしていたんですか?」とできるだけ被験者の方が考えていることを引き出すように心がけたのですが、なかなか難しいというのが感想です。
結局目的は達成出来ず。。。じまいでした。
実施してみた感想
ユーザビリティテストのワークショップを受けて、改めてユーザビリティテストの重要性を認識しましたが、どこから手をつけて良いのかがわからないという疑問が出てきたので、早速質問してみました。
その回答は「他社のサイト(製品)に対してユーザビリティテストをして、まずはユーザビリティテストの実施の仕方に慣れるところからやってみればいい。」という返答をいただきました。
”人のふり見て我がふり直せ”ではないですが、他社のサイト(製品)に対してユーザビリティテストすることによって、「こうすると使いにくい」ということが分かり、自分たちが開発するもののユーザビリティを向上させることができるのではと感じました。
開発者自身もユーザビリティに対して敏感であれば、開発中にディレクターに対して「ここは使いにくそうなので、再検討できないか」というような提案もでき、結果としてコスト削減になるのではと思います。「開発者だからユーザビリティは関係ない」ということは決して言ってはならない、ということを強く感じたワークショップでした。
イベント終了後
勉強会の後、テストの結果が届いていました。
無事合格で、スタッフの面目を保てました。