<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>ユーザビリティ実践メモ＆コラム by ビービット</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/" />
    <link rel="self" type="application/atom+xml" href="http://www.bebit.co.jp/memo/atom.xml" />
    <id>tag:http://www.bebit.co.jp/memo/,2009-11-30</id>
    <updated>2010&#24180;03&#26376;08&#26085; 19:59</updated>
    <subtitle>ユーザ中心アプローチを用いたネットマーケティング支援会社「ビービット」では、徹底したユーザ分析と仮説検証型方法論により、成果の上がるウェブサイトの戦略・設計・構築を実現します。</subtitle>
<entry>
    <title>驚くほど伝わらない、サービスのメリット - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2010/03/post_171.html" />
    <id>tag:www.bebit.co.jp,2010:/memo//2.1527</id>

    <published>2010&#24180;03&#26376;08&#26085; 19:30</published>

    <updated>2010&#24180;03&#26376;08&#26085; 19:59</updated>

    <summary>ユーザ行動観察調査を実施すると、全力で訴求しているはずのメリットや強みが、驚くほ...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="コンテンツ" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>ユーザ行動観察調査を実施すると、全力で訴求しているはずのメリットや強みが、驚くほどユーザに伝わらないケースが多く見られます。<br />
伝わらない理由は様々ですが、今回は具体性が足りないために他社サービスとの違いが伝わらない、という例をご紹介します。<br />
</p>]]>
	<![CDATA[<h3>他社と比較されることを前提に考える</h3>
ウェブサイトで自社サービスのメリットを伝える際には、ユーザは競合他社サイトも同時に見ていることを前提として考える必要があります。
例えば学習塾や教材販売などを例にとると、多くの競合企業が同様のメリットを訴求しており、ユーザも「ある程度名が通っているところは大体どこも同じ内容なんだろう」という先入観を持っています。その中で抽象的な訴求をすると、ユーザは「やはりどこも同じ」と解釈し、それ以上違いを理解しようと努力はしてくれません。

<p><img alt="232_01.gif" src="http://www.bebit.co.jp/memo/232_01.gif" width="534" height="199" /></p>

<p>一方で、料金などはユーザにとって非常に具体的で他社と比較しやすい情報となります。ユーザ行動観察調査でも「サービス内容は大体同じ」という思いを強めたユーザが、料金だけで比較検討をする行動が多く見られました。</p>

<h3>具体性のある情報を提供することが重要</h3>
類似サービスが多く存在する中で、自社サービスのメリットをユーザに伝えるためには、情報の具体性が必要です。「講師の質が高いです」という例の場合、下記のような改善が考えられます。

<p><img alt="232_02.gif" src="http://www.bebit.co.jp/memo/232_02.gif" width="534" height="263" /></p>

<p>例えば講師の質を訴求したい場合には、質とは何を指しているのか、なぜ質が違うと言えるのかを具体的に書く必要があります。パーセンテージや年数など、数字を交えるとよりユーザから見て具体性が高まります。</p>

<p>ただしどんな内容でもとにかく具体的にすれば良いというわけではありません。たとえ他社と異なるポイントであっても、ユーザからニーズがない情報であれば、いくら具体的でも全く意味のない情報になってしまうため注意が必要です。</p>

<p><img alt="232_03.gif" src="http://www.bebit.co.jp/memo/232_03.gif" width="534" height="228" /></p>

<p>インターネット上で、他社との比較無しに検討することはもはやありえません。繰り返しにはなりますが、自社のサービスのメリットや強みをユーザに伝えるため、より具体的な情報を提供していくことが重要です。</p>]]>
    </content>
</entry>
<entry>
    <title>テキストリンクは「ユーザにわかる言葉」で - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2010/03/post_170.html" />
    <id>tag:www.bebit.co.jp,2010:/memo//2.1526</id>

    <published>2010&#24180;03&#26376;01&#26085; 11:19</published>

    <updated>2010&#24180;03&#26376;01&#26085; 11:18</updated>

    <summary>アンカーテキストによるリンクは、様々なリンク形式の中で最も古く、最も簡単で、最も...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="ウェブライティング" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>アンカーテキストによるリンクは、様々なリンク形式の中で最も古く、最も簡単で、最も慣れ親しまれているものと言えるでしょう。今回はそのテキストリンクの使い方について考えてみます。</p>]]>
	<![CDATA[<p>例えば食品の通販サイトで、特定のカテゴリの商品5つに対してリンクするような場合を想像してください。</p>

<p><img alt="図1. テキストによるリンク一覧" src="http://www.bebit.co.jp/memo/231_01.gif" width="400" height="175" /></p>

<p>いかがでしょう？　どれをクリックしたいと思いましたか？</p>

<p>ユーザ行動観察調査でよくあるパターンとしては、<strong>「とりあえず上から順番にクリックしてみる」</strong>か<strong>「一切クリックしない」</strong>です。<br />
ユーザは、リンクには気づいても（アイトラッキングをすると確実に視線は届いています）、クリックした先に何があるかが想像できないため、当てずっぽうの行動をするか、離脱してしまいます。</p>

<p>自社の製品に独自のネーミングを施して、他社との差別化を図るということ自体はよいのですが、その製品が何なのかが伝わらなければ意味がありません。</p>

<p>では、これではどうでしょうか？</p>

<p><img alt="図2. 説明を追加" src="http://www.bebit.co.jp/memo/231_02.gif" width="400" height="175" /></p>

<p>それぞれがどんな製品かを示すテキストを添えることで、ユーザの理解が進みそうな気がしますが、残念ながらこれでも充分ではありません。<br />
もちろん説明文までじっくり読むユーザもいますが、多くの場合、ユーザの視線は行頭のリンクのついた下線部分を走り、やはり先ほどと同じように離脱してしまいます。さらに言うと、リスト部分の行間が狭く、「見慣れないカタカナの固まり」になっていることも可読性を下げ、ユーザの意欲を下げる原因になっています。</p>

<p><img alt="図3. 視線の動き" src="http://www.bebit.co.jp/memo/231_03.gif" width="400" height="176" /></p>

<p>そもそものネーミングを変えられればいいのですが、そうも行かない場合、すぐできる改善としてこのような方法があります。</p>

<p><img alt="図4. 順番を逆にする" src="http://www.bebit.co.jp/memo/231_04.gif" width="400" height="196" /></p>

<p>その製品が何なのかを端的に示すテキストをリンクとして、行頭に移動しました（行間も少し広げています）。ユーザは自分に理解できる言葉で意欲や期待を高め、次のページに行くことができます。</p>

<p>また、販売データやアクセスログをもとに、こんな工夫もできます。</p>

<p><img alt="231_05.gif" src="http://www.bebit.co.jp/memo/231_05.gif" width="400" height="209" /></p>

<p>ランキング形式とすることで、ユーザは自分が気になるリンクが、自分以外のユーザにも支持されているという感覚を持つため、いっそう意欲が高まります。また、興味のなかったリンクに対しても「1番人気ならついでに見てみようかな」とクリックしたくなります。</p>

<p>説明無しで理解できる商品・サービスで、かつマスメディア広告で認知向上のための大キャンペーンを打つような場合は別ですが、一般的には、ユーザにわかりやすい言葉をリンクにしたほうが望ましい効果が得られるでしょう。</p>

<p>参考記事<br />
<ul><li><a href="http://www.bebit.co.jp/memo/2009/04/post_141.html">その表現、ユーザに分かりやすいですか？</a></li></ul></p>]]>
    </content>
</entry>
<entry>
    <title>【海外事例に学ぶ】フォーム入力におけるリアルタイムエラー表示のポイント - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2010/02/post_169.html" />
    <id>tag:www.bebit.co.jp,2010:/memo//2.1525</id>

    <published>2010&#24180;02&#26376;22&#26085; 22:07</published>

    <updated>2010&#24180;02&#26376;23&#26085; 09:21</updated>

    <summary>今回は、A List Apart掲載のルーク・ウロブレウスキ氏(※)による記事、...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="フォーム" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>今回は、<a href="http://www.alistapart.com/">A List Apart</a>掲載のルーク・ウロブレウスキ氏(※)による記事、<a href="http://www.alistapart.com/articles/inline-validation-in-web-forms/">“Inline Validation in Web Forms”</a>をご紹介します。当記事のテーマは、フォーム入力中のリアルタイムエラー表示（インライン・バリデーション）方法の最適化についてです。</p>]]>
	<![CDATA[<div style="font-size:small">※Wroblewski氏はフォームUIの設計・デザインに特化した書籍<a href="http://rosenfeldmedia.com/webinars/webforms/">”Modern Web Form Design”</a>も手がけるなど、最近はフォームUIの第一人者の呈をなしています。</div>

<p><br />
まずはフォーム入力におけるリアルタイムエラー表示がどのようなものか、以下のデモをご覧ください。</p>

<p><strong>【動画】：フォーム入力におけるリアルタイムエラー判定デモ</strong><br />
<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/hlU74LIPauo&hl=en_US&fs=1&"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/hlU74LIPauo&hl=en_US&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object></p>

<p>上記のようなリアルタイムエラー判定のできるフォームについて、ウロブレウスキ氏は21歳から49歳の22人の被験者でユーザ調査を実施しました。<br />
すると、通常の入力フォームと比べ、入力の成功率が22%向上し、エラー率が22%減少、入力時間も42%減少したとのことです。さらに、調査結果からは次のような2つの知見が得られています。</p>

<p><br />
<div style="font-size:large"><strong>【知見１】<br />
エラー判定は、ユーザにとって入力内容が自明でない（入力エラーとなりやすい）項目の場合に有効。<br />
</strong></div><br />
氏名や住所はユーザにとって入力内容が自明ですので、エラーになる確率は低くなります。一方、ユーザ名やパスワードは、既に登録されている可能性や、サイト独自の入力条件(Ex.半角英数6文字以上など)があり、ユーザにとっては入力ミスを犯しやすくなります。</p>

<p><img alt="リアルタイムエラーを実装すべきかどうか" src="http://www.bebit.co.jp/memo/memo/230-01-thumb.GIF" width="551" height="250" /></p>

<p>リアルタイムエラーを実装すべきかどうか、上記のように入力項目の性質を判断材料とすることができそうです。<br />
もしフォームの入力項目がユーザにとってすべて自明の場合(上記左図)は、実装コストを考慮して、通常のページ遷移のエラー判定方式を選択してもよいでしょう。</p>

<p><br />
<div style="font-size:large"><strong>【知見２】<br />
エラー判定結果をユーザに返すタイミングとしては、入力直後が良い。</strong></div></p>

<p>ウロブレウスキ氏は、ユーザの入力に応じたエラー判定の結果表示タイミングについても調査を行っています。実験は以下の3パターンのタイミングで行われました。</p>

<p><strong> [1]入力直後（AFTER）：</strong>正確には、次の入力フォームに遷移した直後に、前の入力フォームの判定結果を出す。<br />
 <strong>[2]入力中(WHILE)：</strong>入力中（1文字入力がある度）に判定結果を出す。<br />
 <strong>[3]入力前と途中(BEFORE AND WHILE)：</strong>入力フォームにフォーカスをあてた直後と入力中に判定結果を出す。</p>

<p><strong>【動画】タイミング別のエラー判定結果表示デモ</strong><br />
<object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/-Mb9G_LmD8E&hl=en_US&fs=1&"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/-Mb9G_LmD8E&hl=en_US&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object></p>

<p>上の動画を見た方はお分かりになると思いますが、結果は「[1]入力後（AFTER）」が最も効果的で、他より7-10秒早く入力を終えられたそうです。<br />
「[2]入力中(WHILE)」は、一文字一文字入力しながら判定結果を確認してしまうため、入力に時間がかかりました。<br />
また、「[3]入力前と途中(BEFORE AND WHILE)」では、[2]と同様の理由で入力時間もかかる上、入力途中で常にエラーが表示される(1,2文字入れただけで判定がはしる)ため、満足度の低下を引き起こしたとのことです。</p>

<p>このように、ユーザへのフィードバックが、タイミングによってはユーザ行動を妨害するノイズにもなり不快の要因ともなり得ます。このような細かいタイミング等は、ある程度実装が進んだ段階でないと気づきにくいかも知れませんが、極力設計する段階から、ユーザの行動に影響する重要ポイントの一つとして、定義し忘れないことが必要でしょう。<br />
また、実際にリリースする前(できればプロトタイピング時)に、簡単なユーザテストを行うことも強くオススメします。</p>

<p><br />
出展： Luke Wroblewski , "Inline Validation in Web Forms" (<a href="http://www.alistapart.com/">A List Apart</a>)Translated with the permission of A List Apart Magazine and the author[s].</p>]]>
    </content>
</entry>
<entry>
    <title>コンバージョン直前のユーザがつまずきやすいポイント - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2010/02/post_168.html" />
    <id>tag:www.bebit.co.jp,2010:/memo//2.1524</id>

    <published>2010&#24180;02&#26376;15&#26085; 11:21</published>

    <updated>2010&#24180;02&#26376;15&#26085; 12:26</updated>

    <summary>コンバージョン率向上を考えた場合、エントリーフォーム最適化（EFO）など、フォー...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="ナビゲーション" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>コンバージョン率向上を考えた場合、エントリーフォーム最適化（EFO）など、フォーム内の改善に意識が向きがちですが、実はフォームに入る前の段階にも改善すべき点が残されている場合があります。</p>

<p>今回はフォームに入る前のページでよくみられる、ユーザのつまずきやすいポイントをご説明します。</p>]]>
	<![CDATA[<h3>◆つまずきやすいポイント1</h3>
　-ユーザが予想していないキーワードで誘導している

<p>ウェブサイトを訪問しているユーザにとって、個人情報の入力などの手続き行為は主目的ではありません。商品を購入したり、申し込み後にサービスを利用することが本当の目的です。その目的に早く到達するため、手続き行為にはできるだけ手間をかけず、手早く終わらせようとする傾向が見られます。</p>

<p>ここで、注意が必要なのが手続きの途中に会員登録のステップがあるケースです。</p>

<p>ECサイトでは「購入」の手続きの途中で「既存/新規ユーザ」の振り分けが行われる場合がありますが、ユーザは手続きのステップとして「会員登録」が必要あることを必ずしも事前に意識していません。</p>

<p>手続きを「手早く終わらせたい」ユーザは「手続きの流れ」などの説明を読み飛ばす傾向があるため、唐突に会員登録の手順に行き当たり、困惑してしまいます。</p>

<p>例えば、「購入ボタン」を押した次のページで、「手続きの流れ」の説明と「新規会員登録」ボタンが用意されていても、説明を読み飛ばして進む（大多数の）ユーザにとって「購入」と「会員登録」との関係性は明確ではありません。</p>

<p>「なぜ会員登録しなくてはいけないのか？」、「購入するには「会員登録」は必須なのか」、「このステップを省略できないのか」などユーザを考えさせてしまいます。</p>

<p><img alt="会員登録ボタンを見て離脱してしまう" src="http://www.bebit.co.jp/memo/229-01.gif" width="568" height="295" /></p>

<p>弊社で行ったユーザ行動観察調査では一旦は購入すると決めたユーザが、「会員登録」ボタンで行き詰まり、「別に会員登録がしたいわけではない」と離脱してしまうケースが見られました。</p>

<p>そのサイト、サービスが「会員でなくても利用できる」場合やユーザが「頻繁に利用するわけではない」と考えているような場合には特に注意が必要です。</p>

<p>簡単な対策としてはボタンのラベル名を「会員登録」から「購入（会員登録）」とし、ユーザが意図している手続きとの関連性を明確することで、「申し込み手順」が読み飛ばされた場合でも支障が出ないようにする、といった方法が考えられます。</p>

<p><img alt="関係性を明確にした例" src="http://www.bebit.co.jp/memo/229-02.gif" width="568" height="145" /></p>

<h3>◆つまずきやすいポイント2</h3>
　-ユーザが予想していない振り分けをしている

<p>サービスによっては、複数のコースがあり、「コースごとに申し込み方法が違う」場合があります。ウェブサイト上では申込手続きに進む前にそれぞれの申し込み方法に振り分けを行う必要がありますが、多くのユーザは、コースごとに異なる申し込み方法が用意されている、ということを予想していません。そのため、真っ先に目についた「それらしい」ボタンやリンクに飛びついてしましい、正しい振り分け先に進めないケースが見られます。</p>

<p>以下の例では、AコースとBコース、それぞれの申し込み方法に振り分けを行っていたのですが、Bコースに申し込みたいユーザでも、誤って1番上のAコースの申し込みに入るケースが見られました。</p>

<p><img alt="振り分けが失敗している例" src="http://www.bebit.co.jp/memo/229-03.gif" width="568" height="347" /></p>

<p>元々、「コースごとに申し込み方法が違う」といったことをユーザは予想していないため、ユーザは自分が行いたい手続きに関するキーワード（「申し込み」や「購入」など）が目に入ると、すぐにそこを押してしまいます。</p>

<p>目的に向けて特定の情報やアクションボタンを探しているとき、ユーザの視界は非常に狭くなっており、周囲の説明文言に意識が向きにくく、振り分けの文言も見落とされてしまいます。</p>

<p>この場合の対策として、選択肢を横に並べることで、振り分けの関係性を明確にし、説明を読まなくても直感的に理解できるようにする方法がとれます。</p>

<p><img alt="横に並べることで振り分けを明確にする" src="http://www.bebit.co.jp/memo/229-04.gif" width="568" height="220" /></p>

<p>今回は、フォームに入る前につまずきやすいポイントを紹介しました。<br />
手続きの流れが既に頭に入っているサイト制作者側の目線だけで制作すると、どうしてもユーザが想定していないキーワードを使ったり誘導や分りにくい振り分けを行ってしまいます。</p>

<p>既に言い尽くされていることではありますが、設計ができた段階で、手続きに全く知識のない方に簡単なユーザビリティテストを行うことが手軽な対策としておすすめです。<br />
</p>]]>
    </content>
</entry>
<entry>
    <title>他媒体からユーザをスムーズに誘導するために、一貫性のある表現を - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2010/02/post_167.html" />
    <id>tag:www.bebit.co.jp,2010:/memo//2.1523</id>

    <published>2010&#24180;02&#26376;08&#26085; 15:03</published>

    <updated>2010&#24180;03&#26376;08&#26085; 19:52</updated>

    <summary>インターネットは企業活動のなかでますます重要度を増し、ダイレクトメール（DM)や...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="ユーザ理解・シナリオ" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>インターネットは企業活動のなかでますます重要度を増し、ダイレクトメール（DM)やテレビCMといったサイト外メディアとの連携も増えてきています。<br />
実践メモでも、サイト外メディアを考慮した情報提供について何度か取り上げてきました。<br />
【参考記事】<br />
<ul><br />
<li><a href="http://www.bebit.co.jp/memo/2009/01/post_128.html">ユーザの「気になっていること」を活用しよう</a></li><br />
<li><a href="http://www.bebit.co.jp/memo/2009/05/post_142.html">紙媒体との連携は大丈夫？</a></li><br />
</ul></p>

<p>今回は、特にサイト内での表現について、サイト外メディアとの連携に課題が見つかったケースと改善例をご紹介します。</p>]]>
	<![CDATA[<p>会員制のサイトなどでは、ユーザに紙のDMを送って、サイト内での申し込み手続きやキャンペーンに誘導することがあります。</p>

<p>このような場合、ユーザを申し込みやキャンペーンのページへスムーズに誘導することが非常に重要ですが、DMとサイト内の表現がずれているために、失敗してしまうケースがあるようです。</p>

<p>メディアが異なるとクリエイティブを制作・管理する方が異なる場合も多いため、特に連携が不十分になりやすい可能性があります。弊社のユーザ行動観察調査では、実際に以下のような失敗例が見つかりました。<br />
<h3>1. DMとサイトで名称や文言が違うために、同じものを指していることがユーザに伝わらない</h3><br />
<p><img src="/images/columntalk/column_167_fig1.gif" alt="図表1：DMとサイトで名称や文言が違うために、同じものを指していることがユーザに伝わらない" width="471" height="222"></p><br />
この例では、DMでの誘導文と誘導先のページで違うキャンペーン名称を用いていました。</p>

<p>すると、ユーザはサイト内で自分がDMで見て気になったキャンペーンがどこにあるか探せず、<strong>「DMのキャンペーン名と違ったので、自分が見たキャンペーンだとは思いませんでした」</strong>と発言しました。</p>

<p>当たり前のような結果ですが、サイト外メディアとの連携が不十分な場合や、サイト内での誘導を強めるために別のコピーを作成した場合など、異なる名称や文言を用いてしまうケースは十分起こりえます。</p>

<p>改善策としては、DMなどサイトへ誘導するメディアの内容を必ず確認し、誤解や見落としがないように一貫性のある表現を用いるべきでしょう。<br />
<h3>2. DMとサイトで表現の強さが違うために、同じものを指していることがユーザに伝わらない</h3><br />
<p><img src="/images/columntalk/column_167_fig2.gif" alt="図表2：DMとサイトで表現の強さが違うために、同じものを指していることがユーザに伝わらない" width="471" height="182"></p><br />
この例では、DMを用いてサイト内での手続きに誘導する際、DMでの誘導文で用いていた「至急」というワードを、誘導先のページでは用いていませんでした。</p>

<p>その結果、ユーザは手続きをどこから行って良いか分からず、<strong>「サイト内ではDMと違ってすぐに手続きが必要という感じがしなかったので、自分が見たものとは違う手続きだと思いました」</strong>と発言しました。</p>

<p>「至急」や「無料」、「限定」といったユーザを惹き付けるワードは、ユーザの印象に強く残る分、しばしば情報を探す手がかりとなります。サイト外でユーザを惹き付けるために使ったワードは同じようにサイト内でも使い、「DMで見たものと同じだ」とユーザに分かりやすいようにすると良いでしょう。<br />
<h3>3. DMとサイト内でデザインが違うために、同じものを指していることがユーザに伝わらない</h3><br />
<p><img src="/images/columntalk/column_167_fig3.gif" alt="図表3：DMとサイト内でデザインが違うために、同じものを指していることがユーザに伝わらない" width="591" height="182"></p><br />
この例では、DMを用いてサイト内での手続きに誘導する際、DMと形状や色使いが異なる見出しやバナーを用いていました。</p>

<p>その結果、ユーザは手続きを行う箇所を探す際に迷って時間がかかり、「DMとサイト内で色も雰囲気も違うので、全く目につきませんでした」と発言しました。</p>

<p>＜ウェブサイト：改善後＞では、DMと同じ色やフォント、画像を用いて見出しやバナーを作成しました。その結果、スムーズな誘導ができ、アイトラッキングツールを用いた分析でも、ユーザが迷わず視線を向ける傾向が見られました。</p>

<p>名称や文言はもちろん、色やフォントといった視覚的特徴が顕著に異なっていると、一見して違うものを指していると解釈してしまい、迷ってしまう可能性が高くなります。</p>

<p>ウェブサイトは能動的なメディアのため、ユーザに自ら情報を見つけ出してもらう必要があります。ユーザがサイト訪問前に接触するメディアでの表現をチェックし、同じ表現で誘導することで、よりスムーズに目的が達成できる、「使えるサイト」になることでしょう。</p>]]>
    </content>
</entry>
<entry>
    <title>目的を持ったユーザに、その他の情報を伝えるには？ - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2010/02/post_137.html" />
    <id>tag:www.bebit.co.jp,2010:/memo//2.1522</id>

    <published>2010&#24180;02&#26376;01&#26085; 10:22</published>

    <updated>2010&#24180;02&#26376;01&#26085; 10:53</updated>

    <summary>更新情報の確認など明確な目的を持ってサイトに定期的に来訪するユーザは、常にサイト...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="ユーザ理解・シナリオ" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>更新情報の確認など明確な目的を持ってサイトに定期的に来訪するユーザは、常にサイトの同じエリアを見て、同じように離脱しがちです。<br />
一方で、このように定期的にサイトを訪れてくれるユーザがいる場合、「彼らの目的達成を妨げることなく、都度他の情報も訴求したい」と考えるサイト運営者が多いのではないでしょうか。</p>]]>
	<![CDATA[<p>今回は、上記のような運営側の意図を達成するために用いられる、プッシュ型とプル型の2つの方法とそれぞれの特徴をご紹介します。</p>

<p><br />
<h3>１．【 プッシュ型 】 目的達成の過程で情報を提示する</h3>固定化しているユーザの視線の動きの途中に情報を挟むことで、ユーザに気づきを与えます。<br />
<dl><dt>■メリット</dt><dd>目に付きやすいので情報伝達の確実性が高く、一部分に手を加えるだけなので手間も少なくすみます。</dd><dt>■デメリット</dt><dd>ユーザにとっては目的遂行途中に予期せぬ情報を挿入されることになるので、内容によっては不快感を与えることでサイトに対してマイナスイメージを抱かれてしまう、または当初のユーザの目的達成の妨げになる危険があります。そのため、目的遂行中のユーザ心理に合った訴求であるかどうかを丁寧に配慮する必要があります。</dd><dt>■アドバイス</dt><dd>・オーバーレイなど動きのある表現であれば、より効果的な訴求が可能です。<br />
・目的途中での訴求が難しい場合は、目的達成後に他を見る余裕ができたところを狙うのも効果的です。詳しくは過去の実践メモ「完了ページやログアウト画面の効果的な使い方」をご覧下さい。</dd></dl><img alt="事例画像Yahoo" src="http://www.bebit.co.jp/memo/227_01-thumb.JPG" width="570" height="352" /></p>

<p><br />
<h3>２．【 プル型 】 サイトデザインを全体的に変化させる</h3>みなさんは季節やイベントごとにGoogleサイトのロゴが変わって、つい気になったり、思わずクリックしたりしたことはありませんか。</p>

<p><img alt="事例画像Google" src="http://www.bebit.co.jp/memo/227_02-thumb.JPG" width="570" height="173" /></p>

<p>弊社で行ったユーザ行動観察調査では、いつもはユーザの目的や行動が固定化しがちなサイトでも、デザインリニューアル後にサイトを訪れたユーザは、サイト全体を細かく閲覧することが度々確認されました。<br />
色調やイラストなど、全体的なサイトデザインの変化は、ユーザを「目的遂行のみを意識するモード」から「全体閲覧モード」に変えられる可能性が高いようです。<br />
<dl><dt>■メリット</dt><dd>無理やり情報を見せるわけではないので、情報内容によりユーザが不快感を抱くリスクが大幅に減少します。ユーザは自分の好きなタイミングでサイト閲覧を行えるので、ユーザの目的を阻害することもありません。滞在時間の増加にも繋がるでしょう。</dd><dt>■デメリット</dt><dd>ユーザに自ら情報を発見してもらう形になるため、サイト側が見せたい情報が伝わるかは不確実です。また、全体的なデザイン変更には一定の工数が必要になります。</dd></dl><img alt="まとめ表" src="http://www.bebit.co.jp/memo/227_03-thumb.JPG" width="474" height="181" /></p>

<p>プッシュ型・プル型、それぞれ長短あわせ持っていますので、状況に応じて使い分けてみましょう。</p>]]>
    </content>
</entry>
<entry>
    <title>第49回　強力なビジネスツールとなるグローバルサイトの要点【後編】 - コラム/トーク</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/column/column049.html" />
    <id>tag:www.bebit.co.jp,2010:/column//3.1521</id>

    <published>2010&#24180;01&#26376;28&#26085; 22:21</published>

    <updated>2010&#24180;01&#26376;28&#26085; 22:42</updated>

    <summary>◆本コラムのサマリ
			
		  
					サイトの成果を最大化するためには...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/column/">
	<![CDATA[<p><strong>◆本コラムのサマリ</strong></p>
			<p>
		  <ul>
					<li>サイトの成果を最大化するためには、ユーザシナリオを考慮することが前提だが、英文品質、サイトの構成、文章量といった形式面の最適化も必要となる。</li>
					<li>グローバルサイトを実際に実装し展開するには、社内や現地法人との調整も重要。</li>
		  </ul>
			</p>

<h4>前回</h4>
<p><a href="http://www.bebit.co.jp/column/column048.html">前編では、</a>自社の製品・サービスがターゲットとするユーザを考慮することの重要性と、サイトの構造の考え方について紹介しました。<br/>
今回は、サイト制作にあたっての注意点および進め方をご紹介します。</p>


<h4>【ポイント1】　外国人の特徴を考慮したサイト形式</h4>
<p>製品やサービスの魅力を伝え、ユーザをビジネスゴールに導くには、ユーザ像やユーザニーズを明らかにし、ユーザシナリオを考慮することがウェブサイト制作において重要ですが、これらに加え、サイトの形式面にも踏まえておくべきポイントがあります。</p>

<p>文化や言語、ユーザの行動特性の違いから、英語のケースでは以下の点が形式上のポイントとなります。</p>

<p>
(1) 英文のネイティブチェックは必須<br/>
(2) 先進的なイメージ訴求も重要<br/>
(3) コンテンツエリアは適度な横幅を確保する<br/>
(4) 文章量を削りすぎない<br/>
(5) リンクは左寄せで配置する<br/>
(6) 「問い合わせリンク」はヘッダに設置する<br/>
</p>

<h5>(1) 英文のネイティブチェックは必須</h5>

<p>これは実際にビジネス上でネイティブユーザに接する機会がないと認識しづらいのですが、企業のグローバルサイトでは非常に重要です。
</p>

<p>日本人でもある程度のスキルがあれば日本語を英文化することは可能です。しかし、どうしてもネイティブが見ると拙い英語となっていることがあります。
</p>

<p>例えば、日本語サイトのコンテンツを以下のように英訳したとしましょう。</p>

<p>「基本的にサポートサイトを本社で運用し、各国はそこへアクセスする。」<br/>
→The headquarter administer a support website, each country access to it, basically.</p>


<p>ネイティブスピーカーからすると、以下の点で疑問を感じるでしょう。</p>
<ul>
<li>用語がおかしい　（「運用」はoperate、「アクセスする」はlinks to itが正しい）</li>
<li>basicallyが最後にある</li>
</ul>


<p>グローバルサイトでは、ユーザの最初の接点が企業ウェブサイトであることも少なくありません。その場合、ユーザの印象は接するウェブサイトによって形成されることになります。そのため、サイトの英文品質の低さは企業イメージや信頼性の低下に直結し、ビジネス機会を逃す結果となってしまいます。</p>

<p>同様の観点で、ヨーロッパのサイトではアメリカ英語ではなくイギリス英語の表現とする必要があります。</p>



<h5>(2) 先進的なイメージ訴求も重要</h5>


<p>海外の大手サイトでは画面全体にわたるブランドパネルや、動きのある画面など、新しい見た目の要素が日本よりも早く実装される傾向にあります。</p>

<p>ニューヨークやシンガポールで実施したBtoBサイトのユーザ行動観察調査では、ユーザの多くがブランドパネルが小さいサイトに対して「古い」という印象を持ちました。</p>

<p>必ずしも先進性の訴求が重要ではない業種でも、過剰とならない範囲で画面全体を使ったブランド訴求や動きのあるコンテンツなどを採り入れるとネガティブな印象を持たれることは少ないでしょう。</p>

<p>ただし、先進性を追求するあまりファイルサイズが大きくなってしまうと回線速度が遅い地域では不便になります。そこで、SAMSUNGサイトのようにファイル容量が小さいバージョンも用意すると良いです。</p>

<p><img src="/images/columntalk/column_049_fig1.jpg" alt="図表1：海外サイトトップページのトレンドは大きなブランドパネル" width="560" height="290"></p>


<h5>(3) コンテンツエリアは適度な横幅を確保する</h5>

<p>アメリカ人やオーストラリア人、シンガポール人などを対象としたユーザ行動観察調査において、英文コンテンツの横幅がやや狭いサイト（3カラムで英文のエリアが380ピクセル程度）を閲覧した20代から30代のユーザが、「狭い」、「右側のエリアが邪魔だ」という反応を示しました。
</p>
<p>新聞といった紙メディアよりインターネットに慣れ親しんだユーザにとっては、英文エリアの幅が狭いと読みづらく、印象を損ねてしまう恐れがあります。
</p>

<p>New York Timesのサイトでも、トップページは細めのカラムが存在する新聞調のレイアウトですが、記事ページでは横幅が広く取られています。この程度の幅を確保すれば問題はないでしょう。</p>

<p><img src="/images/columntalk/column_049_fig2.jpg" alt="図表2：ニューヨークタイムズサイトのレイアウト" width="560" height="290"></p>

<h5>(4) 文章量を削りすぎない</h5>

<p>日本語のサイトの場合、「文章は少なめとする方が良い」と言われます。（ニュースサイトに代表されるような読み物メインのサイトについてはやや事情は異なります）<br/>
ディスプレイ上で文章を読む速度は印刷した文章と比べて25％遅くなるという調査結果もあることから、日本語のサイト設計の際はユーザの「斜め読み」を踏まえた構成にすることが少なくありません。
</p>

<p>しかし、アルファベットをベースとした言語の場合、文字の構造が単純で視認性が高いため、文章量が多くてもユーザはしっかりと読んでいきます。日本語の場合より文章が多めのページ構成となってもそれほど問題はありません。</p>

<p><img src="/images/columntalk/column_049_fig3.jpg" alt="図表3：英文では文章が多い構成でも大丈夫" width="560" height="290"></p>



<h5>(5) リンクは左寄せで配置する</h5>

<p>日本のサイトでは、あるカテゴリ内のリンクを一部だけ表示して「その他はこちら」というリンクをエリアの右下に配置することがあります。</p>

<p>しかし、英語サイトでこの配置にすると、ユーザが気づかない場合があります。
</p>

<p>英語圏のユーザの場合、右寄せとなっているコンテンツに慣れていないため、リンクは左寄せとする方が良いでしょう。</p>

<p><img src="/images/columntalk/column_049_fig4.gif" alt="図表4：リンクの配置" width="560" height="236"></p>


<h5>(6) 「問い合わせリンク」はヘッダに設置する</h5>

<p>海外サイトでは、ヘッダ部分に「Contact Us」というリンクが配置されているものが多くあります。</p>

<p>問い合わせがサイトのゴールとなるBtoBサービスを対象にアメリカで実施したユーザ行動観察調査においても、問い合わせ時にはヘッダを探すユーザが多く存在しました。
</p>

<p>コンテンツエリア内にContact Usへのリンクを設置することも重要ですが、最終ゴールが問い合わせとなるBtoBサイトの英語版では、ヘッダに「Contact Us」リンクを設置することは必須となります。</p>

<p><img src="/images/columntalk/column_049_fig5.gif" alt="図表5：問い合わせリンクはヘッダに配置" width="560" height="245"></p>



<h4>【ポイント2】　サイト制作をスムーズに進めるために</h4>

<p>グローバルサイトを制作する場合、本社内のみならず、海外担当部署や現地法人との調整が発生します。現地法人においてサイトの運用に手が回らないところでは本社側の案に従って運用負荷が軽減されることを望む傾向にありますが、独自にウェブサイトに力を入れているアメリカやヨーロッパは、日本側から単純にサイト構成案を提示してもまとまりません。</p>

<p>アメリカではウェブサイトが充実していないと会社自体が信頼されないという固有の背景があり、現地法人側も試行錯誤を重ねて培ってきた経験とウェブサイト運営に対する自負があります。また、ヨーロッパでは美術的な面が重視される傾向も加わってきます。</p>

<p>この点は各企業ごとの事情にもよりますが、グローバルサイトリニューアルにおいては、プロジェクト初期からアメリカやヨーロッパなどの主要地域の担当者を巻き込み、また運用面を含め具体的な実現イメージを共有しながら進めることが成功の秘訣です。</p>



<h4>まとめ（前編、後編を通して）</h4>
<p>企業のグローバルサイト（海外事業向けサイト）については、日本語サイトをそのまま英訳するだけでは不十分です。利用者となる各国のユーザをそれぞれ分析しユーザシナリオを考えてウェブサイトのコンテンツ、サイト構造、必要な言語を検討しなければ成果をあげるサイトとすることはできません。</p>

<p>また、ユーザが外国人であるがゆえに、サイトの形式面でも日本向けサイトとは異なる注意点を意識しなければなりません。</p>

<p>これらの点を踏まえたうえで、早い段階から社内や現地法人と調整し進めていくことが、グローバルサイトの成果創出を実現するカギとなるのです。</p>
]]>
	グローバルサイト制作にあたっての注意点や、制作の進め方を紹介します。

    </content>
</entry>
<entry>
    <title>わかりにくい1クリックよりも、わかりやすい2クリック - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2010/01/12.html" />
    <id>tag:www.bebit.co.jp,2010:/memo//2.1520</id>

    <published>2010&#24180;01&#26376;25&#26085; 22:06</published>

    <updated>2010&#24180;01&#26376;25&#26085; 22:51</updated>

    <summary>トップページに多くの要素を盛り込まねばならず、情報の整理に悩んでいる方も多いので...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="ナビゲーション" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>トップページに多くの要素を盛り込まねばならず、情報の整理に悩んでいる方も多いのではないでしょうか。そんな時、ユーザの文脈を考慮することで情報整理方法が見えてきます。<br />
</p>]]>
	<![CDATA[<h3>BtoB向け製品を主に扱うメーカーサイトの例</h3>

<p><img alt="BtoB向け製品を主に扱うメーカーサイトのトップページ" src="http://www.bebit.co.jp/memo/226-01.gif" width="525" height="265" /></p>

<p>上の画面例はBtoB向け製品を主に扱っているメーカーサイトのトップページです。各製品カテゴリへのテキストリンクがトップページに配置されており、弊社のユーザ行動観察調査では、はじめてこのサイトを訪れるユーザが「何かごちゃごちゃしている」と言いながら、どこをクリックすべきか迷う傾向が見られました。</p>

<p>そこで、 トップページでは大まかに振り分け、次の階層で各製品カテゴリを選ばせるという図2のような画面に変更したところ、ユーザは目的の製品ページへスムーズに到達できるようになりました。</p>

<h3>改善後の画面</h3>

<p><img alt="トップで振り分け2階層目でカテゴリ選択" src="http://www.bebit.co.jp/memo/226-02.gif" width="525" height="486" /></p>

<p>目的のページに達するまでのクリック数は少ないほうがよいと言われますが、クリックを減らすことが目的になってユーザを迷わせてしまっては本末転倒です。</p>

<p>改善前の画面では、初めてのユーザに対し、専門的な製品カテゴリ名を文字だけで見せてしまったために、判断がつきにくいという問題がありました。</p>

<p>一方、改善後は、まずトップページでの選択肢を絞り、わかりやすい言葉でいったん振り分け、その次の画面ではカテゴリ名に製品画像を付け加えることで、ユーザが直感的に自分の探しているカテゴリを選べるようにしました。</p>

<p>この結果、改善画面案では個別製品ページまでのクリック数は増えましたが、心理的な負担が小さくなったため、ユーザがクリックの数についてネガティブな印象を持つことはありませんでした。</p>

<p>このように、サイトに来訪するユーザが置かれている文脈によってトップページの情報の整理方法は変わってきます（逆に、常連客だけが訪れるようなサイトであれば、ニーズの高い機能やコンテンツへのショートカットを置くことが望ましいと考えられます）。</p>

<p>あなたのサイトがユーザにとって最適な情報整理ができているか、見直してみてはいかがでしょうか。<br />
</p>]]>
    </content>
</entry>
<entry>
    <title>ユーザを混乱させない表組みのコツ - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2010/01/post_68.html" />
    <id>tag:www.bebit.co.jp,2010:/memo//2.1519</id>

    <published>2010&#24180;01&#26376;18&#26085; 09:30</published>

    <updated>2010&#24180;01&#26376;18&#26085; 10:05</updated>

    <summary>ウェブサイト制作において、多くの情報をいかに整理してユーザに伝えるかは重要なポイ...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="レイアウト" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>ウェブサイト制作において、多くの情報をいかに整理してユーザに伝えるかは重要なポイントの1つです。よく使われる方法として表組みがありますが、今回は実際の事例をもとにしたケーススタディを通じて、ユーザを混乱させない表組みのコツをご紹介します。</p>]]>
	<![CDATA[<p><strong>ケーススタディ</strong> 　あるイベントの申込サイトでは、「開催スケジュール」というページでイベントの開催日程表を掲載していました（表1参照）。皆さんならこの日程表をどのように改善するでしょうか？</p>

<p><img alt="イベント開催日程表（改善前）" src="http://www.bebit.co.jp/memo/225-1.GIF" width="545" height="359" /></p>

<p>表１はよく見かける表組みの例ですが、実際にユーザの立場に立ってこの表を使用してみると、いくつかの問題点があります。</p>

<h3>同種の情報をユーザは区別できない</h3>
表1の問題点として、
<ol><li>日付という同種の情報を多く掲載しているため、ユーザには各情報が何の日付を意味しているのか区別できず、分かりにくい</li><li>列数が多いために、セル内に折り返しが発生し、読みにくい</li></ol>
ことが挙げられます。
特に、1つ目の問題点は、表が縦に長い場合にユーザを混乱させる要因の一つになります。なぜなら、画面サイズに収まりきらないほど表が縦に長い場合、下にスクロールしていくと「開催日」などの項目名が画面から消えてしまい、各日付が何を意味するのかユーザは分からなくなってしまうからです。

<h3>ユーザが見たい情報を強調した表組みにする</h3>
これらの問題点を踏まえて、表1を改善してみます（表2参照）。

<p><img alt="イベント開催日程表（改善案）" src="http://www.bebit.co.jp/memo/225-2.GIF" width="553" height="386" /></p>

<p>改善案のポイントは次の2点です。<br />
<ol><li>ユーザが一番見たい情報を強調する</li><ul><li>ユーザがこのページで一番見たい情報は「開催日」であるため、「開催日」とそれ以外の情報を区別</li><li>「開催日」を一番左の列に置き、フォントサイズも大きくする</li></ul><br />
<li>ユーザにとっての補足情報は「備考」にまとめ、表の列数を削減</li><ul><li>補足情報を1列にまとめた上で、ユーザが各日付の意味を分かるように、セル内で【申込期間】などのキャプションを付ける</li></ul></ol><br />
改善案では、開催スケジュールを見に来たユーザが下にスクロールしても、左列の日付が何を意味するのか分からず混乱することはなくなります。</p>

<p>表組みは、情報を整理して見せる際に一覧性が担保できるというメリットがあります。しかし、項目数・同種の情報が多い場合には、安易に表組みを使うとユーザの混乱を引き起こす可能性があります。そういった場合には、ユーザが見たい（もしくは見せたい）情報と、その他の情報とを区別し、強弱を付けた表組みをする必要があります。</p>

<p>情報を整理する際は、ユーザがどの情報を求めているのかを考慮し、きちんと強弱を付けることが重要です。</p>]]>
    </content>
</entry>
<entry>
    <title>診断ツールにおける選択肢の作り方 - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2010/01/post_166.html" />
    <id>tag:www.bebit.co.jp,2010:/memo2//2.1518</id>

    <published>2010&#24180;01&#26376;12&#26085; 09:33</published>

    <updated>2010&#24180;01&#26376;17&#26085; 15:51</updated>

    <summary>ウェブサイトにおいてユーザにいくつかの質問に答えてもらい、その結果として当該サイ...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>ウェブサイトにおいてユーザにいくつかの質問に答えてもらい、その結果として当該サイトが提供するサービスを紹介する「診断ツール」が存在します。旅行会社サイトで好みのツアーを診断したり、証券会社サイトで適切な投資スタイルを診断するなど、様々な場面で用いられています。<br />
今回はこの診断ツールで、ユーザに回答してもらう質問について考えてみたいと思います。</p>]]>
	<![CDATA[<p>近年、ユーザニーズは多様化しており、通り一遍の質問内容ではそのニーズを汲み取りきれず、ユーザが十分納得できる診断結果にならない可能性があります。<br />
先程述べたツアー診断など、ユーザの好みが強く表れる診断ではこの点が特に問題になることがあります。ここでは、同じくユーザの好みが強く表れる分野として、ブライダルでの例をご紹介します。</p>

<p>弊社が、とある結婚式場紹介サイトで行ったユーザ行動観察調査でのことです。ユーザの好みにあった結婚式プランを診断するサービスを設計するために、質問に対する選択肢として下記の2種類を用意しました。</p>

<p><img alt="2つの選択肢の例" src="http://www.bebit.co.jp/memo/170.GIF" width="566" height="198" /></p>

<p>その結果、Aに比べてBの選択肢に好印象をもったユーザが見受けられました。具体的には、「選びやすい」や「自分の気持ちを汲み取ってくれている気がするので、診断結果に信頼がおける」といった意見が得られたのです。<br />
本例からも分かるとおり、ユーザニーズを上手く汲み取る選択肢を用意することで、選びやすさ向上・結果への信頼性向上といったメリットが生まれ、ユーザとの良好なコミュニケーションにつながる可能性があります。</p>

<p>診断ツールの選択肢をさらに工夫することによって、ユーザに気づきを与え、新たな価値観を提案できることもあります。上記のブライダルの例で言えば、Bの一番上の選択肢を見て「2人だけでひっそり結婚式を挙げるのもいいかも知れない」と気づかされるユーザがいるかも知れません。<br />
このようなツールを用いる際は、今いちどユーザの目線に立って、自分の気持ちを反映させやすい選択肢になっているかを考えてみてはいかがでしょうか。</p>]]>
    </content>
</entry>
<entry>
    <title>複数カラムレイアウトをどう活かすか - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2010/01/post_165.html" />
    <id>tag:www.bebit.co.jp,2010:/2009mttest/memo//2.1280</id>

    <published>2010&#24180;01&#26376;04&#26085; 07:00</published>

    <updated>2010&#24180;01&#26376;11&#26085; 14:28</updated>

    <summary>本実践メモでも以前に取り上げたように、ここ数年、横幅900px以上を採用するサイ...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="レイアウト" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>本実践メモでも以前に取り上げたように、ここ数年、横幅900px以上を採用するサイトが増えてきています。</p>]]>
	<![CDATA[<p><a href="http://www.bebit.co.jp/memo/2008/12/900px.html">画面横幅を900px以上にするメリットとデメリット。右端が欠けることに注意</a></p>

<p>横幅の拡大によって、情報を掲載できるスペースは拡大し、実現できる表現の幅も広がります。<br />
もちろんそれらは喜ばしいことですが、自由度が増すからこそ、効果的なスペースの使い方をきちんと考えることがますます重要になります。今回はカラムを複数に切ったレイアウトについて、スペースをどのように活かすべきかを考えてみたいと思います。</p>

<h3>複数カラムの使用は、メッセージを分散させる</h3>
カラムを複数に切って情報を提供することは、1つのページに複数の役割を与えることを意味します。
もちろん、ナビゲーションなどページにとって必要な機能もありますが、より多くのエリアを
定義することはそのページが持つメッセージをぶらしてしまう危険性があることをまずは認識すべきです。
ユーザにとっても、情報が分散されて配置されることで視線の移動が多くなり、情報収集が煩雑になってしまいます。ユーザは同時に複数の情報を、集中して見ることはできないのです。

<h3>ユーザは基本的にメインカラムを見る</h3>
最近よく見られるカラムを3つに切ったレイアウトでは、エリアを以下のように使い分けていることが多いようです。
<ol><li>メインの情報エリア</li><li>ナビゲーションエリア（左/右ナビゲーションと呼ばれるエリア）</li><li>関連情報・広告エリア</li></ol>
<img alt="Yahoo ! Japan トップのレイアウト例" src="http://www.bebit.co.jp/memo/223-1.GIF" width="583" height="501" />

<p>ユーザも無意識のうちに、このような使い分けを認識しているように感じられます。</p>

<p>ユーザは基本的に、何らかの目的を持ってウェブページを訪問しており、必要な情報を探そうとしています。そして、必要な情報は（１）メインの情報エリアにあるはずだと考え、視線や意識はメインの情報エリアに集中するという現象が、弊社のユーザ行動観察調査で見られています。<br />
そのため、<br />
<ul><li>確実に伝えたい情報はメインの情報エリアに配置すること</li><li>各カラムの横幅比の調整などによって、メインの情報エリアがどこであるのかを明確にすること</li></ul>が重要です。</p>

<p>ここでは上図のような3カラムレイアウトを例に説明しましたが、ページの目的と上記3種類のエリアの使い分けを意識することで、以下のようなレイアウトも検討可能です。<br />
<ul><li>本実践メモのように1カラムレイアウト（メインの情報エリアのみ）とし、読み物ページとして役割を特化</li><li>Yahoo! ニュースのようにメインの情報エリアを広く取り、右カラムに他のニュースへのリンク（ナビゲーション）や広告を配置</li></ul><br />
<img alt="Yahoo ! ニュースのレイアウト例" src="http://www.bebit.co.jp/memo/223-2.GIF" width="565" height="381" /></p>

<h3>ユーザのモードを考慮して、カラムの使用を検討しよう</h3>
上でも少し触れたように、ユーザが興味のある情報を探したり、選んだりするページ（例えば、Yahoo! Japan トップ）と、特定の情報を集中して見るページ（例えば、Yahoo! ニュースの個別記事）では、最適なページレイアウトは異なります。なぜなら、ページを見ているユーザのモード（ユーザがそのページに期待しているもの）が異なるからです。

<p>前者では、そのページのメインの情報を伝えるエリアとは別に、関連情報や広告を掲載するエリアを設けておくと、ユーザが関連情報にも関心を持ってくれる可能性が高くなります。（Yahoo! Japan のトップページは、この効果をうまく利用して広告を訴求していると言えます）<br />
一方、後者にあたるページでは下手にカラムを切らずに、メインの情報エリアを広く取り、広いスペースを活用した情報提供を行った方がよいでしょう。</p>

<p>ウェブページのレイアウト、情報の配置に悩んだ際に参考にしていただければ幸いです。</p>]]>
    </content>
</entry>
<entry>
    <title>プルダウンメニューのページ遷移は自動？手動？ - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2009/12/post_164.html" />
    <id>tag:www.bebit.co.jp,2009:/2009mttest/memo//2.1281</id>

    <published>2009&#24180;12&#26376;21&#26085; 06:00</published>

    <updated>2010&#24180;01&#26376;11&#26085; 15:54</updated>

    <summary>プルダウンメニューで項目を選択して、ページ遷移（表示変化）を待っているが何も起き...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="ナビゲーション" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>プルダウンメニューで項目を選択して、ページ遷移（表示変化）を待っているが何も起きない。ユーザ行動観察調査ではこんな光景がよく見られます。<br />
今回は、ページ遷移を伴うプルダウンメニューでよく見かける「ユーザのイメージと異なる挙動をする」設計について考えてみたいと思います。</p>]]>
	<![CDATA[<p>ウェブサイトを利用していて、以下のような経験はないでしょうか？<br />
<ol><li>プルダウンメニューで項目を選択し、次のページへ遷移するのを待っているが何も起きない</li><li>プルダウンメニューで項目を選択すると、勝手に次のページへ遷移してしまい、違和感を感じた</li></ol></p>

<p>特に日常的に使用されるサイトでは、ユーザの期待を裏切らない挙動が求められます。以下の例を参考に、ユーザ心理への配慮について考えてみたいと思います。</p>

<p>ページ遷移を伴うプルダウンメニューは、<strong>「Go」ボタンなどを設置し、ユーザに手動でページ遷移を行ってもらうのが一般的</strong>です。これは、ユーザが誤った項目を選択してしまった場合に、意図しないページに遷移してしまうことを防ぐためです。<br />
また、個人情報が表示されるAmazonの管理画面（下図）などでは、意図せずに表示が切り替わってしまうとユーザに不安を与えてしまう可能性があるため、「Go」ボタンで確実に目的の結果を表示させるという対応が好ましいと考えられます。<br />
ウェブサイトでは、ユーザが意図した通りの動作が起こることが重要です。<br />
<img alt="Amazon.co.jpのプルダウンメニューの例" src="http://www.bebit.co.jp/memo/222-1.GIF" width="343" height="158" /></p>

<p>一方で、自動的に遷移した方が好まれるケースもあると考えられます。以下のような場合が当てはまります。<br />
<ul><li>利用頻度が高い場合（毎日、同じ選択を行うケースなど）</li><li>誤って選択する可能性が低い場合（選択肢が少ないケースなど）</li></ul></p>

<p>日々の生活の中で頻繁に使う機能の場合、そのたびに「Go」ボタンをクリックすることはユーザにとって面倒です。GMailのメール管理機能はその一例と言えます。<br />
<img alt="Gmailのブルダウンメニューの例" src="http://www.bebit.co.jp/memo/222-2.GIF" width="244" height="252" /></p>

<p>また、プルダウンメニューの選択肢数が2~3項目のように少ない場合、誤った選択肢を選んでしまう可能性が低いため、自動的にページを遷移させても大きな問題はないと考えられます。<br />
このようにユーザの<strong>サイト利用の文脈、状況</strong>を考えると、自動的にページを遷移させても問題ないケースもあることが分かります。</p>

<p>ユーザの立場に立った小さな気遣いの積み重ねがユーザの満足度を向上させ、継続的に利用されるウェブサイトの実現につながるはずです。</p>

<p>あなたのサイトのプルダウンメニューがユーザにとって期待通りの挙動となっているか、見直してみてはいかがでしょうか？</p>

<p>実践メモの配信は、今年は本日で最後となります。来年もどうぞよろしくお願いいたします。</p>]]>
    </content>
</entry>
<entry>
    <title>写真・画像の具体的な情報は、ユーザに与える影響が大きい - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2009/12/post_163.html" />
    <id>tag:www.bebit.co.jp,2009:/2009mttest/memo//2.1282</id>

    <published>2009&#24180;12&#26376;14&#26085; 17:52</published>

    <updated>2010&#24180;01&#26376;11&#26085; 14:29</updated>

    <summary>最近は特にECサイトなど、画像を豊富に掲載して、見ていて楽しい魅力的なサイトが増...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="ECサイト" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>最近は特にECサイトなど、画像を豊富に掲載して、見ていて楽しい魅力的なサイトが増えてきています。<br />
しかしサイトの魅力を増す画像も、使い方を誤るとユーザをミスリードしてしまうことがあります。<br />
今回は画像活用時の注意点をご紹介します。</p>]]>
	<![CDATA[<h3>写真・画像の具体的な情報は、ユーザに与える影響が大きい</h3>

<p>ユーザはウェブサイトを閲覧する際、目につくものを拾い読みする傾向が強く、特に注目されやすいのが「写真」と「見出しのキーワード」です。<br />
そのため、アイキャッチ画像とキーワードをあわせて配置するレイアウトは、一般的に非常に効果的です。<br />
しかし、画像の与えるイメージは非常に具体的であるため、ユーザは画像の印象に強く引きづられてしまいます。<br />
実際に弊社の調査で、照明やインテリアを探していたユーザが下図右のレイアウトを見て、読み飛ばしてしまうケースがありました。</p>

<p><img alt="ユーザは、画像の与えるイメージに引きずられる" src="http://www.bebit.co.jp/memo/20091214_001.png" width="566" height="162" /></p>

<p>上のケースの場合、単純に画像を削除してリンクを目立たせることでも、十分にユーザの誤解を避けることが可能でした。また画像を配置する場合でも、照明やインテリア用品を含めた室内写真の画像を用いることで、ユーザに情報が適切に伝わりやすくなりました。</p>

<p>サイト運営時は、常に最適の写真・画像素材があるわけではないケースも多くあると思います。しかし画像がユーザに与える影響は非常に大きいです。<br />
「ただのアイキャッチだから」と安易に選択せず、その画像がユーザに伝えたい内容として適切か改めて一度考えてみることで、よりユーザにとって使い勝手の良いサイトを作ることが可能になります。</p>

<p>※参考：ベルメゾンネット（<a href="http://www.bellemaison.jp/" target="_blank">http://www.bellemaison.jp/</a>）<br />
カテゴリを示す画像にいくつも商品を配置し、カテゴリ内に豊富に商品があることを印象付けている。</p>

<p><img alt="ベルメゾンネットでは、カテゴリを示す画像にいくつも商品を配置し、カテゴリ内に豊富に商品があることを印象付けている。" src="http://www.bebit.co.jp/memo/20091214_002.png" width="556" height="412" /></p>

<p><br /><br /><br /></p>]]>
    </content>
</entry>
<entry>
    <title>入力フォームでの「郵便番号」の意外な盲点 - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2009/12/post_162.html" />
    <id>tag:www.bebit.co.jp,2009:/2009mttest/memo//2.1283</id>

    <published>2009&#24180;12&#26376;07&#26085; 12:46</published>

    <updated>2010&#24180;01&#26376;11&#26085; 14:29</updated>

    <summary>登録や申し込みページの入力フォームにおいて、郵便番号を入力すると住所欄が自動入力...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="フォーム" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>登録や申し込みページの入力フォームにおいて、郵便番号を入力すると住所欄が自動入力される機能は、ユーザの入力負荷を軽減する便利な機能です。実はこの機能、正しく郵便番号を入力してもある条件下ではエラーとなってしまうことがあることをご存知でしょうか。今回は入力フォームでの「郵便番号」の意外な盲点についてご紹介します。</p>]]>
	<![CDATA[<p>ECサイトや会員サイトでユーザが住所を登録する際、サイトによっては「自宅住所」、ではなく「会社住所」を登録する必要があります。また、特に企業向けのサイトでなくても、ユーザ個人の事情などによっては会社住所で登録しようとするため、住所登録時に会社の郵便番号を入力する、というケースは多くのサイトで発生します。</p>

<p>ただ、「会社」で用いられている郵便番号は一般的な郵便番号と異なる場合があります。</p>

<p>郵便番号は、特定の企業（１日の配達量が一定量を超えるような事業所）に対して<strong>「大口事業所個別番号」</strong>という事業者向けの郵便番号を割り当てており、該当する企業はこの割り当てられた郵便番号を使用しています。</p>

<p>しかし、郵便番号から「住所を自動入力する機能」が参照している郵便番号は必ずしもこの「大口事業所個別番号」に対応しているわけではありません。入力された郵便番号が対応していない「大口事業所個別番号」であった場合はエラーが表示されてしまいます。</p>

<p>ユーザとしては郵便番号を正しく入力したにも関わらずエラーが表示されてしまい、かつエラーの理由がわからない、という状態に陥ってしまいます。</p>

<p>ここで最も重要なことは、<strong>ユーザが「入力ミスしてしまった」という誤解のもと再入力してはエラー表示される、という繰り返しを避けること</strong>です。何度入力してもエラーが発生してしまうと、ユーザはサイトに対して非常に悪い印象を持ったまま離脱してしまうことにつながってしまいます。</p>

<p>こうした場合の対策としては、エラー表示に以下のような文言を追記することが考えられます。ユーザが会社住所を入力する可能性のあるサイトでのフォームを作成する際は参考にしてみてください。</p>

<p><img alt="郵便番号検索のエラー表示例" src="http://www.bebit.co.jp/memo/20091207_001.gif" width="566" height="253" /></p>]]>
    </content>
</entry>
<entry>
    <title>なぜその見出しはユーザに気づいてもらえないのか - ユーザビリティ実践メモ</title>
    <link rel="alternate" type="text/html" href="http://www.bebit.co.jp/memo/2009/11/post_161.html" />
    <id>tag:www.bebit.co.jp,2009:/2009mttest/memo//2.1284</id>

    <published>2009&#24180;11&#26376;30&#26085; 09:00</published>

    <updated>2010&#24180;01&#26376;11&#26085; 14:30</updated>

    <summary>「あ、そこに書いてあったんですね。探していたんですけど気づきませんでした。」
ユ...</summary>
    <author>
        <name>beBit,Inc.</name>
        
    </author>
            <category term="レイアウト" scheme="http://www.sixapart.com/ns/types#category" />
    
    
    <content type="html" xml:lang="ja" xml:base="http://www.bebit.co.jp/memo/">
	<![CDATA[<p>「あ、そこに書いてあったんですね。探していたんですけど気づきませんでした。」<br />
ユーザ行動観察調査を行っていると、時々ユーザの口からこんな言葉を聞くことがあります。</p>]]>
	<![CDATA[<p>「本文を斜め読みしているユーザが、探していた文字を見落とす」といったケースならまだしも、見出しとして大きく書かれている文字が気づかれないケースも少なくありません。<br />
その原因の一つに、見出し文字が画像要素と判断されて無視されていることが挙げられます。これは例えば、以下のような場合に起こりやすい現象です。</p>

<h3>１．画像に画像文字が同化している場合</h3>
<img alt="画像に画像文字が同化した見出しの例" src="http://www.bebit.co.jp/memo/219-1.GIF" width="434" height="164" />

<p>特に「目的にあった文字・文章を探すモード」となっているユーザは、本文のみを追っているため、画像を見飛ばしてしまいがちです。上図のように見出し文字が白抜きになっているケースでは、さらにそのリスクは高まります。<br />
多くの場合、本文の文字フォントは黒系統か青字（リンク）であるため、ユーザの頭の中に「黒や青い文字を追っていれば…」といった思い込みが生じ、白っぽい要素は文字として認識されづらくなってしまいます。<br />
よって、ユーザが文字や文章を追って情報探索を行うであろうページでは、上記のようなリスクを避けるため、見出しにはデフォルト文字または本文のフォントに似た画像文字を使用することをお奨めします。</p>

<h3>２．デザインに一貫性がない場合</h3>
1つのサイト内で見出しデザインが統一されていない場合、相対的に視認しづらいデザインの見出しを、ユーザが見出しとして認識してくれない可能性があります。さらに、ユーザがある一方のデザインに慣れ親しんでいる場合、新しいデザインの見出し文字に気づかない可能性がぐっと高まります。

<p>このような現象は見出し以外でもよく見られます。例えば、今まで「青字のテキストリンク」で配置していた導線を、ある日「ボタンリンク」に変えたためにクリック率が下がってしまったということはありませんか？<br />
この現象も、今まで通り「青字のテキストリンク」という前提で導線を探していたユーザが、新しいデザインの「ボタンリンク」を見飛ばしてしまったことで生じていると考えられます。</p>

<p>このようにユーザの慣れにも配慮しながら、サイト内で統一されたルールに沿って、見出しや導線のデザイン要素を用意しておくことで、文字や導線の見落としが起こるリスクを少しでも回避することができます。<br />
※ただし、デザイン要素の統一は悪い方向にも働く可能性があることも認識しておく必要があります。ユーザが一度「これは見る必要がない」と思った要素は、その後、内容を変えて表示しても、同じデザインであるという理由だけでまったく見られなくなってしまう可能性があります。</p>

<p>以上の点に気をつけながら、皆さんもこの機会に見出しのデザインを見直してみてはいかがでしょうか。</p>]]>
    </content>
</entry>

</feed>