更新スケジュールについては、こちらを参照してください。

システムは、ユーザーがアプリケーションにアクセスして簡単に使用できるようにすることで、ユーザーがより質の高い作業ができたと感じ、システムでアプリケーションを使用したくなるようにすることで、魅力的な行動を示します。

エンゲージメント行動は、ユーザーの採用だけでなく、全体的な従業員満足度や顧客満足度にも直接関連するため、ビジネスにとって重要です。エンゲージ動作は、サポート要求を減らすのにも役立ち、ユーザーからの機能要求の品質を高めるのに役立ちます。

エンゲージ行動を作成する際の課題の 1 つは、客観的な指標のみで測定することが難しいことです。代わりに、ユーザーの主観的なエクスペリエンスによって評価されます。ユーザーは、エンゲージアプリケーションが真の価値を提供すると感じています。魅力的なアプリケーションは、アクセス可能で、邪魔にならず、わかりやすくなっています。最小限のオンボーディングとトレーニングが必要です。また、明確な方法を使用して、ユーザーエラーを積極的に防止します。

もう 1 つの課題は、エンゲージメントの目標が、システムのユーザーインタラクションの種別によって異なることが多いことです。たとえば、ケースを管理する内部ユーザーと、Web サイトのフォームから情報を送信する外部ユーザーの目標を設定できます。魅力的なシステムを設計するためには、機能とページの組み立てを開始する前に、作成しようとしているエンゲージメントの種別とユーザーがエンゲージを希望する理由を慎重に検討する必要があります。

ユーザーエクスペリエンス (UX) デザイナーと連携することで、魅力的なアプリケーションの配信に関してより効果的な意思決定を行うことができます。アーキテクチャの観点からは、ユーザーの採用と保持は健全なシステムの重要な要素です。魅力的なアーキテクチャにより、ユーザーが楽しくないシステムで時間を費やすことを避けるためにプロセスを急いだり、ステップをスキップしたりすることによって発生するデータ品質の問題の可能性を低減できます。対外システムの場合、魅力的なアーキテクチャにより、システムを扱いやすくなった顧客が組織でより多くのビジネスを行うことを選択できるため、収益と顧客維持率を高めることができます。

合理化された有益な環境を提供することに集中することで、より魅力的なアプリケーションを作成できます。

合理化されたアプリケーションは操作が簡単で、情報やデータ入力タスクを明確に表示でき、さまざまなフォーム要素に適応できます。合理化されたアプリケーションには、ユーザーが他の一般的なアプリケーションで使い慣れた環境パターンも含まれています。たとえば、ほとんどの Web ブラウザーでは、ユーザーがリンクを右クリックすると、最上位のオプションとして「新しいタブで開く」が表示されます。タブを含む合理化されたアプリケーションも同じパターンに従います。

非効率的なアプリケーション環境の影響は、個々のアプリケーションの範囲を超えて広がる可能性があります。アプリケーション エクスペリエンスが低いと、ユーザーの Trust が損なわれます。より多くの種類のビジネスクリティカルなアプリケーションや顧客向けアプリケーションがデジタルチャネルに移行すると、主要な関係者のロイヤルティが失われる可能性があります。

アプリケーションの複雑さ、フォーム設計、フォーム要素に意図的に取り組むことで、アプリケーションをより合理化できます。

アプリケーションの複雑さを最小限に抑えると、ユーザーには関連するメニュー項目、タブ、ナビゲーションコントロールのみが表示されます。ユーザーグループ、ユーザー権限、適切なアプリケーション環境間の対応付けを作成する必要があります。これらの対応付けを使用して、特定のユーザーに表示するアプリケーション環境を理解し、その環境を提供するために必要な論理的な制御をアプリケーションに提供します。

ユーザーが複雑すぎると、さまざまなエクスペリエンスが低下する可能性があります。

• ユーザーには、不要なタブや無関係なタブが表示され、空白の画面に移動し、無効またはブロックされたリンクが表示されることがよくあります。
• 「ロールが X の場合、このタブを無視...」のような不要な指示や役に立たない指示は、トレーニングやイネーブルメント資料に表示されます。
• ナビゲーションメニューが乱雑になっていると、ユーザーは作業に必要な項目を見つけるために余分な時間を費やすことになります。

これらのエクスペリエンスが低いと、採用率と満足度が低下します。

アプリケーションの適切な複雑さのレベルを判断するときは、次の点を考慮してください。

• ユーザーが実行する必要がある作業の優先度に基づいてメニュー、タブ、その他のナビゲーションコントロールを整理します。
• ユーザーがアプリケーションを使用するためだけに学習する必要がある新しい動作の導入は避けてください。
• ユーザーがユーザーインターフェースの側面をカスタマイズできるようにする機能へのアクセス権を削除しないでください。
• 権限セットを使用して、拡張または縮小されたナビゲーションオプションを提供します。
• Lightning ページの有効化の割り当てを合理化します。アプリケーションあたりのアクティブな Lightning ページ数を最小限に抑えます。動的フォーム、権限セット、条件付き表示を使用して、項目をアプリケーションの Lightning ページに追加します。これは、プロファイルによって有効化および割り当てられた複数の Lightning ページを管理する代わりに実行します。

次のパターンとアンチパターンのリストは、Salesforce 組織でのアプリケーションの複雑さ管理が適切 (および不適切) であることを示しています。これらを使用して、アプリケーション設計を検証または改善できます。

アプリケーションの複雑さの管理に役立つ Salesforce ツールについての詳細は、「Tools Relevant to Engaging (エンゲージメントに関連するツール)」を参照してください。

合理化されたフォームでは、情報が論理シーケンスに整理され、迅速なデータ入力がサポートされ、必要なステップが最小限に抑えられます。また、便利なクライアント側のデータ検証メッセージも使用できるため、フォームの送信サイクルを繰り返す必要がなくなります。

フォームを設計するときは、次の点を考慮してください。

• 関連フィールドをグループ化します。プロセスまたはデータ入力タスクの同じステップに関連する項目をグループ化します。現在の ToDo に直接関連しない項目を削除します。
• データ入力と検証を早期に行います。ユーザーがデータを入力する必要がある項目は、フォームの早い段階で表示されます。データ書式設定やデータの欠落に関する問題を項目レベルでできるだけ早く (つまり、ユーザーが次のステップに移動したりフォームを送信したりする前に) 明らかにすることをお勧めします。また、ユーザーが項目にデータを入力する前に項目レベルのエラーを表示しないようにします。
• データ入力タスクを最小限に抑えます。できるだけ多くの項目を事前入力またはオートコンプリートして、データ入力エラーを最小限に抑え、効率を向上させます。必須または重要なデータの入力のみをユーザーに求めます。現在のビジネスプロセスに関連しないデータ入力を排除します。可能な場合は、自由形式のテキスト項目の代わりに選択リストを使用して、有効なオプションの選択を適用し、同じ回答のバリエーションを減らします。
• サーバへの送信を最小限に抑えます。複数ステップフォームでデータを複数回サーバーに送信しないでください。すべてのカスタム LWC または Aura コンポーネントでクライアント側キャッシュを使用してナビゲーションまたはページネーションアクションを処理します。(Salesforce Lightning Experience および Salesforce モバイルアプリケーションでは、デフォルトでクライアント側キャッシュが使用されます)。ユーザーがサーバーにデータを 1 回のみ送信するようにフォームを設計します。フォームを送信する前にクライアント側でユーザー入力を検証します。これにより、意図しないユーザー送信を最小限に抑え、重複またはダーティなトランザクションによってバックエンドの帯域幅が消費されることを防止し、より適切なデータ処理を設計するのに役立ちます。
• フォーム状態の管理。クライアント側キャッシュは、ナビゲーションやページネーションなどの動作に役立つだけでなく、断続的な接続の問題によるデータ損失を最小限に抑えるのに役立ちます。また、状態を効果的に管理することで、アプリケーションはサーバーへのデータ送信を適切に調整し、トランザクションの重複を防止できます。また、サーバー側のアクションの状況に基づいて、関連性の高いメッセージをタイムリーにユーザーに表示できます。合理化されたフォームでは、データ操作は 1 回のみ送信され、ユーザーはサーバーで長時間実行されている操作が完了するまで待つ必要はありません。
• アクセシビリティ標準に準拠します。アプリケーションの利用者を最大化し、すべての顧客をアプリケーションの対象に含めるには、フォーム設計でアクセシビリティの標準を適用します。

合理化されたフォームは、アプリケーションのデータの整合性を高め、アプリケーションがユーザーにどれほど役立つかを示すのに役立ちます。また、ユーザーはエラーに対処しやすくなり、フォーム送信の状態を明確に把握できるため、サポートチケットや要求を減らすこともできます。さらに、合理化されたフォームにより、迅速かつ効率的なデータ入力が可能になり、ユーザーはより長い時間かかるプロセスが完了するまで待機することなく、さらに作業を進めることができます。

次のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不適切な) フォーム設計を示しています。フォームデザインの検証や改善に使用できます。

より合理化されたフォームの作成に役立つ Salesforce ツールについての詳細は、「Tools Relevant to Engaging (エンゲージメントに関連するツール)」を参照してください。使用事例に適したフォームツールの選択に関する具体的な指針については、「Architect’s Decision Guide to Building Forms with Salesforce (Salesforce を使用したフォームの作成に関するアーキテクトの決定ガイド)」を参照してください。

エンゲージメントアプリケーションは、さまざまなデバイスやインタラクション種別、フォーム要素に適切に適応します。デバイス種別に応じて、さまざまな種類のユーザー操作が容易 (または困難) になり、フォームや項目の読みやすさも変わります。フォーム要素は、画面のサイズに加えて、ユーザーが画面を操作する方法も示します。タッチスクリーンを使用するデバイスが増加し、一部のユーザーはアクセシビリティのために特殊なデバイスを使用することもあります。フォームを設計するときは、次の点を考慮してください。

フォーム要素のバリエーションを考慮しないと、次のようなさまざまな問題が発生する可能性があります。

• データ品質が低い
• 使用できないアプリケーションインターフェース
• サポートエージェントのトラブルシューティングまたは「代理注文」セッションの増加
• ユーザーの採用率が低い、有効ユーザー数が少ない、アプリケーションの「放棄」率が高い

Salesforce アプリケーションのフォーム要素間の相互運用性を考慮して設計するには、次の点を考慮してください。

• すべてのアプリケーションでサポートされているフォーム要素を特定します。
• **入力メソッドとユーザーのアクセシビリティのニーズを特定します。**詳細は、「アクセシビリティ」を参照してください。
• 可能な場合は、標準機能を使用してデバイス間で適応型環境を提供します。
  • Salesforce が提供する Lightning ページテンプレートでは、デフォルトでさまざまなフォーム要素がサポートされます。Aura を使用してカスタム Lightning ページテンプレートを開発する場合、開発者はフォーム要素情報をコンポーネント設計ファイルに組み込む必要があります。
  • Salesforce が提供する標準ページコンポーネントは、サポートされるフォーム要素での表示を処理します。LWC または Aura を使用してカスタムコンポーネントを作成する場合、開発者は幅認識を処理し (Aura と LWC では実装が異なります)、コンポーネントの設計ファイル内でフォーム要素のサポートを宣言する必要があります。
• **すべてのデバイスでフォーム**の合理化に関するガイダンスに従います。
• **主要なフォーム要素のテスト計画 (および適切なテスト) を作成します。**理想的には、すべてのアプリケーションのすべてのデバイスとフォーム要素でテストします。ただし、フォーム要素テスト用に適切なデバイス (またはデバイスシミュレーター) を設定するのは、大きな投資になる可能性があります。特定のアプリケーションまたはアプリケーションセットにモバイルまたはタブレットのユーザーセットが多数含まれることがわかっている場合は、モバイルおよびタブレットフォーム要素でそれらのアプリケーションの正確なテストを優先します。

次のパターンとアンチパターンのリストは、Salesforce 組織でのフォーム要素の適切な (および不適切な) 認識を示しています。これらを使用して、作成前にデザインを検証したり、リファクタリングが必要なページを識別したりできます。

効果的なフォーム要素設計のための Salesforce ツールについての詳細は、「Tools Relevant to Engaging (エンゲージメントに関連するツール)」を参照してください。

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーで合理化されたアプリケーションのより多くのパターンを検出します。

役に立つアプリケーションを使用すると、ユーザーは集中の邪魔や中断が少なく、より強力かつ効果的に作業できます。

役に立つアプリケーションは、手動エラーを軽減し、必要なときに必要な場所でユーザーにフィードバックを提供することで、データの整合性を維持します。ユーザーが現在および次に焦点を絞る必要があるアクションを把握し、問題をより迅速に解決するための関連情報を提供します。ユーザーのアクションと有意義な影響や成果を明確に結び付けることができます。

通知とメッセージ、アプリケーション内ガイダンス、レコグニションと報奨の 3 つの主要な習慣を使用して、より便利なアプリケーションを作成できます。

通知とメッセージは、ユーザーが最新情報を把握するのに役立ちます。

適切に設計された通知およびメッセージングシステムは、重要な意思決定に必要な情報をタイムリーにユーザーに提供することで、エンゲージメントと生産性を向上させることができます。不適切に設計された通知およびメッセージングシステム (関連性もタイムリー性もないメッセージを表示するシステム) は、逆の効果をもたらします。内部ユーザーは通知をすぐに無効にしたり無視したりして、重要なビジネスプロセスに影響する可能性のある正当なメッセージを見逃します。無意味な通知にうんざりした顧客やその他の外部ユーザーは、システムの使用を完全に停止する場合があります。

アプリケーションによるユーザーへの通知とメッセージの送信の処理方法を決定するときは、次の点を考慮してください。

• **エラーの場合は、最後の手段として通知とメッセージを使用します。**人間の介入なしで特定の種類のエラーを修正できるバックエンド処理を使用して、システムのエラー処理を設計します。ToDo を完了できない重大なエラーに関するメッセージのみをユーザーに送信します。同様に、ビジネスユーザーが自分で実行できる (する必要がある) 是正措置がある場合のみエラーメッセージを送信します。追加のエラーメッセージや詳細は、レポートで提供したり、非同期方法を使用してテクニカルサポートスタッフに送信してフォローアップしたりできます。
• 関連性、緊急性、適時性に基づいてメッセージ種別を選択します。メッセージの種別によって、ブロックまたは中断動作のレベルが異なります。通知は「ブロック」メッセージの一種で、作業を続行する前にユーザーに通知の確認を求めるものです。エラーメッセージと同様に、通知は慎重に使用する必要があります。トースト通知はノンブロッキングで、異なる永続性動作を持つことができ、さまざまな種類のメッセージの使用事例をサポートします。最も邪魔にならないメッセージは、アプリケーション内通知またはメールです。これらは、ユーザーが選択したタイミングと方法で処理できる情報を提供するために最適です。
• 次に何を実行する必要があるかを検討します。通知には情報的なもの (成功メッセージなど) もあれば、ユーザーが何らかのアクションを実行する必要があるものもあります。通知を設計するときは、通知自体だけでなく、ユーザーがアクションを実行するために必要な追加情報も考慮してください。アクション可能なすべての通知に、ユーザーが追加情報を検索したり、フォローアップ手順を完了したりできる明確な手順やリンクを含めます。
• 読みやすさに重点を置く。各通知の目的と、それに応じてユーザーが実行する必要のある次のステップを明確に伝えます。メッセージは、基盤となるシステムの内部の仕組みに精通していないビジネスユーザーが理解できるようにする必要があります。メッセージを作成するときは、アクセシビリティ標準に従って、メッセージが表示される地域のサポートユーザーにローカライズしてください。

アプリケーションビルダーが一貫した方法に従うことができるように、どのような場合に通知やさまざまな種類のエラーを使用するかを設計標準に含めます。

次のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不適切な) 通知とメッセージングを示しています。これらを使用して、構築前に設計を検証したり、リファクタリングが必要な利用状況を特定したりできます。

通知およびメッセージング用の Salesforce ツールについての詳細は、「Tools Relevant to Engaging (エンゲージメントに関連するツール)」を参照してください。

アプリケーション内ガイダンスは、複雑なワークフローを理解しやすくしたり(必ず最初に最適化しておく必要があります)、新しいスタッフのオンボーディングを支援したりする強力な方法です。これは、プロセスの変更の導入、新機能の強調表示、自動化されたスケーラブルなトレーニングの配布を行う優れた方法です。ただし、慎重に実装しないと、アプリケーション内ガイダンスが過度に使用される可能性があります。ポップアップやアラートを頻繁に行うと、ユーザーの騒音や中断が大きくなり、生産性が低下する可能性があります。また、アプリケーション内ガイダンスの使用頻度が低いため、リリースおよび変更管理プロセスが煩雑になる可能性があります (特にシンプルな機能)。最終的に、アプリケーション内ガイダンスの過剰使用と過少使用のどちらも、ビジネスに次のようなリスクをもたらす問題を引き起こします。

• データの整合性の低下
• ユーザーエラーの増加
• ユーザーのストレスレベルが高く、ユーザーの満足度が低い
• ユーザーの生産性の低下

アプリケーション内ガイダンスは、ユーザーの考え方によって「多すぎる」か「十分ではない」かが決まるため、シナリオごとに異なる方法で使用します。新しいシステムを初めて導入するユーザーは、使い慣れたシステムの新機能について単に学習するユーザーよりも頻繁にメッセージングが必要になります。

効果的なアプリケーション内ガイダンスを作成するための鍵を次に示します。

• 設計標準を開発します。アプリケーション内ガイダンスが公開されすぎると、ユーザーがメッセージを頻繁に破棄したり無視したりする可能性があります。この時点で、アプリケーション内ガイダンスはリソースではなく厄介なものになります。プロンプト、ウォークスルー、項目レベルのヘルプテキスト、検証メッセージ、パス、画面フローなどを使用するタイミングを明確にするために、設計標準を定義します。
• **ガイダンス実装の優先順位付けシステムを作成します。**アプリケーション内ガイダンスのすべての使用事例を実装する必要はありません。代わりに、次の質問に優先順位を付けます。より直観的なワークフローを作成するために、より適切な項目名、ボタンの表示ラベルの明示化、より優れたフォーム設計、およびプロセスの最適化をシンプルに使用できるのはどこか?パスに役に立つテキストやリンクを追加できる場所は?アプリケーション内ガイダンスがビジネスコストに与える影響は?ユーザーにメッセージを配信する頻度は?また、すべての関係者が確認できるように、実装がロードマップに含まれていることを確認します。
• **ユーザーを有効な (および提案された) アプリケーション内ガイダンスに対応付けます。**ユーザーをアプリケーション内ガイダンスに対応付けると、ユーザーに表示されるアプリケーション内ガイダンスが多すぎることによる「ヘルプの過負荷」を特定して防止できます。これは多くの場合、チームが特定の使用事例について偏狭に考えすぎているため、サイロ化された開発の結果です。ユーザーが何にさらされるかの全体像を維持することは、大規模な組織では特に重要です。ロードマップにガイダンスの実装を含めることも役立ちます。
• **フィードバックを収集して改善に役立てます。**アプリケーション内ガイダンスの利用状況に関するデータを確認し、アプリケーション内ガイダンスのリリースの効果を判断するために使用します。ガイダンス作成者を支援するために、ユーザーが自由回答型のフィードバックも提供してください。

次のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不適切な) アプリケーション内ガイダンスを示しています。これを使用して、構築前に設計を検証し、リファクタリングが必要な実装を特定できます。

アプリケーション内ガイダンス用の Salesforce ツールについての詳細は、「Tools Relevant to Engaging (エンゲージメントに関連するツール)」を参照してください。

レコグニションと報奨をアプリケーションに組み込むことで、そのアプリケーションを使用する個人は仕事の影響をより身近に感じ、貢献度、生産性、パフォーマンスの価値をよりよく理解できます。また、ロイヤルティとエンゲージメントを解放する強力な方法でもあります。

レコグニションやアプリケーションエクスペリエンスの報奨を与えるように設計していないと、次のようなさまざまな問題が発生する可能性があります。

• 進行状況や進行速度の理解に苦労しているユーザー
• 目標や未完了の作業への進行状況に関する混乱
• 自分の ToDo と「全体像」との関連性を感じていない非生産的なユーザーが多い
• 手動の低レベルの目標レポートによる管理時間の浪費

報奨を与えるアプリケーションエクスペリエンスは、会社の文化、ポリシー、標準、および個々のユーザーのコンテキストと設定によって異なるため、設計と提供が難しい場合があります。デスクトップユーザーが喜びや感謝を感じるのに役立つ機能は、モバイルのユーザーや、騒がしく忙しいホームオフィスで作業をしようとしているユーザーにとって苛立ちとなる可能性があります。アプリケーションを使用して非公開または機密性の高い情報を操作しているユーザーは、紙吹雪やバッジのような形でのマイルストーンに関するコミュニケーションに感謝しない可能性があります。一方、分散した営業チームは、このようなゲーミフィケーションを適切なアプリケーション環境として認識できます。最終的に、選択する実装パターンは、チームのユーザーエクスペリエンス (UX) デザイナーと協力して決定することをお勧めします。

アーキテクチャについては、ユーザーが評価され、報われると感じるのに役立つ機能をアプリケーションで実装する方法と場所を特定することが重要です。また、これらの機能によってアプリケーションの再利用性が低下したり、実際のビジネス バリューが失われる可能性がある方法と場所を理解することも重要です。

Salesforce アプリケーションでレコグニションと報奨を評価するときには、次の点を考慮してください。

• **ユーザーが自分の進捗状況とチーム全体の統計を確認する方法と場所は?**レポートは重要ですが、多くの場合、サマリーデータが含まれており、日常業務のコンテキストを見落としてしまう可能性があります。Lightning アプリケーション・ビルダーなどのツールを使用して、アプリケーションのコンテキスト内のレコード画面にグラフやダッシュボードを埋め込むことができます。これにより、ユーザーは日常業務に取り組むときにその影響や進行状況を理解できます。
• **ユーザーはどのように認識される必要がありますか?**これは、チームまたは個人の設定によって異なる場合があります。場合によっては、スーパーバイザーはユーザーの進行状況に関するメッセージを表示して、より大きなグループと共有できます。レコグニションは、従業員の士気を高めるのに役立つ追加特典になる場合もあります。また、特定の ToDo やプロジェクトの進行状況の通知をユーザーのみにすることを希望する場合もあります。

以下のパターンとアンチパターンのリストは、Salesforce 組織での適切な (および不適切な) 認識と報奨を示しています。これを使用して、構築前に設計を検証し、リファクタリングが必要な実装を特定できます。

評価と報奨のための Salesforce ツールについての詳細は、「Tools Relevant to Engaging (エンゲージメントに関連するツール)」を参照してください。

次の表に、組織で検索 (または作成) するパターンと、回避または修正の対象となるアンチパターンの選択を示します。

✨ パターン & アンチパターンエクスプローラーで、役立つアプリケーションの他のパターンを見つけます。

Salesforce Well-Architected の関連性の維持にご協力ください。このコンテンツに関するフィードバックをいただくためのアンケートにご協力ください。また、今後の展望についてもお聞かせください。