サービス、製品の解説するためにマニュアルやスクリーンキャストを作ることがあります。しかし、利用者はのんびり説明に耳を傾ける余裕がないときもあるわけですから、使っているうちに覚えてもらえるようなユーザーインターフェイスを必要とします。Webサイトをはじめ様々なシーンでいえることですが、すべてのアクションはテキストから始まっています。それゆえ、見た目を考える前にテキストでどのように簡潔に説明できるかを模索する必要があります。

例えば Twitter をみてみましょう。機能が少ないシンプルなサイトですが、UI 要素をすべて省いてしまうと状況が大きく変貌します。タイムラインを読むことは可能ですが、返信がしたい、設定を変えたいといったアクションを起こすことが出来なくなります。テキストは私たちが何かしたいときの道案内をしているということがテキストを省いてみることで改めて気付かされます。アイコンで補助できる部分はありますが、テキストがないことで意味を大きく失うわけです。

インターフェイスをデザインする際に、考えなければならないことは幾つかありますが、大きく「タイポグラフィ」「構造・配置」「色彩・形状」という３つが挙げられます。インターフェイスに最適なテキストを練り出したあとにこの３つの要素を取り入れることでインターフェイスの意味が深まります。

例えば「送信する」というテキストがあるとします。これも本文のテキストを同じ書体にするのではなく、OSのメニューでよく使われているような書体や見た目にすることで意味が深まるでしょうし、ボタンらしい形状をもつことで押すと何かが起こるということも直感的に分かります。また、フォームの下にテキストが配置されているのであれば、フォームの情報を送信するのだということも理解しやすくなります。

インターフェイスに表示されているテキストに意味をもたせるには「タイポグラフィ」「構造・配置」「色彩・形状」が欠かせませんが、肝心のテキストがきちんと考慮されていない状態だと見た目が変わっても改善されてない場合があります。逆に見た目は同じでもテキストを変えるだけで人のアクションが変わることもあります。テキストと３要素は、UIデザインの基本ですが、テキストがすべての要である以上、しっかり考えて行きたい部分です。

インターフェイスデザインにテキストが重要ということは、マイクロソフトやアップルが公開しているガイドラインをみても分かります。アップルのほうでは別途 Apple Publications Style Guide (PDF) というジャーナリストがもっているスタイルガイドにも似たラベリングやヘルプを書くときに役立つガイドラインを公開しています。２つのガイドラインから幾つか項目をピックアップしてみました。

• 冗長な言い回しは避ける
• 可能な限り短くする
• 繰り返しにならないようにする
• 専門用語は省く
• アクションが必要なところは明確に表現
• 短縮型の表現を使わない (英語の場合)
• 省略形を使うときは細心の注意が必要

マイクロソフトもアップルも早い段階でライターを開発プロセスに取り込むことを勧めています。ユーザビリティ、情報構造、ビジュアルを考慮する前に、一度モニターに映し出されているテキストに注目してみてはいかがでしょうか。そうすることで様々な問題が解決することもあるでしょう。

そもそもマニュアルとは？

電子書籍でもハマる問題ですが、今までのマニュアルの見た目・印象を活かしつつ電子化してしまうと、紙のように見えて紙ではないよく分からないデジタルマニュアルになります。「よりリッチに」ということでインタラクティブなコンテンツが盛り込まれた CD-ROM が同封される場合もあります。しかし、そんな形ではマニュアルの電子化に未来はありません。

『電子化』という言葉が出てくると、「いかにモニターに映し出すか、どう操作させるか」の議論になってしまい、肝心の本質が抜けてしまっている場合があります。そもそもマニュアルはどのような役割をもっていて、人はそこから何を欲しているのかを理解した上で『電子化』をしなければ本末転倒のようなことになりかねませんし、先述したような『リッチ路線』に走ってしまうわけです。逆にマニュアルのもつ役割を果たしていれば、紙媒体のときとは見た目が変わってモニターに表示されていても、利用者は違和感なく利用することが出来るのではないでしょうか。

では、マニュアルとして必要とされる要素・性格とはどういったものがあるでしょうか。シンプルにまとめると以下の３つになります。

• 正確
• 明白
• 最新

マニュアルだからこそ情報は正確でなければ意味がありません。しかし、情報が正確でも分かり難くては意味がありませんから、図を活用したり、ステップを設けるなどをして分かりやすく表現します。エッセンス（本当に重要なことだけ）に絞り込むことで、明白さを引き立てているマニュアルもあります。これら２要素はテクニカルライティングの真髄とも呼べる部分ですが、第三の要素である「最新」が今追いつけていない部分です。

製品ライフサイクルに合わせて情報を用意すれば良いというわけではなくなってきた今日。サイクルが短くなってきたのはもちろんですが、サイクルとサイクルの間でも製品は生きているわけですから、情報はアップデートしていかなければいけません。徹底的なテストをして出荷される製品でも、大衆が使ってはじめてマニュアルに入れるべき情報が見えてくる可能性もあります。

マニュアルは『正確・明白な情報』が記載されているものの、製品・サービスの百科事典というわけではありません。すべての人が必要だと考えられるわずかな情報しかマニュアルには記載されていません。つまり、考えられる使い方すべてを網羅しているわけではありませんし、未来の変化に対応出来るとも限りません。

紙媒体のマニュアルでは、流動的で多様性のある人と製品・サービスの関係はサポートしきれないわけです。紙では対応しきれなくなった部分を補うために Web 技術が必要になってきます。

Wikiを利用したマニュアルの可能性

製品・サービスの情報を最新に保つツールとして Wiki がここ数年活用されています。従来はプログラミング言語のマニュアルが Wiki というケースがほとんどでしたが、ソフトウェアやサービスなど利用シーンが増えて来ています。

• Adobe Lab Wiki
• Second Life
• OpenOffice.org Wiki
• IBM DeveloperWorks Wiki
• GigaSpaces
• Opera Browser and Internet Suite

Wikiを利用することで、Web 上に散らばっている製品・サービスに関わる情報をひとつにまとめることが出来るだけでなく、Tips集といった今まで紙のマニュアルで取り入れることが出来なかった情報も盛り込むことが出来ます。Wikiだからといって情報はいつのまにか埋め尽くされるわけではありませんし、情報を確認したり整理する作業は必要になります。しかし、高価なシステムを利用しなくても拡張性と柔軟性があるオンラインマニュアルが作れるという意味では Wiki の利用価値は高いでしょう。

マニュアルは強力なコンテンツ

マニュアルに Wiki を利用など Web を活用することで、Web におけるテクニカルライター（又はマニュアルに関わる人）の役割が少しずつみえてきます。Webだからこそ、正確・明白な情報は必要とされますが、流れが早く膨大な情報が散らばっている Web で必要とされる新たな役割があります。

観察

Wikiでどのような情報が追加・削除・編集がされているかという部分だけでなく、Web 上で製品・サービスに関してどのような情報が流れているか把握します

共有

集めた情報をオンラインマニュアルとして掲載と告知が必要になります。マニュアルにある貴重な知識を共有しやすくするための仕掛け・仕組みも盛り込みます

恊働

オンラインマニュアルを通して得たフィードバックを次の製品サイクルへの貴重な情報に加工したり、マーケティング・PRのアイデアとして利用できます

製品の公式サイトへはアクセスしなくても、何か困ったときにオンラインマニュアルへアクセスしたり、PDFをダウンロードしている方はいるのではないでしょうか。Webサイトのアクセス解析をすると、他のページよりオンラインマニュアルのほうがたくさんアクセスされているところも少なくないはずです。しかし実際のところ、オンラインマニュアルのコンテンツの充実やデザイン提案がなされているところは少ないです。アクセスが集中しているところにテコ入れがされていないのであればもったいないですね。

マニュアルも Web に公開されることで、顧客との距離がより一層深まります。だからこそ、マニュアルを単なる製品の付属品として扱うのではなく、ひとつのコミュニケーションツール / マーケティングツールとして扱うことで新たな視点が加わるでしょう。

書籍や雑誌をはじめとした印刷物。TVやラジオで見られるような広告。デスクトップで動作するソフトウェア。これらの制作プロセスは Web サイト制作において影響を与えてきてモデル。テクノロジーやノウハウが蓄積され独自性も多少出て来たものの、Webサイト制作プロセスは基本的なところは10年くらい変わらないのではないでしょうか。

配布してしまったら終わりの印刷物。一瞬でもインパクトがあればそれで良いテレビCM。企画といっても仕様や機能を決める話になり、始めたら後に戻りにくいウォーターフォール式のソフトウェア開発。いずれのプロセスも長所はありますし、それぞれの形に合っているから使われているわけですが、人と人、情報と情報、そして人と情報が常に双方向に繋がり続けている Web という有機体にはいずれの方法も適していません。

流動的に変化を続ける Web だからこそ、アジャイルソフトウェア開発が受け入れられたのかもしれません。開発陣によるこうした活動に影響されるかのようにデザインプロセスもプロタイプやユーザーテストを繰り返した反復型に変化してきました。アジャイルのように、完成までのプロセスの中の１フェイズが進化している部分はありますが、全体的なプロセスやお客様 / クライアントの関係が従来のままなので長期的にうまく運営できないサイトも出てきています。

他媒体の制作プロセスを参考にして独自に進化することは良いのですが、Webサイト制作プロセスで問題なのは、手を動かして作るという部分だけのプロセスのみ参考にした点にあるかもしれません。以下に雑誌が出来るまでのプロセスを簡単にまとめてみました。

成果物のUXにおいて、Jesse James Garrettが話しているようにエンゲージメントを与えるということが重要になってくると思います。それぞれのサイトの趣旨によっても変わってきますが、長谷川さんはどのようなアウトプットの仕方でエンゲージメントを与えようと考えますか？また、その際、気を付けていることや長谷川さんが持っている方法論等があれば教えてください。

from: toshi

ここ数年、デザインやマーケティングなど様々な分野で耳にするようになった「エンゲージメント」。愛着心や絆など、分野でによってニュアンスが微妙に異なるこの言葉ですが、ここで言う「エンゲージメント」とは「積極的に行動する状態」「集中・没頭出来る状態」を指します。アプリケーションやサイトを利用において、利用者が意味のある体験をしたかどうかを測る測定値としてエンゲージメントに注目する場合もあります。エンゲージメントのある体験とは楽しいだけでなく、生産的でしょうし、簡単と感じる場合もあるでしょう。

楽しい時間を過ごしているとき、自分にとって意義のあることをしているときは、集中力が増しますし、時間がアッと言う間に過ぎてしまう感覚があります。こうした心理状態を英語では「In the Zone」と呼ぶことがあります。日本語訳すると「無我の境地」といったところでしょうか。スポーツ選手が例に挙がることがありますが、無我の境地とは以下のような状態を指しています。

• フォーカスが絞られている
• 明確なゴールのために機敏な反応をする
• 余計な知覚や考えが取り除かれる
• 自意識過剰ではなくなる
• 自分に主導権があるように思える

人が「無我の境地」に入り、ゴールと向かい合うことでエンゲージメントが生まれるわけですが、これをそのままデザインに応用することが出来ます。つまり、上記に書かれている状態に人が入りやすい状態を作り出すことでエンゲージメントを助長するわけです。スクリーンサイズが小さいモバイルアプリケーションで上記の状態になるように様々な工夫がなされています。

例えば Google の Web 検索を見てみましょう。最初は検索ボックスが表示されているだけですが、文字を入力しはじめると検索したいキーワードを予測して出してくれたり、的中率が高そうな他の検索キーワードを提示してくれます。入力後に検索結果が表示されるわけですが、目的に辿り着きやすいようにサイト名だけでなく幾つかの情報が最小限ですが丁度良い量で表示されています。最初の検索ボックスがあるページがシンプルなのはもちろんですが、そのあとの行動の邪魔にしないためのシンプルを作り出す方がエンゲージメントにおいて重要になります。

人が没頭するという意味でのエンゲージメントをより深く理解したい方は Mihaly Csikszentmihalyi の著書『Flow』がオススメです。

発表された当時から「なんかスゴそうだけど何かよく分からない」と言われていたGoogle Wave。常に細かな改善はされていましたし、今年の 5 月に開催された Google I/O 2010 では Wave を利用したカンファレンスの整理や情報交換に利用されていました。私も先月開催されたセミナー＆ワークショップで Wave を利用していたわけですが、発表されてわずか1年でGoogle Wave 開発中止になりました。

一般公開されている Public Wave を見てみると結構盛んなやりとりをされているものも少なくなく、利用者の使い方を反映してどう改善していくのか楽しみだっただけに少し残念です。Wave の技術や学んだことは Chrome OS へ受け継がれるでしょう。

Waveが残したもの

開発が中止になったとはいえ、すべてが無駄だったとは言いきれません。デザインや技術的なところで学べるところはたくさんあります。以下に Wave がもたらしたインパクトをポジティブとネガティブに分類してまとめてみました。

ポジティブな点

HTML5の可能性を提示

Waveの功績は HTML5 に脚光を浴びせたところでしょう（良くも悪くもですけどね）。Wave が出てきた辺から Google サービスのモバイル版では先進的な動きが見られ始めました

超リアルタイムの実装

書いている課程をそのまま見れたり、Waveの成長を再生する機能など Web 上の「リアルタイム」に新たな側面を加えました。Waveではこれを上手く活かすことが出来ませんでしたが、今よりリアルタイムなリアルタイムサービスや時間軸を湾曲させたサービスが登場するかもしれません

Webアプリを拡張するという考え方

様々なWebアプリケーションが世に出回っていますが、機能を拡張出来る Web アプリケーションは少ないと思います。組み合わせ次第では特定のコミュニケーションに特化した「Waveアプリ」も作れたのではないでしょか

ネガティブな点

一言で表せなかった『謎』アプリ

やろうと思えば何でも出来てしまうのが Wave のスゴいところでしたが、何でも出来るが故に人に説明し難いアプリになったのは事実。「メールに代わる新しいコミュニケーションツール」という抽象的なコンセプトがありましたが、蓋をあけると機能がたくさんある何でもアプリでした

人はそれほどクリエイティブではない

開発者側からすれば「何でも出来る道具箱をあげるから、何かスゴいことしてご覧」という思いもあったのでしょう。ただ、Public Wave を見ると分かりますが、ほとんどが掲示板のような使い方です。Wave を使うことの明確なコンセプトもなければ、使うためのシナリオがあまりにも幅広いので、利用者は馴染みのある使い方に留まってしまったのでしょう

機能のスゴさでは満足しなくなった

Waveには様々な技術革新がありましたし、複雑過ぎるほど機能がたくさんありました。技術好きな方も最初はおもしろがっていたものの、徐々に離れていった理由のひとつとして、結局そこには技術しかなかったというところがあります。人が集まるような何かがなかったのでしょうし、それは技術や見た目の問題ではなかったのだと思います

ソーシャルになれないGoogle

先述した「機能のスゴさでは満足しなくなった」に繋がりますが、どうも Google は人を絡めたサービスを作るのが上手ではないようです。素晴らしい技術やインタラクションを実装することが出来ても、そこに人間的な要素（今風でいうならソーシャル的な要素）を加えた途端に意味がよく分からないアプリになってしまうことがあります。唯一、ソーシャルな分野で成功しているサイトといえば YouTube を挙げることが出来ますが、買収したサイトですし類似の自社サービス Google Video はご覧のとおり機械的で静かなサイトです。

ソーシャルアプリが作れないどころか、YouTube 以外に買収してうまくいっているものがないのも懸念点です。ロケーションサービス Dodgeball を早期買収はしたものの上手く軌道に乗らず、開発者は Google を出て foursqure を立ち上げています。他にも Jaiku、JotSpot、Blogger など魅力的なサービスを買収しているものの、宙に浮いたような状態です。

開発者向けにブログを立ち上げたりコードを公開するといった社交性を示している Google ですが、いざアプリケーション開発になるとそうはいかないみたいですね。Facebook の Like ボタンは3億回クリックされていたり、Twitter も 200億ツイートを突破しました。Facebook や Twitter もそれぞれ検索サービスがありますし、利用頻度も増えています。このように、人の動きが大きく変わってきているということは、今までのような広告収入では上手く機能しない可能性があります。

Waveの開発中止の発表は「ソーシャルになれないGoogle」の象徴として捉えることが出来ますし、彼等が未だ開拓出来ていないソーシャルスペースに今後どのようなサービスを提供するのか注目です。

Webをはじめとしたテクノロジーを利用したものには、馴染みのない機能や象徴的で捉え難いアイデアがあります。それらをスクリーンショットで見せたり、分かりやすい解説があったとしても伝わらない場合が多いです。そこで、他にある似たようなものと関連付けさせて理解しやすくします。これを私たちは「メタファー」と呼びます。

メタファーはパソコンの中にたくさん見ることが出来ます。アイコンデザインがその代表格です。絵としてフォルダを表現することで、頭の中で「幾つかの書類をまとめることが出来る」という本物のフォルダと関連付けがしやすくなり、操作を促すことが出来ます。フロッピーディスクアイコン (保存)のようにメタファーからシンボルへと進化した例外もありますが、機能やインタラクションを説明せずに利用者に伝えることが出来るメタファーは、アプリケーションデザインやWebデザインでよく使われます。

メタファーが作り出す「使い難い」

ユーザビリティを向上させることが出来るメタファーですが、何でもメタファーにして表現すれば良いわけではありません。使い方を間違えるとかえって使い難いと感じられてしまう場合もあります。

メタファーは先述したとおり『他にある似たようなものと関連付けさせる』ところから始まります。馴染みのあるモノ・コトと関連付けが出来るので理解はしやすいですが、同時にある一定の期待値を利用者に与えてしまう可能性があります。メタファーによって作り出された期待値と、実際もっている機能がマッチしないと利用者は「使い難い」と感じます。言い換えれば「期待はずれだった」といえるでしょう。

ひとつ例を見てみましょう。

例えばフォルダをメタファーとして使った機能があるとします。利用者はこのメタファーを見たことで本物のファルダと関連付けさせて様々な期待を抱くでしょう。例えば「たくさんの書類が入る」「小さくまとめれる」「ラベルが付けられる」などがあります。しかし、実際の機能はラベルを付けることが出来なかったとしたら、フォルダと同じようなものだと認知していた利用者は戸惑うかもしれませんし、同じような作法をもたない機能に対して「物足りない」と感じるかもしれません。

もちろん、示したメタファーが作り出す期待値とまったく同じものを機能として再現する必要はないでしょう。しかし、期待値と機能のギャップがあればあるほど、使い難く感じてしまいます。たくさんの期待に応えていたとしても、メタファーが生み出すコアのようなアイデアが再現されていなければすべてが無駄になります。

電子書籍による紙メタファーの危険性

iBooksをはじめ、今見かける数多くの電子書籍のインターフェイスは『紙』というメタファーがたくさん使われています。最初はリアリティのあるアニメーションや綺麗なインターフェイスに魅了されていたかもしれませんが、次第に使い難い、無駄と感じている方が増えて来ています。この要因が先ほど書いたメタファーによる期待値と実際出来ることのギャップがあります。

iBooks のインターフェイスは見た目は美しいですが、めくってもめくってもページは減ることがありません。ページというメタファを使ったことで紙のページと関連付けして人は理解します。様々な『紙の良さ・特性』を期待するわけですが、iBooks はその期待に応えてくれているわけではありませんし、期待を裏切るものが幾つかあります。では、めくったらページが減っているように見えるインターフェイスにすれば解決するのかといえば、それは数々ある期待のひとつに応えたに過ぎません。デジタルメディアのメリットも活かさなければいけませんから、どうしても紙を再現出来ない部分がありますし、デジタルメディアを利用するという期待を裏切ってしまう可能性すらあります。

電子書籍は言葉自体はそれほど難しくありませんが、コンセプトを理解するのが難しい部分があります。手軽に電子書籍に触れてもらうために紙のメタファーを採用したという経緯は理解出来ますが、これに頼り過ぎてしまうとチグハグなものが出来てしまいます。紙っぽいけど使い難く、デジタルのメリットとして挙げられる拡張性や柔軟性がないものもあります。先ほどから「紙をメタファー」と書いていますが、現状「紙のようなギミック」といってもいいでしょう。今のところ、紙の良さを移行/移植するための試みばかりされているので、期待値のギャップから「やっぱり紙のほうが良いよね」という結論になってしまう方もいます。

書籍のもつ特性は、デジタル機器で電子書籍を読む際に役立つことがある部分もあります。しかし、それは紙の特性とイコールではありません。デジタルのもつメリットを活かして、どういった部分で書籍のメタファーが役に立つのかを吟味することが読みやすくて期待を裏切らない電子書籍になると思います。

余談になりますが、ここ数ヶ月間 Twitter 上で電子書籍と紙のデザインについて何回か語っていたので以下にまとめておきます。

1. yhassy 今の漫画は見開きだったり、次のページをめくるという行為をうまくコマ割やストーリーテリングに活用していますね。iPad とかだとスワイプで次のページへ動くアニメーションを動きとしてとらえて表現する漫画もでてくるかな。
2. yhassy Web を利用した電子出版といえば 10 年くらい前からありますね。当時はページめくりのギミックを再現したり、ページの拡大・縮小が出来たりとか、そんなかんじだった。パソコン上でしか見れないとか。
3. yhassy ページめくりのエフェクト自体はまぁいいとして、それをマウスでぐぐぐってドラッグしなければならないのが何よりも面倒だった。見た目は再現出来ててもインタラクションがあまりにも違いすぎて使い難かった。
4. yhassy なんで、iBook は立体的な本のような UI をわざわざ付け足したのかな。あんなことせんでもページをめくれることを伝えることは出来るし、そもそも紙の本でもないしな。あれだけスペースを使うことが必要だったのかしらね。ちなみに Kindle はない。
5. yhassy iBooksの栞機能は微妙だねぇ。縦横と持ちかえるだけでページ数も変わるわけだから、あてにならない。どちら向きで栞をしたかによって別の向きだと2ページにわたって栞されてることも。向きを変えるだけでどの辺まで読んだかという記憶も辿り難くなる。
6. yhassy 電子書籍という名の、昔でいうCD-ROMみたいなパッケージング
7. yhassy 今のところ電子書籍は作る側/書く側にとってはメリット、読み手にとってはデメリットという感じがしないでもない。
8. yhassy 書籍が生まれてからページ番号が付くまで50年かかったわけだから、電子書籍のデザインが発展途上なのも仕方ないな。
9. yhassy 電子書籍やオンラインミュージックって購入しても所有するためにお金を払っている感じがしない。どちらかというと契約費用という感じ。買っても「あれするな、これ出来ない」という制約が付いてくる。コンテンツを楽しみつつも制約のことを気にしないといけない。
10. yhassy 電子書籍より紙書籍のほうが良いなと思うことのひとつとして、著者からサインをもらいやすいという点かな。著者と出会ったこと、サインをもらったことで本に別の価値が生まれる。

今のような記事ページになった理由

今年の始めに記事ページを新しくしました。そのあと小さな調整を行ったり機能を追加はしていましたが、そろそろどのような結果が出たのが発表するには良い時期だと思いますので幾つか紹介したいと思います。

ご存知の方もいるかもしれませんが、今「記事」と呼ばれるエントリーはほとんどすべてレイアウトが違います。中には色を変えただけのものもありますが、レイアウトが少し複雑なものや画像が活用されているものもあります。凝り過ぎたことをすると読み難くなってしまいますが、毎回見た目が新鮮なので飽きることもありませんし、それがキッカケで読んでくれる方もいるかと思います。

ユーザーを利用者や閲覧者などに分類するのをx軸と考えると、各タイプの成長、もしくは分類の変化をy軸と考えられるのではと思いました。最終的に獲得したいターゲットユーザーにもよりますが、例えば、ECサイトでの観覧者から消費者への変化という風に、各タイプの学びによるステップアップ、もしくは他タイプへの変化は、どういう道程・要因が考えられるかをお聞きしたいです

from: CalmTech

この質問に応えるには、まず全体像を視覚化してみたほうがよさそうですね。X軸のユーザ分類にはユーザーという言葉に潜む５つの側面で紹介したものを活用します。左から右へ向かうにつれてユーザーがより能動的なアクションをとると見なして並べてみました。Y軸には「ECサイト」や「Webアプリ」など幾つかサイトの種類を配置。各種Webサイトがどういった側面をもったユーザに響くのか考えてみました。

UX は概念的な説明になりがちですが、講演で解説した道筋を、続くワークショップで具体的に体感することが出来たのではないかと思います。来て頂いた方全員のモチベーションが高く、ものすごい短い時間だったのにも関わらず質の高いアウトプットが出て来たのは私にとって嬉しくもあり同時に驚きでした。これこそ青森パワーといったところでしょうか。

あまりワークショップの経験はありませんが、「セミナーで言っている意味がワークショップで分かった」という声を何人から頂いてホッとしました。また機会があれば、関東・関西でも同じ内容でやってみたいところです。
ちなみに、ワークショップの概要は「不合理な人間から導き出すデザイン提案」という記事で読むことが出来ます。

特定の作業と関連付け出来ない

「UXって何の仕事をする人なの？」と聞かれると応えるのに困る方もいるでしょう。「UXはシナリオやペルソナを作る人」と考える方もいるかもしれません。IA も似たようなかんじで「ワイヤーフレームを作る人」と捉えている方もいると思います。デザインプロセスを通して生まれるこれら『副産物』は IA や UX を考えるにおいて必須なのかといえば、そうではありません。IA を専門としている方が、デザインプロセスでたまたまワイヤーフレームを作り出したに過ぎません。UX にしても同様です。専門としている方がたまたまペルソナやプロトタイプを作っているに過ぎず、それらを必ず作らなければならないのかといえばそうではありません。

では、なぜ彼等はそれら副産物を作るのでしょうか？

その理由のひとつとして、ワイヤーフレームやペルソナを作ることが制作チームやクライアントとのコミュニケーションに適しているからと判断したからです。他の手法が適しているのであれば他を採用しているでしょうし、なくてもコミュニケーションがとれると判断すればやらなくていいわけです。IA だからワイヤーフレームを作らなければならない。UX を考えるにはシナリオを作り込まなければならない・・・といった具合に作業と関連付けて言葉を解釈してはそもそもの目的を失ってしまうでしょう。

言葉の共有とはビジョンの共有

昨年開催された CSS Nite LP7 のパネルディスカッションで、「私たちは何も共有していない」と発言しました。「デザイン」にしろ「Web」にしろ人によって捉え方が違います。それぞれ視点・姿勢をもっていると思いますが、誰かが間違っているというわけではありません。違いはあって当然なのですが、問題なのはこうした言葉が共通語／当たり前の言葉として会話が進んでしまっているという点にあります。

制作にあるミスコミュニケーションの中には、当たり前と思って使っていた言葉の解釈のズレによって発生するものがあります。上記で説明した「副産物」は言葉の解釈のズレを図や絵を通して埋めるための道具と考えることが出来るでしょう。全員がまったく同じ考えをもつ必要はありません、ただ全員が同じ方へ向けるようになり、迷ったときに立ち返るもの、そしてフォーカスできるものがあれば良いわけです。言葉の共有を通して作るサイトの進む道も共有しやすくなると思います。

講演ではサイトのゴール（ビジョン）を明確にすることが重要だと話しました。UX は様々な切り口で語ることが出来ますし、単純には表現出来ないでしょう。しかし、ひとつだけ語るのであれば「ゴールを共有するために努力を惜しまない」になると思います。UX といえば「使う人の体験」「使い心地」など作り手以外へ向けた考えが多いですが、私はそうではなく、作り手へ向けた考えのほうへ重点を置きたいです。作り手が考える『よい体験』が共有出来ていなければ使い手どころの話ではないと思いますし。

UXの何が大事なのか？そしてそれをどう仕事に活かせばいいのか？
今回のセミナーは、これらのコトを振り返って考えをまとめることが出来た良い機会でした。

さいごに

スライドはいつものように SlideShare にて公開されていますが、講演のアウトラインや質問など、セミナーに関する情報は Google Wave のほうに集約されています。セミナー前に募集した質問の幾つかは応えることが出来ましたが、時間が足りなかったので他の質問はサイトの記事として執筆しようと思います。

来場してくれた方、質問してくれた方、ありがとうございました。

セミナーは誰でも参加出来ます

何か書き込めば自動的に参加出来ますが、書き込まなくてもツールバーにある「Follow」をクリックすれば受信箱に登録されます。

抽象的なアイデアを話しているかのようにみえる「UX」ですが、意味をあやふやになってしまうのは実は「Experience (体験)」のほうではなく「User (ユーザー)」という部分にあるのではと感じています。「Webサイト」とひとことで表すものの、Webアプリケーション、Ｅコマース、コミュニティサイト、個人サイトと様々な種類があり、それぞれ人との関わり方が違います。Webでの操作は能動的なものが多く「User / 利用者」と表現しやすいですが、すべてが能動的な Web サイトではありませんし、能動的な行動にも幾つか違いがあります。

使うといっても、Webアプリケーションを操作する方と、Ｅコマースを訪れる方は見所が違いますし、自分がした体験の評価の仕方も異なります。つまり、UX について語るとしてもどのような人たちに何を提供したいのかという前提を共有していないと、「よい体験を」なんていうえらく抽象的で当たり前のような回答しか出てこないこともあります。「U」なくして「X」はないわけです。言葉では User と単純に表していますが、単なる利用者としてしか言葉を捉えていないとすれば、場合によっては場違いな体験を提供しているなんてこともあり得えるわけです。

「Ｕ」のなかにある５つの側面

サイトもひとつにカテゴライズ出来ない場合があるように、そこへ訪れる方達も明確なタイプの振り分けは出来ません。一元化は出来ないものの、訪れる方達のもつ様々な側面を把握することによって、どういった体験を提供することが優先なのか課題が見えてくる可能性があります。

利用者

Webアプリケーションやサービスを使っている方。彼等にはタスクを達成させたいという明確な目的があり、タスクを達成させるために具体的な行動をとります。

よって、彼等に対しての体験はタスクを中心に検討する必要があり、インターフェイスデザインもタスクから拡張して組み立てていくといいでしょう。タスクの達成するまでの道筋がいかに明確なものなのか、そしてそのタスクの邪魔になるようなものがあるかないかで印象が変わってきます。繰り返して利用する場合があるので、覚えやすいかどうかも課題です。

観覧者

動画やプロモーションサイトをみて楽しむ方。彼等はサイトを訪れているその時間を楽しく過ごしたいことを目的としており、役に立つ、効率的という部分で評価をしません。コンテンツを観覧する前からある程度の期待をもっており、たとえ多少待つ必要があっても待つことがあります。

彼等の期待に応えることが出来るコンテンツがあるかどうかだけでなく、感情にどれだけのインパクトを与えてくれるかという点も観覧者にとっての評価対象です。楽しむのは１度きりという場合がおおいですが、サイトを通して受けた感情が大きければ大きいほど他の人にも伝える原動力になります。

消費者

モノやサービスを購入する方。品揃えはもちろんのこと財布を開いて購入したいと思える情報がそこにあるかどうかが評価の対象になります。彼等の期待は販売しているブランドだけでなく、競合サイトのサービスを利用したときの体験にも関係している場合があります。期待に応えることが出来なければ購入はしませんし、次回は別のサービスへ切り替えることもあります。

彼等にとってサービス自体の善し悪しが問題ではなく、自分が支払っただけの価値を得れたかどうかによって評価が変わってきます。もちろんここでいうサービスとは Web サイトだけでなく、その企業が運営する電話でのサポートなども含まれます。お金と体験が最も密接に繋がっているといえるでしょう。

探訪者

なんとなく目的が自分の中で見えているものの、ピンポイントの場所を見極めることが出来ず、探し求めている方。目的のものが見つかるまでの道筋を極力短く、かつ明確に示すことが課題。明確なひとつの答えを示すだけでなく、幾つかの提案をするというアプローチもある。また、見つからなかった場合にどのような補助が出来るかを考えることで、評価に大きく関わることがあります。

明確ではないものの『探す』という具体的なアクションがあるので、その行動に対して邪魔になるような要素は省く必要がありますし、補助出来るものがあれば導入を検討していきたいところです。

放浪者

目的はないものの、おもしろいもの、役にたつもの、楽しいものをなんとなく探している方。購入・利用・観覧といった目的を得るチャンスをどのように提示するかが課題になります。クリックして次々にみるというよりかは、その場でどれだけの情報をみることが出来るかも放浪者には扱いやすいでしょう。訪問者がたくさんの情報をスキャニングできるような情報配置の工夫が必要になります。

ユーザーという言葉の意味を共有する

今回５つの側面を洗い出してみましたが、考えていくとさらにいろいろな側面が出てくる可能性があります。ペルソナを作るという手法もありますが、今回紹介したようにサイトを訪れる方達の大まかな側面を把握し、どういった方へ向けてサイトを作っているのかを共有しておくだけでも違いがあるでしょう。作り方にも影響するでしょうし、どういった部分を評価するのかが見えてきます。

私たちが何気に使っている「ユーザー」という言葉。この言葉のもつ意味は使っている人それぞれで違うことがありますし、その違いにより完成するサイトの展望も異なることがあります。コンセプトワークやブレインストームをするというプロセスは様々なアイデアを考え出し洗練させるだけでなく、言葉の共有をしていくためのプロセスではないかと考えることがあります。情報共有をしなければならない言葉は幾つかありますが、「ユーザー」はプライオリティが高い言葉といえるでしょう。

先月開催された Google I/O 2010 は、WebMプロジェクト、Chrome Web Store、Google TV などなど興味深い話題が目白押しだったわけですが、デザイン関連でもおもしろい講演があったのも見逃してはいけません。Google とデザインはかけ離れていると考える方もいるかもしれませんが、そんなことはありません。装飾的な意味でもデザインはないかもしれませんが、彼等は高いデザイン意識をもって開発をしています。その例として以前紹介した Google のデザインガイドライン10項目が挙げられます。

Google I/O では「Beyond design: Creating positive user experiences」というUXの話題で講演を行っています。動画とスライドデータが公開されているので、興味はある方はぜひダウンロードしてみてください。

私たちが「使いやすい、直感的」だといっている機器やソフトウェアでも、脳や身体は何かしらの処理を行っています。自分が使いやすいと思っていることも、人にとってはそうではない場合があります。これはリテラシーの高い／低いということで片付けることが出来ることでしょうか。デザインを考えるにおいて「簡単に（気軽に）使ってもらう」ということはひとつの課題であると同時に目標です。

インストラクショナルデザインは、人がいかに学習するのかを研究しデザインする分野です。Wikipedia では「より良い学習の環境を総合的にデザイン」と書かれているので、教育分野のデザインと考える方も少なくありません。20世紀後半から今世紀になると人の学習の仕方だけでなく、脳がどのように情報を処理するのかにも注目が集まりはじめます。こうした背景から認知負荷理論 (Cognitive Load Theory) が登場します。

人の認知や記憶には限界があるので、個々に確立されている独自のシステム（スキーマ）を援用して効率よく情報を処理するというのが認知負荷理論の考え方です。認知負荷理論に関しては 鈴木達也氏の人間の情報処理と映像 [PPT]が分かりやすくまとまっています。この資料は映像視聴における認知負荷についてまとめられており、Webサイトを観覧する行為にも似ていることから、参考になるところがあると思います。この資料を読むと３種類の負荷があると考えることが出来ます。

先月ひっそりと実装された、新しい機能「読むモード」。このサイトの読書体験を毎回新鮮なものにしたいという思いから様々なレイアウトで提供しているものの、人によってはシンプルに読みたいという方もいます。そういった方に向けてナビゲーション要素や独自のレイアウトを一切省いて読むことを可能にするのが「読むモード」です。RSSを購読してもらえれば、同等のシンプルな見た目で読むことは出来ますが、わざわざ購読はしたくないけどシンプルにさっと読みたいという方には最適な機能だと思います。

iPad で読むモードに切り替えても読みやすい

Danah M. Boyd と Nicole B. Ellison が、2007年に発表した「Social Network Sites: Definition, History, and Scholarship」というSNSに関する文献で始めて「ソーシャルメディア」という言葉が使われたといわれています。以下がその文献でソーシャルメディアという言葉が使われた文章になります。

Furthermore, as the social media and user-generated content phenomena grew, websites focused on media sharing began implementing SNS features and becoming SNSs themselves. Examples include Flickr (photo sharing), Last.FM (music listening habits), and YouTube (video sharing).

文献では SNS の定義から歴史まで語られているだけでなく、当時の傾向から考えられる未来についても供述されています。人々がコンテンツ(メディア)を消費するだけでなく、自ら作るようになってきたわけですが、こうした人々の行動に合わせるかのように、コンテンツを共有するサイトが次第に SNS 的な機能を盛り込んでいきました。人と人の間で共有されたり創造されるメディアを文献では「ソーシャルメディア」と呼んでいます。

以前はコンテンツ共有するWebサービスが、次第にソーシャルメディアを扱うサイトへと変化している例があります。例えば flickr は最初は写真(メディア)を共有するサービスでしたが、グループやプロフィールを強化してSNSのようになっていきました。また flickr 外でコンテンツを公開したりコミュニケーションのきっかけを作る仕掛けもあります。以前はユーザー名しか表示しなかったブックマーク共有サイト delicious も今は名前や自分のURLを表示させる機能を実装しています。

現在、ソーシャルメディアの代表格のような存在になっている Twitter や Facebook。そしてチェックインという従来あまり見られなかったコンテンツ共有を模索している Foursquare のようなロケーションサービスにも SNS 機能があります。つまり SNS 上で行われているコンテンツ共有の一部にソーシャルメディアがあり、ソーシャルメディアは SNS を必要としているわけです。人と人を繋げる何かがあるかどうかという部分が SNS であり、それはソーシャルメディアを語るのに欠かせない存在といえます。

見方が「What (何)」から「How (どのように)」へ変化した

SNSは「Web 2.0」という言葉が流行していた時期に耳にするようになった言葉ということもあり、使い古されたもの、一時期流行ったもの、時代遅れのようなものと考えてしまうかもしれません。実際はそうではなく、ソーシャルメディアという言葉が SNS によって生まれてきたということからもわかる通り、今だから重要だといえます。もちろん、Orkut から始まるプロフィールカタログのようなサイトだけが SNS ではなく、今は様々な形をとっています。従来は主に機能やインターフェイスから SNS を捉えていた場合もありましたが、今はそうではなく人の関わり方や社会との関わり方にフォーカスされていると思います。「What (何)」から「How (どのように)」へ変化したのかもしれません。

以前からソーシャルメディアと Web2.0 との関係についてディスカッションされています。捉え方によっては Web2.0 の一部としてソーシャルメディアをみることが出来ますし、発展 (進化) 系のようにみることも出来ます。どのように定義するにしても切り離すことは出来ないでしょう。

また SNS の見方が「What」から「How」へ変化したように、ソーシャルメディアも同じように「How」へ注目していかなければいけません。何のサービス/ツール/機能を導入するのかが重要ではなく、どのようにすれば先にいるユーザ、顧客にコミュニケーションをとることが出来るのかという部分にに注目する必要があります。ソーシャルメディアという言葉がどのように生まれたのかを知ることで、改めてその重要性に気付かされます。

昨年 Opera のパネルディスカッションに参加したときにも感じたことですが、Opera はどのブラウザよりも「Open Web」という思想を信じてソフトウェア開発をしているという印象があります。Tetzchner氏の話も Web はオープンであるべきという強い主張があると同時に、それに寄り添う形で Opera は開発を進めているという内容でした。

今回のTetzchner氏の話で２つのことを感じました。

ひとつは Opera の主張は共感できるものの、それを強く出していることが逆に異質なものを作り出しているという点。もうひとつは、彼等の目指している Web とはまったく反対側のほうに世界が向かっているという点です。

Operaらしくあることで生じる違和感

私は Opera を未だにディフォルトブラウザとして使ったことがありません。バージョン10から、UI が整理され、アイコンも美しくなったので魅力的な雰囲気がするものの、未だにテストで時々使う存在です。その理由として「なんとなく違う」という違和感が挙げられます。

ひとつ分かりやすい例として、Opera Mini for iPhone があります。起動もまずますですし、ページの表示速度は Safari より早く、戻る・進むボタンによる操作も快適です。Symbian OS の Opera Mini は使ったことがあったので、それと似た操作感でブラウジングが出来ます。個人的にはページ内検索がお気に入りです。よく出来ているのですが、『違う』のです。iPhone アプリなのにも関わらず iPhone アプリを操作していない雰囲気がしてしまいます。気になった部分を幾つか挙げると以下のとおり：

• 時計などが表示されているバーをタップしてもページ上に戻らない (タイトルバーで戻る)
• ブラウザ下に配置されているメニューが他と違う
• タップ以外のジェスチャーを使ったページズームが出来ない
• テキストの選択・コピー・貼付けの UI が独自仕様
• リンクをクリックしても App Store が立ち上がらない
• ホームボタンとして Web ページを追加出来ない

Opera Mini for iPhone は、操作感や装いがいかにも Opera Mini らしいわけですが、iPhone らしくはないといったところでしょうか。今まで Opera Mini を使っていた方が同じ操作感で iPhone 上で Opera を使いたいという場合には最適なのですが、iPhone アプリとしてみたときにどうしても違和感を感じてしまうわけです。実はこれと同様なことはデスクトップアプリのほうでもあって、Mac OS X を立ち上げているのに Opera のウィンドウだけが別の世界感を持っています。それはそれで良いという方もいると思いますが、それが私の中で「なんとなく違う」という思いになってしまうのでしょう。

どの機器からでも Web へアクセスしてもらうためのソフトウェアを提供するという目的は Opera Mini は達成しているでしょう。実際たくさんのデバイスでも使えますし、どのデバイスで操作してもだいたい同じです。しかし、利用者が使っている機器やソフトウェアに最適化された形で提供しているのかといえば少々疑問です。オープンな Web へアクセスするわけですから、どの機器からでも一定の使い心地を提供することが重要だとという考えからかもしれません。

閉ざされた世界へ向かう Web アプリ達

どこからアクセスしても操作が同じなのが Web アプリケーションの魅力です。例えば Windows でも Mac からでも Gmail はアクセス出来ますし、どちらからアクセスしてもボタンが変わることもありませんし、使い心地は同じです。いつでも何処でも自分のデータにアクセス出来る Web アプリケーションは素晴らしいですが、デスクトップアプリケーションではありません。たとえ Fluid のようなツールを使って単体アプリケーションのように見立てても「なんとなく違う」わけです。そういった意味では Opera と同様の課題を Web アプリケーションは持っているわけです。

Gmail が出始めてからしばらくは Mailplane というアプリケーションから利用していました。その理由として大きかったのが、アドレス帳や iPhoto といった他のアプリケーションの連携と、Finder から直接ドラッグ＆ドロップすればファイルを添付出来るという手軽さ（デスクトップアプリらしい振る舞い）があります。今年になって公式にドラッグ＆ドロップ機能が実装されたので、またひとつ Mailplane を使う理由は減ったかもしれません。Gmail の例だけでなく、デスクトップと Web アプリのギャップは徐々に狭まっているとはいうものの、見た目を含めた違和感をどう埋めて行くのかが今後の課題といえます。

この課題の解決方法として Web アプリケーションの『アプリ化』があります。Webブラウザひとつあれば、何でも出来ると言われていた時代は久しいもので、今や様々な Web アプリケーションが携帯電話・スマートフォン向けに最適化され出荷されています。たとえ、Web アプリケーションをホームに追加してもらったとしても Opera Mini にみるような違和感が残るわけですから、デバイス／OSの機能を活用したアプリケーションを開発したほうが良いという考えです。

Tetzchner氏も公演中に危惧していたことですが、近年みるモバイルデバイスの囲い込みエコシステムは Web とは相反する姿でしょう。iPhone はロックがかかっていて、Android はそうではないからこちらのほうが良いという考えがあると思いますが、いずれも閉じたエコシステムの中アプリケーションが動いていたりマネタイズモデルがあるわけですから同じようなものです。Apple はオープンスタンダードといわれている HTML5 を積極的に使うと主張しているものの、彼等が見ているものは Web アプリケーションというより、閉ざされた iPhone アプリの世界です。そして、その閉ざされた世界へ Web アプリケーションは次々と流れています。

メリットがたくさんあるのは分かります。利用者は自分が馴染んでいる使い心地で、すぐにアプリケーションを利用したいですし、それを当然と考えているでしょう。それぞれのデバイスのために開発する手間があるものの、特定のデバイスならではの機能を最大限に生かすことで表現豊かなアプリケーション開発を可能にするという意味では開発者にもメリットがあります。特にブラウザ上よりさらに近い場所へサービスを提供出来るという点と、閉じたエコシステムなので課金が楽に行えるというメリットも見逃せません。多くの方がオープンな Web より閉じた世界へ注目するのは近年の流れからすると当然のことといえるでしょう。

人々が求めているわけですから、良いことなのかもしれません。データがオープンな仕様でアクセス出来れば、作られるアプリとそれを取り巻く世界は閉じていても良いのかもしれません。しかし、本当にそうなのでしょうか。

オープンな Web は何が提供できるだろう

高機能で優れた Web アプリケーションが次々と登場する前は、デスクトップアプリケーションや特定の Web ブラウザに特化したアプリケーションばかりでした。オープンな世界とクローズな世界は振り子のように常にゆれ動いているのかもしれません。しかし CSS3 や HTML5 を利用するという技術的かつ漠然な提案では利用者は納得することはないでしょう。では、今後またオープンな Web アプリケーションには何が求められるのでしょうか。

ひとつ考えられるのが、HTML による GUI 生成の強化だと思います。今でもボタンやプルダウンといったフォーム要素 OS ごとに合わせて生成されていますが、さらに多くの要素が OS らしく再現出来るようになって欲しいですね。メニューもせっせと CSS で記述するのではなく、nav要素の内容が自動的に OS に合わせた見た目と使い心地を再現するというのもひとつの手段です。すべての見た目を CSS によって解決するのではなく、OS に任せることが出来る度合いがもっと増えて欲しいです。

また、人によって Web アプリケーションとデスクトップアプリケーションを織り交ぜて使っているわけですから、Web アプリケーションがデスクトップアプリケーションへアクセス出来る仕組みも欲しいですね。Web アプリケーション同士は API で繋がっていますが、アプリケーションであればどんな種類でも必要に応じて繋がると、ますます両者の境はあやふやになって便利になりそうです。OS 側もネイティブアプリ向けだけでなく、Web アプリが『自立』出来るような環境や機能を充実していって欲しいところです。

上記に挙げたアイデアに近いものは既に幾つかあります。また、振り子のように Web アプリケーションの時代が来るのかどうかは分かりませんが、Web に携わる仕事をしている以上、Web について時々立ち止まって考えたくなりますし、Tetzchner氏の講演はその良いキッカケを作ってくれました。