僕らがユーザーテストをする理由

どうして世の中のデザインの現場では、ユーザーテストをやらずに開発者側の閉じた発想だけでデザインを完結しようとするんですかね？

前回の「ユーザーテストで作り手の思いこみ＝デザインを破壊する」では、「ユーザーテストは作り手の思いこみ＝デザインを壊すための手法」であり、「ユーザーの好みを知り、ユーザーの期待を知り、ユーザーの喜びを知るための手法」であると書きました。ユーザーテストをやらないデザイン・チームはまさに、ユーザーの好みや期待や喜びには関心がないんでしょうか。

また、ユーザテストは「互いに隔離されていたユーザーとデザイナーがユーザーテストを通じてコミュニケーションをとる」ためのツールであるとも書いていますが、ユーザーとコミュニケーションをとるのがイヤなんですかね。だとしたら、とんだひきこもり集団ですよね。

彼らがユーザーテストをやらない理由

ユーザーテストをやったことのない人の多くは、「自分たちが前提としているユーザーの行動が自分たちの思いこみとは大きく異なっている」などとは思ってもいません。

もちろん、それは彼らがユーザーのことをよく知っているからではなく（たまに「ユーザーのことなら知っている」という人もいますが）、単に人間の普段の行動や認知というものがどれだけ複雑で豊穣なものであるかを考えたこともないからです。
「テストなんてやらなくてもユーザーのことは調べた」という人の多くは、アンケート調査の5段階評価の数字をみて、ユーザーの何たるかをわかった気になっているのでしょうけど、だったら普段のコミュニケーションもアンケート形式の5段階評価の質問だけで済ませれば？って思います。

マーケティング・リサーチや数字だけの顧客満足度調査と、ユーザーの行動そのものを詳細に知る人間中心設計やユーザー中心のデザインの違いを理解できてない人が多いのですが、前者は単に結果のみを知るものであって、後者はその結果が何から生まれてくるのかどうして生まれてくるのかを知ることで、結果そのものを変える具体的な解決策＝デザインを模索するという意味でまったく違うものです。つまり手を動かさないで文句ばっかり言ってる人が行うのが前者、手を動かしながら考え結果を出そうとする人が行うのが後者です。

他にもユーザーテストをやらない理由＝言い訳はいくらでもあるでしょう。

ユーザーと話をしないことには、限りない数の言い訳がある。「どんなものが必要なのかはわかっている」「時間がない」「難しすぎる」「お金がかかりすぎる」「社員をユーザーのところへやることはできない。重要な情報が漏れてしまう」「ユーザーはいつも自分が何が欲しいかわかっていない」など。
ローラ・デ・ヤング「第13章：ソフトウェア・デザインを支える組織」
テリー・ウィノグラード『ソフトウェアの達人たち―認知科学からのアプローチ』

かつてフロイト派の精神分析学者のジャック・ラカンは「うまくいかないことには理由がある」という旨の主張をしていましたが、これは人が理由なんて考えるのは何かがうまくいかなかったり、何かをしたくない場合のほうが多いということでもあります。つまり、ユーザーテストをやりたい、やっている人には実は特にそれをやる理由を述べる必要はあまりなかったりします。

ユーザーテストをやらなくてもいい、ユーザーのことなら知っていると思う人の多くは、何より本当にいいものに触れたことがないからデザインの力をあまく見ているのだろうなって感じます。
まぁ、そういう仕事をするのは別にいいですけど、そんなやり方でつまらないものをつくってお茶をにごすつもりなら、できたものは市場には出さず社内の倉庫にでも眠らせておいていただきたい。

ただ、そんな投げやりな態度だけで終わらせるのもどうかと感じますので、すこしユーザーテストについて書いておきたいと思います。
ユーザーテストをやってみようと思うけど、どうやったらいいかわからないという方には以前書いた「ユーザーテストはこうやります」などを参照いただくとして、ここではあえて「ユーザーテストをする理由」についても書いてみたいと思います。

僕らがユーザーテストをする理由

もちろん、ユーザーテストだけがユーザーを知る方法、ユーザーとコミュニケーションする方法ではありません。

ユーザビリティテスティングは、確認テストでも品質保証テストでもない。むしろ、非常に探索的で、ユーザの好みや満足度および問題を知るためのツールである。これを唯一のツールとしてはならないのは、フォーカスグループや調査、前後関係の調査、技術サポートの記録などから集められたデータも、ユーザの好みと満足度および問題に対する的確な洞察を提供するからである。
キャロル・M・バーナム『実践ユーザビリティテスティング』

先に引用した『ソフトウェアの達人たち―認知科学からのアプローチ』の「第13章：ソフトウェア・デザインを支える組織」という論文のなかでローラ・デ・ヤングもこんな風にも書いています。

ユーザーに焦点を合わせるというのは、単なる態度ではない。そのための作業が必要なのだ。（中略）何をデザインするのかを知るための地ならし作業であるマーケット･リサーチで、あるいは日々のプログラミングにおける決定、うまくいったかどうかを決めるユーザービリティ・テストで、製品がユーザーの求めているものに応えているかどうかの品質保証の手続きにおいて、そして消費財サービスにおいてである。
ローラ・デ・ヤング「第13章：ソフトウェア・デザインを支える組織」
テリー・ウィノグラード『ソフトウェアの達人たち―認知科学からのアプローチ』

ユーザーを知り、それをデザインに落とし込む手法としては、僕も以前「人間中心設計（Human Centered Design＝HCD）で使う主な手法」というエントリーでまとめたとおり、ユーザーテストだけが唯一の手法というわけではありません。



むしろ、そもそもユーザーが普段どんな風に製品を使っているか、どんなところに困っているかを知るのであれば「ユーザー調査とユーザビリティ評価の違い」で書いたとおり、コンテキスチュアル・インクワイアリー法などを用いたユーザー調査を実施したほうがいい。
僕もプロジェクトの予算の関係で、ユーザー調査とユーザーテストのいずれか一方しかできないのであれば、ユーザー要求を把握するためのユーザー調査のほうを優先して行うようすすめています。

しかし、ユーザー調査をやっても、実際にデザインしたものをユーザーがどう使うのかを完璧に予測することはできません。
ユーザーが何を重視し、何をどのような順番で利用するかの仮説はユーザー調査のデータから分析することはできたとしても、実際のデザインがそれを重視しユーザーの求める重要度の順で配置できているかについては、再度、ユーザーテストによるユーザー自身の評価を行わなくてはわからないのです。先にヤングが「うまくいったかどうかを決めるユーザービリティ・テストで」と書いているのはまさにそういう意味で、ユーザーテストは仮説検証のツールなのです。

なぜ「僕ら」なのか

このエントリーを「僕らがユーザーテストをする理由」としたのには理由（わけ）があります。「僕」ではなく「僕ら」としたところに。

僕は人間中心のデザインを成功させるのに何より大事な要素は、デザインチームの協働作業力、コラボレーション力だと思っています。
協働作業、コラボレーションが大事なのには2つ理由があります。

  1. ブレインストーミングやワークショップの技法を用いて複数の頭の集結を試みたほうが問題解決＝デザインのための創造性を発揮できるから
  2. ユーザーの行動や経験はドキュメントや記録映像だけでは共有しきれないから

人間中心のデザインというアプローチは、デザインを行う人たちの働き方を大きな変更をうながします。

「1.ブレインストーミングやワークショップの技法を用いて複数の頭の集結を試みたほうが問題解決＝デザインのための創造性を発揮できるから」の理由がまず従来のデザインの発想を大きく変えるものではないでしょうか。すなわち、優秀なデザイナーがひとりで黙々と作業する中でクリエイティビティを発生させるというやり方から、チームがブレインストーミングやワークショップの実践の中で創造性を生み出していくというやり方への移行において。
このあたりについては「ブレインストーミングの７つの秘訣」や「ワークショップ形式で楽しくプロジェクトを進める方法」で書いていますので参照ください。

また、デザインを生み出していくエンジンとなるものを、ものの視点から人間の行動にフォーカスするという意味でもそうです。人間中心のデザインにおいては、ものの形を決める理由そのものを人間の認知の仕方や行動に、ユーザーの行為や経験に求めていかなくてはなりません。つねにユーザーとのコミュニケーションが必要になってくるのです。

「2.ユーザーの行動や経験はドキュメントや記録映像だけでは共有しきれないから」という意味では、先にも引用した『実践ユーザビリティテスティング　「利用品質」を忘れていませんか』のなかで、著者のキャロル・M・バーナムがこんな風にも書いています。

チーム学習に由来する有用性に加え、実際のユーザが、自社の製品や創造物、傑出した製品に関係した現実場面で、繰り返し苦闘する様子を見るという共有の経験から非常に多くのものが得られる。「百聞は一見に如かず」なので、最も急速に変化を生じさせるには、ユーザが1人といわず次から次へと同じタスクで奮闘するのを見ることができるようなプロセスを使う。
キャロル・M・バーナム『実践ユーザビリティテスティング』

そう。「百聞は一見に如かず」です。そして、ユーザーテストはデザイナー自身が見たほうがいい。

ユーザビリティテスティングでしばしば起きるように、チームの開発者は、最初の「あの間抜けなユーザ｣という非難から、「確かに、ここは問題だ」という認識を経て、最期は「修正方法がわかったぞ！」となる。
キャロル・M・バーナム『実践ユーザビリティテスティング』

「ユーザーテストで作り手の思いこみ＝デザインを破壊する」で書いた思い込み＝デザインを壊すというのは、まさにこういう意味でなのです。単に自分がつくったデザインを壊すだけでなく、ユーザーの行動を通して修正方法そのものを発見することなのです。だからこそ、ユーザーテストはデザイナーとユーザーとのコミュニケーション・ツールとして役立つのです。

ユーザーテストはむずかしくない

最後に、ユーザーテストはそれほどむずかしい手法ではありません。

基本的には、ユーザーに自分たちがつくったデザインを触ってもらえばいいのです。大事なのは手法じゃなくて、ユーザーとの出会い、コミュニケーションの機会をどれだけ増やせるかってことですから。

もちろん、細かな点で注意は必要ですし、より深い理解を得ようとするのであれば、ちゃんとしたユーザーテストを実施するスキルをもった人間が行う必要があるでしょう。しかし、あまりちゃんとした知識をもたない人間が行ったとしても、やらないよりははるかに多くの示唆が得られます。
それゆえ、ユーザーテストをやらなくていい理由なんて本当はどこにもないのです。

　　

関連エントリー

この記事へのコメント

コメントを書く

この記事へのトラックバック