年 9 月 2015
ボリューム 30 番号 9
最新のアプリ - 最新のアプリのユーザビリティ プラクティス
Rachel Appel | 年 9 月 2015
.jpg)
ユーザビリティは重要であっても、アプリケーションの開発時に見落としがちな側面です。開発者は、UX の専門家や UI のデザイナーにユーザビリティを任せてしまう傾向があります。しかし、ユーザビリティに関する技法の中には開発者が適用して大きな効果が得られる技法 (規模の大小はあります) もあります。
本来の目的は、実際に使いやすいソフトウェアを開発することです。つまり、よく使うコマンドは目立たせ、すぐに使えるようにし、あまり使わないコマンドは、できるだけ少ない回数のクリックで済むようにします。今回は、優れた最新のアプリのビルドに役立つ、いくつかのユーザビリティ技法を確認します。
開発者の多くは、「ベスト プラクティス」という言葉をあまり好まないようです。まるで、ベスト プラクティスのみが唯一の実践方法だ言っているように聞こえますが、開発者はそうではないことを知っているからです。大半のシナリオにうまく作用するプラクティスもあれば、幅広い範囲の技術に対してうまく作用したりしなかったりするものもあります。ほとんどの開発者が「ベスト プラクティス」という言葉を使いたがらない理由はここにあります。ここでは、「グッド プラクティス」(good practice) という言葉を使います。グッド プラクティスとは、一般に、他の方法と同等またはそれ以上にうまく作用するプラクティスのことです。すべてのシナリオに、そのプラクティスを適用すべきだという意味は含めません。
「バッド プラクティス」(bad practice) もあります。これは、ほとんどの場合に明らかに劣悪なプロセスを指します。目的を実現するのにもっと優れた設計や開発テクニックがあれば、それはバッド プラクティスです。バッド プラクティスは、ユーザーを欲求不満にさせるため、明白で簡単に見分けられます。ソフトウェアがうまく使えずいらいらさせられるのは、バッド プラクティスが原因です。
ユーザビリティのグッド プラクティス
おそらく、最も重要で優先度の高いユーザビリティ プラクティスは、アクセシビリティです。ソフトウェアのアクセシビリティを向上すれば、使いやすくなります。一部のユーザーにとっては、アクセシビリティが課題になります。聴覚に障碍のある方、視覚に障碍のある方、運動能力に障碍のある方、認知に障碍のある方を考慮しなければなりません。アクセシビリティを考慮した設計を組み込んだ Web サイトやアプリを開発するのはそれほど難しくはありません。そのテクニックの多くは、HTML や CSS に簡単な変更を加えるだけです。このことについては、「アクセシビリティを備えた最新のアプリの設計と開発」(msdn.microsoft.com/magazine/dn913189) で取り上げました。
よく使うコマンドは、目立つように表示します。ユーザーが苦労して情報を探さないようにします。ユーザーがコマンドの名前や同義語を入力してコマンドを探さなくてもすむように、Visual Studio のクイック起動機能のようなものを使用します。通常のメニューやナビゲーションに、クイック起動機能を追加します。その際も、ユーザーがタスクを遂行するのが難しくならないようにします。タスクを簡単に遂行できないユーザーは、そこで作業が止まり、アプリ ストアのレビューに低い評価を付けます。
優れたソフトウェアをビルドする際に重要なのが、一貫性です。アプリ内やアプリと OS の間に一貫性を持たせます。iPhone アプリに似た外観や動作を備えアプリを Android デバイスや Windows デバイス向けに提供すると、欲求不満を訴えるユーザーがでてきます。ユーザーがデバイスを購入する理由には、デバイスのスタイルの好みも入っています。ホスト OS のスタイルを規範としたうえで、独自のスタイルを追加します。そのためには、個別のコード ベースが必要になりますが、バックエンド コードは依然としてアプリ間で共有できます。
一貫性のあるナビゲーションも不可欠です。Web サイトやアプリ全体で、同じナビゲーション スタイルを使用します。優れたナビゲーション設計の一環として、ユーザーがよく使用するコマンドにはすばやくアクセスできるようにします。ユーザーがコマンドを起動するたびに記録することで、よく使われるコマンドを判断できます。フォーム内のボタンやコントロールなどの要素には一貫性のあるラベルを付けます。小説ならば、類語や同義語をうまく使い分けることで表現豊かな文章になりますが、ソフトウェアでは、同じ動作やフィールドに別の語句を使うと、ユーザーの混乱を招くだけです。
多くのユーザーが、それぞれ、多くのサイトにログインしています。この副作用として、すべてのリソースに同じパスワードを使用するユーザーが増えています。これは、セキュリティの専門家が避けるよう警告している状況です。さらに、開発者が、OAuth、Microsoft、Google など、既に信頼を得ているセキュリティ プロバイダーを使わずに、独自のセキュリティ インフラストラクチャをビルドすることで、この悪習慣を助長する Web サイトが設計されます。Facebook や Twitter の認証でも、独自に作成するより優れています。
可能な限り、ユーザーに選択肢を与えます。独自のログイン システムを作成してもかまいませんが、メンテナンスが必要になります。ログインのデータが侵害されればそれは開発側の責任になります。既に信頼を得ているプロバイダーを利用すれば、この責任はプロバイダーに移ります。プロバイダーはチーム一丸となって、メンテナンスやユーザー データの保護に取り組んでいます。セキュリティの専門家にセキュリティを任せることで、業務に専念し、ソフトウェアでの業務上の問題を解決する時間を確保します。
適切な既定値がアクセシビリティを向上します。2015 年の今でも、郵便番号から詳しい住所を自動入力するのではなく、都道府県や市区町村の入力を個別に求める Web サイトやアプリがたくさんあります。小さなドロップダウンの長いリストから選択するのに比べれば、小さな番号の並びを入力する方が簡単です。モバイル優先の設計を使用したソフトウェアのビルドの詳細については、「モバイル優先で最新のアプリを開発する」(msdn.microsoft.com/magazine/dn948114) で取り上げました。
レスポンシブ UI は、フォーム ファクターや特定のデバイスの能力に応じてスケールが変化します。デバイスに応じてソフトウェアが調整される方が、ユーザーにとって明らかに優れています。レスポンシブ UI にするとモバイル優先になる傾向があります。また、モバイル優先の設計は、従来のソフトウェアよりも使いやすくなる傾向があります。レスポンシブ UI のビルドの詳細については、「WinJS アプリ向けに CSS を使用して最新のレスポンシブ UI をビルドする」(msdn.microsoft.com/magazine/dn451447) を参照してください。
最小機能の設計は、最新のアプリのもう 1 つの特徴です。ユーザーは、あまり使わない機能が数多く選択肢に含まれていると、そのアプリをあまり使わなくなります。簡潔で、状況に応じて選択肢が変わるアプリを選びます。Windows 8 以降のアプリでは、ユーザーがアプリで作業中は非表示にできるアプリ バーがあり、必要に応じて選択肢を表示できます。
ユーザビリティのバッド プラクティス
多くの Web サイトやアプリには、ユーザーにメール アドレスの入力を 2 回求めるフォームが組み込まれています。メール アドレスを正しく入力できないならば、番地、市区町村、都道府県などの情報を正しく入力できるとも思えません。こうしたフィールドへの入力が 2 回求められないのはなぜでしょう。
メール アドレスの再入力を求められるといらいらします。人間には癖があります。タイピングにもタイプ ミスにも癖があります。2 回入力を求めても、同じタイプ ミスを犯しがちです。
Captcha の考え方は画期的でした。Web サイトやアプリが、数字、単語、語句を含む画像を表示します。ユーザーがその数字、単語、語句をそのまま入力します。通常、画像には加工が施されているため、コンピューターがその画像を識別することはできません。最近になって AI システムが画像認識を実行して簡単に Captcha を認識できるようになり、問題が生じています。皮肉にも、人間の方が Captcha に苦労するようになっています。加工が施されたパターンを見る場合、人間の目もコンピューターもあまり変わりません。このように、優れたアイデアに見えてもいずれそうでもなくなる可能性があります。
特にスクリーンの音声ガイドなどの支援技術に頼っているユーザーにとっては、無限スクロールやページの自動更新も問題になります。Facebook や最近の Twitter は無限スクロールをうまく取り入れていますが、新しいコンテンツが到着して古いコンテンツを横へずらすときに、まだ難しさがあります。このような機能を実装するときは、アクセシビリティの高い別の入力デバイスの導入を検討します。
小さな [閉じる] ボタンは、操作に慣れたユーザーにとっても厄介です。タッチ デバイスを使っている場合、小さな領域はタップしにくいので、慣れた人でも [閉じる] ボタンを使えないことがよくあります。はっきりと目立つ [閉じる] ボタンがあればよいのですが、多くのダイアログ ボックスは先へ進むボタンしかなく、中止する方法を備えていません。レスポンシブな最新のアプリは、常に、操作を簡単に中止する方法を用意しています。
書式が適切に設定されていなければ、優れた Web サイト設計とはいえません。フォームの電話番号フィールドを見て、やる気をなくすユーザーもたくさんいます。きっと、どんなに悩んでいるか知らないのだと思います。国コードは必要なんだろうか、番号だけでよいだろうか、かっこやダッシュも入力すべきだろうか。思い切って自分が正しいと思うように入力してみると、モーダル ウィンドウで警告を受けて、ワークフローが中断します。
同じように、URL フィールドも厄介です。多くは、「http://」が自動的に入力されません。このような Web サイトやアプリは、やはり、ユーザーが [送信] をクリックしたときに初めて「http://」が必要であることを通知し、検証エラーとしてフォームのフィールドをすべてリセットしてしまいます。
フォームのエラー処理に関連するバッド プラクティスがあります。フォームが存在する意味は、データを取得することにあります。しかし、開発者がフォームを複雑で理解しにくくしてしまうことがよくあります。入力漏れや入力ミスがあったときにすべてのデータを強制的にクリアするフォームにはいらいらします。多くのWeb サイトやアプリで、この状況が続いています。作業を終えるのに、倍の時間がかかります。
開発中のアプリで収益を得たいのであれば、この方法はよくありません。ユーザーの購入を妨げることになります。フォームがクリアされるアプリは入力に時間がかかります。フォームのクリアを決めているのは開発者の都合です。
もう 1 つの問題は、適切な既定値を用意していないことです。国内ユーザーがほとんどならば、その国を既定値として、他の国を選択肢として表示します。都道府県、郵便番号など、特定のフィールドで最もよく使われる値にも、同じことが当てはまります。既にアプリをリリースしているのであれば、よく使われる値をデータベースでチェックできます。まだ開発中であれば、ユーザーの意見を聞きます。Web サイトで忘れてはならない既定値は、やはり、チェックするニュースレターや製品情報を受け取るオプションの設定です。
多くの Web サイトやアプリが、適切な検索機能を用意していません。検索機能がまったくいないものもあります。Search Engine Watch によると、92 パーセントもの Web ユーザーが少なくとも 1 つの検索エンジンを常に使用しています。
検索結果はわかりやすくまとめて、明確かつ一貫した方法で表示します。検索結果やコンテンツの周辺に広告を配置する場合でも、一番上には配置しないようにします。ユーザーは、検索結果が広告に紛れてしまうと、何も見つからなかったという理由で立ち去ることになります。
UI 設計には、外観に関する禁止事項がいくつかあります。私はこれを「目障りな UI」と呼んでいます。拡大して読まなければならない小さなフォント、過剰な広告、入れ子になった広告などがその例です。多くの Web サイトやアプリが広告収入に頼っているため、広告は必要悪です。しかし、広告が入れ子になっている場合 (実際、よくあります)、最悪です。
もう 1 つ、よく使われていて避けたいユーザビリティは、ボタンの色と位置です。操作の実行や継続を指示するボタンを明るい赤にすることがよくあります。この色は、操作の停止や取り消しを意味します。ユーザーは、信号機の緑、黄、赤から、進む、注意、停止を判断することがよくあります。
その他のユーザビリティ プラクティス
「その他のユーザビリティ プラクティス」には、ナビゲーションがあります。ナビゲーションは、種類によってより使いやすくなる場合と、そうでない場合があります。ナビゲーション体系を設計するときは、明確性と一貫性が必要です。通常は、ホスト OS のパラダイムを取り入れるのが一番です。アプリと OS 間の一貫性を維持すると、ユーザーはわかりやすく感じます。新しいユーザーや、多くのテクノロジを利用しないユーザーには、特にわかりやすくなります。また、パラダイムの一貫性に基づいたショートカットを好む経験豊富なユーザーも、やはり同じです。
タブ メニューは、多くの場合、適切でわかりやすいナビゲーションを実現します。しかし、タブの行が多すぎると、ナビゲーションが難しくなります。デスクトップ アプリは従来のプルダウン メニュー構造でうまく機能しますが、Web アプリやネイティブ デバイス アプリでは、通常、別の体系が必要になります。たとえば、Windows Phone ではライブ タイルを使用して、アプリの起動やナビゲーションのために大きくてタップしやすい領域を用意することで、ユーザー エクスペリエンスを高めています。
技術メディア サイトの TechCrunch によると、ハンバーガー メニューがアプリや Web サイトの操作時間を大幅に減らすと言われています。1 つのハンバーガー メニューを選ぶと、必ず、使用状況の統計に関する通知を継続的に受けることになります。ナビゲーションのユーザビリティ要素に関する詳細については、「Windows ストア アプリでのナビゲーションの必須要素」(msdn.microsoft.com/magazine/dn342878) を参照してください。
まとめ
アクセシビリティが優れているほど、そのソフトウェアは使いやすくなります。小さな変更を実装することで、ユーザー ベースを 20 パーセント近く増やすことができます。ビジネスの標準から考えると、これは破格の数字です。有能なマネージャーならだれでもこの数字に飛びつくでしょう。アクセシビリティとそれに伴うユーザビリティを組み込むには、アクセシビリティの高いテクノロジを自身で試してみることをお勧めします。目隠しをして、スクリーン リーダーでページを利用してみます。音声デバイスを使用してみます。
今回取り上げたいくつかのプラクティスは、「グッド」か「バッド」に振り分けていますが、その評価は常にどちらか一方に振り分けられるわけではありません。バッド プラクティスの骨組みを壊して、もっと使いやすくすることはいつでも可能です。同様に、グッド プラクティスでも、容易にうまくいかなくなります。ユーザーの意見に耳を傾けます。ただし、ユーザーが間違っていることもあるので、鵜呑みにしてはいけません。アプリの使用状況を監視すると、実際にユーザーが行っている作業がよくわかります。最善の判断をお願いします。
Rachel Appelは 20 年を超える IT 業界での経験を持つマイクロソフトの元社員で、コンサルティング、執筆活動、および指導を行っています。彼女は Visual Studio Live!、DevConnections、MIX など、業界トップ クラスのカンファレンスで講演しています。専門分野は、マイクロソフトの各種開発ツールやオープン Web を重視したテクノロジとビジネスを連携させるソリューションの開発です。彼女のことをもっと知りたい方は、彼女の Web サイト rachelappel.com (英語) をご覧ください。
この記事のレビューに協力してくれたマイクロソフト技術スタッフ Frank La Vigne に心より感謝いたします。