Yunicode

プロデューサー永田ゆにこの日記です

【読書メモ】モバイル・ユーザビリティ 使いやすいUIデザインの秘訣

モバイル・ユーザビリティ 使いやすいUIデザインの秘訣

モバイル・ユーザビリティ 使いやすいUIデザインの秘訣

感想

「なぜモバイル用に対応したものを作らないといけないの?」から始まり、モバイルユーザービリティについて徹底的に書かれている。アプリに限らず、今後ウェブサイトというものを作る人はモバイルデザインを避けては通れないので必ず一度は読んだ方がよい本です。お恥ずかしい話ですが「90:9:1の法則」を初めてきちんと知った。
最近行われたQiitaのリニューアルでタグがまさにあいうえお順で並べられており「アルファベットは消え去るべき」に書かれていた内容を痛感した。あとKindle fireがとてもアレということはよくわかった。

以下、自分用要約まとめ。

ユーザービリティ調査の進め方

定性的ユーザー調査

  • 厳密に正確な統計が無くても、数少ないユーザー事例から問題の大きさを測定できる。

モバイル戦略

2009年に実施したユーザーテスト

  • 悲惨なタスク達成率
  • パソコンよりはるかにおそいダウンロード
  • 小さな画面の中でスクロールを繰り返し迷子に
  • 情報の肥大化
  • 不慣れなユーザー・インターフェース
  • jsのクラッシュ
  • 操作への抵抗感
  • モバイル機器のモデルとして従来メディアのデザインを使用
  • 自動的に画像を切り替えて表示するカルーセル形式はモバイル機器ではほとんど用をなさない

2009年以降改善された点

  • タスク成功率の向上
  • ユーザーインターフェースの慣れ
  • jsの状況改善
  • 抵抗感の現象
  • 買い物や支払いにモバイル機器を使うことにたいして嫌悪感や抵抗感を抱く人は減っている
  • ダウンロード時間に関する問題は解決していない

モバイル機器の種類によって異なるユーザービリティ

  • 小型画面(ガラケー)、中型画面(スマホ)、大型画面(スマホタッチ対応)の3種類に分けられる
機器ごとにデザインするのがベスト
  • モバイル用にデザインしたサイトをひとつは用意する
  • モバイル版には掲載しきれない機能を必要とするユーザーのために、簡単にパソコン版のサイトに切り替える機能をモバイル版につけるようにする

モバイルサイト vs フルサイト

  • 余裕があればモバイルに最適化したサイトを個別に構築する
  • モバイルユーザーがフルサイトにたどり着いた場合、モバイルサイトの代用品としてフルサイトを見ていないか確認
  • フルサイトからモバイルサイトに移動しようとするユーザーのために明確なリンクを用意
モバイルに最適化したサイト
  • モバイルを使う上で重要ではない機能を排除
  • 文字数を減らし、二次的な情報は次のページに先送り
  • 太い指でも操作上問題ないようにインターフェース要素を大きく
  • ユーザーの要求に対する答えや情報が、プラットフォームによってばらつきがあってはいけない
フルサイトがモバイルでの利用で適さない理由
  • 大部分のタスクに対してフルサイトよりもデザインの良質なモバイルサイトから良質のユーザーエクスペリエンスを得ることが出来る
  • フルサイトを訪問すると余計なクリックが必要になり遅くなる
  • しかし、パソコンユーザーからのトラフィックはモバイルをはるかに上回っている

- お金を稼いでくれるパソコンユーザーを軽視はできない

パソコンとモバイル機器で重要な違い
  • コンテンツは異なる
  • より短く単純なライティング
  • メディアに合わせてデザインし直す必要
  • 情報の断層構造の工夫
  • 指入力とマウス入力の違い
  • 複雑な操作を減らす
モバイル機器はパソコンに比べて与えられるものが限られる
  • パソコン用のコピーライティングは簡潔に
  • モバイル用のコピーライティングはさらに簡潔に

- モバイルユーザーはせっかち

  • できるだけ少ない機能を提供すべき
  • シンプルなナビゲーションを心がける必要
レスポンシブデザイン
  • メンテナンスコストが低い
  • モバイルだけというユーザーをサポート
  • 画面上でコンテンツを移動させたり、デザイン要素を拡大・縮小したりすることで画面の大きさに合わせるだけでは充分とは言えない

- プラットフォームごとの相違点に適用できていないのであればレスポンシブとは言えない

ユーザービリティガイドラインが対立することはない
  • モバイルユーザビリティには通常のウェブサイトユーザビリティより厳密でより絞り込んだデザインが要求される

モバイルサイト vs アプリ

現在のモバイル戦略
  • アプリがベスト
  • Webサイトのデザインでは最低か出来ることが限られているから
将来のモバイル戦略
  • サイトがベスト
  • 複数のアプリから深い断層になるコンテンツを検索できるアプリはまだない
  • HTML5のような新しいWeb技術がモバイルサイトの機能を大幅に向上させている
  • 長期的に見ればモバイルアプリよりモバイルサイトが勝る
  • しかしそれはいつ起こるか予測できないので現在最高のUXを実現するならアプリが優位

モバイルアプリ

モバイルアプリは一時的な利用にとどまることが多い
  • ダウンロード回数だけを測定しても意味ない
  • ユーザーはたくさんのアプリをインストールしているので埋もれてしまう可能性が高い

進みは遅いが希望はある

2000年から2009年までの9年間の間に、パソコンでの4年間の進歩に相当するモバイルユーザーエクスペリエンスの進歩があった。インターネットユーザービリティのペースの半分で改良が進んでいる。

小さな画面のデザイン

モバイルユーザービリティの4つのハードル

  • 小さな画面

- ユーザーはオンライン情報を理解するために短期記憶に頼らなくてはならない

  • やっかいな入力
  • 遅いダウンロード
  • 粗末なデザイン

モバイルスペースの浪費

  • モバイルサイトやアプリを成功させるガイドラインは小さな画面向けにデザインすること
  • より高い情報密度=動き回る必要性が減り、望む情報が手に入る可能性が高まる
  • 多くの情報や圧倒されるような情報を画面に詰め込んではいけない

Chrome

  • コンテンツを操作するコマンドを提供するビジュアルデザイン要素
Chromeいくつかの例
  • Windows

- ガジェットエリアなど

  • アプリケーションソフト

- メニューバー・ツールバー・ルーラーなど

  • Webブラウザ

- URLフィールド・ブラウザツールバー・ブラウザボタンなど

  • モバイルアプリ

- アイコン付きタブ・ナビゲーションバーなど

  • ウェブサイト

- ナビゲーションバー・ロゴ・ブランド表示・検索ボックスなど

ガイドラインは、肥大化に用心すること!
  • 一時的に隠し、必要なときにだけ表示する方法を考える
  • うっかり起動させないよう、難解なジェスチャは避ける
  • 何度も繰り返すことによって隠れていても存在することを記憶してもらえるよう、一貫性を貫く
Chromeに代わるジェスチャ?
  • 代替となるジェスチャに正しいアフォーダンスがあり数が多すぎなければうまく機能する

- ページをめくるスワイプジェスチャなど

  • 人々が過去に行ったジェスチャをまねているので習得しやすく思い出しやすい
Chromeのメリット
  • コマンドやオプションを安定して提供
  • 常に同じ機能が表示されるので習得が難しくない
オーバーロードコマンド vs 汎用コマンド

画面スペースを有効に使うには2つのコマンドを使う必要がある

  • 汎用コマンド
  • ピンチ・ズーム、など
  • オーバーロードコマンド
  • 同じコマンドを異なる結果を得る為に使う
  • コンテキストによって結果が変わることもある
  • オーバーロードコマンドはたいてい紛らわしい
  • BACKには「取り消し」と「前のページへ戻る」が混在

画面をモバイル機器に最適化する

ここでは韓流ポップスターを多くカバーするAllKpop.comのリデザインについて。デザインの制約がきついほど、最適なユーザビリティを供給するためにUIを磨かなければいけない。

  • 機能の削減
  • 記事を選ぶ為に署名は必要ない
  • タッチする目標を広く
  • 見出しを全文表示に
  • 流し読みしやすく
  • 情報の香りをもっと強く
  • 写真の使用
  • 写真の方が認識が素早い
  • タイル感の余白を少し狭く
  • ファースとビューで4番目の記事をスクロールなしで読めるように
  • ディバイダーとして発行日を表示
  • オプション間のスペースを空ける
  • ドロップダウン・メニューにラベルをつける

反復デザイン

完璧なUIを一発でデザインはできない。反復デザインという手法を使って再デザイン。反復デザイン・反復ユーザーテストを何回か継続してより多くの利益を上げるサイトデザインを。

モバイル機器上でタイプすること

モバイル入力はユーザーにとって面倒。

  • 書き込めるよう支援

- デフォルト値や略語
- コンピュータ処理
- コピペ
- 既知値は自動入力

  • フォームは短く

ダウンロード時間

インタラクションコスト

機器上でタスクを完了するために必要なごく小さなアクション数。アクションが追加されることはユーザーにとって苦痛である。

  • ダウンロードをできるだけ減らす。
  • 必要な情報だけ
  • 画像を使いすぎない
  • プログレスバーでフィードバック

最初の段階でユーザー登録させない

  • マニュアルを読んでくれるように依頼することからスタートすべきではない
  • 最初のエクスペリエンスはユーザーに強制するものではなく、魅了し引きつけるものであるべき
  • 起動画面で同意を求めない
  • 求めるのであればなぜいまその同意が必要なのかを事前に説明
  • 長い説明書やマニュアルは読ませない
  • UIの中ではユーザーの言葉で話す

90:9:1の法則

  • 90%はROMユーザー
  • 9%は時々寄与するユーザー
  • 1%は非常に積極的に参加するユーザー

モバイルに適したライティング

モバイルで読むのは何故困難なのか?

  • 一度に見られるものが少なくなる

- 理解しづらい

  • 文章を目で追うことができず多くのスクロールをしなければならない
  • 読みやすく、目を通しやすくすべき

疑問に思うなら取り去ってみよう

  • 時間を潰したいのに冗長だと起こるのはなぜ?
  • 時間つぶしのアプリこそキラーアプリである
  • 時間を浪費する冗長な表現は嫌われる
  • 解決方法
  • 余分な情報をカット
  • 背景となる情報は次ページに

モバイルコンテンツ用の署名

署名欄に対する原則は排除すること
  • 誰が書いたか知りたい?120語しか読まないのに署名で無駄遣いすべき?
  • モバイルの文章はパソコンより短くすべき
署名欄が合った方がいい場合
  • 著名人の場合
  • 特定の資格や記事の信頼性を高める場合
  • 信憑性を高める場合
  • その手の記事をよく書いている場合
  • 意見記事・レビュー記事・政治的解釈など

二次的コンテンツはリンク先へ

モバイルクーポンの例
  • モバイルユーザーは必要な情報を探すことにとてもせっかち
  • 「Buy Now!」ボタンがいつも押しやすい場所にあり、大きく明確で他のボタンと間違えて押す可能性が低くあるべき
Wikipediaの例
  • 概要をつかむために記事の見出しを見て、読みたいものがあればそこへ行けば良い
  • 最初の情報がよく読まれる

ミニIA コンテンツの構造化

mini-information architecture:小規模な情報の構造化
「トピックごとの情報をどう組み立てるか?」

長々と続くページは一般的に見づらい
  • 使い勝手の悪いmini-IAは例外無く取り除いて行く
  • iPadや電子書籍リーダーのようなタブレットの場合は
  • スクロールさせるよりもページを区切っておいた方が使いやすい
アルファベット順は消え去るべし
  • ユーザーが探しているものの名前を知らない場合は使えない
  • 項目によっては並べる順序にロジックがあり、かえって探しづらくなってしまう
使い方を変える構造
  • 長い1ページにする
  • 二次的なトピックスを探すのが難しくなる可能性
  • mini IAを行う
  • 情報を適当なまとまりに分類
  • 分散型情報にする
  • たくさんのトピックスの中から選んだ情報を組み合わせて二次的なトピックスを作る

タブレットと電子書籍リーダー

iPadのユーザービリティ

  • iPadで重要なことは、画面が広いだけでなく、利用する状況が違うこと
  • iPadがiPhoneと大きく異なる点の1つはタブレットの大きな画面では通常のウェブサイトが充分に機能する
  • 小さいターゲットを正確にタッチするには指が太すぎるという共通の問題も残る
  • iPadの「美しい」特性を生かすなら画像は大きくわかりやすいほうがいい
タブレットはシェアされる機器
  • ユーザーが利用したいアプリをすぐに判別できるようにアプリのアイコンを特徴的に
iPadは何の為に使われる?
  • ノートPCでやっていた複雑な情報検索をiPadでやる
iPadデザインに潜む3つの脅威

iPadのUIでユーザーに重大な混乱を引き起こす3つ

  • 目に見えない
  • かくれてしまってアフォーダンスを与えてくれない
  • 思い出せない
  • 業界標準コマンドに広く準拠
  • iPad上でほとんどのユーザが自然にできるジェスチャはタップとドラッグ
  • 一本指でダブるタップや長押しはすぐに慣れない
  • 指を吹く数本使ったジェスチャは間違う可能性が高い
  • 予想外の反応
  • ユーザービリティについてユーザーに聞くよりユーザーの様子を見た方がいい
カードの達人 vs スクロール信者

忠実にひとつのナビゲーションの方法だけを採用し同じページ内や画像の向きによって複数のナビゲーション方法を混在させない

  • カード
  • 固定した大きさのキャンバスの中に美しいレイアウトを配置が可能
  • 情報を得るには別カードにジャンプしなくてはならない
  • スクロール
  • 好きなだけ情報を入れられる
  • 室の高いレイアウトができない
スプラッシュ画面と起動ノイズ
  • 最初は楽しませてくれてもすぐに歓迎されなくなってしまう長い導入部
  • 起動音は使わない
画面の向き
  • iPadでは横向きを好むユーザーの方が多い
  • すべての向きで機能がアクセスできることを推奨
よりよいiPadUXのために
  • インタラクティブな領域を大きくよりわかりやすく
  • 繊細なGUIでインタラクティブの葬祭性を向上
  • 妙な付加価値をつけようとしないこと
  • 戻る・検索・ヘッドラインなどほとんどのアプリで使われている標準的なナビゲーションをサポートする

未来への展望

将来のユーザーインターフェースについての考察

モバイルは「より小さく」「より安く」「様々な用途に応じて」進化

  • パソコンは重要なまま存続する

- 仕事で価値を生み出す割合はデスクトップPC、時間を使う割合はタブレットやモバイルへ

  • 第3の画面:テレビ

- テレビにはモバイル・デスクトップとは異なる3番目のUIが必要になる