はじめに
三菱総研DCSのUXデザイナーの武内です。
今回は営業から「ユーザビリティテストの仕事です!」と聞き、
ユーザビリティテストをするつもりで話を聞いたら、
ユーザビリティテストだけでは不十分だと判断した時の話を紹介したいと思います。
概要
日本、および海外で利用されている専門性の高いアプリケーション※1で、お客様からご相談をいただきました。
専門性が高いゆえに、利用している方もその分野における専門性の高い方となります。
※1:専門性の高いアプリケーション:ここでは、使用するにあたりユーザーに特定の業務知識を高く求めるアプリケーションを意味しています
相談内容
お客様はこのアプリケーションを利用している海外のユーザーが「いけてない」と言っていたという話を、現地のメンバーから伝え聞いたとのことです。
お客様はそれがとても気になっていました。何が「いけてない」のか?
どこの国の、どなたが、どのような文脈で話しているのかなどはすべて不明、また、それを確認することもできない状態だそうです。それでも、このアプリケーションが抱えているらしい問題をお客様は知りたい。
これは非常に難しい。どこで誰にとってどんな問題が出ているのかがわからないのです。
手がかりは一言だけなのです。
ユーザビリティテストは万能薬ではない
この話を伺ってきた営業はユーザビリティテストで解決できるはずだと思っていました。
ユーザビリティテストでアプリケーションの問題が分かれば「いけてない」は解決できる!
しかし、何について言われたのか曖昧な状態でユーザビリティテストを実施しても解決はできません。
ユーザビリティテストは決して万能薬ではない。
的外れなお仕事は、お客様も私たちも幸せにはなりません。
ここで、「いけてない」という発言の裏には、どういう問題が潜んでいそうなのか。
グループのメンバーで早速話し合いました。
- 使えない、使い勝手が悪い
- 全く使い方がわからず、アプリケーションを使う目的が果たせない
- かろうじて使えるが、時間がかかりすぎる
- ユーザーが想像もできない動きをする
- 何をしているのか分からなくなる
- どこにいるのか分からなくなる
- 目的を果たすまでの操作がいつまでも覚えられない
- 単純に慣れていない
- 見た目の問題
- 好みじゃない
- 最近よく見るアプリの感じではない(慣れの問題を含む)
- 文化の違い
- 混乱させられる
- 色の意味が違う
- 言葉の意味が違う
- 使っている言語設定が得意な言語では無い
- 混乱させられる
- メンタルモデル※2のずれ
- 同じようなアプリケーション、似ているアプリケーションを使ったことがある、あるいはあったが、それと違う。(実はこれも慣れの問題を含む)
※2:メンタルモデル:○○はこういう物だ、これはこういうことをするとこうなる。という過去の経験から学んだその人の頭の中のモデルのことです
調べられそうな事を整理して考えよう
ユーザビリティとは JIS Z 8521:1999 において、以下のように定義されています。
ある製品が、指定された利用者によって、指定された利用の状況下で、指定された目的を達成するために用いられる際の、有効さ、効率及び利用者の満足度の度合い
ユーザビリティテストとは、これらの度合いを測ることです。
- 問題が「使えない、使い勝手が悪い」の場合
ユーザーの目的に対してユーザビリティテストを実施することで、問題点をはっきりさせることができます。 - 問題が「見た目の問題(好み、流行り)」の場合
ユーザビリティテストで確認できることは少なく、ご協力いただく方に事前、あるいは事後インタビューを行い、もしかしたらヒントくらいは分かるかもしれない、という曖昧な話になります。 - 問題が「文化の違い」の場合
色や使われている言葉の各国での捉え方は提供されている各国で調査してみれば早々に分かるでしょう。
言語設定はユーザーの背景の話しとなるため、どのぐらいのユーザーが不得意な言語設定を我慢して使っているのかを調べることになります。調べる対象は数人に直接聞くよりアンケートで大規模に確認する方が良さそうです。実施と対応にはそれなりの時間とお金がかかります。どこまで費用と時間をかけられるのか、もしかけた場合、かけた後得られる物とバランスするのか、お客様の判断が必要です。 - 問題が「メンタルモデルのずれ」の場合
ユーザーの背景の話になります。専門性の高いアプリケーションですが、これまでも似たような別のアプリケーションを使用し、業務をずっと行ってきたのかもしれない。また、現在も並行して使っているのかもしれない。
そこから何か気づくことがあり、発言として出てきていることがあるのかもしれない。これも曖昧な想像の話しです。
この場合、実際に使っているユーザーの背景、環境を聞かせてもらうことから始めるのが手がかりを探る一つの方法だと考えられます。
最終的に、調査とテストを行い、まずは問題点を明らかにし、問題点の原因について仮説を作る事が重要であるというご提案になりました。
まだまだご提案段階なので、今後どうなるかわかりませんが、問題点の仮説ができたら、検証を行うということになるでしょう。
続きをお話しできる機会があれば、また書きたいと思います。
まとめ
- 問題があるらしいという状態でも、調査自体が叶わない場合は存在する
- 起きている問題自体が分からない場合、「問題」となりそうな可能性を考えつく限りあげてみる
- そこからユーザビリティテストなのか、調査なのかを考え直そう