デザイナーや開発者がユーザビリティ業務を掛け持ち?

ユーザビリティの専門家がいるに越したことはない。しかし、規模の小さいデザインチームであれば、デザイナー自身がユーザテストをはじめとするユーザビリティ業務を行うことで得るところがある。

デザイナーや開発者がユーザビリティ業務を実施しても良いものか、それともユーザビリティの専門家に任せるべきか、という質問をセミナーなどでよく受ける。状況次第、というのがその答え。デザイナーや開発者がユーザビリティにまで手を広げることには、一長一短がある。

短所:専門性こそが成果を生む

何でも自分でこなそうとするジェネラリストよりも、スペシャリストの方が生産性が高い、というのはアダム・スミスの時代から言われてきたことで、ユーザ・エクスペリエンスの分野でも、これはそのとおりである。一括りに“デザイナー”と言っても、グラフィックデザイナーからインタラクションデザイナー、インフォメーションアーキテクト、ライター、その他にも様々な“デザイナー”がいて、それぞれが専門にするデザインが一つになってユーザ・エクスペリエンスが形成される。もちろん、一人の人間がビジュアルデザインとインフォメーションアーキテクチャを掛け持ちするのは可能だが、それぞれの専門家に任せたときの出来に及ぶことはまずあり得ない。

“ユーザビリティの専門家”も、簡易な定量調査や本格的な測定調査、フィールドスタディ、比較評価、サイト分析、サーベイ、ガイドラインや規格の構築などユーザビリティ関連業務の万事を得意とするわけではなく、どこか一部を専門とする場合が多い。

手を広げれば広げるほど、各専門分野の学習に充てられる時間は減り、積める経験も少なくなる。経験不足は、ユーザビリティの専門家にとって大きな痛手である。ユーザの行動を正しく分析できるかどうかは、ユーザの行動をどれだけ広く観察してきた経験があるかに大きく依存してくるからだ。

「デザイン」と「ユーザビリティ」の切り分けは、特に注目に値する。なぜなら、まったく別の性格特徴を求める2分野だからだ。部品を組み立てて何かを作り上げることに意欲を燃やす人に利があるのが「デザイン」であり、一方、「ユーザビリティ」に携わる人には、分析的思考や概念化のスキルが求められる。

同じように専門分化している業界は他にもたくさんある。たとえば、映画製作もその一つだ。主演男優が脚本を書くこともできなくはない が、腕の立つ脚本家に任せた方がずっと質の高い映画を作れると考えるのが普通である。

長所:スタッフの人数を抑えられる

ユーザ・エクスペリエンス・デザインの各構成要素をそれぞれ任せられるプロのデザイナー10人でチームを作って、プロジェクトに臨めれば最高だ。ユーザ調査等、ユーザビリティ関連業務を担当するユーザビリティの専門家も潤沢にいて、デザインをサポートできるとなればさらに申し分ない。

ユーザ・エクスペリエンスに適切な投資をできるまでになった成熟度の高い大企業であれば通常、数十人、あるいは数百人規模のユーザ・エクスペリエンス部門を設けている。しかし、中小企業(や成熟途上の大企業)では、それほど大きなチームを持つことはできない。

ユーザ・エクスペリエンスのチームがまだ弱小であるが故に、ユーザビリティ専門家を抱えることの必要性を正当化できずにいる企業は多い。ユーザビリティの担当者はわずか一人、というプロジェクト“チーム”が多いのが現状である。幸い、ユーザビリティの基礎を習得するのはさほど難しいことではない。チームメンバーには3日間のワークショップに参加して、自分のデザインをユーザテストで検証する方法を学んでもらうこともできる。

ユーザビリティの専門家がいないからといって、ユーザビリティを無視して良い訳はない。自分たちで、簡単にでもユーザビリティ業務を実施することで、必ずや得るものがあるだろう。簡易なユーザテストなら、最小限のリソースで実施できる

短所:客観性の欠如

しかし、自分で自分のデザインをテストするとなると、進んで非を認める気にはなかなかならないかもしれない。デザイナーは、ユーザが不満を言ったり、問題を指摘したりしても、それは少数意見に過ぎないとして、むしろ積極的にはね除けてしまう。深刻なデザインのやり直しが求められる事態をテストの結果が示唆していても、なかなか受け入れられないのだ。また、ユーザの行動はかくあるべき とする持論に執着しやすく、ユーザが違う行動をとるケースをテストに盛り込むことを忘れがちだ。

ユーザテストについて教えるときに重点を置くことのひとつに、良いタスクの作り方がある。経験が浅いと、タスクの作り方が悪く、いまひとつのデータしか取れずに終わる場合が多い。デザイナーの場合は、ユーザが目指しているゴールよりも、自分のお気に入りの機能にもっぱら注目してタスクを考えてしまいがちだ。

客観性に欠ける恐れがあるということを自覚 できていれば、そうならないようにと意識することができる。たとえば、自分が個人的に気にしている範囲を超えてタスクを作るように心がければ良い。

同僚に、テストプランをチェックしてもらったり、セッションを1つか2つ見てもらったりすることで、客観性を上げることもできるだろう。

長所:信頼性が上がれば、コミュニケーションが容易になる

同じ人間がデザインとユーザビリティの両方を担当すれば、ユーザビリティの担当者が報告する知見をデザイナーが聞き入れない、という事態を心配しなくて済む。人は自分でやった仕事の結果を信じるからだ。

何人かで手分けしてプロジェクトを進めるときは、ミーティングを開いたり、レポートを書いたりして、互いにコミュニケーションを取っていかなければならない。それに引き替え、デザイナーがユーザテストを行えば、テストで明らかになったことを踏まえて、すぐに問題点の修正に取り掛かれる。情報が一人の人間の頭に入っていれば、ミーティングやレポートやコミュニケーションにかかる間接経費はいらなくなる。

逆に、ミーティングやレポートがなくなることで、ユーザビリティに関する知見が議論されたり、精緻化されたりすることもなくなるという欠点がある。そうなれば、知見が深まることは減り、ユーザ・インターフェイスの再概念化もなかなか進まなくなる。レポートをまとめるには経費がかかるが、新人のデザイナーや将来のプロジェクトに備えて社内知識を蓄積するための良い手段であることも間違いない。

まったくテストをしないよりは、何かした方が良い

ユーザビリティに関する業務は、できることならユーザビリティの専門家に任せた方が良い。しかし、専門家に任せるという理想的な選択肢と、何もしないという最悪の選択肢の二者択一ではない。その間を取って、デザイナーや開発者に二足のわらじを履いてもらい、ユーザビリティ業務を掛け持ちしてもらうことも可能だ。その方が、何もしないよりは遙かにましである。

2007 年 6 月 25 日