ある程度、コンバージョン達成に意欲があるユーザーだけがいるので、余計な部分で離脱の原因は作りたく無い部分です。

ということで、今回はフォームを改善するにあたっての10のポイントをまとめてみました。

と、その前にフォーム分析を行うにあたってどのようなポイントを指標として確認していけば良いかに少し触れていきたいと思います。

フォームの指標

フォームまわりで確認できる指標はそれほど多くはありません。大きく４つと言えるでしょう。

1. フォームページの離脱もしくはフォールアウト
2. フォームでのエラー発生数
3. 放棄（離脱）をした際に入力していたフォーム
4. 放棄した人のその後のパス

１はどのツールでも確認できるものです。通常は問題点を見つける際にも利用しますが、既に「フォームを改善」にフォーカスをしているのであれば、改善の結果を評価するための指標として利用すると良いと思います。

離脱数を見てしまうと、TOPページなどに戻った数は見えなくなってしまいますので、フォールアウトレポートや次ページの遷移を見る中で、通常のサブミット画面とは別のページに遷移している数を確認していくと良いでしょう。

２つ目はフォームでのエラー発生数です。これは改善を行っていくためには非常に重要なものの１つと言えるでしょう。エラーが発生しているということは、サイト側が想定している入力ではない方法で入力がされているということです。

エラーの種類ごとに、発生数を集計し発生率の高いものから、仮説をたてて対応策を検討していくと良いでしょう。

３つ目は、取得できるツールが少ないというか、頑張ればGoogle Analyticsでも取得できないことは無さそうですが、あくまで、ここでは取れた場合ということで。（もし取得方法を知りたい方はご連絡ください）

エラーとは別に、サブミットをせずに画面を閉じたり、他のページへ遷移をしてしまった理由に、途中でわからなくなったり、面倒になったりといったことがあります。

エラーが発生していないので、こういった理由は判断するのが難しいのですが、最後にカーソル（フォーカス）があったフォームの場所をJavaScriptで取得して計測することは可能です。

ということで、これを集計すると意外なフォームで放棄をしてしまっていることがあります。ここでは「何故このフォームで放棄をしてしまったのか？」を仮説として設定し、改善策の案に役立てると良いでしょう。

さて、最後です。放棄した人の動線です。サイトを離脱してしまった人はわかりませんが、サイトを離脱したわけではなく、ページを一旦はずれ、別ページに行っている人を見ます。

ここをうまく読み解ければ「何か不明な点があって一旦離脱した人」を見つけ出すことが出来ます。何かの同意にチェックをするにあたって、不明な点があり離脱している場合も多くあります。

ということで、既に結構な量を書いてしまったのですが、ここまでがWeb解析ツールを使ってフォーム分析をする場合のTipsです。ここからはそこから改善をする場合のTipsです。

実際に改善をする際のTips

実際に改善をしていくにあたって、どのようなポイントを１０個洗い出してみました。もしかしたら、もう少しありそうな気がしますが、切りも良いのでここでは１０個で。

１：フォームの数は最低限にする。

フォームで入力される項目は、訪問者の属性を知る上でも重要な部分です。その為、どうしても入力数を増やして知りたい属性を増やしてしまいがちです。

知りたい気持ちを抑え、少なくする努力をすると良いでしょう。例えば住所を聞いたところで、住所まで知っていてもそれほど活用しない場合もあります。もしかしたら郵便番号だけわかれば地理情報としては十分なのかもしれません。

２：準備に時間のかかる情報は事前にインフォメーションする。

通常の会員登録であればそれほど問題ありませんが、たまに、その情報を入力するにあたって準備に時間のかかるものをシラッと入力を促していたりするフォームに出会うことがあります。

もし、会社で入力をしようとしていて、その情報が家に帰らないとわからないのであれば、放棄しちゃいますよね。そこでまた戻ってきてくれれば良いですが、「途中まで入力したのに…」と意気消沈してしまう場合もあります。

３：クリアボタンはいらない。

もともとのHTMLの機能として対象のフォームに入力したものをきれいに消し去ってしまうクリアボタンを付けることがあります。いまだに、このボタンを設けているフォームを見かける事がありますが、果たしてこのボタンの利点は何でしょうか？恐らく入力したものを全て消してしまいたい人はあまりいないでしょう。

４：エラーを寛容にする。

名前を全角入力をしたあとに、半角入力で電話番号を促したりする場合があります。しかし、その違いに何の意味があるのでしょうか？最終的にデータベースへは半角で保存をした方が良いかもしれませんが、それが全角であってもサーバ側で半角に修正することはそれ程難しいことではありません。「全角で入力をしてください」「半角で入力をしてください」なんてお客様に強要していないですか？

５：入力例を表示する。

エラーを寛容にしたとしても、やはり何を入力して良いかは戸惑う部分です。その為に入力フォームごとに入力例を設けていることは重要です。最近ではフォームにうっすらと例を表示しておき、フォーカスされた時点で消す方法も良く利用されています。このように、どのフォームに何を入力する必要があるかを明示することは非常に重要と言えます。

６：フォームのラベリング

どのフォームに何が入力されているかを示すことは非常に重要です。どのラベルがどのフォームと結びついているかを、ラベルと距離が離れないようにしていくと良いでしょう。

また、必須入力もわかりやすくすることが良いです。もちろん、基本は全て必須入力であり、必要のないものは取得しないぐらいでも良いはずです。ユーザーからしたら必須入力では無い物をわざわざ入力する必要はないからです。

７：延々と続くプルダウンをなくす

プルダウンはたくさんある項目の中から１つを選択してもらいたい場合に便利な方法と言えます。しかし、実際に何十もの項目を１つのプルダウンに入れてしまうと、選択する側は大変です。

果たしてそれ程詳細に取得すべき項目なのか？もう少し大きなカテゴリに分解して２つのプルダウンに分けることが出来ないかなどを検討すると良いでしょう。

８：タブ送りが考慮されているか

HTMLの組み方によってはタブボタンを押しても、画面に表示されている順番通りにタブが遷移しない場合もあります。

タブがうまく利用できないことで、ユーザーは入力の時はキーボード、フォームを選択するためにマウスと行き来をしなくてはならなくなります。細かいことですが、タブ送りを考慮した作りをしておくと良いでしょう。

９：不要な情報を表示しない

何故かフォームを入力するページで、サイト内キャンペーンの広告を表示しているサイトに出会うことがあります。そこからページを放棄してしまって、別のページにいって戻ってこなかったら非常にもったいないでしょう。

フォームには必要最低限のリンクを設けるだけで、バナー広告などは表示しないようにしましょう。

１０：フォームのフォーカスをわかり易くする

フォームの入力をする際に、どのフォームを入力しているのか分かりづらい場合もあります。特にフォーム量が多い場合や別の資料を見ながらの入力などでは見失いがちです。

CSSを利用して、フォーカスされているフォームがどこにあるかをわかり易くすることで、ぐっと入力のユーザビリティがあがると思います。

まとめ

書き始めたら結構長くなってしまいました。。後半のTipsは「ユーザビリティの向上」「手間の軽減」「不要な間違いを防ぐ」といった観点から洗い出しを行っています。

おそらく、この観点で見ていけば、もう少し色々な工夫もできると思いますので、是非、色々とテストをしながらフォームの最適化をしていって頂ければと思います。

昨日顔を出してきたIA Cocktail Hour Tokyoの主題です。これって結構難しいですよね。そして、やはりみなさんも苦労しているっぽい。

社内ブログや社内SNSはやはり、Postする人が限定されてしまうのはどこも同じらしい。いくつか出ていたのが「自分がどう書いていいかわからない」「この人に意見なんて出来ない」「自分のレベルが低いかもしれない…」など。

情報共有の目的

情報を共有することの目的としては、その状況に応じて様々なわけですが、プロジェクト内部の情報共有のような、進行具合や状況を把握するための情報共有と、こんなサイト知ってる？といった、参考情報の共有があるわけです。

どっちも難しいと言えば、難しいわけですが、状況の把握の場合、特にそれがプロジェクトなどであれば、仕事の中で必要なわけですし、受け取る側も受け取る意欲があるわけで、まぁ、なんとかなる場合も多いわけです。おそらく。

ということでこれは誰かにおまかせして、今回はもう１つの参考情報としての共有についてもう少し考えてみたいなぁと。

これって、直接的に業務に関係ない場合もあったりするので、実は状況把握としての情報共有よりはるかに難しい気がしています。

仕事に役に立つかもしれないし、役に立たないかもしれない。でも、それを知っておくことで、チームやグループの幅は広がるといったものです。

ある人から見れば、「無駄な情報」かもしれないし、他の人がみれば「のどから手が出るほどありがたい」情報かもしれないわけです。

情報を集める方法と知らせる方法

気にする部分は大きく２つ。「情報を集める方法」と「情報を知らせる方法」です。

情報を集める方法といっても、RSS使えとか新聞読めとかそういうことではなく、ピックアップされた情報を集約する方法です。

これは出来るだけ簡単な方が良いのかなぁと思ってます。それこそ、Bookmarkletなどを利用してPostしたりTamblooぐらいになってしまうとさらにうれしい。

つまり、いちいちテキストエリアを目の前にして何を書くか考えてしまうことでハードルがあがってしまうわけで、この際、もうそういった事すらやめてしまう。

あとは、誰かがそれを再編集していく。どこかで繋がるものもあるかもしれないし、そうでないものもある。ちょっと、違うものもあるかもしれないから、それは別にしてしまうか削除する。

これをやっておくと、だいぶ情報の質が高まるわけです。編集という作業であれば、自分の意見を書く訳ではないので、誰でもできるわけです。そして何より、編集という作業を通して、その情報について考えるし詳しくなれる。ということで、グループで仕事としてローテーションでも良いかと。

次に情報を知らせる方法ですが、これはRSSで配信しておくことは重要だと思います。ここである程度取捨選択ができますからね。

それと、ホワイトボード。オフィスなどのどこかに書かれたものがアップされてれば、もしかしたら目につくということにもなるかも。最近のはやりの企業だと、マインドマップとかを会社の廊下とかに用意してますよね。

これは月間ASCIIに載っていたのですが、株式会社内田洋行では、同社が提供しているパーフェクトプロジェクションアダプター（PPA）というのを利用して、会社の壁に並べた複数のディスプレイに、誰でも簡単に自分のPCから情報を掲示できるそうです。

これで集約した情報の新着を載せていたら面白いだろうなぁと。

まとめ

ということで、情報共有について少し考えてみました。偉そうな理想を並べましたが、結局は、メールで情報共有、リアルに顔を突き合わせてコミュニケーションが一番盛り上がったりするものです。

おぉ、そういえば情報共有で思い出したのですが、FrindFeedというサービスを利用して、はてなのアクセス解析タグとDeliciousのWebAnalyticsタグを１つのRSSになるようにしています（WebAnalytics – FriendFeed）。

一応、ニュースだったりブログのエントリーを中心にしているので、わたくしめが勝手に不要なリンクは削除したり、コメントを入れていたりもします。なので、パブリックというよりは、かなり偏った感じの情報ですが。ご興味があれば是非。これも情報共有。

Omniture | Products | Conversion | Survey

自分が関わっているサイトでも、簡単なアンケートを取得して、それを結びつけることをおこなっており、こういった動きはいいんじゃないかなぁと思います。

やっぱり行動だけでは判断出来ない部分もありますからね。

この AutoPagerize は今後 WEB の UI を考える上でのインパクトも考えてみたいなぁと思うものの、今日はこの AutoPagerize によってWeb解析ツールで計測しているページビューがどう変わるかを考えてみたいと思います。

集計方法によって変わるPV

Web 解析方法には「サーバログ型」「タグ型（ビーコン）」「パケットキャプチャ型」なんかがわるわけですが、これらは集計方法が異なることなります。ここでは、それぞれの詳細は触れませんが、データの取得もとが違うといった感じです。

AutoPagerize はページの下のほうにくるとAjaxで次のページを自動的に取得して継ぎ足されていきます。ブラウザ上は一枚のページに見えるんですが、ブラウザの裏側ではページの下に来るとHTTPのリクエストな流れている感じです。

この仕組みを考えるとそれぞれの仕組みでのPVはこんな感じに変わると思います。

サーバログ型

サーバログ型は文字通りサーバのログを元に集計するわけです。AutoPagerize による継ぎ足しのリクエストはサーバログ上からは通常のリクエストと同じように処理されるので、解析ツール上は普通にAページからBページへ遷移したように見えます。

PVも普通にAページ、Bページ…とカウントアップされていきます。

タグ型（ビーコン）

これがちょっとやっかいです。この方式は現状スタンダードなのはページが読み込まれた際に JavaScript が起動してデータを取得し、解析サーバに渡す方法です。この方式で AutoPagerize のリクエストを考えた場合結構面倒な感じになります。

先読みして継ぎ足しされたファイルは、私がテストをしみる限りは、Bodyの中などに記述された JavaScript は実行されないようです。OnClick などで何かしら起動するきっかけがあれば大丈夫なようなのですが…

つまり、2ページ目以降はページが読まれたのかどうかを確かめることが難しい形になってしまいます。せめて JavaScript が実行されればなんとかなるのですが…

ちなみに画像を埋め込むだけのビーコンの場合は、画像がコールされるだけなので特に問題なくページが取得できると思います。

パケットキャプチャ型

パケットキャプチャ型については基本はサーバログ型と同じです。HTTPリクエストを解析して処理をするので、同じようにAページ、Bページと遷移したようにみえ、PV上でもAページ、Bページ…とカウントアップされるはずです。

まとめ

思い立って出来る部分についてはテストをしてみたのですが、正直タグ型がなすすべあらず…というのが残念な結果でした。タグ型は取得項目を色々と仕込めたりと使い勝手が高いので非常に好きなだけに残念です。

「PVが取れないからじゃあ何も出来ないのか？」というと個人的にはそうでもないなぁとは思っているのですが、それにしても RIA のリッチアプリケーションやAjaxの利用が増えてきているなかで、こういった部分の対応もベンダー側に考えていってもらう必要があるのかもしれませんね。

例えば坂本さんも取り上げられていた映画の告知サイトなどが分かりやすいと思います。

なぜ標準ができるのか？

これは私が関わっている業界でも起きているのですが、競合サイトを意識することで起きてしまうことも多いようです。

その原因はユーザーからの問い合わせからであったり、担当の上司であったりと様々なものが考えられます。「何であっちのサイトにあるのに、こっちにはないの？」という単純な質問が最終的に横を見てサイトを作ってしまうということに繋がってきてしまうのだと思います。

もちろん「新たに考えるのも面倒だし、同じものを用意しておけば良いんでないの？」といった感じもあるでしょう。そうして、同じようなメニューが増えてくることで、業界標準がなんとなく出来上がってきているのだと思います。

比較のユーザビリティ

ネットの利点の１つに情報比較のしやすさがあります。

ネットが一般的になってきた現在では、消費者が何かのアクションを起こす前に情報を集めて比較しておくことなどが当たり前のように行われています。それこそ家電量販店の流入は価格コムなどの比較サイトからの流入がかなりを占めるそうです。

同じ項目が並んでいることで比較をしながらサイトを渡り歩いているユーザーにとってはユーザビリティが向上します。経験上どのラベルのメニューには何が含まれているかがわかりますからね。

必ずしも良いわけではない

ただ、業界標準が情報整理の観点で必ずしも良いわけではないと思います。この辺りは難しいですね。ガラッと変えてしまうとユーザビリティを落としてしまう可能性があります。

よって、ちょっと面倒ですがJND以下の対応をしていくことなどもあると思います。ちょっとずつ変えながら最終的な方向へ向かわせる。そして1年ぐらいすると去年と比較するとずいぶんと変わっていたという感じです。この辺りは以前書いたJND以下で考えるユーザビリティを読んでみてください。

まとめ

実際に業界標準は色々なところで起きているようで、サイト構成だけでなく、サイトのデザインなども同じような形になってきているところが多いようです。ニュースサイトなどもその傾向が強いかもしれません。

この辺のユーザインターフェースをガラッと変えることは、担当からすると非常に勇気がいることなんですよね。

UIを変えることでユーザーが離れていってしまうかもしれない、変えないんだったら今ぐらいのユーザー数は確保できる。だったら、変えなくてもいいんじゃない。

多分そんなところからよりさらなる業界標準を作ってしまっているのかもしれませんね。

水産庁のサイトって始めて見たのですが、組織が運営しているサイトでまだまだこんなものが残っているんですね。ある意味化石です。保存しておいても良いと思います。

ペルソナ

事前にペルソナを考えるというお題があったため、私のグループではペルソナを中心に据えながらサイトマップ作成に励みました。

ただ、サイトゴールを考えると水産庁のサイトは「情報を正しく伝えること」だろうということで、結局作られたペルソナいったん別のところへ追いやられてしまいました。

このペルソナを使った手法、どうもサイトによって向き不向きがあるようです。ペルソナを使った手法についてはそれ程詳しくないので、実はそんな議論は済んでいるのかもしれませんが…

官公庁のような「情報を正しく伝えること」がゴールにあるようなサイトやサイトゴールとして掲げているものがターゲットを絞っていないもの、例えばポータルサイトなどではペルソナを利用しない方が良いのだと思います（実際にとあるポータルサイトの担当の方は使っていないということでした）。

この辺りは私のような何年も同じサイトに関わっている人間よりも、制作会社で色々なサイトに携わっている方の方が肌で感じているかと思います。

情報の整理とペルソナ

水産庁のサイトは見ていただいた通り、そもそも「情報の整理って何？」という状況になっています。

ということでは私のグループで行ったのは、どのような情報があるかの理解もあり、現状のTOPからリンクしている情報を分類しました。

そこでグループ分けをしたものを、再度ペルソナに照らし合わせて分類をし直すという作業を行いました。

ペルソナを当て込むと、もともと分類したカテゴリと違うところに分類されるものが出てくるんですね。こういったところがペルソナの効果？の１つなのかもしれません。

ちなみに講師の坂本さんは４つぐらいのペルソナで整理をしていました。今回の場合は複数ペルソナを利用して研磨的に使う方が、サイトのゴールから照らし合わせても良いのかもしれません。

マーケティングとIA

マーケティングとIAについて質疑応答時にありましたね。この辺りについては非常に難しいところだと思います。

企業のエゴ（マーケティングより）と消費者視点（IAより？）とのバランスが取れたサイトを作るということは非常に難しいもので、かつそれは状況によって変わってきます。

坂本さんはもちろんサイトを作る中でマーケティング的な話は行うこともあるし、そういった知識がIAにも必要であろうということでした。その上でマーケティング的な提案は運用を行いながらしていくと。

ここは非常に難しい部分ですね。エゴをどこまで取り入れるか。でも取り入れないと企業としての営みが成り立たない可能性もあります。

私の関わっているサイトでは、その部分をクリアするためにサイト構造を大きく２つに分けています。

情報として整理している部分とプロモーション・キャンペーンページ群です。この辺りを明確に分けることで、マーケティングとIAのバランスを取ろうと運用しています。

動線としてはプロモーションページをLP（ランディングページ）に据えて、顧客の理解が深まったところでより事務的な話が必要であればそちらに誘導するといったイメージです。

まとめ

今回は色々な刺激があったので、ちょっと散文になってしまいましたが、非常に面白い体験でした。実際に私は数年前はIAに近いことを行っていたこともあるのですが、現在は立場が違うため直接IAの業務に関わることはありません。

つまり半分趣味での参加だったのですが…。

ただIAを行うということは、サイトに求められているもの、背景、マーケティングなど全般を理解が求められるため、サイトを作るうえで非常に常用なポジションになることは確かだと思っています。

そういった意味でWEBサイト制作や運営に関わっている人間が知らないでは通れない部分であり、まだまだフレームワークの少ないIA分野を育てていく必要があるのだと思います。

そして今回の勉強会において、「情報」というところに注目し、画面という2次元的なものとフロー構造という3次元的なものを両方実現していくというIAの仕事は、非常に高度なスキルが必要なんだなぁ　と改めて感じるものとなりました。

ユーザーインターフェースを考えていく上で、サイトのリピート性の箇所を変更する場合は、そういった慣れへの配慮をしておく必要があります。

慣れへの対応

ECサイトなどの場合は、リピート利用をしていただくことが多くなります。そういった箇所を変更する際、ロイヤリティの高いリピートユーザーへの配慮があります。

そのサイトが使いにくいかどうかは別にして、ロイヤリティの高いユーザーはそのユーザーインターフェースに慣れてしまっています。

よって、インターフェースがガラッと変わってしまうとミスを引き起こしやくすなり、サイトとしてはユーザビリティを向上させたつもりでも、「改悪」だなどと悪いイメージを持ってしまう可能性も出てきてしまいます。

こういった際にJNDを考慮してユーザーインターフェースを修正していくと良いと思っています。JNDとはJust Noticeable Differenceのことで、人が違いを認識するか・しないかの境目を指しています。（JNDとは）

例えば元々左上にあった「決定」ボタンをいきなり画面の右下に移動してしまったら混乱をしてしまう可能性があります。こういった際はまず両方の位置に置いていくなどをしてきます。その後、段階的に場所をシフトしていくと良いと思います。

訪問期間と修正タイミング

段階的に修正を行っていくにあたって、修正を行っていくタイミングも重要です。長からず、短からずです。これはサイトの平均訪問回数などを参考にしておくと良いと思います。

ロイヤリティの高いユーザーが数値上特定できるのであれば、それらのユーザーの平均訪問回数で求めていくのが良いと思います。

だいたい3回程度の訪問を目処に段階的に修正を行っていくことで、混乱を避けながら行っていくことが出来ると思います。

まとめ

今回の話は決して「JNDをきちんと測定して対応をした方が良い。」という話ではありません。

ある程度、そういったロイヤリティが高いであろうリピートユーザーへ配慮をしながら少しずつ修正をおこなっていった方が混乱が起きにくいということです。

逆にユーザビリティの根幹に関わらない部分や見せ方についてはJND以上の変化をつけた方が「対応しました感」が出て良い場合もあります。

良くも悪くもユーザーは学習します。悪いユーザーインターフェースだったとしてもです。

どこがユーザーインターフェースのクリティカルポイントであり、それを変更することで、ユーザーにどう変化があるか。そういった部分を考えながらユーザーインターフェースの設計をすることが良いユーザビリティを生む第一歩だと思います。

ただ、重要なことは
「ユーザーにとってWEBサイトは目的を達成するツールでしかないこと。」
です。

これはユーザーインターフェースを設計することでも同じなのですが「そのサイトをユーザーが使う目的をきちんと定義し、その為のツールを提供すること。」これが非常に重要です。

その定義があって初めて、それに合わせた「早さ」や「快適性」「情報」などの設計が必要になるのです。

このことはサイトを作り始めてしまうと見失いがちですが、マーケティング、UI設計など全てに関わってくることですので、是非これを再度見直してみてください。

【IT Japan 2007】「デザインに凝ったウェブサイトほど予約率は低かった」，星野リゾート社長が講演：ITpro

「ほしのや」の予約システムはFLASHで作られていますが、非常に質が悪い。これはずいぶん昔からなのですが、RIAの利点がまるっきり生かされていない、だったらHTMLで作った方がよっぽどユーザビリティがあがるというシステムです。残念ながら。。

ところが、上記のような講演が載っていたので、これは？！と思いアクセスしてみると相変わらずのまま…

プラスとマイナスのユーザビリティ

以前、RIAの評価の研究をしていた時に考えていたのがプラスのユーザビリティとマイナスのユーザビリティの考え方です。「プラスのユーザビリティ」とは「やると良い対応」の部分で、「マイナスのユーザビリティ」とは「やってはいけない対応」の部分を指しています。

最低限のユーザビリティを達成する場合は「マイナスのユーザビリティ」の部分をいかに無くしていくかという部分がポイントになってきます。さらにより良い部分を目指すために「プラスのユーザビリティ」の対応があるわけです。

どちらに対応した？

ほしのやさんの内容を考えていて思ったのが、このマイナスのユーザビリティとプラスのユーザビリティでは、どちらを対応したかで売上の跳ね返る効果は変わってくるかもしれないなぁということです。

ニールセンの言葉を借りると「ユーザビリティに気づかれないことが究極のユーザビリティ」なわけです。

マイナスのユーザビリティの対応は「ここ使いにくいなぁ」から「普通」にしたところなわけです。ここの部分の印象はユーザーにとっても非常に大きいわけで、その分、売上への貢献も大きいはずです。

しかし、それ以上のプラスαのユーザビリティは、対応するのも難しく、なんかちょっと「使い勝手良いかも」程度にしかならないわけです。つまり、その分の売上への反動も小さい。

そんな訳で、ユーザビリティの対応が「プラスのユーザビリティ」であったか「マイナスのユーザビリティ」の対応であったかは大きく変わってくるのだと思います。

まとめ

「ほしのリゾート」の場合、このマイナスのユーザビリティの対応がまず行われた印象が非常に強いです（まだの部分もあるようですが…）。さらに、もともとブランド力も非常に高いので、そういった意味で効果は大きくでたのだと思っています。

自分の経験からも、マイナスのユーザビリティ対応は非常簡単なうえ、ユーザーが受ける印象も大きいものがあります。それに対して、細かいところまで気を使って対応したプラスのユーザビリティは、気づかれない場合すらあります。

ただ、このプラスのユーザビリティが「いかに気持ちよく帰ってもらうか？」というところで、長期的なブランド価値としてみれば非常に効果の高いものだと思っています。

「ほしのや」さんが究極のホスピタリティをリアルで提供しているように、ネットでもその提供を目指して、よい良いサイト作りをしていって頂きたいなぁ…ということで、このエントリー変えさせていただきます。

構築ガイドの方では3章を担当してました。HTMLとは違う、RIAを使うと良いユーザーインターフェースについてまとめています。事例を沢山とりあげながら、まとめているので、非常に参考になると思います。

また、構築ガイト2.0ではRIAの評価チームを取り纏めを何故かさせて頂いていたため、評価項目のパートに関わってます。これは構築ガイドをベースに、RIAを評価するための方法を構築しようと頑張った内容が入ってます。

FLASHのアプリはもちろんのこと、Ajaxのアプリにも十分活用できる内容になってますので、是非ともダウンロードしてご活用くださいませ。