コンピューターの専門家… 1997年当時のプログラマーの姿

Web アプリケーションのプログラマーというものは、故意にではないにしても、かなり自分本位の連中です。私たち (当然、私も含まれます) は、誰もが自分たちと同じか、あるいは元々プログラマーのようになりたがっている、と思い込みがちだからです。10 年前、私たちは Y2K 問題に対してアプリケーションの「将来を保証する」ための作業の報酬で新車を買えるほどでした。この作業の多くは、年の表記を 4 桁のフォーマットに忠実に変換する簡単なもので、笑いが止まりませんでした。哀れな大衆は、わけのわからないインターネットとプログラマーたちが構築するアプリケーションをどうにか理解しようと必死でした。

しかしその 10 年後、Y2K 問題を懸念していた大衆は立ち上がり、まさしくインターネットを占拠するようになりました。今では、隣人のブログを読んだり、義理の母親のソーシャル・ネットワーキング・サイトに書き込みをしたり、長い間音信不通だった従兄の家族写真を見たりできます。いずれにしても、利用されているのは 10 年前のコンピューターの専門家が構築した Web アプリケーションです。ただし、ここに大きな問題があります。アプリケーションを使用しているユーザーは、Web プログラマーのような人々ではありません。ユーザーにとって優先度の高いものや、社会的アイデンティティーはそれぞれに異なり、Internet Explorer を起動するときに何を期待するかもユーザーによって全く違います (大部分のユーザーは IE を使用していて、Firefox については名前も聞いたことがないぐらいです)。

この点がなぜ問題になるかと言えば、このようなユーザーがインターネットの世界で優勢になるにつれ、ユーザーの知識も豊富になってきています。しかしこの知識とは、Web に関するものではなく、自分が気に入っているものに関する知識であり、自分が煩わされていることに関する知識です。最近の優れた Web アプリケーションでは、機能と同じくユーザー・インターフェースも重要です。ユーザーにとって、ソーシャル・ネットワーキング・サイトでクリスマスの飾りを誰かに送れるかどうかは、忘れてしまったパスワードを思い出すための機能があるかどうかと同等の関心事です。このようなユーザーを満足させるには、blink タグを使わないようにするだけでは事足りません。ユーザーはプログラマーの技術的な知恵には関心ありません。彼らが求めるのは、直観的で使いやすいアプリケーションです。プログラマーはこのようなアプリケーションを実現しなければなりませんが、その対象となるユーザーについては必ずしも十分に理解しているとは思えません。

プログラマーは、自分たちとは違うユーザーをどのようにして満足させられるのでしょうか。それには、名前と職業でプロファイルを作成しようとするのではなく、ユーザーが入力する内容について理解しなければなりません。ユーザーの好き嫌いをどうやって知るかも重要ですが、最も重要なことは、あなたが作った Web アプリケーションとユーザー・インターフェースについてユーザーの好き嫌いを決定する要因は何であるかを知ることです。

最近のインターネット・ユーザーは独学で学んでいます

何よりもまず、最近のインターネット・ユーザー、つまりあなたの Web アプリケーションを使用する人々は独学でインターネットを学んでいます。彼らは Web アプリケーションをほとんど直感だけで理解しますが、理解の拠り所とするのは、自分たちの世界で物事が機能する仕組みについて持っている知識だけです。コンピューター・サイエンスのカリキュラムを受けているわけではないので、ソーシャル・ネットワーキング・サイトで友人のリストが静的配列として保存されるのか、連結リストとして保存されるのか、あるいは Friend オブジェクトへの一連の参照として保存されるのかに関心を持つことはありません。

ユーザーは、インターネットの外にある世界に基づいて理解できるものをクリックしているだけに過ぎません。例えばユーザーが誰かにメッセージを送信するとします。ユーザーは、確認ボタンが表示されることや、使用可能なキーに制限があることは、一切想定していません。そこでプログラマーは、ユーザーがメッセージを入力して顔文字やその他の小さな署名テキストなどを追加し、ボタン 1 つで送信できるようにしなければなりません。一方、本を購入する場合には、本の裏表紙を「読んで」、本の見返しをチェックし、表紙を見てから、簡単に (そして衝動的に) ショッピング・カートに追加して購入手続きに進めるようにします。購入手続きでは、送料見積もり、税、関連本のタイトルが表示されるなど、細かな手順が続きますが、これらはユーザーが望む手続きの中心ではありません。ユーザーが望んでいるのは、現実の世界での体験をモデル化した手軽な購入手続きです。

手本とするのは、新しいメディアです

それでは現実の世界とは一体何でしょう。何がユーザーの体験を教えてくれるのでしょうか。ユーザーがアプリケーションに満足しているのか、それともアプリケーションの動作があまりにもひどくてクレームの E メールをカスタマー・サービス・チームに送るほどなのかは、当然、コンピューター・サイエンスの教科書を読んでもわかりません。ユーザーは Tim Berners-Lee と Jakob Nielsen の名前を耳にしたこともないでしょうが、この 2 人が専門としている分野は新しいメディアです。

一般的な Facebook のユーザーに、平日の夜に何をするかを聞いてみてください。ほぼ間違いなく、「TV」、「TiVo」、「YouTube」、そしてかなりの数で「XBox」や「PlayStation」という答えが返ってくるはずです。友達と出掛ける、そしてもちろん遅くまで残業する、という答えが多数あるのに併せて、「メールを送る」、「ブログを投稿する」という答えを聞けば、今日のインターネット・ユーザーの、世界に対する見方や Web アプリケーションに対する見方に何が大きな影響を与えているかは明らかです。

しかし、このことが実際には何を意味するのでしょうか。その答えは何よりもまず、使いやすい Web アプリケーションを構築したいと思ったら、自宅に DVD プレイヤーを置くか、何らかの形で TV 番組の録画をプログラムする装置が必要だということです。突飛な意見に聞こえるかもしれませんが、TiVo のメニュー構造や Blu-ray/DVD に収録されたお気に入りの TV 番組の最新シーズンを調べてみて、これらの製品のインターフェースとあなたの Web サイトのナビゲーションや構成に共通するところがまるでないとしたら、あなたは深刻な問題を抱えていることになります。消費者たちは、TiVo や DVD プレイヤー、それに Metal Gear Solid 4 の PlayStation 3 用バンドルなどのサービスにお金を支払っています。つまり、あなたが対象とするユーザーは、これらの製品に価値を見いだしているということです。

もう 1 つ大事なことは、アプリケーションは少なくとも初期アクセスの時点では無料だということです。あなたの作るアプリケーションにユーザーがお金や時間を費やすようにさせたかったら、ユーザーが価値を見いだしていることがわかっているものを参考にアプリケーションのモデル化を行ってください。別の言葉に置き換えると、Web デザイナーとしては、ユーザーにとって常に満足でき、価値があり、直観的に受け入れられるものが何であるかを把握し、それをアプリケーションに適用する必要があります。そうすれば、独学のユーザーにとってあなたのアプリケーションは価値を「実感」する体験となるはずです。

Web アプリケーションの競争相手は別の Web アプリケーションではありません

現在、Web デザイナーはかなり恐ろしい事実に直面しています。それは、Web アプリケーションを設計する際に、自分たちはおろか、自分たちのような相手でさえ対象にすることができないという事実です。アプリケーションは、期待と偏見に満ちた人々が使用する前提で構築しなければなりません。しかしこうした考えは、他のインターネット・アプリケーションにおける考えを基にしたものではありません。事実、Web 開発者はもはや、別の URL でアクセスする他のアプリケーションと張り合うようなアプリケーションを構築してはいません。競争相手となっているのは、ユーザーが喜んで時間を費やしている、ありとあらゆるものです。

ほんの一部ですが、以下にアプリケーションの真の競争相手を記載します。

• PlayStation 3、XBox 360、任天堂 Wii などのゲーム
• LOST、Battlestar Galactica (バトルスター・ギャラクティカ)、Survivor (サバイバー)、CSI: Miami (CSI: マイアミ)、Scrubs などの TV 番組
• Facebook、YouTube、Twitter (コンピューターおたくはまだ健在です) などのサービス
• AppleTV、NetFlix、Blockbuster やその他すべての映画のレンタルおよびデジタル配信サービス
• iPhone、Blackberry、Treo などのテキスト・メッセージング・サービス

Facebook と YouTube 以外はすべて、PC を利用したオンライン・サービスではありません。強力なオンライン・コンポーネントを持つ Twitter でさえも、大抵は携帯電話からアクセスします。つまり、ユーザー・インターフェースがどんなに優れていても、ユーザーは Web に特有のことを期待しているわけではないという点を肝に銘じなければなりません。それでは、競争相手となっているこれらのサービスおよび製品だからこそ、ユーザーが期待するものとは何でしょうか。

上に戻る

ユーザーが欲しがる機能およびフォーム

フォームと機能のどちらが重要であるかについては、長い間議論が続いています。美しいデザインのほうが機能よりも優先されるでしょうか。強力な機能を持つアプリケーションは、見た目に美しくてもあまり役に立たないアプリケーションをやすやすと打ち負かすでしょうか。この論点は、ユーザビリティーに関する議論の核心を突いています。なぜなら、機能と美しさという 2 つのレベルでの設計が関係してくるからです。

しかし理論に深入りする前に、まずはアプリケーションの競争相手を調べてみる価値があります。機能と美しさの優劣という点で、Twitter、YouTube、Prince of Persia (プリンス・オブ・ペルシャ)(訳注: PlayStation 3、XBox 360 等向けのゲーム)、LOST ではどう対処しているでしょうか。

圧倒的な支配力を握るのは機能です

注目を集めている (そして収益を上げている) メディアのアプリケーションやソースを一目見れば、機能が重要な決め手となっていることは明らかです。おそらく皆さんが構築している Web アプリケーションに最も近いのは Twitter だと思いますが、これを例に取ると、Twitter に実際に備わっているのは機能だけです。ステータスを入力すると、そのステータスは他の誰もが見られるように表示されます。Twitter の世界では、とびきり見た目のいいユーザー・インターフェースでも、情報配信という基本的な機能が使い物にならなかったり、実行不可能であったりすれば、それを補うことはできません。

別の競争相手として、大ヒットしたテレビ番組や映画に目を向けてみると、そこにはかなり共通の要素があります。その要素とはストーリーです。「Big Brother」(驚いたことに、その場面の 90 パーセントはほとんどホーム・ビデオで撮影したかのようです)、「LOST」(そして同様の多くのシリーズ番組)、「CSI:」ではいずれも、視聴者はその登場人物に引かれてチャンネルを合わせています。かつての大衆小説の時代でも、同じことが言えます。ストーリーはフィクションの重要な要素であり、最終的に人々が夢中になるのは営利目的の特殊効果や素晴らしいグラフィックではなく、ストーリーです。

私たちが対象としているユーザーが切望しているのは、何かをやり遂げることです。その「何か」とは、革のジャケットを買うことであったり、新しいタイヤ・セットの入手可能なサイズを調べることであったり、あるいはオークションで有名ギターリストのサイン入りフェンダー・ストラトキャスター (訳注: フェンダー・ストラトキャスターは代表的なエレキギター) に最高競売価格を付けることかもしれません。その目的が何であれ、ユーザーがあれこれいじり回さなくても目的を簡単に達成できるようにしなければなりません。つまり、あなたのサイトに必要なのは卓越した機能であり、機能は他の何にも増して遙かに大きな重要性を持つということです。あなたのサイトにはどんな機能があるのでしょうか？実際のところ、あなたは自分のアプリケーションのコア機能を明確かつ簡潔に説明することができますか？説明できるようにするべきですが、それができないのであれば、デザインと開発の他のどの部分より、アプリケーションのコア機能に一層多くの時間を費やすべきです。

フォーム (そしてデザイン) が機能をサポートする必要があります

当然のことながら、見栄えに全く手を付けないのは大きな間違いです。人々が PlayStation 3 にお金をかけるのにはそれなりの理由があります。また、ここ数年は OS X ユーザー・インターフェースにかなりの人気が集まっています。美しさ (具体的には、すっきりとしていて見た目に楽しめる美しさ) は、ユーザーの心を動かします。ただし、どんなデザインでも機能をサポートするべきであり、事実上、機能に直観的に結び付いていなければなりません。再び Twitter を例に挙げると、図 1 に示す Twitter Web インターフェースはひどく単純で、芸術的なデザインとは程遠い作品です。

Twitter ページ上のあらゆる表示はコア機能をサポートし、投稿をフォローしてくれるフォロワーに関する情報や最新の更新内容、自分のメッセージ、そして基本的な Twitter 情報を提供します。これはまるで、デザイナーがサイトのコア機能を念頭においてすべてのデザインを決定したかのようです。

今度は映画とテレビ番組の概念に話を戻すと、一見すると機能よりもフォーム、つまり美しさに重要性が置かれているように思えますが、それは当たっていません。プロダクション・バリューが疑わしい番組が生き残っている一方、数百万ドルの予算をつぎ込んだ番組が大失敗に終わるのは何故でしょう。ステレオタイプを卒業する意欲のある人には、その答えは明らかです。それは、私たちは優れたストーリーが好きだからです。私たちは、簡単に特定できる (技術の世界では、「使いやすい」という言葉に置き換えられます) 登場人物とハッピー・エンディング (これは、「必要なものを手に入れる」という言葉に置き換えられます) を好みます。

視聴者に好まれるストーリーでは、美しい衣装や費用のかかるセットを使っている場合も、何十年も前に遡ったキメの粗い白黒のショットを使っている場合もあります。しかしいずれにしても、デザインが機能をサポートしていることは確かです。多くの TV 番組では、過去の回想シーンや未来を想像するシーンが真実味を帯びるように、数百万ドルをかけています。そうすることによって、番組のなかで重要な位置を占める人物もリアルに見えてくるからです。これも同じく、機能、つまりストーリーがすべてを支配していることを意味します。

自分のアプリケーションをつぶさに検討してみてください。デザイン要素、あるいは特定の色やグラフィックを取り去ったとしても、アプリケーションは同じく有効ですか？これは、「同じく美しいか」という質問とは違い、単に有効性について質問しているだけです。アプリケーションの見掛けを魅力的にすることには何の問題もありませんが、ただし、デザイン要素によって重要な機能が際立つようにしてください。一般に、オンライン・ストアのショッピング・カートが色付きであったり、背景の色と対照的になっていたりするのには理由があります。その理由とは、注意を重要な機能要素に向けるためです。その一方、ショッピング・カートの画像がいかにリアルに見えるかは、少しも重要ではありません。

上に戻る

機能を主体にした設計方法とは

アプリケーションのニーズに従い、何よりも先に機能を優先させるとしたら、実際にはどのような方法を採りますか？順調に事を運び、デザインが機能を支援するという状態を維持できるようにするために、繰り返し使用できる重要な原則がいくつかあります。

コア機能を定義すること

単純に聞こえますが、アプリケーションを「クールな Web アプリケーション」からユーザーにとって欠かせない生活の一部に変える最初のステップは、コアとなる機能を定義することです。言い換えると、そのアプリケーションが何をするものなのかを簡潔に述べるということです。しかも 2 つや 3 つの文で述べるのではなく、単刀直入な 1 つの短い文を見つける必要があります。例えば YouTube のコア機能は、「ユーザーが動画を共有して見られるようにすること」と言えば十分です。Amazon.com の場合はさらに簡潔で、「包括的なオンライン・マーケットの提供」という表現に尽きます。

もちろん、上記のサイトには明示的な機能が一切表明されていませんが、Web アプリケーションのあらゆる点で、そのコアとなる機能は明白です。あなたのサイトでコアとなる機能は何でしょうか？それを定義するには見掛け倒しの機能や補助的な機能、あれば便利だという機能に惑わされずに、そのサイトで実行できなければならない 1 つのことに焦点を合わせなければなりません。そうして余分なものをすべて取り去った末に、非常にしっかりと明確に定義された機能を表明できるはずです。

その表明を書き込んだ付箋紙をモニターに貼ってから、やらなければならない作業を行ってください (図 2 を見ると、具体的に何を言っているのかがわかります)。

この表明は、何をするにも心に留めておかなければなりません。競争相手の話に戻ると、TV 番組、ビデオ・ゲーム、映画などを成功に導いているものが何なのかを考えてみてください。それは、明確に定義された機能の表明がもたらすもの、つまりフォーカスです。視聴率が低下してきた人気の TV 番組を例に挙げると、このような番組 (映画も同じく) についてはよく、「jumping the shark (ジャンピング・ザ・シャーク)」と言われるようになります。この奇妙な言葉は、1970年代の「Happy Days」というコメディー番組を意味する隠喩です (詳しくは、Wikipedia を参照してください) が、基本的に番組がその核とする目的から逸脱した仕掛けや、突飛な話の展開を採り入れるようになる時点を指しています。つまり、「jumping the shark」をオンラインの世界で言い換えると、コア機能の欠如を隠すためにスクリーン効果や特殊なデザインを使用することです。

Web アプリケーションで「jumping the shark」を避け、メディア市場の中で競争しなければならない、しっかりと定義 (そして改良) された映画、TV 番組、ビデオ・ゲームに遅れをとらないようにする方法は、コア機能を定義することです。そうすれば、サイト上のすべて、そしてアプリケーションに含まれるすべてが、そのコア機能をターゲットにしていることを確実にできます。

上に戻る

機能を辿るパスの強調

アプリケーションの目的を把握したら、今度はユーザーにその目的を明らかにする必要があります。しかし、それは思うほど簡単ではありません。Amazon がそのホーム・ページに、「今まで欲しかったあらゆるものをここで買ってください」といったバナーを大々的に載せていないことは明らかです (マーケティング責任者がそうしようと試みたとは思いますが)。TV シリーズの冒頭で、真黒な画面に白く大きく浮かびあがった「大好評を博したシーズン 1 のストーリーの再開となることをお約束します！」という文字を想像してみてください。それではあまりにも押し付けがましくなってしまいます。

ユーザーが求めているのは、コア機能が何であるかの説明 (あるいは売り込み) ではなく、それを体験することです。そのためには、コア機能を強調するような形で常にユーザーがコア機能を意識した状態で、サイト内を導いていかなければなりません。図 3 をよく見てください。何が真っ先に目に飛び込んできますか？

Amazon.com は、コア機能を強調する上で素晴らしい成果をあげました。上記の図を見ると、以下の項目が目立っています。

• 太字で表示された 2 つのオレンジ色のボタンは、どちらも購入用のボタンです。一方は 2 日以内の配送にアップグレードする場合のボタンで (購入画面に続きます)、もう一方はユーザーのショッピング・カートに商品を追加するためのボタンとなっています。
• オレンジ色で強調表示されたもう 1 つの項目、「Shop All Departments (すべてのカテゴリーを見る)」タブは、明らかに「必要なものはすべて Amazon.com から入手できる」という意味です。
• ユーザー・エクスペリエンスの中心となる製品は、大きな太い文字でカラフルに表示されています。
• 上記以外の項目はすべて、かなり控え目な表示になっています。

Amazon.com の機能はどこにも具体的に述べられていませんが、ユーザー・インターフェースによって明らかにされています。このユーザー・インターフェースが製品の選択から購入まで、ユーザーをかなり意図的に導きます。

さらに当然のことながら、強調表示された項目が変わっても、フォーカスが変わることは決してありません。図 4 も同じく Amazon.com の画面ですが、今度は購入画面です。

1 つの大きなオレンジ色のボタン「Place Your Order (レジに進む)」を除いて、この注文以外のすべての選択肢が表示されなくなっています。この段階になると、Amazon ではサイトの他の部分や製品カテゴリーを検索するためのタブを表示しません (ただし、これらのエリアに進むことはできます)。Amazon.com は、この段階でユーザーが必要とするのは、注文を完了することであると理解しているからです。製品ページでは不可欠だったボタンそのものが、購入の段階では問題になります。製品の小さなアイコン画像でさえ、注文の完了というこのページの目的から関心をそらすことになるため、問題です。

あなたのアプリケーションのコア機能を書き込んだ付箋紙を見てください。あなたのサイトはそのメッセージに応えていますか？機能に従って、ユーザーが確実にサイトを進めるようにしていますか？そうでなければ、TV 番組や映画、ゲーム、そしてその機能を明らかにしている Web アプリケーションに負けることは目に見えています。

アプリケーションに「ファジー」テストを適用すること

Web アプリケーションに伴うすべての懸念事項にバランス良く対処するのは、常に簡単であるとは限りません。デザインの美しさそのものよりも機能のほうが重要であるとはわかっていても、どの Web アプリケーションでもデザインがアプリケーションの一部であることは明らかです (この言葉が信じられなかったら、カスケーディング・スタイル・シート (CSS) やインライン・スタイルを一切使っていない Web アプリケーションをリリースして、成功するかどうかを確かめてみてください)。そしてこの点でも、アプリケーションはその競争相手 (あらゆる形態のメディア) と同様に、細部にのめり込みがちです。

週 1 回の連続 TV 番組の登場人物を書いているのか、ビデオ・ゲームのキャラクターの台詞を書いているのか、あるいは Web アプリケーションのカラー・パレットを作成しているのかに関わらず、どうやったら機能が第一に優先されることを確実にできるでしょうか。その最も簡単な方法の 1 つは、「ファジー」テストを適用することです。これは基本的には「製品のどの部分が、10,000 フィート離れて見た低解像度で人目を引くか」というテストです。ここで言う「解像度」は、ピクセルだけを意味するのではなく、アプリケーションや製品を遠くから見たときに、何が目立っているかということを意味します。目立っているのは、格好のいいロゴ、派手な見掛けの CD、それとも特定のキャラクターの見事な赤毛でしょうか。爆発シーンや予想外の話の展開でしょうか。それとも、注目を引くのは製品の中核となるもの、つまりコアとなる機能 (コアとなる機能が何か忘れてしまった場合は、図 1 をもう一度見てください)、映画の土台となるストーリー、あるいは XBox 360 のゲーム・タイトルのなかで最も魅力あるゲームでしょうか。

幸いなことに、これを Web アプリケーションで確かめるのは簡単です。文字通り、ファジー・テストを適用すればよいのです。Web アプリケーションの簡単なスクリーン・ショットを取って、それをグラフィック・アプリケーションで開いてください。そして、ページのテキストが読めなくなるまでスクリーン・ショット全体を何回かぼやけさせます。例えば図 3 に示した Amazon.com のスクリーン・ショットをぼやけさせると (実際には、5 回の「ブラー」操作を実行しました)、図 5 のような結果になります。

あっという間に、あらゆる細部が見えなくなっています。目に留まるのは無論のこと、製品の画像と明るいオレンジ色のボタンです。細部が見えなくなっても、肝心な項目は依然として目立っています。そこで自分の意見だけを事実として受け入れずに、ぼやかしたスクリーン・ショットを友人たちにも見せてください。できれば、アプリケーションについて何も知らない友人に見せるのが理想的です。彼らの目に留まるものは何ですか？目標は、ユーザーに使ってもらいたいとい思っている要素、つまりサイトのコア機能と関連する要素に注目がいくようにすることです。

「ファジー」テストのよいところは、これによって正しい方向に進んでいるかどうかがわかるだけでなく、デザインや使用している色、そしてページのレイアウトについての実態を把握できることです。このテストでは、サイト上で可視のほとんどすべてのものが簡素化されます。見出しのフォントを調整するのに 3 時間かけたとしても、その 3 時間の努力は 1 回か 2 回のブラー操作で消えてしまいます。しかし、同じ 3 時間を「購入」ボタンの色の調整に費やしてボタンが目立つようにすれば、アプリケーションを 10,000 フィートから眺めるこのテストで、その努力の成果が現れます。

上に戻る

アプリケーションに可能なその他の対策

自分 (そしてアプリケーション) には他の Web アプリケーション以外にも多くの競争相手がいるということがわかると、遙かに困難なタスクを請け負うことになります。にわかに大きな問題となってくるのは、人を引き付けるストーリー展開です。ユーザーの時間を獲得するための競争ということは、すなわち魅力的なストーリー展開が、あなたのアプリケーションの脅威となることを意味します。

コア機能を明確にしてフォーカスを合わせるという他に何ができるかと言えば、かなりの数の対策が考えられます。具体的な問題とその対処方法については今後の数回の記事で取り上げていきますが、差し当たり考えなければならないことは山のようにあります。ここでは、この連載の次回の記事を前向きな姿勢で読めるように、アプリケーションを改善するための具体的な対策内容をいくつか説明します。

TV を見る、ビデオ・ゲームをする、Web サーフィンをする

おかしなアドバイスに聞こえることは承知ですが、これは的を射たアドバイスです。ハリウッドの幹部が面倒がって競争相手の映画をまったく見なかったとしたら、いつまでその地位を維持していられるでしょうか。実際に XBox 360 を持っていないのに、次の素晴らしい XBox 360 ビデオ・ゲームのコードを作成できると思いますか？もちろん馬鹿げた考えです。ですから、外に目を向けて競争相手を調べてください。絶大な人気を集めている TV 番組を探してください (しかも、しばらく続いている番組です。一時的に流行った番組では意味がありません)。iTunes や TiVo を使って、エピソードをいくつか見てください。地元の映画館で上映されている最新の大ヒット作を参考にしてください。そしてもちろん、1 にも 2 にもサーフィンです。自分のアプリケーションがヒットしそうなキーワードで Google を検索してください。既知の競争相手のサイトにアクセスしてください。Web を隅々まで探索して、人気のありそうなサイトに注意を向けてください。

このような調査を行っているときには、できるだけ多くメモをとります。書き込む項目は、自分が好きなもの、嫌いなもの、素晴らしいと思うものや面白いと思うものなどです。そして自分が選んだ項目 (特に Web サイト) を友達にチェックしてもらいます。友達が Web をサーフィンしてサイトと対話する間、彼らがどのように行動するのか、そして使用する特定のパターンやボタン、手段があるのかどうかを観察します。その結果を手掛かりに、ユーザーが求めているものが何かを考えてください。

Web 以外でのモデルを探す

Web 中心の思考回路から抜け出すのに効果的なもう 1 つの方法は、アプリケーションでモデル化している振る舞いについて検討することです。一例として、アプリケーションに何らかのショッピング・カートや買い物カゴがあるとします。この場合、あなたがモデル化しているのは在庫リストです。在庫リストはユーザーが作成し、ユーザーがそのリストを「使用」します (つまり、商品を購入するか、商品を欲しいものリストに追加するなど)。これを Web 以外のメディアで表す方法を考えてみてください。例えば映画館の場合、途中で買ったポップコーンと飲み物をカウントしない限り、在庫リストがあるとは言えません。では、ビデオ・ゲームの場合はどうでしょう。在庫管理は、多くのビデオ・ゲームに共通する部分です。在庫リストを確認する方法や、商品を「引き出す」方法について、これらのビデオ・ゲームではどのように行っているかを考え、その方法を Web アプリケーションでの新しい魅力ある方法に置き換えられないかを検討してください。

注: 連載の次回の記事では、在庫管理について具体的に説明するので、上記については十分時間をかけて考えてみてください。次回の記事を読むときに役立つはずです。

検討すべきもう 1 つの興味深いモデルは、コミュニケーションです。ユーザーがあなたやあなたのアプリケーションとコミュニケーションを取るには、問い合わせリンクをクリックして E メールを送信することになっていますか？それとも電話をかけるという方法ですか？これを他のメディアでのコミュニケーション・モデルに当てはめてみると、この場合もビデオ・ゲームでは、独特な方法で何年もコミュニティー、ソーシャル・ネットワーク、コミュニケーションに取り組んでいます。ここから何を学べるのか、そして自分のアプリケーションに適用できるかどうかを検討してください。

上に戻る

まとめ

明らかに、あらゆる新しいメディアを競争相手として捉えることによって得られるものは、この他にもたくさんあります。しかし、フォーカスが欠如しているとなると、Ajax の手法や賢いデザイン (これらについては今後の記事で詳しく検討する予定です) のすべてをもってしても、それを補うことはできません。あなたのサイトの目的は何ですか？その目的をユーザーに対してどれだけ明らかにしていますか？予想と先入観をすべて取り払ったときに、サイトはどのようなルック・アンド・フィールになりますか？本当に際立っているものは何ですか？

コアとなる機能に関するこれらの質問に答えられるとしたら、競争力があり、ユーザー・フレンドリーで使いやすいアプリケーションを順調に構築していると言えますが、それでも甘く考えることは禁物です。そのようなアプリケーションを構築するには、多大な努力を要します。この連載では今後数か月にわたり、アプリケーションの力を最大限に引き出すための具体的手法を詳しく探っていきますが、その前に何にも増して重要なのは、コア機能に取り組むことです。何が本当に大事で、アプリケーションで最も重要な機能は何なのか、時間をかけて明らかにしてください。それが、今後すべての作業の前準備となります。

参考文献

学ぶために

• Web のユーザビリティーに関してディスカッションするなら、Jakob Nielsen の Web サイトにアクセスしないことには始まりません。このサイトには、多数の記事と優れたリソースが揃っています。
  
  
• ユーザビリティーと密接に関連するのはアクセシビリティーです。使いやすいサイトは必ずと言っていいほど、高いアクセス性を誇っています。アクセシビリティーについての詳細は、Web Accessibility Initiative オンラインを調べてください。
  
  
• 『Head First HTML with CSS & XHTML』を読んでください。XHTML と CSS について、初心者にもわかりやすくその概念を説明しています。
  
  
• ビデオ・ゲームが Web に情報を提供するのと同じく、Web もビデオ・ゲームの情報源となります。PlayStation 3 のゲーム「リトルビッグプラネット」がどのように Web 2.0 イニシアティブをゲームに組み込んだかを調べてください。
  
  
• 『Head First Web Design』を読んでください。Web デザインに関して丁寧に説明しているこの一冊で、ユーザビリティー、色、レイアウト、ナビゲーションの詳細だけでなく、知的所有権についても理解できます。
  
  

議論するために

• developerWorks blogs:developerWorks コミュニティーに参加してください。
  
  

著者について

Brett McLaughlin はノンフィクション作家としてベストセラーを書き、またいくつかの賞を受賞しています。彼が執筆したコンピューター・プログラミングやホーム・シアター、分析や設計に関する本は、これまで 10 万部以上売れています。彼は 10 年近く技術的な本を執筆し、編集し、そして製作してきており、ワープロの前に座っていることが好きですが、ギターを弾いたり、家で 2 人の息子を追いかけたり、彼の妻と Arrested Development (訳注: 米国で作成、放映されていたテレビ番組) の再放送を見て笑い転げることも好きです。彼の最新の本『Head First Object Oriented Analysis and Design』は 2007年の Jolt Technical Book award を受賞しています。彼の古典作『Java & XML』は、Java 言語での XML 技術の使い方に関する決定作の地位を保っています。

この記事を評価する

コメント

上に戻る

目次

• コンピューターの専門家… 1997年当時のプログラマーの姿
• ユーザーが欲しがる機能およびフォーム
• 機能を主体にした設計方法とは
• 機能を辿るパスの強調
• アプリケーションに可能なその他の対策
• まとめ
• 参考文献
• 著者について
• コメント