このブログの更新を
RSSやTwitterで受信できます

WO!011|要点解説!ヤコブ・ニールセンのiPadユーザビリティ調査報告書

Webユーザビリティの父とも呼ばれる工学博士ヤコブ・ニールセンが、2010年5月の第1版に続き、iPadユーザビリティ調査報告書(第2版)をリリースしましたので、その要点を5つのポイントにわけてまとめてみました。

原文(英語)はこちらからどうぞ。

タップ動作について

“Fat-Finger”問題

iPadを操作するのは、基本的には人間の指です。
PCのマウスカーソルと比較すると、指は大きくて(太くて)、細かい選択操作には向いていませんし、タップする瞬間は、その接点は指で覆われて見えず、iPadが反応するまでは、どこをタップしたのかが分かりません。

そのため、「指による操作」を考慮してインタフェースを設計しないと、次のような“Fat-Finger”問題を引き起こしてしまうでしょう。

●ニュースアプリ「USA TODAY」
右下のアイコンが小さすぎて、正しくタップできない(タップしたはずなのに反応しない)可能性がある。

●レシピアプリ「Paprika」
小さいアイコンが狭い間隔で並んでいるため、タップした際、意図せず隣のアイコンが反応してしまう。

USA TODAY(左)とPaprika(右)における“Fat-Finger”問題

「余白の設計」でより確実なタップ動作を

“Fat-Finger”問題の解決策の1つが余白の設計です。

余白には内部の余白(パディング)と外部の余白(マージン)があります。

余白(パディングとマージン)の設計

見た目では小さなアイコンであったとしても、パディングをタップできる面として設計すれば、多少ずれたポイントをタップしても、動作してくれる可能性は高まるでしょう。
※ちなみに調査書では、タップ可能な面積は1cm×1cmが望ましいと指摘しています。

逆にマージンでは、タップできない面を設計します。
アイコンが隣り合う場合には、このマージンを広くとっておくことで、タップミスを軽減させることができるでしょう。

タップできることを判らせる

PCサイトであれば、マウスカーソルの変化で、クリックできるかどうか判りますが、タブレット端末では、実際にタップしてはじめて、タップの可否が判ります。いわば、一発勝負です。

そのため、ユーザーに対して、事前にタップできることをしっかり伝えることが重要になります。

調査書内での言及はありませんでしたが、例えば、「FOTUNE」や「TIME」のように、アイコンで明示するのも1つの方法でしょう。

また、「SEARS」にあるように、立体感をつけるなどのアフォーダンス(タップできそうな形状)で伝えるのも有効です。

タップできることが判る好事例(左から「FOTUNE」「TIME」「SEARS」)

大きなディスプレイの活用について

ユーザーの「利便性」「効率性」を重視しよう

iPadは、9.7インチの大きなディスプレイが備わっています。

大きなディスプレイであるがゆえに、iPhoneのサイズでは難しかった表現や機能を実現することが可能になったわけですが、それが制作者の「表現の場」になってしまってはいけません。

ニュースアプリ「abc News」では、2つのビュー(インタフェース)が用意されています。

そのうちの1つ「Globe Veiw」は、斬新性はありますが(最初はユーザーも面白がってくれますが)、一度に俯瞰できる記事数が少なく、また記事の詳細ページにたどり着くには2タップも要するため、本来このページに求められるインデックス(記事選択)としての役割は、充分に果たしきれていません。

「abc News」の斬新なGlobe Veiw

一方、「List View」では、多くの記事から選択できるようにスペースを有効活用しており、また、1タップで記事詳細までたどり着くことができるため、ユーザーにとって使いやすいインデックスページと言えるでしょう。

ユーザーの「利便性」「効率性」を重視したList Veiw

このように、大きなディスプレイは、「斬新性」ではなく、ユーザーの「利便性」「効率性」を高めるために活用されるべきです。

※エンタメコンテンツなどの斬新性が求められるものは、この限りではありません。

ポップオーバーの使い過ぎには注意

ポップオーバーとは、「epicurious」にもあるような上層レイヤーに表示されるナビゲーション機能のことを言います。一見、ユーザーにとって便利な機能のように見えますが、調査書内では、このポップオーバーに対して問題提起をしています。

「epicurious」はレシピを紹介するアプリです。
このポップオーバーは、レシピのカテゴリー(「メイン料理」や「デザート」など)を選択するためのナビゲーションになっています。

「epicurious」のポップオーバー

ここで考えていただきたいのは、このポップオーバーが表示されているとき、ユーザーは「目的のレシピをカテゴリーから探そう」としているわけですが、下のキャプチャで青色で塗ったところは、そのユーザーの選択ニーズに対して、何かしら貢献しているのか?ということです。
言い換えれば、ユーザーの選択ニーズに対して、広いディスプレイの一部分だけで応えようとするのは、正しい設計と言えるのか?ということになります。

青の範囲はユーザーの選択ニーズに応えているか?

もう1つ、ニュースアプリ「REUTER」の例をご紹介します。
ポップオーバーに限らず、ナビゲーションの項目は、選択の意思決定ができる要素が盛り込まれていなければいけません。
この「REUTER」のポップオーバーの場合、記事を選択させるナビゲーションとして使っていますので、ユーザーが選択判断できる要素としては、少なくとも記事のタイトル文を表示させる必要があります。
そうすると、どうしても文字量が多くなりがちで、それに伴って、文字サイズも小さくなってしまうため、項目の判読性が乏しくなり、ナビゲーションとしての使いやすさを損ねてしまっているきらいがあります。

「REUTER」のポップオーバー

また、この他にも、項目数が多くなるとポップオーバー内でスクロールが発生するアプリもありますが、そこまでして、この狭いポップオーバーの中で完結させるのが、ユーザーにとって使いやすいのか?と考えると疑問が残ります。

結論としては、もしポップオーバーを実装しようとするなら、以下3つの条件をクリアしているか?をよく考えるべきであると調査書の中で提唱しています。

1)選択項目が少なくて、スクロールが発生しないこと
2)選択するにあたって、背景の画面を見る必要があり、かつ、ポップオーバーがその画面を妨げないこと
3)意思決定に必要な情報が、ポップオーバーの各項目に画像を使わず、少ない文字量で収めることができること

モーダルビューorフルスクリーン

モーダルビューは、「sears」にもみられるような上層レイヤーに小さなウィンドウを出現させて情報を掲載する表示方法です。
しかしながら、ポップオーバーと同様、むやみに実装すべきではないと、警鐘を鳴らしています。

「SEARS」のモーダルビュー

そのポイントは「情報量」です。
「sears」では、モーダルビュー内では情報が収まりきらず、スクロールが発生しています。
これは、モーダルビューに固執するあまり、ユーザーの情報取得の妨げになっているといえます。

逆に、「Zappos」では、フルスクリーンで表示させており、モーダルビューでは掲載しきれない情報まで盛り込むことができています。

SEARS(左)とZappos(右)の商品詳細

モーダルビューを検討する際には、そこに盛り込む情報量を十分考慮する必要があるでしょう。

スワイプ動作について

認知されにくいスワイプ

スワイプ動作は、他のジェスチャー(タップなど)に比べて認知されにくい傾向にあります。
例えば、「The Washington Post」では、横方向にスワイプできることを、画面を見るだけで認知するのは難しいでしょう。

「The Washington Post」ではスワイプできることが判らない

「スワイプできること」を認知させる好事例としては「THE DAILY」「WIRED」があります。
この2つは、右下に「矢印」アイコンを置いているだけですが、これだけで、スワイプの認知率を高めることが期待できます。

「THE DAILY」と「WIRED」 スワイプ認知の好事例

また、好事例と言えないかと思いますが、「Bing」のアプリは特徴的でしたので、ご紹介します。
これは、アプリを最初に起動した際、スワイプできることをレクチャーしてくれる、というものです。
ただし、本来的には、教えられなくても判るインタフェースが理想的なので、ギミックにたよるのは、最終手段かもしれません。

「Bing」の特徴的なスワイプ認知事例

スワイプとカルーセルの同居は避けよう

カルーセル機能

カルーセル(=回転木馬)は、ページの一部分がスライドできる機能のことをいいますが、画面全体がスライドするスワイプを同居させると、複雑すぎるナビゲーション体系になってしまうので、注意が必要です。

例えば、「Bing」のコンテンツ選択ページでは、赤の範囲はスワイプ、青の部分はカルーセルが動作します。
タッチする場所によって、挙動が変わるので、充分な説明を受けないと、使いこなすのは難しいでしょう。

「Bing」では、スワイプとカルーセルが混在

ナビゲーションについて

アクシデントに備える「バックボタン」

「タップできるとは知らずに触ったら、いきなり違うページに移動してしまった」

「タップできるのは判るけど、押したらどうなるのか予測できない。試しにタップしたら、突然ページが変わってしまった」

‥というように、予期せずページが移動してしまい、そのまま迷ってしまった経験は、誰しも一度はあるのではないでしょうか。

予期せぬタップによるアクシデント

このようなアクシデントを未然に防げるようにインタフェースを設計するのは、もちろん大切ですが、もし突然ページが変わってしまっても、ユーザーが迷わない導線を用意しておくことも肝要です。

具体的には「戻る」ボタンを、目につきやすい場所に設けること。
これだけで、すぐ前のページに立ち返ることができるので、迷い道から脱出することができます。

「The Dairy Telegraph」の「戻る」ボタン

いたって単純な施策ですが、「戻る」ボタンがあるのとないのでは、ユーザーにかかるストレスには大きな差ができるでしょう。

アプリを設計する際には、是非とも忘れないようにしたいものです。

ホーム画面には「リターンボタン」

例えば、「Zappos」のように、「戻る」ボタンと「ホーム」ボタンが隣接している場合、ひとつ前のページに戻ろうと思って、誤って「ホーム」戻ってしまうケースが考えられます。

「Zappos」では誤って「ホームボタン」をタップする可能性がある

ホーム画面はアプリの最初の画面のため、「戻る」ボタンがないのが一般的ですので、元のページに戻るには、再び同じ経路をたどる必要があり、とても面倒です。

「Bing」では、その手間を軽減するために、ホーム画面に「リターンボタン」を設けています。

「Bing」の「リターン」ボタン

「戻る」ボタンに加えて「リターン」ボタンを実装することで、どのページからでも、ひとつ前のページに必ず戻れるナビゲーションが実現できるようになります。

本体の向きについて

今回の調査書では、ユーザーは、iPadの向きには固執せず、最初に持った向きでそのまま利用する傾向にあると報告されています(※1)。

つまり、ユーザーは向きの変更による表示や機能の変化を期待しておらず、縦(ランドスケープ)でも横(ポートレート)でも、同じ体験ができるように設計されるべきです。

※1 ただし、以下2つのケースに限っては、ユーザーはiPadの向きを変更する傾向にあります。
1)写真、動画、文章をより大きく見たいとき
2)何か問題に直面した時

機能・表示が向きによって変わってしまう例

「Time」では、横向きと縦向きとで、スワイプの方向が変わってしまいます。
ユーザーは、向きが変わっても、同じ向きにスワイプしようとする傾向にあるため、それに反することは、ユーザーのストレスになりかねません。

「Time」では、スワイプの向きが変化

さらに、「BBC NEWS」では、向きによってナビゲーションの有無が変わってしまいます。そのため、向きを変更するたびに、ユーザーは新しい「使い方」を学習しなければなりません。

「BBC NEWS」では、ナビゲーションの有無が変化

できる限り、縦向きでも横向きでも、同じ体験ができるようにアプリを設計すべきです。

片方しか対応していない場合には

しかしながら、コストの問題などで、片方の向きにしか対応できないケースもあるでしょう。

その場合には、「THE DAILY」にあるように向き変更を促す案内画面に切り替える対応を、少なくとも実施すべきです。

「THE DAILY」では、向き変更を案内している

——————————————————————————————————————————————————————————————

※本稿は、調査報告書を厳密に訳したものではございません(言葉の置き換えや、一部独自の解釈を加えております)ので、その点は、あらかじめご了承ください。
なお、調査報告書の正確な内容を知りたい方は、こちらより原文をご覧ください。

Posted by THINKJAM.

Posted in

このブログの更新を
RSSやTwitterで受信できます

ページの先頭へ