スポンサーリンク

UI/UX

良いUXのために、ユーザビリティテストで「クリエイターのエゴ」を叩き壊そう!

良いUXのために、ユーザビリティテストで「クリエイターのエゴ」を叩き壊そう!

先日開催された、日本ディレクター協会@関西主催のイベント「ディレクターだらけのLT大会」に、佐伯が登壇して参りました。

テーマは「製作者のエゴを叩き壊す”ガチ”ユーザビリティテストのススメ」です。

UXの天敵「クリエイターのエゴ」

ユーザー中心設計を実践する時、一番難しいのは「クリエイターのエゴ」を排除することなんじゃないかな、と思うのです。

ユーザー中心設計というのは、ユーザーニーズを満たすコンテンツを生み出すための設計手法・プロセスのことですが、正しい手法を用いたからといって、正しい成果が得られるとは限りません。

アプリ開発やWeb開発には、デザイナー、エンジニア、イラストレーターなど、様々な種類のクリエイターが関わってきますが、正しいユーザー中心的な成果を生み出すためには、メンバーの一人ひとりが「ユーザー利益のために尽くす」という使命感を持って取り組む必要があります。

ところが、クリエイターも人間ですから、建前では「ユーザーのために!」と分かっていても、「面倒くさいなぁ」とか「やりたくないなぁ」思うことはあるわけです。

また、クリエイターという人種は、「やりたくない」という気持ちよりも、「やりたい」「やってみたい」という気持ちの方がコントロールが難しいことがあります。ステキなビジュアル、かっこいいインタラクション、面白そうな最新技術など、何かを思いついてしまったら、それを作ってみたいという気持ちを抑えきれません。

このような創造欲は、クリエイターにとって重要な素養ですが、それらはあくまでクリエイターの個人的な嗜好であり、ユーザー中心というポリシーに従えば、ユーザーの利益を追求した結果以外は実装されるべきではありません。

また、人間である以上、避け難い心理的な弱点もあります。

特に注意すべきは「確証バイアス」と言われる心理現象で、先入観を持って観察し、自分に都合のいい情報だけを集めて、その結果さらに先入観を補強してしまう、という状態です。

こうなると、自分では真剣に「ユーザーの利益のために尽くしている」つもりでも、実際には「自分に都合の良い理屈」ばかりを集めてしまっていることがあるので注意が必要です。

これらのような、本来、ユーザー利益のために尽くすべきクリエイターが、ついつい持ち込んでしまう個人的な好みや願望のことを、我々は「クリエイターのエゴ」と呼んでいます。

いろんなクリエイターのエゴ

やりたくない
 ・面倒くさい
 ・むずかしい
やってみたい
 ・かっこいい、カワイイ
 ・流行の技術、面白い技術
心理的弱点
 ・先入観、思い込み(確証バイアス)
 ・固執、執着
 ・もったいない

クリエイターのエゴは防げない

私は、「クリエイターのエゴ」の発生を防ぐことはできないと考えています。

だいたい、プロジェクトの開始時点では、誰でも意識は高いのです。心に余裕がある時は、誰だって気持ちは大きく、優しくなります。自分のことよりユーザーのことを第一に考えることもできます。

しかし、心の余裕というのは、減りやすく増えにくいものです。

プロジェクトが進行していくにつれ、仕様が変わったり、ボツが生まれたり、作業に追われたり、締切が迫ってきたりしているうちに、だんだん心の余裕は失われて、そのうち、見ず知らずのユーザーよりも、自分の気持ちを優先するようになっていきます。

かといって、「常に意識を高く持て」なんて命令するのもナンセンスです。やりたくないことを「やれ」と命令したところで、クオリティもパフォーマンスも上がりません。

むしろ、「クリエイターのエゴ」は完全に防ぐことはできないという前提で、どのようにしてユーザー利益を追求するのかを考えて実行することが、プロジェクト管理者の役割だと考えます。

私の場合は、プロジェクトに発生してしまった「クリエイターのエゴ」は、「ユーザビリティテスト」を活用して叩き壊すことにしています。

ユーザビリティテストは弱点を洗い出す

ユーザビリティテストは、主にコンテンツの弱点を見つけるためのテストです。

ざっくりと説明すると、実際にコンテンツをユーザーに使ってもらい、その行動を観察するというテストです。ただし、観察者はけっしてユーザーに助言をしてはいけません。そして、ユーザーには考えていることを口に出しながら操作してもらいます。

具体的な実施方法については、下記のサイトなどを参考にしてください。
ユーザビリティテスト|Wikipedia
ユーザビリティテスト|U-Site

このテストで、ユーザーの行動を観察していると、制作側では気づけなかったコンテンツの弱点を洗い出すことができます。もちろん、コンテンツに隠れている「クリエイターのエゴ」も、ことごとく洗い出してくれます。

面白いのが、このテストで出てくる弱点や問題点は「初めて気付かされたこと」よりも、「やっぱりなぁ」とか「ですよね〜(汗」と言ってしまう類のもの、つまり、うすうす気づいてはいたけど「やりたくなかったこと」の方が多いように思います。

クリエイターのエゴを叩き壊す!

ユーザビリティテストはコンテンツの弱点を洗い出すテストですが、テスト本来の目的の他に、私は「クリエイターのエゴ」を叩き壊すための儀式としても使っています。

と言っても、ユーザビリティテストの風景を、なるべくすべてのメンバーに見せるだけです。ただし、動画ではいけません。生で見るがいいのです。

クリエイターは、自分たちが一生懸命作ったデザインやプログラムに、大変な愛着を持っています。しかし、どれだけ一生懸命に作ったとしても、だいたい、最初のユーザビリティテストは散々な結果になるものです。ユーザー中心なモノ作りは、ユーザー抜きではけっして完成しません。

そのテストを、クリエイターの目の前で見せることが「クリエイターのエゴ」を叩き壊す儀式となります。

ポイントは、「テスト中はユーザーに助言をしてはいけない」という点です。そして、ユーザーから観察者に質問をすることも禁止です。つまり、観察する側は、本当にただ黙って見守ることしかできません。しかし、ユーザー側は思っていることをすべて口に出します。

一生懸命作ったデザインやプログラムが、

理解してもらえない、、、
役に立たない、、、
気づいてもらえない、、、
ユーザーをイラっとさせる、、、

このような、ユーザーが困っている声を聞いて、イラッとされている雰囲気を感じて、すぐにフォローできる距離にいるんだけど、絶対に発言してはいけない、というシチュエーションを味わわせるのです。

動画ではいけない理由は、目の前に相手がいないので、その場でフォローすることがそもそも不可能だからです。目の前に相手がいてフォローできる場所にいるのに、絶対に我慢しなければいけないという「生殺し感」が大事なのです。だいたい、呼吸が荒くなってきたり、「ぐっ」とか声が漏れたりします。

テストの後に起こる変化

このテストを体験すると、あきらかにメンバーの意識が変化しています。

まず、「ユーザーにとって」とか「ユーザーのために」という、ユーザーの気持ちを理解しようとする発言が急激に増えました。また、会議の場でも、ユーザー中心について議論される内容のレベルが上がりました。

クリエイターにとって、自分の作品が目の前で酷評され、それを黙って見させられるというのは立派な恐怖体験だろうと思います。

ユーザーが満足しないものを作ると、いかに恐ろしい結果となるか身を持って味わい、二度と同じ体験をしないためには、ユーザーに心から満足してもらえるモノを作るしかなくなります。

ここまできてようやく、メンバーの一人ひとりが「ユーザー利益のために尽くす」という使命感(?)を抱き、真にユーザー中心なモノ作りをするための土台が整うのです。

管理者の仕事は命令ではなく制御すること

プロジェクトメンバーのコントロールは、管理者の重要な責務です。ルールを作ったら、そのルールを守らせるところまでが責任です。がんばって欲しい人に「がんばれ」と命令することは仕事ではありません。

人を使う立場というのは難しいですが、「ユーザーのためなら鬼にも悪魔にもなる!」ぐらい開き直っても面白いかと思います。

LT後の反応

しばらく講師業から離れていたため、人前で話すのは1年ぶりだったのですが、皆さんにはなかなか楽しんでいただけたようで、最後は拍手と共に「ドSコール」をたくさん頂きました。

LT大会 2015/7/18

時間が5分しかないため、実際に話した内容は大幅に割愛していて、それでもなんとか伝わるように「にゃんこフリック道場」の失敗エピソードを混ぜてお話ししました。軸がブレるので、この記事からは削りましたが、そのうち別の記事としてまとめたいと思います。

ユーザビリティテストの面白い効能、というつもりでネタを考えていったのですが、どうやらWeb界隈ではユーザビリティテストを導入されていない所も多いらしく、LT後にはユーザビリティテストそのものに関する質問をいただきました。

頂いた質問と回答を載せておきます。

ユーザビリティテストの母数は?

にゃんこフリック道場」の場合、ユーザビリティテストの実施は8人でした。
(※最終プロトタイプのテスト数。部分プロトタイプによるテストは含まず)

他のプロジェクトでも、だいたい10人弱です。

A/Bテストなどと比べると少ないように見えますが、ユーザビリティテストは正解を探すためのテストではなく、弱点を探し出すためのテストです。テストと修正を5人繰り返せば、ほとんどの弱点は洗い出せると言われています。

複雑なユーザビリティテストは資源の無駄である。最良の結果は、最高でも5人のユーザーに、小規模なテストを可能な限り実施することで得られる

ユーザビリティテスト|Wikipedia

テストはアナログ? なにかツールを使う?

アナログです。実際にユーザーに操作してもらっている所を肉眼で観察します。
(記録用に撮影することはあります)

また、「にゃんこフリック道場」ではテストシナリオを作りませんでした。アプリの性質上、「○○してください」という指示を伝えることは、ユーザーに「○○ができる」という情報を与えるため、それを避けたかったためです。その結果、3分もプレイせずに飽きられて終わってしまったテストもありましたが、それはそれで収穫の多い良いテストでした。

ユーザビリティテストでクオリティが上がる?

テストによってクオリティは上がりません。重要なことは、テストによって洗い出された問題点を分析し、解決策を導き出すことです。

我々の場合は、他社よりも圧倒的に時間と人手が限られていますので、限定された条件の中で、実現可能な解決策を見つけ出すことが常に難しい問題です。

また、テストを修正を繰り返すためには、あらゆるコードとリソースのメンテナンス性が高くなければ不可能です。最初から、プロトタイプ完成後には怒涛のテスト・修正ラッシュがくるという前提で開発しておくのが良いでしょう。

まだユーザビリティテストを導入されていない方は、ぜひとも取り入れてみてください。きっと「クリエイターのエゴ」が見えてくると思います。


【アプリ紹介】にゃんこフリック道場

弊社が開発したフリック入力の特訓アプリ「にゃんこフリック道場」です。

にゃんこフリック道場 | iTunes

Thanx

Image by beans via Flickr

スポンサーリンク