ホーム‎ > ‎Patterns‎ > ‎

Help


ホームページ移転のお知らせ
1月1日にリニューアルを実施いたしました。
これに伴い、ページのURLが以下のアドレスに変更となりました。
http://android-design.teamegg.co.jp/
お手数をおかけしますが、リンク集やお気に入り登録情報などの修正をお願いします。

ヘルプ


私たちとしては開発者が本ウェブサイトのアドバイスに従うことで、アプリに関する事柄を学習し、開発したアプリを誰もが使いこなすことが出来ると保証したいと願っています。しかし、残念なことにそうはならないでしょう。

ユーザの中には使用中に疑問や問題にぶつかる人もいるでしょう。彼らはあなたのアプリ内でヘルプを使うことで答えを探すでしょうが、スムーズに答えが見つからない場合はアプリの使用をやめ、二度と使わない可能性もあります。

このページでは、アプリ内のヘルプを見つけやすくするデザインパターンと、ヘルプの充実を期待するユーザ向けのヘルプ内容を作成するためのTipsをカバーしています。

アプリ内のヘルプのデザイン

非常に限られた場合を除き、未承諾のヘルプを表示しない
当然、あなたはすべてのユーザがアプリを最大限活用するために、早くコツを覚えて、クールな機能を見つけて欲しいと考えていることでしょう。そのため、初めてアプリを開いたすべての新しいユーザのために、スライドショーや動画やスプラッシュ画面を使った機能紹介を表示したくなると考えるかもしれません。または、ユーザが初めて特定の機能に触れた時に、役に立つ吹き出しやダイアログを表示することを考えるかもしれません。

ほとんど全ての場合において、このようなアプローチが正しくない理由を以下に示します。
  • 作業が中断される。あなたの善意にもかかわらず、ユーザはアプリを使うことに夢中になっているので、目の前に置かれた情報を邪魔に思ったり不快感を感じるでしょう。 また、ユーザはヘルプを求めているわけではないので、おそらくそれに注意を払うことはありません。
  • ヘルプは普段必要とされていない。アプリにユーザビリティの面で問題がある場合は、単にその問題をヘルプへ投げっぱなしにしたままではいけません。UIを改良してユーザビリティを改善してください。 Androidデザインのパターン、スタイル、ビルディングブロックを適用することで、ユーザの理解度を高めることが出来るでしょう。

ジェスチャーを介してのみ利用できる価値の高い機能がある場合のみ、ヘルプを求めていない新規ユーザに対してヘルプを示す意味があります。

例えば、私たちはホーム画面にアプリを置く方法についてこのヘルプを使用しています。この機能は:
  • 価値が高い
    これがなければ、ユーザは自分のニーズを満たすために最も頻繁に訪れる、Androidの画面をカスタマイズできないでしょう。
  • ジェスチャーを通してのみ利用可能である。この機能のためのボタンやメニューがないため、ユーザは自分自身で絶対に発見できないでしょう。

しかし、価値の高いジェスチャーのみの機能の全てにチュートリアルが必要ではなく、例えばどのようにスクロールするかは教えるべきではありません。(根本的なシステム全体の操作方法として知っているので)
「すべてのアプリ」画面に訪れたすべてのユーザに、半透明のオーバレイを表示して重要なジェスチャーを示します。

要点:アプリ内でヘルプを提供するなら、ユーザが必要なときに「ユーザから来させるようにする」ほうがはるかに良いです。

ヘルプに導くために標準的なデザインに従う
アプリ内のすべての画面で、ヘルプのアクションオーバフローを提供してください。常にメニューの一番最後の項目にし、ラベルは「ヘルプ」(Help)としてください。

たとえ、画面に他のアクションオーバフロー項目が含まれていない場合でも、ヘルプは表示するべきで、アクションバー内に表示させてはいけません。

私たちは、ユーザがヘルプを見つけるために必死になる必要がないように、この標準的なデザインを確立しました。(Give me tricks that work everywhereの設計原理を参照してください。)

ヘルプの呼び出しは常に緊急だと考える
ヘルプに加えて、著作権情報、クレジット、利用規約、プライバシーポリシーなどの他の情報を表示したいと思うかもしれません。
ユーザにヘルプメニュー項目を通してこれらの情報を示したいと考えるでしょうが、アプリの中で何が起こっているのか、なぜそれが起こっているのかをユーザに示すことを優先してください。法的な注意事項やアプリの製作者を気にするような一部のユーザは、これらの情報を探すことを負担に思うことは無いでしょう。
カスタマサポートへの問い合せやフィードバックのような、あなたが提供したいすべての連絡オプションについても同じ事が当てはまります。ユーザがヘルプを参照する前に余分なステップを増やさないように、これらの情報を提供してください。ヘルプコンテンツをこれらの前に置くことで、ユーザが答えを自分自身で見つけることができ、サポートのコストが減るでしょう。

「ヘルプ」を選択した時:
×やってはいけない

ヘルプか他のオプションか尋ねるダイアログの表示
○良い

ヘルプコンテンツのWebブラウザをすぐに起動し、他のオプションをフッタに配置する。
◎更に良い

アプリ内にヘルプ画面を構築し、他のオプションをアクションバー内に提供する。例えば、ユーザはアクションボタンを通じてあなたに質問したりやフィードバックすることができます。アクションオーバフローはユーザが滅多に必要としない、ヘルプでない情報を記載するのに最適な場所です。

このシステムはWebブラウザを起動するよりも多くの開発作業を要求しますが、ヘルプを得るためにアプリを切り替える必要やネットワーク接続をする必要が無いため、ユーザにとってより親切です。

ヘルプ画面の内容を記述するための原則

ヘルプはUIの一部
ヘルプ画面はアプリのUIを拡張したものであり、アプリの説明ではありません。最初から最後までヘルプがシームレスで有益であると感じるようにするには、コアアプリのヘルプの画面上のすべての単語を、私たちのWriting Style原則に従って記載するべきです。

すべてのピクセルの数を確認する
アプリについての詳細の1つ1つ、特にUIの見え方やプラットフォームの標準のふるまいなどの非常に明白なことについて文書化する必要はありません。このような標準的な機能について詳細にテキストで示さないことで、画面をすっきりさせることができます。

画像は言葉よりも早く伝わる
テキストとアイコン、部分的なスクリーンショットと吹き出し、および他の画像を組み合わせることを検討し、主要なUI要素を記述と詳しい手順を提供してください。少ない言葉で物事を説明することで、ユーザはより素早く情報を吸収するでしょう。

ざっと目を通させ、読ませない
ユーザは最初から最後までヘルプをしっかり読むことはありません。彼らは周りをざっと眺めることで、欲しい答えを含む情報の断片を探します。そのため、書式や太字の見出し、箇条書きや番号付きのリストやテーブルのようなレイアウト選択や段落間の空白を工夫することでユーザの負担を軽減出来ます。コンテンツが多い場合には、スクロールを削減するために複数の画面に分割してください。

答えに一直線に連れて行く
ざっと目を通すことが出来る画面は優れていますが、答えがすぐそこにあり、全く目を通す必要のないシンプルな画面はより優れたものです。アプリ内の各画面から直接、その画面に関連したヘルプを表示することを検討しましょう。私たちがコンテキストヘルプと呼ぶこのヘルプは、究極のユーザアシスタンスです。そのアプローチを採用する場合も、ヘルプ画面の残りの部分を取得する方法を提供するようにしてください。



原文はこちら > Help

Except as noted, this content is licensed under Creative Commons Attribution 2.5. For details and restrictions, see the Content License.

Comments