オンラインヘルプのベストプラクティス
現在、かなり複雑なWebポータルを開発しています。ユーザーエクスペリエンスを向上させるために、ユーザーがサイトの特定の側面を理解するのに役立つ状況依存オンラインヘルプシステムを提供したいと考えています。
私たちの場合、サイトにはあらゆる種類の表形式のデータやグラフなどを表示するさまざまなウィジェットがあります。たとえば、そのようなウィジェットの1つに [〜＃〜] vix [〜＃ 〜] とヘルプシステムは、VIXとは何かの簡単な説明を提供します。
今、私はインターネットを見て回り、 オンラインヘルプのデザインチェックリスト などの興味深い記事を見つけましたが、見つけたもののほとんどはかなり古くなっています。私が特に興味を持っているのは、次のような設計上の問題です。
- ポップアップ、div、または外部ページへのリンクを使用するかどうか（またはいつ使用するか）
- ヘルプエントリはどの程度包括的である必要がありますか？平均的なユーザーはどれだけ読んでもいいですか？
- ヘルプシステムへのアクセスを提供する良い方法は何ですか？疑問符アイコンでUIを乱雑にすることは確かに最適ではありません
- ヘルプエントリをオンデマンドでAJAX=（ちょっと吸って、すぐに情報が欲しい）でロードするか、それをプリロードする（大量の不要なトラフィックを引き起こす）必要があります。
- その他のすべきこと、すべきでないこと
これらの質問のいくつかに対する答えは明白に思えるかもしれませんが、使いやすさに関しては、直感的な答えが常に最良であるとは限らないという経験をしました。次に、私はソフトウェア開発者なので、エンジニアの視点から物事を見る傾向があります。そして、これは、ユーザーインターフェイスの設計に向けた角度からの見方がかなり悪いことです。だからこそ、この分野の経験豊富な人々からフィードバックをもらいたいと思っています。
狭い範囲の回答を提供するので、すべての質問に答えるつもりはありません。
Andrea Amesがかなり数年前にUBCのダウンタウンキャンパスで行われたミニ会議で報告した研究によると、組み込みの支援と使いやすさはヘルプよりも優れています。彼女は、3つの異なるヘルプ配信方法を家計簿ソフトウェアと比較した経緯を語りました。ユーザーは、埋め込まれた支援をヘルプの形式として認識せず、ソフトウェアを通じて指示および案内する情報を使用するのではなく、「ソフトウェアを単に使用している」と報告します。ユーザーが問題に取り組んでいるとき、多くの場合、ユーザーが最後にしたいことは、解放して別のことを開始することです。多くのユーザーにとって、ヘルプを開始することは「何か他のもの」のカテゴリーに当てはまります。最後に聞いたところ、AndreaはIBMで働いていました。 埋め込みアシスタントラベルやボタン名ではなく、コンテキストを方向付け、説明、指示、および提供する機能を持つユーザーインターフェイスに直接表示されるテキストを指します。
ロイスホークは、迫り来る刺激反応と呼ばれる脳の不随意反応について報告しました。トラのように、視野に予期しない変化があった場合、脳は次のように反応します。1）短期記憶をフラッシュする、2）アドレナリンを放出して行動に備える、3）環境を視覚的に再スキャンする。ポップアップがこのinvoluntary応答もトリガーする場合、ヘルプポップアップでユーザーの短期記憶をフラッシュし、ストレスを増大させると、おそらくそれらはそうではないと想像できるでしょう。彼らがその経験を嫌う理由は確かですが、嫌いなのです。この研究論文は、2000年にホノルルで開催されたSTC共同リージョン7＆8会議の議事録にあります（その年だったと思います）。それのコピーを見つけるのは難しい。
人々に読んでもらうのは難しいかもしれません。時には彼らはあなたが何を望んでいるのかを知っていると思い込み、ヘルプを読むことを拒否します。明白な答えは、説明を必要としないようにアプリをシンプルにすることです。しかし、それは必ずしも簡単なことではなく、長い間苦労してきました。
しかし、コンテキスト固有のヘルプに関しては、テキストボックスにフォーカスを移すたびにヘルプが表示されるようにしました。たとえば、下のオレンジ色のボックスは、郵便番号のテキストボックスにフォーカスがある場合にのみ表示されます... 
この方法では、ヘルプを表示するためにユーザーがアイコンをクリックする必要はありません。アプリに入力している間、自然に表示されます。
もちろん、これはすべてに対して機能するわけではありません。ラジオボタンやチェックボックスでは機能しないため、これらの独自のメカニズムを考案する必要があります。小さなi情報アイコンは、質問の横でうまく機能します。
他のいくつかの質問に答えようと思います...
ポップアップ、div、または外部ページへのリンクを使用するかどうか（またはいつ使用するか）
ポップアップが好きな人はいません。可能な場合は、上の図のようにヘルプが表示される可能性がある各フィールドの横の空の場所を見つけてください。この方法では、何も覆っていません。要点を伝えながら、すべて（ヘルプを含む）をできるだけ簡潔にします。
ヘルプエントリをオンデマンドでAJAX=（ちょっと吸って、すぐに情報が欲しい）でロードするか、それをプリロードする（大量の不要なトラフィックを引き起こす）必要があります。
対処するヘルプテキストの量に基づいて、ここでオプションを比較検討する必要があります。とにかくgzip圧縮を使用している場合、すべてをHTML内に保持することは大したことではないかもしれません。
基本的な指示を提供するツールチップまたは常に表示されている領域を呼び出してから、より高度なコンテキストヘルプにリンクします。ツールヒントは疑問符などに表示される傾向がありますが、多くのツールが必要な場合は、この目的のために初期設計にある単純な呼び出し領域を使用することをお勧めします。
ツールチップまたはコールアウトはIDを使用して、正しいヘルプ項目に移動できるようにします。私は新しいウィンドウ/タブ/ポップアップ/ divを開きませんが、高度なヘルプが必要な場合は、スクリーンIDとツールチップ/コールアウトIDを使用して戻るための目立つリンクBACKを付けて、そのページに移動します。正しい場所で、フォームの入力を維持します。
高度なヘルプなので、関連する項目へのリンクと完全なヘルプナビゲーションがある「RoboHelp」スタイルのヘルプにフォールバックする傾向があります。私が取り組んでいるほとんどのアプリケーションは、さまざまなレベルのアクセス/ユーザータイプ/ロール属性で認証されているため、ヘルプでナビゲートできるものはユーザートークンを調べて、表示する情報を決定します。
これのいくつかがあなたのポイントのほとんどの宛先に役立つことを願っています。
アプリケーションが特定のトピックに焦点を当てており、頭字語/奇妙な用語でいっぱいである場合、ユーザーはそれが焦点を絞ったアプリであること（ユーザーが学習すれば生産性を高めることができる）であり、学習体験に従事したいと考えるでしょう。問題は、この意思が最初と3番目の出会いのためだけであるということです。
初めて使用する場合は、ガイド付きチュートリアルが必要かどうかをユーザーに尋ねることができます。ウィザードのように、ハイライトされたものを表示する手順でこれを作成したり、ユーザーがクリック/フォーカスした内容を聞いたり、現在の要素のヘルプを提供したりできます。 IMOこれはチュートリアルのゲーム体験のようなもので、コントロールを学び、目的を達成します。ユーザーはいつでもこのチュートリアルを終了し、必要に応じて戻ってきて、チュートリアルの招待を再度表示しないようにしてください。このエクスペリエンスは、初心者ユーザーに提供する必要があります。
中級/上級のユーザーには、頭字語とタイトル/ツールチップ要素で十分だと思います（つまり、明確なIAと直感的/一貫性のある要素がある場合）。ツールチップはユーザーの邪魔になりませんが、ユーザーが迷惑をかけずに助けを必要とする場合があります。それらはかなり離散したスタイルである必要がありますが、依然として観察可能です。
これは、オンラインヘルプのツールとしてライブチャットを使用するためのリンクです。これがお役に立てば幸いです https://www.experienceux.co.uk/ux-blog/2017/05/30/6-steps -to-delivering-first-class-live-chat-user-experience /
投稿の概要：
ライブチャットの行動を促すフレーズを簡単に表示/アクセスできるようにします（ウェブサイトの右下の領域など）。
残りのページコンテンツの後に（たとえば、数秒後）、行動を促すフレーズをロードして、より多くの注意を引きます。
人の名前と写真を表示して、「これは本当の人間ですか？」という障壁を克服するのに役立ちます。
ブラウザーウィンドウ内でチャットウィンドウをその場で読み込み、ユーザーが最小化できるようにすることで、ユーザーが並行して閲覧しやすくします。
Facebook MessengerやWhatsAppなどの使い慣れたメッセージングサービスの設計パターンに従って、ユーザーが新しいことを学ぶ必要性を減らします。
新しいメッセージの通知を表示したまま、Webチャットウィンドウを最小化できるようにします。