Palm Programmer's Laboratory
Palm OS User Interface Guidelines/1-2
1-2 デザインプロセス
前のセクションでは、Palm ハンドヘルドの重要な特徴と、その特徴がアプリケーションのユーザーインターフェースにどのような影響を及ぼすかについて学びました。Palm ハンドヘルドの特徴は、ユーザーにフォーカスしたデザインプロセスによってもたらされました。ユーザーは速く、簡単に使え、バッテリ寿命が長く安価なデバイスを求めています。全てのデザイン上の決定は、ユーザーにこれらのものを提供するためになされたのです。
このセクションでは、PalmSource 社の内外で優秀なデザイナによって使われているユーザー中心のデザインプロセスを紹介します。このプロセスに従えば、アプリケーションを素晴らしいものにできます。ユーザーにフォーカスしたデザインプロセスは別段新しいものでも独特なものでもありません。優秀なインターフェースデザイナは、どのプラットフォームでも同じようなプロセスに従っています。
驚くにはあたりませんが、大抵の場合ユーザー中心のデザインプロセスは守られません。結果できあがるのは貧弱なユーザーインターフェースです。このような理由から、このセクションではまずインターフェースデザインの誤った、誰もがやってしまいがちなアプローチから説明します。その後、推奨されるアプローチを説明します。
普通のアプローチ
取り組んでいるアプリケーションがどのようなものになるかが見えてくると、すぐにその中に飛び込んでコーディングを始めたいという誘惑にかられるものです。そしてデザイン上の問題は開発サイクルの後の方でなんとかしようと考えるのです。しかし、これはアプリケーションのデザインとしてはほとんど常に、とりわけ Palm OS では間違った方法です。
ほとんど無制限の処理能力と大きくてカラフルなディスプレイがある場合、ある程度は貧弱なユーザーインターフェースを免れることができます。Palmハンドヘルドでは、デザイン上の欠陥はもっと目につきがちです。
アプリケーション開発者はテクノロジーが好きですから、彼らの本能は技術的な解決にフォーカスしがちです。ユーザーが解決したがっている本当の問題は、クールな機能の追加ラッシュにより埋没してしまいます。
書籍コレクター向けアプリケーションのデザインを担当することになったとしましょう。ユーザーが望んでいるのは、所有している書籍を管理でき、どれを誰に貸しているのか、それがいつ返ってくるのかがわかることです。この課題に対する「技術フォーカス」なアプローチの典型例は以下のようなものになるでしょう。
“このアプリケーションには少なくとも画面が２つ必要だ。メイン画面は書籍のリスト、２つ目のはその書籍が貸出中か、そうであれば誰に貸出中かを表示する詳細画面だ。「新規」ボタンが必要だし、そうだな、編集ボタンと削除ボタンも必要だよね。あと、書籍リストはタイトルと著者名でソートできないと。データ入力は、新しい本を入手した時に ISBN 番号をスキャン入力できるようにしたいね、ユーザーがバーコードスキャナを持ってるかもしれないから。その方が Graffiti で書くより断然速いし。書籍データをお互いにビームしあったりもできるな。Palm VII シリーズを持ってるユーザー向けに、アプリから Web クリッピングアプリケーションへリンクしてオンラインで本を買えるようにするとか．．．”などなど。
この最初の思考プロセスの後、すぐに最初のスケッチが描かれます（図 1.4 参照）。
図 1.4 最初のデザインスケッチ
ご覧のとおり、このアプリケーションデザインの方法は信頼できるプロセスというより、ブレインストーミングのセッションにそっくりです。このようなプロセスは、まともなアプリケーションに辿り着くかもしれませんし、辿り着かないかもしれません。この最初のデザインにはいくつかの問題があります。
- ISBN 番号のスキャン機能はナイスかもしれませんが、それは ISBN 番号しか拾うことができません。ユーザーは Web などでその番号を検索し、書名などに変換しなければならないでしょう。デバイスにバーコードスキャナがついていないユーザーや、ISBN 番号のないほど古い本をたくさん持っているユーザーはどうするのでしょう？
- 書籍情報の赤外線通信はちょっとした便利機能ですが、そのささやかな便利さのわりには処理コストがかかります。誰かさんに書籍情報をビームするのは、どれくらい意味のあることでしょうか？
- その本が貸出中かどうかの確認のために詳細画面への移動を強いるのは、ユーザーがしたいことが単に一覧を眺め、どれが貸出中かを知りたいだけの場合には退屈な作業になってしまうでしょう。
お勧めのアプローチ
さて、インターフェースデザインの普通のアプローチについて見てきました。次は、もっと良いアプローチについて考えましょう。このアプローチは複数のステップに分かれていて、より望ましい ―― ハッピーになれたユーザーが喜んでお金を出してくれるような ―― 結果をもたらしてくれるものです。この正しいアプローチのステップは以下のとおりです。
- デザイン目標を決める
- ユーザーを知る
- ユーザーシナリオを作る
- 実装案を作成する
- 最初のデザインコンセプトを開発する
- デザインを完成させる
ここで説明するデザインプロセスに、完全に従う必要は必ずしもありません。特に、小さな企業や個人でやっている場合には。ソフトウェア開発は多くの要因に影響される複雑な仕事であり、全てのプロジェクトは互いに異なります。とはいえ、この推奨 UI デザインプロセスについて知り、できるだけそれに従えば良いことがあるでしょう。
デザイン目標を決める
Palm のデザイナは、次のデザイン目標の実現を決めました ―― デバイスはシャツのポケットに収まり、速くて簡単に使え、学習曲線が急でなく、低コストで、安心して使えるだけのバッテリ寿命を持つこと。Palmのデザイナがデザイン目標を持って始めたのと同じように、アプリケーション開発でもデザイン目標を持って始めるべきです。一般的な Palm OS アプリケーションのデザイン目標のセットは以下のとおりです。
- 学習と使用が簡単
- 便利
- 多くの人が多くの場合に望み、必要とするものを提供する
- ユーザーの素早い目的達成を手助けする
アプリケーションは他の目標を持つこともできますが、Palm OS プラットフォームで成功したければ上記のデザイン目標を達成すべきです。
小さな企業では、アプリケーションのアイデアとデザイン目標は間違いなくあなた自身から出てくるでしょう。大きな企業では、デザイン目標はマーケティング部門から出てくるかもしれません。前節の書籍アプリケーションの例を考えてみて下さい。アプリケーションが何をすべきかという記述は、大きな企業のマーケティング部門から出てくるかもしれませんし、独立したアイデアかもしれません。“書籍コレクターが、書籍をいつ誰に貸したかを管理できるアプリケーションを作成する” これに、Palm OS の伝統的なデザイン目標は副詞を単純に追加します。“書籍愛好家が手早く、簡単に書籍を管理し、誰に貸しているかわかるようなアプリケーションを作成する”
ユーザーを知る
ユーザーは千差万別です。もしあなたがコンピュータのプロフェッショナルのような人であれば、すなわちあなたは Palm ハンドヘルドの、あるいはあなたの製品の未来の典型的ユーザーではありません。
ハンドヘルドは使い方が簡単なため、コンピュータ業界の外でも多くの人を惹きつけます。コンピュータ業界の人には“ハードウェア”と“ソフトウェア”、“アプリケーション”の違いは快適ですが、業界の外にいる一般的なユーザーはハンドヘルドを総合的に１つのデバイスとして見ています。彼らはハードウェアの問題とソフトウェアの問題、あるいはアプリケーションのバグを区別するという考えを持っていません。彼らが知っているのは自分にやらねばならない仕事があるということだけであり、Palmハンドヘルドがその手助けをしてくれることを期待しているのです。
アプリケーションが訴求しそうなユーザーベースをよく調査して下さい。できれば、ターゲットユーザーをより良く知り、彼らがなぜそのアプリケーションを欲しがっているのかを学ぶためにフォーカスグループを設定します。ワインデータベースのアプリケーションなら非技術系の顧客に広く訴求するでしょう。内部メモリを調査するユーティリティは顧客のほとんどが技術系のはずです。ゲームであれば Palm界の技術系と非技術系の両方に訴求力があるでしょう。
広範な顧客のために、できるだけ組込みアプリケーションに追従しておきたいと考えるでしょう。ユーザーはすでそれらの使い方を知っており、それ故にあなたのアプリケーションの使い方についても暗黙のうちによく知っているということになるのです。機能を“改良”するのはやめましょう。“改良”というのは、グローバル検索機能におけるプレフィックスと同じようにサフィックスでの検索をサポートするようなことです。
一部の限られた、高度に技術的な顧客を対象としているのであれば、ユーザーインターフェースデザインの大部分を免れるかもしれません。しかし、優秀なインターフェースは決して害にはなりません。良い UI を作れば、ユーザーはそのアプリケーションをより高く評価してくれるでしょう。
前節から見ているデザイン目標のような典型的ユーザーの記述は、マーケティング部門から別の情報としてやってくる場合もあります。小さな企業には、マーケットリサーチの専門知識を備えた大きなマーケティング部門を持つという贅沢はできないかもしれません。しかし、友人や家族の中からでもユーザーを見つけ、彼らのニーズについて話すことはできます。
書籍アプリケーションについては、以下の特徴を持つ人々がこのアプリケーションを買いそうだということがわかりました。
- 読むことが好き。
- 大抵たくさんの本を所有している。
- 暇さえあれば本屋をぶらついている。
- しばしば、どの本を持っていてどの本を持っていないか、または持っていてまだ読んでいないかを思い出せない。
- たくさんの本を友人に貸しているため、どの本を持っているか調べる時に問題になる。
- 多くの人はテクノロジーが苦手。
対象となる顧客の大部分はテクノロジーが苦手なので、できるだけ簡単に使えるようにアプリケーションを作成しなければなりません。そして、ユーザーが既に慣れ親しんでいる組込みの Palm OS アプリケーションと同じ感覚で使えるように作成する必要があります。
ユーザーシナリオを作る
典型的なユーザー像を集めたら、そのユーザーを意識しながらデザインを始めます。そのアプリケーションを使って、ユーザーはどのような問題を解決しようとしているのでしょうか？ どのような前提のもとでユーザーはアプリケーションを使おうとしているのでしょうか？ ユーザーはオフィスにいるのでしょうか、空港？ 自宅？ それとも車の中でしょうか？
いくつかのユーザーシナリオを作りましょう。ユーザーシナリオは、ユーザーがそのアプリケーションでいつ、何をするかを記述したものです。“ユーザーは１日に５回、地下鉄に乗っている間に電子メールにアクセスする必要がある”というのは良いシナリオ記述です。ユーザーが何をするか、彼または彼女がどこでそれをするか、どれくらいの頻度でするかが明記されています。ユーザーシナリオを作成するもっとも良い方法はもちろん、フォーカスグループや他の方法を使って、潜在的なユーザーと話をすることです。
ユーザーシナリオを見つけ出すには、以下のことがらを知っている必要があります。
- ユーザーがその作業をする可能性
- ユーザーがその作業をする頻度
例えば、Date Book でその日のスケジュールにアクセスすることから始めるのは頻繁に ―― １日のうちに数回は ―― ありそうなことです。頻繁に利用される作業は、簡単に実行できなければなりません。
予定の入力は頻繁に実行されるもう１つの作業です。しかし、０分や30分以外の時間から始まる予定（例えば 3:05など）というのはそれほど多くありません。このような予定の入力を可能にするとしても、頻繁に発生するわけではありませんからタップが数回余分に必要となっても良いでしょう。
必要でも頻繁に実行されないタスクというものもあります。たとえば、新しい Palm ハンドヘルドを使い始める時には、最初のアプリケーションとして Welcome アプリケーションを起動するものです。しかし、通常起動されるのは１回だけですから、頻繁とはいえません。
頻繁には発生しないと思われるものも含め、できるだけ多くのシナリオを作成して下さい。これはデザインプロセスの中でもトリッキーな部分です。アプリケーション開発チームがサポートする、想定済みのシナリオは簡単に作成できるものです。そのようなシナリオだけにフォーカスしていると、最終的にできあがるアプリケーションは、チームのニーズには合致していてもユーザーのニーズには必ずしも合致しないでしょう。網羅性の高いユーザーシナリオは、ユーザーのニーズに注目し続ける努力を必要とするのです。
書籍アプリケーションのデザインにおける誤ったアプローチに関する議論を覚えていますか？ あのデザインにはバーコードスキャン、ビーム、および Palm VII のワイヤレスインターネット接続を使用した書籍購入が盛り込まれていました。これらは悪いアイデアではありません。しかし、ユーザーベースにはテクノロジーが苦手な人々が多く含まれていることはすでに見たとおりです。彼らは通常、m100 のようなローエンドのハンドヘルドに惹かれます。ハイエンドのハンドヘルドを持っているユーザーは少数でしょう。Palm VII を持っていそうにはありませんし、ましてやバーコードスキャナを持ってなどいないでしょう。それゆえに、ISBN 番号のスキャンやインターネット経由での書籍購入はあきらめなければならないのです。ビーム機能でさえ、実際に Palm Professional ユーザーが数多くいることがわかれば捨てなければならないでしょう。カラー表示への依存は、このアプリケーションでは間違いなく良くないアイデアです。カラーのハンドヘルドは高価になる傾向があります。人々がそれを持っている保証はありません。
テクノロジーにフォーカスしたデザインは誤った方向へ逸れて行ってしまいがちなので、アプリケーションのユーザーシナリオをいくつか検討するようにしましょう。
- ユーザーは所有している全書籍の一覧を見たいと思っています。（頻繁にありそう）
- ユーザーは書店にいて、特定の本を所有しているかどうかを知りたいと思っています。（頻繁にありそう）
- ユーザーは書店にいて、新しく購入した書籍をリストに追加したいと考えています。（頻繁にありそう）
- ユーザーはデスクトップコンピュータから離れており、インターネットで書籍を購入したいと考えています。（頻繁でもありそうでもない）
- ユーザーは友人に本を貸そうとしています。（ありそうだが頻繁ではない）
- ユーザーは自宅にいて特定の書籍を探しており、それが貸出中かどうか知りたがっています。（頻繁にありそう）
- ユーザーは貸出中の書籍一覧を見たいと考えています。（ありそうだが頻繁ではない）
- ユーザーは特定の著者、あるいは特定のテーマについて所有している書籍の一覧を見たいと考えています。（ありそうだが頻繁ではない）
- ユーザーは指定した人物に貸している書籍の一覧を確認し、それらがいつ返却される予定かを知りたがっています。（頻繁でもありそうでもない）
- ユーザーはバーコードスキャナを所有しており、新しい書籍の ISBN 番号をスキャンしたいと考えています。（頻繁でもありそうでもない）
デザインの最初の３つのステップ（デザイン目標を決め、ユーザーを知り、ユーザーシナリオを作成する）では、ユーザーの問題をどのように解決するかについてはまだ着目していないことに注意して下さい。そのかわり、彼らの問題を解決できるよう、ユーザーを理解することに注力するのです。
実装案を作成する
ユーザーが誰で、アプリケーションをどのように使うかのイメージを掴むことができたので、次のステップではアプリケーションの実装案を記述します。この記述では、アプリケーションの見た目よりも操作感に着目します。これにより、実装の案はユーザーシナリオから自然に導かれます。
このステップの背後には、２つの考え方があります。第一に、実装案への合意の上でアプリケーションの設計と開発に全員を巻き込んでしまえば、エンジニアはインターフェースデザイナによる外観のデザインと並行して機能を設計できます。第二に、アプリケーションの操作感にフォーカスすることにより、アプリケーションの外観に関する（この時点では開発を不必要に遅らせることになる）ありがちな論争を先延ばしにできるのです。
もちろん、１人で仕事をしているのであれば外観の開発をする前に実装案を作成するこれら２つの理由は無関係です。外観への注力を少し先延ばしにしてソフトウェアを開発することが役に立つと思うかもしれませんし、思わないかもしれません。いずれにせよ、ユーザーシナリオのフローや前のステップで作成した典型的ユーザーの記述に従って実装を行なっていくことになります。
書籍アプリケーションの実装案は以下のとおりです。
- 起動時の画面はアドレス帳に非常に似ています。所有している書籍の一覧が表示され、タイトル順にソートされています。アドレス帳のメイン画面を真似るのは、このアプリケーションに親近感を感じやすくするためです。
- ユーザーは大量の書籍を所有しているかもしれないので、アドレス帳と同じように文字を入力するだけで書籍を検索できるようにします。
- 特定の書籍を所有しているかどうかを素早く知ることができるように、特殊な表示が可能なフィルタを提供し、特定の著者の全ての書籍や特定のテーマに関する全ての書籍、貸出中の全ての書籍を表示できるようにします。
- 起動時画面では、新しい書籍情報の入力や書籍の詳細情報表示を可能にします。
- 詳細画面には、タイトル、著者名、カテゴリ、および友人への貸出に関する状態が表示されます。
- メイン画面は、ユーザーが素早くリストをスクロールしてどの本が貸出中かを見られるように、貸出状態を表示できるようにします。
- データ入力を簡単にするため、デスクトップアプリケーションに統合されたコンジットを提供し、ユーザーが書籍情報のほとんどをデスクトップで入力してハンドヘルドに同期できるようにします。人は時に同じ著者の本をいくつか購入しますから、著者名に関してはデータベースに既存の著者名にもとづいた名前補完機能を提供します。
- 他の組込みアプリケーションとの統合も行ないます。友人への書籍の貸出しは名前でアドレス帳にリンクされ、連絡先もそこに含まれることになるでしょう。友人が本を返却する日付を入力することにより、予定表との連携もできるかもしれません。ただし、多くの人は友人への貸出しに期限を設定しないため、常に利用可能な機能にするよりはユーザー設定で有効にできるオプション機能にした方が良いでしょう。
テクノロジーにフォーカスしたデザインアプローチを思い出してみると、新規ボタンに加えて編集ボタンと削除ボタンをすぐに思いついています（あとスキャニングとビーム、ワイヤレスインターネット経由での書籍購入もありましたが、前のステップで除外しました）。ユーザーが頻繁に行なう作業にフォーカスしている間、編集と削除のボタンは話題に昇りませんでした。書籍情報は変化しませんから、編集ボタンは……そう、アドレス帳の編集ボタンほど重要ではありません。それに、書籍愛好家は滅多に本を捨てません。しかし、ユーザーがデータ入力での誤りを修正できるよう、なんらかの方法を提供すべきでしょう。そのため、サブ画面メニューまたはコマンドボタンとして編集と削除を提供することにします。
最初のデザインコンセプトを開発する
アプリケーションの特徴を記述し終わったら、次は外観を開発する番です。最初のデザインコンセプトに着目しながら始めましょう。最初のデザインはメイン画面に焦点を当てています。この時点で、UI 要素の選択が問題になってきます。しかし、ユーザーインターフェースの詳細は確定できないでしょうし、アラートのようなサブ画面はもっと後になるまで無視されることになるでしょう。
ユーザーシナリオの可能性と頻度を考慮することは重要です。頻繁に使用されるコマンドや設定は、より簡単に発見でき、素早く実行できるべきです。
アプリケーションの重要な機能に簡単にアクセスできるよう、適切な UI 要素を選択します。 UI 要素の選択に関する詳細は本書の残りの章で説明しています。
図1.5に、書籍アプリケーションの初期デザインコンセプトを示します。誤ったアプローチによる最初のデザイン（図1.4）との違いに注目して下さい。
図1.5 初期デザインコンセプト
ユーザーのニーズを学ぶのに時間をかけたため、彼らの抱える主要な問題が収集した大量の書籍の管理であることはわかっています。ユーザーシナリオには、頻繁に行なわれる作業としてどの本を所有し、それがどこにあるのかを確認するというものがあります。書籍の一覧は非常に長くなりうるため、もっとも重要な作業は文書一覧の提示と新しい書籍の入力であると判断しました。メイン画面では、カテゴリ選択による表示のフィルタリングや、ルックアップフィールドへの文字入力による移動などにより、書籍情報のナビゲーションを支援します。ノートアイコンを使うことにより、書籍一覧をスクロールするだけでどの本が貸出中かを簡単に確認できます。ノートアイコンをタップすると、貸出しに関する詳細情報を表示します。貸出情報は、誰にいつ貸出して、いつ返却されるのかを表示し、ルックアップボタンを提供することで、返却期限を知らせる必要がある場合にアドレス帳の連絡先情報に素早く移動できます。
他の画面も用意します。書籍タイトルのかわりに著者名でソートできるようにするプリファレンス画面や、特定の人物に貸出している書籍を検索する検索画面です。これらの作業はユーザーシナリオでは頻繁には発生しないものとして記述されているため、コマンドボタンではなくメニューを通してアクセスすることになります。
この時点ではまだスケッチに過ぎないかもしれませんが、作成したデザインがユーザーのニーズに適合しているかどうかを検証するために、この段階でユーザビリティのテストを始めるのにそのスケッチは適しています。メモ用紙くらいシンプルなテクノロジーを使ってモックアップを作ることもできますし、共通タスクのユーザーウォークスルーをすることもできます。ユーザビリティのテストを実施したら、デザインコンセプトに磨きをかけて次の段階が完了するまで再テストをします。
デザインを完成させる
主要なコンセプトがプロジェクトに参加している（インターフェースデザイナやマーケティング、エンジニアリングを含む）全員の合意を得られたら、デザインを確定できます。この時点で、アプリケーションの全画面をデザインし、全ての画面遷移を把握する必要があります。また、全てのUI要素を画面上に正しく配置し、メニューのデザインもする必要があります。全てのエラー状態も定義する必要があります。
この段階はソフトウェアのアルファバージョンの作成段階でもあるべきです。従って、アルファリリースが完了したら、より多くのユーザーテストとフィードバックを得ることができ、ベータビルドやその先の最終ビルドへのデザインを洗練していくことができるのです。
アルファ版の開発中にデザインは完成しているということに注意して下さい。多くの開発者は製品開発サイクルのもっと後までユーザーインターフェースデザインを放置しておきたがりますが、それは誤りです。もし最後まで待っていたら、初期デザインは開発済みのコードに縛られてしまいます。先延ばしにするほどデザインの変更は困難になり、インターフェースをそのまま放置する理由付けは簡単になっていくのです。
