B側ユーザーオペレーションシステムの構築（B側ユーザーヘルプシステムの構築についてお話します）

Bサイドユーザーヘルプシステムの構築について

編集者注: ユーザーヘルプシステムは、ユーザーエクスペリエンスを向上させ、ユーザーを正しい方向に導くことができます。この記事の著者は、B サイドシステムのヘルプガイド設計プラクティスを整理し、B サイドデザイナーが独自のビジネスシステムに適したユーザーヘルプシステムを構築できるように支援することを目指しました。

読む前の注意事項:

この記事はやや学術的な内容なので、少し読みにくいかもしれません。
この設計トピック（B サイド製品のユーザーヘルプシステムの構築）に関しては、公開レベルで参照できる既成の概要記事は基本的に存在しません。これはエンタープライズ製品レベルのデザインリサーチから生まれたものなので、いくつかのコンセプトは私の現在の知識レベルと伝えたい意味に基づいて要約されています。より適切な表現があれば、訂正していただければ幸いです。
実際、マクロ的な意味では、ユーザーヘルプシステムは大きな設計提案です。実際、ユーザーエクスペリエンスにプラスの影響を与えるすべての設計ポイントを含めることができます。ただし、ここでは一定の制約とトレードオフが行われており、そうしないと記事が非常に長くなる可能性があります。
記事で言及されているポイントの中には、個別に取り出せば独立した記事として書けるものもあるため、詳細に説明されていないポイントもあるかもしれません。それは、後から補足したり深めたりする機会があるかどうかによります。
これは B エンドのユーザーヘルプシステムに関する記事ですが、実際には B エンドには C エンドよりも多くのシナリオがあるため、C エンドの製品設計にも何らかのインスピレーションがあるはずです。
この記事には確かに欠点や抜けがある。ぜひご指摘ください。興味のある友人は、このデザイントピックについて一緒に話し合うことができます。
最後に、この記事を読んでこの分野の製品設計についての知識を得た方々にとって、この記事が役に立ち、刺激となることを願っています。

B サイド製品は、特殊なビジネス属性と複雑さのため、通常、学習コストが高くなります。これらのコストは、複雑なビジネス概念やプロセスの理解に反映されるだけでなく、システム全体の相互作用コストにも反映されます。

大規模なビジネスシステムでユーザーの可用性を確保し、ユーザーに従うべき道筋を提供して正しい道を進むように誘導し、従うべき道筋がなかったりユーザーが迂回しなければならない状況を避けるために、グローバルシステムレベルで広い範囲をカバーできるBサイドユーザーヘルプシステムを導入することは、ユーザーエクスペリエンスの向上に非常に役立ちます。

1994 年にヤコブ・ニールセンが提唱した 10 のユーザビリティ原則のうち、最後の原則である「ヘルプとドキュメント」は、B サイドのユーザーヘルプシステムを構築するための中核となる原則です。理想的には、ヘルプドキュメントなしでシステムを使用できるのが最善ですが、場合によっては (特に B サイドシステム)、何らかのガイドヘルプを提供する必要があります。これらのガイド付きヘルプは、次の 3 つの条件を満たす必要があります。

直接発見できます。
ユーザーのコアタスクに集中する必要がある。
タスクの実行を支援するために、具体的な手順をリストする必要があります。

本稿では、現在の B サイドシステムで広く使用され、一定レベルのユーザー認知を形成しているヘルプガイド設計手法を整理することで、B サイド設計者が自社のビジネスシステムに適したユーザーヘルプシステムを構築できるように支援します。

この記事は、次の種類のユーザー支援設計プラクティスに従って詳細に構成されています。

まず概念を紹介しましょう。各タイプを詳しく説明する前に、まず概念を明確にしましょう。B側ユーザー機能ライフサイクルとは、簡単に言えば、典型的なユーザー (初心者ユーザー、中級ユーザー、熟練ユーザーを区別しない) が B 側システムで特定のビジネス機能を使用する完全なサイクルです。

このサイクルは、システム観察段階（主に収益性の高い SaaS 製品の場合、社内企業製品は一般的に無視できます）、システムコンタクト段階、特定の機能の使用試行段階、使用段階、使用後段階、製品フィードバック段階に分けられます。

製品は、ユーザーがシステム全体でスムーズな機能体験を得られるように、各段階で適切なヘルプとサポートをユーザーに提供する必要があります。ユーザーヘルプシステムを導入する出発点は、人間の介入を最小限に抑えながら、ユーザーの使用中に製品を自己説明可能にし、それによってユーザーの認識におけるシステムの安定性と信頼性を向上させることです。

プロアクティブヘルプの中心的な目的は、実際には、ビジネスシステムに関連する専門用語、機能紹介、操作手順、ビジネス情報フローなど、ユーザーができるだけ早く製品に慣れることができるようにすることです。システムとユーザーとのインタラクションにおいて、システムはプロアクティブなヘルプを通じてユーザーの行動意図を推測します。

「まずはこの支援を提供します。それが本当に役立つかどうかは、あなた自身で判断してください。」

一般的に、プロアクティブな支援が発生するシナリオには 2 つの種類があります。

ユーザーは、システムに接触し、システムに慣れ、システム内の特定の機能を使用しようとしている段階にあります。これらの状況は、主に狭義の初心者ユーザー向けです。
既存のユーザーが新しい機能やインターフェースに遭遇した場合（製品の機能やインターフェースが反復された場合）、この状況は広い意味ですべての初心者ユーザーに当てはまります。

現在、このタイプのヘルプには、テンプレート例、テキスト/グラフィックチュートリアル、ウィザードフォーム、ツールヒント、テキストプロンプトなど、いくつかのソリューションが一般的に存在します。

同時に、プロアクティブヘルプが現在のユーザー目標に直接関連しているかどうか、特定のユーザーの使用シナリオに依存しているかどうか、または特定の使用シナリオの外部で直接表示されるかどうかに応じて、プロアクティブヘルプはプロモーションヘルプと関連性ヘルプの 2 種類に分けられます。

プッシュヘルプは通常、ユーザーの目標とは直接関係ありません。そのデザインフォームのいくつかは、比較的ランダムなタイミングで表示され（実際のアプリケーションでは、ユーザーがシステムの指定された領域を長時間操作していないことが検出されたときなど、タイミングの選択には大まかな範囲が一般的にあります）、ユーザーに何らかのヘルプコンテンツをプッシュします。プッシュには、直接的なフラットレイと段階的な開示の 2 つの形式があります。

直接タイルスタイルは、役立つ情報を一度に表示することで効果を発揮し、新機能のリリースに通知が必要な状況に適しています。ステップバイステップの開示方法では、役立つ情報をステップごとに分解し、ユーザーが製品の機能とプロセスに慣れるようステップバイステップでガイドします。複雑なビジネス機能に関する具体的なチュートリアル指示に適しています。

2 つの表示形式にはそれぞれ長所と短所があります。前者は情報媒体が小さいため、コンテンツが多すぎると、情報の受信と理解によってユーザーの認知的負担が増加します。後者は情報キャリアの数が多いですが、その数が多すぎると頻繁な操作によってユーザーの操作負担も増加します。

同時に、どちらもサポートとしての特定のユーザー使用シナリオが欠けているため、プッシュヘルプはユーザーの通常の操作フローに一定の影響を与えるため、一般的にユーザーによって選択的に無視されます。もちろん、アプリケーションシナリオが適切であれば、前述のユーザー機能のライフサイクルに戻って、システムにコンタクトして特定の機能を使用しようとする段階では、チュートリアルとウィザードが、ユーザーが製品の初期のフレームワークを形成する上で一定のガイド役を果たします。

積極的なヘルプフォームと押しつけがましいヘルプフォームのそれぞれの具体的なヘルプデザインフォームについて説明しましょう (注: 次の各デザインフォームのリストには、特定の製品インターフェイスのスクリーンショットは含まれていませんが、比較的簡単なフレームワークの説明があります)。

1) テンプレートの例

B サイド製品におけるテンプレート例は、通常、サンプル文書、サンプルデータなど、比較的完全な例を事前にユーザーに提供します。最終的なプレゼンテーション効果をユーザーが直接体験できるようにすることで、ユーザーは同様の機能操作を実行するように促されます。もちろん、テンプレートの例では編集と削除をサポートする必要があります。

2) テキスト/グラフィックチュートリアル

チュートリアル: 初心者向けの簡単なチュートリアルがプレーンテキストで説明されています。デザイン性を重視した製品の中には、チュートリアルの際にテキストに写真やイラスト、アニメーションなどの視覚的な表現を加えるものもあります。より複雑なビジネス運用プロセスについては、ビデオによる説明やサンプルのデモンストレーションを追加することもできます。形式に関係なく、目的はユーザーがシステムの機能的特徴をすぐに理解できるようにすることです。

初心者向けのチュートリアルは通常、ユーザーが特定のページを開いたときに表示されます。最も一般的なコンテンツキャリアはポップアップウィンドウです。比較的単純なビジネスロジックや 1 ページの関数を含む関数の説明の場合、通常、ユーザーは一度にすべてを学習できます。

より複雑なビジネスロジックや複数ページにわたる機能リンクを含む機能説明の場合、通常は段階的に説明され、すべての知識ポイントが段階的に徐々に公開されるため、ユーザーは十分な時間をかけて情報を受け取って理解することができます。

もちろん、どちらのフォームでも、ユーザーはスキップするか無視するかを選択できます。システムに二次エントリーチュートリアルエントリを保持するかどうかは、各製品の成熟度に基づいて決定できます。

3) ウィザード形式

ウィザード形式とチュートリアルの違いは、明確な方向性があることです。ウィザードは、特定の機能の使用シナリオを事前にユーザーに通知するため、インターフェイス内の特定の領域を具体的に示し、特定の操作の特定の場所に応じて変更されるため、ユーザーは機能の全体的な操作ロジックとプロセスを実際に認識できます。

ウィザードは主に特定の操作のガイダンス指示に重点を置いています。システムは、ユーザーが現在いるページの主要な機能と操作を視覚的に強調表示します。ここでのデザイン処理には、通常レイヤー処理とマスク処理の 2 つの方法があります。両方のデザイン処理の中心的な目的は、ユーザーの注意を現在のページのコア機能に集中させることです。

関連するヘルプは、ユーザーのタスクと直接的または間接的な関係があります。これは通常、ユーザーの現在のタスクに関連するコンテキストに表示され、コンテキスト内のプロンプトを通じて関連する役立つコンテンツをユーザーに通知します。

一般的なデザイン形式は 2 つあります。最初の設計形式には、ユーザーインタラクションの動作が含まれます。マウスのフォーカスが対応するタスクコンポーネントに近づくか、ユーザーが対応するタスクフローを開始すると、関連するヘルプが表示されます。

関連するヘルプは、通常、ユーザーの実際の使用状況に応じて表示され、必要な関連情報をタイムリーにユーザーに提供し、現在のタスクでユーザーが抱く可能性のある質問に直接答えるため、ユーザーに無視される可能性が高くなります。

情報提示の設計形式に基づいて、関連性支援は、直接的な拡張、段階的な開示、およびエントリの提供の 3 つのカテゴリに分類できます。

関連性ヘルプは、初心者および中級ユーザーがタスクを効率的に完了するための強力なツールです。プッシュヘルプとの最大の違いは、関連性ヘルプはユーザーに積極的に「プッシュ」されるのではなく、単一のユーザーの行動によってトリガーされる点です。

以下では、アクティブ関連性ヘルプフォーム内の特定のヘルプデザインフォームについて説明します。 (注: 以下の各設計フォームのリストには、特定の製品インターフェースのスクリーンショットは含まれませんが、比較的簡単なフレームワークの説明が含まれます。)

1) ツールチップ

ツールチップは、その強力なインタラクティブ性とエクスペリエンスの自由度の高さにより非常に頻繁に表示され、一部の製品の初心者向けヘルプで悪用されることがよくあります。製品内で頻繁に使用されると、逆効果となり、製品全体が情報過多になり、肥大化してしまう可能性もあります。

マテリアルデザインのツールチップの公式定義は次のとおりです。「ツールチップを有効にすると、機能の説明など、要素を識別するテキストラベルが表示されます。」

ツールチップは単なるリマインダーです。ユーザーがコントロールをアクティブにしたときに表示され、特定の要素の機能的特徴を簡単に説明します。すべてのツールチップは、一時性、整合性、シンプルさの要件を満たす必要があります。

一時性とは、ツールチップが適切かつ短時間で表示および非表示になることを意味します。
マッチングとは、ツールチップが関連付けられている要素の近くに表示する必要があることを意味します。
簡潔さは、ツールチップに含まれるテキストコンテンツに要件を課し、可能な限り簡潔で説明的なものである必要があります。

ツールチップの基本的な設計原則は、ユーザーが混乱する可能性のある機能やモジュールを明確に示し、ユーザーの動作（ホバーやクリックの動作）を通じてタイムリーかつ直接的な拡張ヘルプを提供することです。

2) テキストプロンプト

情報を表示する最も直感的な方法として、テキストプロンプトは通常、直接的かつフラットな形式で表示されます。より多くの機能とより複雑なロジックを持つページの場合、ユーザーの行動を導くために役立つ情報をページ上に直接配置するのは、単純で大まかなデザイン方法です。

具体的な設計手法には通常、ページタイトル、ページ機能の補助的な説明、プレースホルダープロンプトなどが含まれます。

3) ウィザード形式

関連性ウィザードの設計は、実際にはプッシュウィザードとそれほど変わりません。主な違いは、関連性ウィザードは、ユーザーがマウス、キーボード、またはジェスチャーを通じて特定の機能をトリガーしたときにシステムからユーザーに提供される先制的な回答であり、ユーザーが迷ったり、途方に暮れて堂々巡りしたりする状況を減らし、回避することです。

それらのほとんどは、対応する機能を説明するのに役立ちます。プッシュウィザードは、ユーザーが何ができるかという質問に答えることに重点を置いていますが、関連性ウィザードは、ユーザーがそれをどのように行うべきか、なぜ行うべきか、そしてそれを実行した後の結果はどうなるかを答えます。

4) リンクエントリー

直接展開のバリエーションとして、エントリが提供するヘルプは、直接展開 (ページの直接表示やツールチップの表示など) では役立つ情報が多すぎるシナリオで主に現れます。ユーザーが関連するページまたはモジュールにジャンプしてヘルプを表示したり取得したりできるように、リンクエントリを提供する必要があります。したがって、このタイプのヘルプは通常、受動的なヘルプとリンクされます(受動的なヘルプについては後で詳しく説明します)。

エントリベースのヘルプの最もシンプルな設計形式は、現在の関連機能領域に (テキスト) リンクエントリを提供し、それを他の設計要素と視覚的に区別することで、ユーザーが自分でヘルプを取得できるようにガイドすることです。

同時に、異常事態に対するガイダンスも、プロアクティブな関連性支援設計の一形態です。ユーザーが正常プロセスまたは異常プロセスの終了ノードに入るときに、関連するガイドリンクの入り口を追加すると、ユーザーが正常な機能プロセスに再び入るのに非常に役立ちます。

関連性ヘルプは現在のユーザーの使用コンテキストに基づいているため、その適用範囲はプッシュヘルプよりも広くなります。ユーザーの特定のアクション目標が関係する場合はいつでも、対応する形式の関連性ヘルプを導入して、ユーザーがタスクをより効率的に完了できるようにすることができます。

積極的な援助についての理論的な説明は終了しました。それでは、プロアクティブヘルプ（駆動ヘルプと関連ヘルプを含む）の設計実践ガイダンスをまとめてみましょう。

プロアクティブヘルプのヘルプ情報は簡潔かつ要点を押さえたものである必要があります。プロアクティブヘルプはある程度ユーザーの注意をそらすため、ヘルプ情報の適時性、情報量、関連性が非常に重要になります。
主にプッシュヘルプの場合、システムによって無視されるプロアクティブなヘルプをユーザーが積極的にスキップできるようにしてください。
ヘルプコンテンツは明確でアクセスしやすく、ユーザーが必要とする可能性のある情報のプロンプトをプッシュし、ユーザーの現在のタスクに直接関連するヘルプ情報についてタイムリーで適切なプロンプトを提供する必要があります。
製品の開発段階と成熟度に応じて、プロアクティブなヘルプを他の場所から繰り返し利用できるかどうかを検討してください。

パッシブヘルプの中心的な設計目的は、初心者ユーザー、中級ユーザー、熟練ユーザーの 3 つのユーザーグループを含むユーザーが問題に遭遇したときに、システムが応答性の高いヘルプを提供できるようにすることです。簡単に言えば、組み込みのヘルプとガイダンスの指示を通じて、製品の使用時にユーザーが遭遇する質問に答えることです。

受動的なヘルプは、一般的に能動的なヘルプに依存します。製品開発の初期段階では積極的な支援が必要です。製品が一定規模まで開発され、ある程度の成熟度に達すると、受動的なヘルプを導入することで、全体的な製品エクスペリエンスを大幅に向上させることができます。

完全なパッシブヘルプは、通常、ユーザーが製品に慣れ、より効果的かつ効率的に使用できるようにすることを目的として、アクティブヘルプにいくつかの共通ヘルプ情報を統合します。 「私はここでたくさんのお手伝いをします。何か問題があれば、私が伺ってお手伝いできるかどうか確認します。」

パッシブヘルプが使用されるシナリオは比較的幅広く、ユーザー機能のライフサイクル全体に及ぶ場合もあります。ユーザーがシステムを観察し、システムに触れ、システムに慣れてシステム内の機能を利用しようとし、システムを使用し、システムを使用した後、最終的な製品のフィードバックに至るまで、受動的なヘルプを通じて、システム使用のクローズドループ全体に必要なヘルプとサポートを提供できます。

現在、このタイプのヘルプには、ヘルプセンター/ヘルプドキュメント、カスタマーサービスサポート、およびグローバル常駐機能という3つの主なソリューションがあります。

同時に、パッシブヘルプがヘルプ情報を要約形式で表示するかどうか、およびシステムにすでに関連するヘルプがあるかどうかに応じて、パッシブヘルプに要約ヘルプと一時ヘルプという別の分類ディメンションを追加できます。サマリーヘルプの設計形式は主にヘルプセンター/ヘルプドキュメントといくつかのグローバル常駐機能であり、臨時ヘルプは主にカスタマーサービスサポートです。

パッシブヘルプを設定する主な目的は、ユーザーの質問に答え、ユーザーが遭遇する問題の解決を支援することです。ライフサイクル全体を通じて、ユーザーにとってこのタイプのヘルプの存在は、製品の全体的な機能を完全に学習できるように導くことができます。

ニールセンのユーザビリティ原則である有用性原則の最も初期の設計実践は、この種の要約ヘルプです。つまり、ユーザーがシステムを理解し、機能的な操作に慣れるためには、十分に詳細で包括的なヘルプドキュメントをシステムに提供する必要があります。

複雑な業務運営と複雑なプロセスを伴う大規模な ToB システムの場合、要約ヘルプドキュメントがないと、問題に遭遇したユーザーは無力になってしまいます。これらのヘルプ情報により、製品のトレーニングコストを大幅に節約でき、ユーザーは製品全体のロジックを独自に学習できるようになります。同時に、製品自体についても、要約ヘルプによって製品全体の完全性を向上させることができます。

一般的に言えば、このタイプの要約ヘルプは、積極的に無視される可能性が最も高いものの、頻繁に言及されるユーザーヘルプ情報です。優れた要約ヘルプモジュールは、初心者ユーザーが熟練したユーザーに変身するための最も効果的な学習ツールです。

パッシブサマリーヘルプフォームの各特定のヘルプデザインフォームについて説明します (注: 次の各デザインフォームのリストには、特定の製品インターフェイスのスクリーンショットは含まれていませんが、比較的簡単なフレームワークの説明があります)。

1) ヘルプドキュメント

ヘルプドキュメント。ソフトウェア業界の発展に伴い、多くのシステムが保有するコンテンツを拡張してユーザーヘルプセンターを形成するようになるため、ここでも用語を統一するために「ヘルプセンター」という用語が使用されています。

通常、ヘルプセンターには、非常に詳細なドキュメント、ビデオチュートリアル、さまざまな説明資料が含まれます。ユーザーはヘルプセンターを使用して、知りたい質問に対する回答を得ることができますが、もちろん、システム自体が十分な詳細と完全な回答を提供することが前提となります。

一般的なヘルプセンターは、製品の紹介、製品の紹介と使用方法、よくある質問の概要の 3 つの部分で構成されます。

製品紹介セクションでは、既存の製品アーキテクチャに焦点を当て、製品の主なモジュールを紹介します。また、製品に登場するビジネス用語もリストアップして説明します。外部の SaaS 製品が関係する場合は、製品の購入にかかる料金に関する指示があります。

製品の使用開始と使用に関する部分では、製品機能の実際の適用シナリオに焦点を当て、コア機能の詳細な機能操作ガイドを提供して、ユーザーが製品機能をどのように使用して製品の効果を最大化できるかを理解できるようにします。

よくある質問 (FAQ) の要約は、主にユーザーがビジネスや製品で頻繁に遭遇する可能性のある問題に対する回答を提供するもので、ユーザーが同じ問題に遭遇したときにシステムがタイムリーな支援を提供できるようにします。

スペースの制限により、ヘルプセンターの設計方法について簡単に説明します。中核となる設計原則は、ニールセンのユーザビリティ設計原則に従うことです。

検索が簡単;
ユーザーのコアタスクをターゲットにする。
説明はできる限り段階的かつプロセス指向にする必要がありますが、テキストを使いすぎないように注意してください。

ヘルプセンターは実際には多数のドキュメントの集合体であるため、ドキュメントが構造化され、明確に提示されているかどうかが、ヘルプセンターの読みやすさを測る鍵となります。さらに、ほとんどのユーザーは実際にはドキュメントを読むことを好まないため、ドキュメント内の重要な情報を直接伝える方法についても、ヘルプセンターの設計者は慎重に検討する必要があります。

2) グローバル常駐機能

グローバル常駐関数は通常、要約されたヘルプ情報への入り口として機能します。製品ページでの具体的な表現は、それらが表す機能操作コントロールが常にインターフェイス内に存在し、ユーザーがいつでも操作できることです。一般的なものとしては、グローバル検索ボックス、ヘルプセンターの入り口、カスタマーサービスへの問い合わせの入り口、便利な操作（トップに戻る、パンくずリスト、ナビゲーションメニューの切り替えなど）などがあります。

さらに、B サイド製品のホームページ (ダッシュボードとも呼ばれます) は、通常、ユーザーを支援する役割も果たします。通常、いくつかの重要な情報の概要、リマインダー、さまざまなよく使用される機能への入り口など、ユーザーが最も関心を持ついくつかの情報を集中的に表示することで、ユーザーの操作コストを大幅に削減できます。

一時的な支援の設計形態は、一般的に、現在ほとんどの大規模および中規模の B エンド製品に構成されているカスタマーサービスサポートシステムです。

1) 顧客サービスサポートシステム

顧客サービスサポートシステムの設計は、それ自体が非常に大規模な製品設計提案です。簡単に説明します。インテリジェントロボットカスタマーサービスを導入することで、企業は単純で反復的なユーザーフィードバックの少なくとも 80% ～ 90% を解決できるようになります。ただし、製品の使用中にユーザーが通常遭遇する複雑な問題については、ヘルプとサポートのために手動のカスタマーサービスに頼る必要があります。現在、ほとんどの製品は、インテリジェントカスタマーサービス+手動カスタマーサービスのモデルを採用しています（テンセントは例外だと聞いています）。インテリジェントなカスタマーサービスは、まずシステムヘルプセンターにすでに存在する問題のフィードバックをフィルターし、次に手動のカスタマーサービスが介入します。

一方、製品開発の初期段階では、手動の顧客サービスのリソース割り当てがよりタイムリーになります。製品が一定規模まで発展すると、手動の顧客サービスのリソースは大幅に減少します。そのため、一部の製品では、グローバル永続機能の形式でページにカスタマーサービスサポートの連絡先情報も表示され、ユーザーはより積極的に対象を絞ったサポートを求めることができます。

インテリジェントなカスタマーサービスサポートと手動のカスタマーサポートの連携に関して、重要なポイントは、前者の質問ナレッジベースのビジネスカバレッジが十分に広いかどうか、質問の識別精度が十分に高いかどうか、提示された回答の満足度が十分に高いかどうかにあります。これら 3 つすべてを達成できない場合、ユーザーエクスペリエンスは大幅に低下します。

臨時ヘルプ製品の中核となるのは、システムに組み込まれた、またはサードパーティによって呼び出されるインスタントメッセージングツールのセットです。ここでのカスタマーサービスサポートシステムは、グローバル常駐機能と組み合わせて使用されることがよくあります。

受動的な臨時ヘルプ形式のカスタマーサービスシステムの設計について（注：以下の各設計形式のリストには、特定の製品インターフェースのスクリーンショットは含まれていませんが、比較的簡単なフレームワークの説明があります。）

受動的援助の理論的説明はこれで終了です。それでは、受動的援助（要約援助と一時援助を含む）の設計と実践ガイダンスをまとめてみましょう。

要約されたヘルプには、主にヘルプセンター向けのドキュメントの作成が含まれます。文書が包括的かつ詳細であることを確認する必要があります。ユーザーは積極的に助けを求めてくるので、ドキュメントの提示方法はユーザーの読書習慣に適合している必要があります。同時に、提供されたコンテンツをユーザーがより効果的に理解できるように、いくつかのデザイン形式を使用する必要があります。
臨時ヘルプは主に顧客サービスサポートシステム向けです。インテリジェントなカスタマーサービスと手動のカスタマーサービスを組み合わせることで、ユーザーの質問に迅速に回答し、ユーザーエクスペリエンスと全体的な満足度を向上させます。重要なのは、人工知能は愚かではないということです。

自動ヘルプの主な目的は、いくつかのシステム自動化処理方法を通じてシステムのフォールトトレランスを高め、ユーザーの意思決定のプレッシャーを最小限に抑えることです。システムがユーザーの期待を予測できるほどスマートであれば（または、その背後にいる製品設計者が十分に思慮深い場合）、システムはユーザーに積極的にアドバイスや支援を提供したり、ユーザーが一部のタスクを自動的に実行できるように支援したりすることもできます。

「まずは起こりうる問題の解決をお手伝いしましょう。この助けが必要になる可能性が高いと思います。」

自動化により、複雑さが主にシステムに移行し、ユーザーの意思決定手順と運用上のリスクが軽減されます。ユーザーの操作リスクが比較的低く、システム機能がそれをサポートできるシナリオでは、システムを直接配信して自動的に完了させることができます。ユーザーの操作リスクが比較的高く、システム機能がそれをほとんどサポートできないシナリオでは、必要なフォールトトレランス機能を提供しながら、ユーザーが選択できるオプションをいくつか提供できます。

自動ヘルプが表示されるシナリオも、通常、ユーザーによる製品の使用のさまざまな段階に分散しています。もちろん、この種のヘルプは C エンド製品や B エンド製品でより一般的です。現在、このタイプのヘルプには、自動リマインダー、自動入力、自動修正など、いくつかのソリューションが一般的に存在します。

同時に、自動ヘルプがユーザーの目標のアクションプロセスを直接省略するかどうかに応じて、自動ヘルプにリマインダー（半自動とも呼ばれる）ヘルプと自動ヘルプという別の分割ディメンションを追加できます。リマインダーヘルプは、主にユーザーに可能なオプションを通知し、最終的な意思決定権をユーザーに委ねるために、ユーザーが認識できるインターフェイスに反映されます。一方、自動ヘルプは、主にユーザーがタスクを自動的に処理できるように支援し、ユーザーの意思決定プロセスを直接省略します。

製品の各機能操作の詳細には自動ヘルプが散りばめられており、ユーザー満足度と製品認知度が向上します。

リマインダーヘルプは、機能の操作やユーザーインタラクションに関するフィードバックをリマインダーの形式でユーザーに提供し、ユーザーがアクションを続行するかどうかを決定できるようにします。 B サイドシステムにおける最も一般的な設計形式は、データ入力のエラー報告、事前設定されたデフォルトパラメータ、データ入力後の推奨オプション、重要なデータのデフォルトの前面表示、自動ファジーマッチング、最後の入力内容の記憶と自動表示などです。核心は、ユーザーが最も必要とする可能性の高い情報をユーザーに近づけ、それによってインタラクションコストを削減することです。

自動ヘルプは、ユーザーの対話プロセスを直接省略し、対応するアクションをシステムのバックグラウンドで自動処理します。 B 側システムの一般的な設計形態としては、データ入力形式の制限 (指定された形式に準拠していないデータの自動修正など)、テキスト入力ミスの自動スペル修正、データタイプの自動識別と分類、およびフォールトトレランスの高い検索マッチングなどがあります。中心となるポイントは、システムがユーザーの意思決定を支援し、ユーザーの作業の一部を直接的に解放することです。

自動ヘルプを使用するかどうかに関して、まず考慮すべきことは、現在の対象シナリオにおいて、ユーザーに代わって特定の決定を下すために自動ヘルプが必要かどうかです。自動ヘルプは、製品設計者がそれがユーザーが本当に必要としているものであると 100% 確信している場合にのみ使用してください。一歩引いて考えてみると、これがおそらくユーザーが必要としているものであると推測される場合は、リマインダーヘルプを使用できます。ユーザーの実際の目的が不明な場合は、ユーザーの意図に反する可能性のある決定を下さないでください。

結局のところ、自動ヘルプがうまく行われれば、それは全体的な製品エクスペリエンスにとって最高のものとなるでしょうが、うまく行われなければ、ユーザーの実際の製品エクスペリエンスに深刻な影響を与えることになります。

B サイド製品のユーザーヘルプは、システム全体に散在する単一ポイントのエクスペリエンスであり、何らかの設計手法を通じてシステム内のポイントを統合して接続する必要があります。設計方法は、ユーザーからのフィードバック、ユーザーへの通知、概要ヘルプセンターなどの形をとることができます。

ユーザーヘルプシステム全体は、実際の環境におけるスーパーマーケットのガイドシステムのようなものです。能動的なヘルプは温かいウェイターのようなもので、受動的なヘルプはサービスフロントデスクのようなものです。いくつかのヘルプ方法を通じてユーザーの行動をガイドし、複雑なシステム全体の中でユーザーが迷子にならないようにすることが、デザインの重要なポイントです。

最後に、B 側ユーザーヘルプシステムの構造図を示します。それがあなたにとって何らかのインスピレーションと助けとなることを願っています。

著者：Mu Ge;公式アカウント: UX Chocolate デザインの要点はどこにあるのでしょうか?

タイトル画像はCC0ライセンスに基づいてUnsplashから引用しています

<<: aigc コンテンツ操作 (現在の AIGC は私の仕事にどの程度の権限を与えてくれますか?)

>>: Facebook は自社製品をどのように運営しているのでしょうか? （Facebookの新たな製品運営とプロモーション方法、対外貿易にとって最も困難な年、一緒に社内スキルを練習しましょう）