Palm Programmer's Laboratory
Zen of Palm/1-3
1-3 デザインの検証
悟りへと続く道における３つめの謎かけは、現実世界におけるデザイン品質の検証と関係があります。
なぞかけ３ Q: 鍛冶屋が完璧な蹄鉄の作り方を学ぶためには？
ヒント：謙虚さが知識への道を照らすのです。
この謎かけは、ユーザーインターフェースデザインの検証に関係があります。これまでユーザーインターフェースデザインを主題として書かれた本は全て、ユーザーによるテストの重要性を強く強調しています。しかし、この謎かけでは Zen of Palm を踏まえたユーザーテストを行なうためのある種のアプローチを提案します。このアプローチはハンドヘルドとそのアプリケーションをデザインしている PalmSource、およびそのライセンシー各社が使用しているものです。
デザイン品質の検証
もしユーザーインターフェースのテストが本当に重要かどうかについて懐疑的なら、あなたや一緒に働いているエンジニア・デザイナとあなたの顧客がどれくらい違うかについて考えてみて下さい。コンピューティングの世界に属していると、仕事の全てでコンピュータを使うことが自然になります。たとえばデスクトップやハンドヘルドのバラエティを前にしても、コンピュータに恐れをなすことなどありません。それを使って仕事をすることや、それを理解することを楽しむことができます。そんなあなたのコンピュータへの親しみは、非技術系分野の人々に対する理解を困難にします。ハンドヘルドを含め、コンピュータというものは不動産やペットショップを本業としている人々にとってはまったくの異質物に感じられるものです。非技術系の人々はコンピュータを快適に感じるとは限りませんし、使うことを好むとも限らないのです。
コンピュータに居心地の悪い思いをするという状態の感触を掴むために、新しくより効果的な、しかしフランスの文学や哲学の知識を要求されるコンピュータプログラム開発の世界を想像してみましょう。アプリケーションをコンパイルしようとして、次のようなエラーメッセージが出力されたとします。“付帯現象イベントです。デカルト的二元論を用いてリトライして下さい。” あなたは思うでしょう。ぼかぁエンジニアであって哲学者じゃないんだ！ ってね。そしていずれこのコンパイラに反抗を企てることになるのです。
基本的なユーザーテスト
多くの人々はコンピュータやコンピュータ関連の製品を好まないため、ユーザーテストでフィードバックを得ることが重要になります。これは必ずしもコストが高くつくものではありませんし、とりわけ難しいものでもありません。経験のあるデザイナでさえ、シンプルなユーザーテストから有益な結果を得ることができます。
重要なのは理論の徹底ではなく、現実のユーザーであることを忘れないで下さい。だからこそ、アプリケーションが現実的な状況で有用かどうかをテストするべきなのです。以下の基準を心に留めておいて下さい。
- アプリケーションは制限があったとしても作業を完全に実行できるか？
- ユーザーはアプリケーションの名前と、とりわけそのユーザーインターフェースからアプリケーションが何をするものか理解できるか？
- ユーザーインターフェースは、アプリケーションに実際には実装されていない各種の魅力的な機能をほのめかしていないか？（おそらく、ユーザーの混乱と失望を避けるために再デザインが必要）
- 全ての機能を見つけ出すのにどれくらいの時間がかかるか？
- 以前見つけたことのある機能を思い出すのにどれくらいの時間がかかるか？
では、シンプルなユーザーテストを行なうためのいくつかのアイデアを検討してみましょう。もっとも重要な考え方は、たくさんの非公式なテストの実施は形式的なテストを少しだけやったり全くやらないよりも良いということです。マジックミラーを用意してコンサル企業を雇ったりする必要はありません。個人の開発者や小さな企業であれば、基本的なテストしかできないかもしれません。包括的なテストを行なうだけの資源を持ち合わせている企業であれば、基本的なテストは包括的テスト計画の最初のフェーズにすることができるでしょう。
シンプルなユーザーテストは、それができることの全てであれ大きなテスト計画の一部であれ、早めに開始しましょう。アルファ版ができるまでユーザーインターフェースデザインのテスト開始を待つという誤ちをおかしてはなりません。まずなんらかの動作するものを作ってからユーザーテストを始めるべきだと考えるのであれば、おそらくはすでに罠にはまっています。その時点で動作するものを得るために多くの作業を行なっても、ユーザーテストでそのデザインが全て間違っていることに気付くだけでしょう。それまでにやってしまったエンジニアリング作業を全て反故にしたいのですか？ それをやるには多分遅過ぎるでしょうから、デザインを妥協せざるを得なくなってしまうのです。
- POINT
- 早い段階からテストせよ
早いスタートをきるために、デザインのユーザーテストはスクリーンショットをシミュレートしたものを使って始めましょう。これは、鉛筆とインデックスカード、HTML ページ、Macromedia Director、Adobe Illustrator、Satellite Forms、NS Basic、Visual C++、Metrowerks Constructor、その他何でもお望みのものを使って作成できます。アルファ版を待っていてはいけません。
- POINT
- シミュレーションを使ってテストせよ
早期のテストでは、ユーザーインターフェース全体をカバーする必要はありません。テストは選択的に行なうことができます。最高の出来栄えを実現しなければならないようなユーザーインターフェースの特定の部分を明確にするところから始め、それらをテストしましょう。それに加え、疑念を感じる部分についてはそれが本質的でなくても全てテストしましょう。これは、Palm 社がまだ小さな企業だった頃、オリジナルの Palm ハンドヘルドのユーザーインターフェーステストにおいてデザイナがとったアプローチです。包括的なユーザーインターフェースのテストを行なうことのできない個人の開発者や小さな企業では、もっとも重要な部分に絞ってテストを行なうことができるのです。
- POINT
- 選択的にテストせよ
もちろん、包括的な本式のユーザーインターフェーステストができる場合でも、非公式で選択的なユーザーテストをやめるべきではありません。完全なドキュメントを備えた形式的なテストは、確信や信念に基づく賭け、および 80/20 ルール適用の基礎となるデータを与えてくれます。
テストの被験者は、製品の詳細に膝まで漬かっている人でなければ誰でも ── 受け付け係や誰かの義理の兄弟、あるいは通りを歩いているその辺の人々でも ── なることができます。彼らを連れてきて席に座ってもらい、アプリケーションを使って彼らにしてもらう作業について説明します。彼らにその作業を実行してもらい、進行に合わせて彼らが何をしているのか質問しましょう。後は話を聞きながら見守るだけです。彼らがどこでつまずくかを観察しましょう。
- POINT
- 外部の人々を使って、入念にテストせよ
観察の間、メモをとりましょう。順序付けられたドキュメントは、テストを正確に評価し、どのような変更をするべきかを正しく判断する助けになります。
同じテストを実施する全ての被験者に対し、設定や進行に一貫性を持たせましょう。テストの度に、被験者には同じ説明をし、同じ質問をするようにします。被験者それぞれの反応や動作を記録に残して下さい。全員に対して同じ方法でテストの設定と実行をすることにより、結果をより有意義なものにすることができます。
デザインの中にトラブルの起こりやすい個所を見つけたら、トラブルを解消または低減するような調整を行ないましょう。そしてさらにいくつかのテストを行ないます。テストして、調整。これを繰り返しましょう。コーディングが進み過ぎる前に、デザインを洗練するのです。反復的なユーザーテストは、オリジナルの Palm ハンドヘルドの成功における決定的な要因でした。実際、ソフトウェアデザイナはコーディングの前に、全てのユーザーインターフェースのプロトタイプをハイパーカードで作成していたのです。
- POINT
- 繰り返しテストせよ
なにを見つけたか
ユーザーインターフェースデザインをテストすると、デザインの一部をユーザーが理解できないことに驚くでしょう。あなたはアプリケーション全体のコンテキストで見ているため、あなたにはデザインのその部分はものすごく明白なものに見えます。あなたは全てのディテールがどのように全体に組み込まれているかを見ているわけです。ユーザーはそのようなコンテキスト抜きで個々の機能や手続きを見ていますし、何が起こっているかについては特に考えていません。ユーザーが画面のどこをタップすべきか、あるいは何を入力すべきかがわからないのであれば、それを知る必要があります。たとえば、PalmSource 社のネットワーク HotSync ソフトウェア、これはネットワーク経由やリモートでの同期を可能とするものですが、その画面には次のように書いてありました。“ユーザー ID とパスワードを入力して下さい”。これをあとどれくらい明確にできるでしょうか？ そう、これはある被験者を降参させてしまったのです。彼はユーザー ID というのがハンドヘルドのユーザー名なのか、あるいはネットワークのユーザー ID なのか、はたまた電子メールのユーザー ID なのか判断できなかったのです。デザイナはコンテキストを知っているため、どのユーザー ID を入力すれば良いかわかりましたが、この入力要求はユーザーにとっては曖昧だったのです。
ユーザーテストは、平易な言葉に置き換えるべき専門用語もまたあぶり出してくれます。私達は業界用語に慣れてしまっているため、それを忘れがちです。業界用語の使用を避けるためには、コンピュータの経験が少ししかない人にそれをどう説明するかを考えましょう。たとえば、検索機能の説明をするのであれば、“検索モーダルダイアログのテキストフィールドに検索文字列を入力して下さい”などと言わず、“行の中から探したい言葉を書いて下さい”としましょう。
- POINT
- 平易な言葉を使うこと
専門用語や曖昧さ、あるいはその他の言葉の問題を片付けるには、文書作成者や編集者、あるいは少なくとも文系の友人にでもアプリケーションのダイアログを一通り見てもらうことです。これは有利な時間的投資になります。
ユーザーテストはデザイン上のその他の不備も明らかにしてくれます。これには、“アルバカーキで左折”症候群も含まれます。これは古いバックス・バニーのアニメに出てくるもので、バックスがマイアミビーチへの長いトンネルを掘っていたところ、おかしなところに出てしまい、「アルバカーキで左に曲がらなきゃいけないような気がしたんだ」と言うというものです。同様に、なんらかの作業をしようと試みるユーザーはアプリケーションに関するメンタルモデルを作り始めます（これが長いトンネルを掘るのに相当します）。もしユーザーが早い段階で誤った方向を向き、そのまま進んでしまったら、その誤りにもとづいたモデルを作ることになり、最終的にはユーザーは非常に混乱することになるのです。
- POINT
- 操作の道筋を明確にしよう
人々はアプリケーションを使ってみる時、それがどのように機能するかを理解しようとし、そしてある操作に関するいくつかの選択肢や道筋を前にして、どの方法をとるか決めるために消去法を使う場合があります。最初に彼らはもっともありそうにない選択肢を排除し、その次にありそうにない選択肢を、同様にして残りが１つになるまで選択肢を排除します。これは人々が多肢選択式のテストをする時に使うのと同じ方法です。このアプローチは、アプリケーションのデザインがシンプルで整理されている場合にうまく機能します。選択肢があまりに多いと、どれが正しいのかを見極めるのが難しくなります。それ以降も、ユーザーは多くの選択肢のうち、どれが正しいのかを思い出そうとして苦労するでしょう。選択肢が２〜３個しかなければ、ユーザーはどれが正しいかをより簡単に判断したり覚えておくことができます。
なぞかけ３の答え
さぁ、３つめのなぞかけに答える準備ができました。
Q: 鍛冶屋が完璧な蹄鉄の作り方を学ぶためには？
A: 馬の口から直接聞くべし
“馬の口から直接聞く”という言葉は、馬の扱いに関する古代芸術からきています。 購入を検討している客は、生き物の口の中を見たり歯をチェックすることによって、馬の成長期における不審な徴候を確認できたのです。
私達のなぞかけの場合には、“馬の口から直接聞く”という表現には２つの意味があります。１つ目は、ユーザーの意見を聞くべきだということです。漫画に登場するおしゃべりな馬のように、彼らは彼ら自身のニーズについて多くのことを知っており、あなたは彼らから学ぶ必要があります。もうひとつは、自分自身について知り、学ぶ必要があるということです。馬を観察しましょう。どのように歩くのか見るのです。別の地面ではどうでしょう？ 歩き難いのはどれでしょう？ でこぼこ道？ 舗装道路？ 一番役に立つのは何でしょうか？ 同様に、ユーザーには観察する価値があります。彼らはアプリケーションにどのようにアプローチするでしょうか？ あなたのイノベーションは、彼らの期待やコンピュータの使い方にどのように適合するでしょうか？
鍛冶屋は蹄鉄を試しに馬に付け、フィットするかどうか観察し、より良くフィットするように作りなおすことで蹄鉄を改善することができます。あなたはユーザーインターフェースデザインをテストし、人々がどこでつまずくかを観察し、トラブルがなくなるようにデザインを変更することで製品を改善することができます。これは明白なことに見えるかもしれませんが、製品の完成に向けて突き進んでいる時に必要な時間を確保するのは簡単なことではありません。
シミュレーションを使って早い段階からテストを始めましょう。部外者を使って、入念にテストを行なうようにしましょう。全てをテストできないのであれば、重要な部分と自信を持てない部分をテストしましょう。製品の発展にあわせてテストを続けましょう。ユーザーテストにかけた努力は、長期的な製品の使いやすさやカスタマーサポートのコスト削減、そして顧客を喜ばせるといったことによって報われることになるでしょう。
