Home » Archive

Articles in the UserInterface Category

General, UserInterface »

[12 11月 2013 | カルーセルバナーがターゲティングにフィットしやすい理由 はコメントを受け付けていません。 | ]
カルーセルバナーがターゲティングにフィットしやすい理由

最近、PC、スマートフォンのいずれのサイトでもよく見かけるカルーセルバナー・パネルですが、これはバナーを配置していくにあたって、「4つのバナーを全部見せたい、でも、それをそのまま載せてしまったらページ長くなってしまったり、1つのバナーが小さくなったりスマートなデザインじゃないしなぁ」的な理由かと思います。

まぁ、実際には他にも色々な理由があるとは思いますが、これがターゲティングに非常に使いやすいという話をつらつらと書いていきたいと思います。

General, UserInterface »

[14 5月 2012 | One Comment | ]
テストパターンを考える時のアイデア その3

前回(テストパターンを考える時のアイデア その2)は「競合や同業のパターンを探る」「UIのパターンまとめを見る」「過去のナレッジの確認」といった部分でのテストパターンの洗い出しに触れたわけですが、今回は「競合や同業のパターンを探る」を実際に考えた場合の例を少しだけ(軽め)。具体的にはグローバルナビゲーションを検討する場合の例などを簡単に挙げてみます。

Featured, General, Marketing, UserInterface »

[11 1月 2009 | One Comment | ]
フォームを改善するための10のポイント

コマースサイトや新規獲得サイトにおいてコンバージョンプロセスはサイトで最も重要な部分だったりします。

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

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

General, UserInterface »

[27 9月 2008 | 情報共有の方法を考える はコメントを受け付けていません。 | ]

「どうやって情報共有をしているか?」
昨日顔を出してきたIA Cocktail Hour Tokyoの主題です。これって結構難しいですよね。そして、やはりみなさんも苦労しているっぽい。
社内ブログや社内SNSはやはり、Postする人が限定されてしまうのはどこも同じらしい。いくつか出ていたのが「自分がどう書いていいかわからない」「この人に意見なんて出来ない」「自分のレベルが低いかもしれない…」など。
情報共有の目的
情報を共有することの目的としては、その状況に応じて様々なわけですが、プロジェクト内部の情報共有のような、進行具合や状況を把握するための情報共有と、こんなサイト知ってる?といった、参考情報の共有があるわけです。
どっちも難しいと言えば、難しいわけですが、状況の把握の場合、特にそれがプロジェクトなどであれば、仕事の中で必要なわけですし、受け取る側も受け取る意欲があるわけで、まぁ、なんとかなる場合も多いわけです。おそらく。
ということでこれは誰かにおまかせして、今回はもう1つの参考情報としての共有についてもう少し考えてみたいなぁと。
これって、直接的に業務に関係ない場合もあったりするので、実は状況把握としての情報共有よりはるかに難しい気がしています。
仕事に役に立つかもしれないし、役に立たないかもしれない。でも、それを知っておくことで、チームやグループの幅は広がるといったものです。
ある人から見れば、「無駄な情報」かもしれないし、他の人がみれば「のどから手が出るほどありがたい」情報かもしれないわけです。
情報を集める方法と知らせる方法
気にする部分は大きく2つ。「情報を集める方法」と「情報を知らせる方法」です。
情報を集める方法といっても、RSS使えとか新聞読めとかそういうことではなく、ピックアップされた情報を集約する方法です。
これは出来るだけ簡単な方が良いのかなぁと思ってます。それこそ、Bookmarkletなどを利用してPostしたりTamblooぐらいになってしまうとさらにうれしい。
つまり、いちいちテキストエリアを目の前にして何を書くか考えてしまうことでハードルがあがってしまうわけで、この際、もうそういった事すらやめてしまう。
あとは、誰かがそれを再編集していく。どこかで繋がるものもあるかもしれないし、そうでないものもある。ちょっと、違うものもあるかもしれないから、それは別にしてしまうか削除する。
これをやっておくと、だいぶ情報の質が高まるわけです。編集という作業であれば、自分の意見を書く訳ではないので、誰でもできるわけです。そして何より、編集という作業を通して、その情報について考えるし詳しくなれる。ということで、グループで仕事としてローテーションでも良いかと。
次に情報を知らせる方法ですが、これはRSSで配信しておくことは重要だと思います。ここである程度取捨選択ができますからね。
それと、ホワイトボード。オフィスなどのどこかに書かれたものがアップされてれば、もしかしたら目につくということにもなるかも。最近のはやりの企業だと、マインドマップとかを会社の廊下とかに用意してますよね。
これは月間ASCIIに載っていたのですが、株式会社内田洋行では、同社が提供しているパーフェクトプロジェクションアダプター(PPA)というのを利用して、会社の壁に並べた複数のディスプレイに、誰でも簡単に自分のPCから情報を掲示できるそうです。
これで集約した情報の新着を載せていたら面白いだろうなぁと。
まとめ
ということで、情報共有について少し考えてみました。偉そうな理想を並べましたが、結局は、メールで情報共有、リアルに顔を突き合わせてコミュニケーションが一番盛り上がったりするものです。
おぉ、そういえば情報共有で思い出したのですが、FrindFeedというサービスを利用して、はてなのアクセス解析タグとDeliciousのWebAnalyticsタグを1つのRSSになるようにしています(WebAnalytics – FriendFeed)。
一応、ニュースだったりブログのエントリーを中心にしているので、わたくしめが勝手に不要なリンクは削除したり、コメントを入れていたりもします。なので、パブリックというよりは、かなり偏った感じの情報ですが。ご興味があれば是非。これも情報共有。

General, UserInterface »

[25 6月 2008 | Omniture Survey はコメントを受け付けていません。 | ]

24日にOmnitureの方で新しい機能がリリースされました。Omniture Surveyというもので、ざっとニュースリリースなどを読む限りはアンケートを簡単に行うことができ、それをアクセス解析のデータと結びつけることが出来るもののようです。(日本でのサービス開始は不明)
Omniture | Products | Conversion | Survey

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

General, Marketing, UserInterface »

[13 12月 2007 | AutopagerizeとPVを考える はコメントを受け付けていません。 | ]

Google や Frickr を延々とスクロールできるようになる Greasemonkey のスクリプト AutoPagerize 。慣れてくるとこれに対応していないサイトにイラっときてしまったり。
この 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の利用が増えてきているなかで、こういった部分の対応もベンダー側に考えていってもらう必要があるのかもしれませんね。

General, UserInterface »

[27 8月 2007 | サイト構成の業界標準は良い? はコメントを受け付けていません。 | ]

先日参加し、前回のエントリーでも取り上げたWebsig24/7 IA分科会で坂本さんが少し触れられた内容ですが、ある程度ネットで見られることが普通になってきている業界ではトップページからの構成が同じようになり、業界標準のようなものが出来上がりつつあります。
例えば坂本さんも取り上げられていた映画の告知サイトなどが分かりやすいと思います。

なぜ標準ができるのか?
これは私が関わっている業界でも起きているのですが、競合サイトを意識することで起きてしまうことも多いようです。
その原因はユーザーからの問い合わせからであったり、担当の上司であったりと様々なものが考えられます。「何であっちのサイトにあるのに、こっちにはないの?」という単純な質問が最終的に横を見てサイトを作ってしまうということに繋がってきてしまうのだと思います。
もちろん「新たに考えるのも面倒だし、同じものを用意しておけば良いんでないの?」といった感じもあるでしょう。そうして、同じようなメニューが増えてくることで、業界標準がなんとなく出来上がってきているのだと思います。
比較のユーザビリティ
ネットの利点の1つに情報比較のしやすさがあります。
ネットが一般的になってきた現在では、消費者が何かのアクションを起こす前に情報を集めて比較しておくことなどが当たり前のように行われています。それこそ家電量販店の流入は価格コムなどの比較サイトからの流入がかなりを占めるそうです。
同じ項目が並んでいることで比較をしながらサイトを渡り歩いているユーザーにとってはユーザビリティが向上します。経験上どのラベルのメニューには何が含まれているかがわかりますからね。
必ずしも良いわけではない
ただ、業界標準が情報整理の観点で必ずしも良いわけではないと思います。この辺りは難しいですね。ガラッと変えてしまうとユーザビリティを落としてしまう可能性があります。
よって、ちょっと面倒ですがJND以下の対応をしていくことなどもあると思います。ちょっとずつ変えながら最終的な方向へ向かわせる。そして1年ぐらいすると去年と比較するとずいぶんと変わっていたという感じです。この辺りは以前書いたJND以下で考えるユーザビリティを読んでみてください。
まとめ
実際に業界標準は色々なところで起きているようで、サイト構成だけでなく、サイトのデザインなども同じような形になってきているところが多いようです。ニュースサイトなどもその傾向が強いかもしれません。
この辺のユーザインターフェースをガラッと変えることは、担当からすると非常に勇気がいることなんですよね。
UIを変えることでユーザーが離れていってしまうかもしれない、変えないんだったら今ぐらいのユーザー数は確保できる。だったら、変えなくてもいいんじゃない。
多分そんなところからよりさらなる業界標準を作ってしまっているのかもしれませんね。

General, UserInterface »

[27 8月 2007 | IAとペルソナとマーケティングと はコメントを受け付けていません。 | ]

土曜日にWebSig24/7 IA分科会の勉強会に参加してきました。今回はネットイヤーの坂本さんによるIA(インフォメーション・アーキテクチャ)の説明と実際に水産庁のサイトマップを考えるというところまでをグループワーキングで行ってきました。
水産庁のサイトって始めて見たのですが、組織が運営しているサイトでまだまだこんなものが残っているんですね。ある意味化石です。保存しておいても良いと思います。

ペルソナ
事前にペルソナを考えるというお題があったため、私のグループではペルソナを中心に据えながらサイトマップ作成に励みました。
ただ、サイトゴールを考えると水産庁のサイトは「情報を正しく伝えること」だろうということで、結局作られたペルソナいったん別のところへ追いやられてしまいました。
このペルソナを使った手法、どうもサイトによって向き不向きがあるようです。ペルソナを使った手法についてはそれ程詳しくないので、実はそんな議論は済んでいるのかもしれませんが…
官公庁のような「情報を正しく伝えること」がゴールにあるようなサイトやサイトゴールとして掲げているものがターゲットを絞っていないもの、例えばポータルサイトなどではペルソナを利用しない方が良いのだと思います(実際にとあるポータルサイトの担当の方は使っていないということでした)。
この辺りは私のような何年も同じサイトに関わっている人間よりも、制作会社で色々なサイトに携わっている方の方が肌で感じているかと思います。
情報の整理とペルソナ
水産庁のサイトは見ていただいた通り、そもそも「情報の整理って何?」という状況になっています。
ということでは私のグループで行ったのは、どのような情報があるかの理解もあり、現状のTOPからリンクしている情報を分類しました。
そこでグループ分けをしたものを、再度ペルソナに照らし合わせて分類をし直すという作業を行いました。
ペルソナを当て込むと、もともと分類したカテゴリと違うところに分類されるものが出てくるんですね。こういったところがペルソナの効果?の1つなのかもしれません。
ちなみに講師の坂本さんは4つぐらいのペルソナで整理をしていました。今回の場合は複数ペルソナを利用して研磨的に使う方が、サイトのゴールから照らし合わせても良いのかもしれません。
マーケティングとIA
マーケティングとIAについて質疑応答時にありましたね。この辺りについては非常に難しいところだと思います。
企業のエゴ(マーケティングより)と消費者視点(IAより?)とのバランスが取れたサイトを作るということは非常に難しいもので、かつそれは状況によって変わってきます。
坂本さんはもちろんサイトを作る中でマーケティング的な話は行うこともあるし、そういった知識がIAにも必要であろうということでした。その上でマーケティング的な提案は運用を行いながらしていくと。
ここは非常に難しい部分ですね。エゴをどこまで取り入れるか。でも取り入れないと企業としての営みが成り立たない可能性もあります。
私の関わっているサイトでは、その部分をクリアするためにサイト構造を大きく2つに分けています。
情報として整理している部分とプロモーション・キャンペーンページ群です。この辺りを明確に分けることで、マーケティングとIAのバランスを取ろうと運用しています。
動線としてはプロモーションページをLP(ランディングページ)に据えて、顧客の理解が深まったところでより事務的な話が必要であればそちらに誘導するといったイメージです。

まとめ
今回は色々な刺激があったので、ちょっと散文になってしまいましたが、非常に面白い体験でした。実際に私は数年前はIAに近いことを行っていたこともあるのですが、現在は立場が違うため直接IAの業務に関わることはありません。
つまり半分趣味での参加だったのですが…。
ただIAを行うということは、サイトに求められているもの、背景、マーケティングなど全般を理解が求められるため、サイトを作るうえで非常に常用なポジションになることは確かだと思っています。
そういった意味でWEBサイト制作や運営に関わっている人間が知らないでは通れない部分であり、まだまだフレームワークの少ないIA分野を育てていく必要があるのだと思います。
そして今回の勉強会において、「情報」というところに注目し、画面という2次元的なものとフロー構造という3次元的なものを両方実現していくというIAの仕事は、非常に高度なスキルが必要なんだなぁ と改めて感じるものとなりました。

General, UserInterface »

[14 8月 2007 | JND以下で考えるユーザビリティ はコメントを受け付けていません。 | ]

ある日突然マウスのクリックの左と右が入れ替わったらどうでしょうか?多分ほとんどの方は最初数回は間違えてクリックしてしまうのでないでしょうか。
ユーザーインターフェースを考えていく上で、サイトのリピート性の箇所を変更する場合は、そういった慣れへの配慮をしておく必要があります。
慣れへの対応
ECサイトなどの場合は、リピート利用をしていただくことが多くなります。そういった箇所を変更する際、ロイヤリティの高いリピートユーザーへの配慮があります。
そのサイトが使いにくいかどうかは別にして、ロイヤリティの高いユーザーはそのユーザーインターフェースに慣れてしまっています。
よって、インターフェースがガラッと変わってしまうとミスを引き起こしやくすなり、サイトとしてはユーザビリティを向上させたつもりでも、「改悪」だなどと悪いイメージを持ってしまう可能性も出てきてしまいます。
こういった際にJNDを考慮してユーザーインターフェースを修正していくと良いと思っています。JNDとはJust Noticeable Differenceのことで、人が違いを認識するか・しないかの境目を指しています。(JNDとは)
例えば元々左上にあった「決定」ボタンをいきなり画面の右下に移動してしまったら混乱をしてしまう可能性があります。こういった際はまず両方の位置に置いていくなどをしてきます。その後、段階的に場所をシフトしていくと良いと思います。
訪問期間と修正タイミング
段階的に修正を行っていくにあたって、修正を行っていくタイミングも重要です。長からず、短からずです。これはサイトの平均訪問回数などを参考にしておくと良いと思います。
ロイヤリティの高いユーザーが数値上特定できるのであれば、それらのユーザーの平均訪問回数で求めていくのが良いと思います。
だいたい3回程度の訪問を目処に段階的に修正を行っていくことで、混乱を避けながら行っていくことが出来ると思います。
まとめ
今回の話は決して「JNDをきちんと測定して対応をした方が良い。」という話ではありません。
ある程度、そういったロイヤリティが高いであろうリピートユーザーへ配慮をしながら少しずつ修正をおこなっていった方が混乱が起きにくいということです。
逆にユーザビリティの根幹に関わらない部分や見せ方についてはJND以上の変化をつけた方が「対応しました感」が出て良い場合もあります。
良くも悪くもユーザーは学習します。悪いユーザーインターフェースだったとしてもです。
どこがユーザーインターフェースのクリティカルポイントであり、それを変更することで、ユーザーにどう変化があるか。そういった部分を考えながらユーザーインターフェースの設計をすることが良いユーザビリティを生む第一歩だと思います。

General, Marketing, UserInterface »

[23 7月 2007 | 目的を達成するツールでしかないこと はコメントを受け付けていません。 | ]

サイトを提供する側に立つと、企業側の論理といったようなものでサイト構築がされていく場合があります。もちろん、企業も売上をあげないと組織としてなりたたなくなってきてしまうので、有る程度はそういった「企業側の論理」を仕込む必要もあるわけです。
ただ、重要なことは
「ユーザーにとってWEBサイトは目的を達成するツールでしかないこと。」
です。
これはユーザーインターフェースを設計することでも同じなのですが「そのサイトをユーザーが使う目的をきちんと定義し、その為のツールを提供すること。」これが非常に重要です。
その定義があって初めて、それに合わせた「早さ」や「快適性」「情報」などの設計が必要になるのです。
このことはサイトを作り始めてしまうと見失いがちですが、マーケティング、UI設計など全てに関わってくることですので、是非これを再度見直してみてください。