在这里阅读我们的更新计划。

系统通过使人们能够轻松访问和使用应用程序、让用户感觉他们正在完成更高质量的工作以及让人们希望在系统中使用应用程序来展示引人入胜的行为。

提供吸引人的行为对业务很重要，因为它直接关系到用户的采用以及整体工作人员和客户满意度。参与行为也有助于减少支持请求，并有助于提高用户功能请求的质量。

创建吸引人的行为的挑战之一是很难仅通过客观度量来衡量。相反，它是根据用户的主观体验来衡量的；用户觉得吸引人的应用程序提供了真正的价值。参与应用程序是可访问的、非侵入性的、易于理解的。他们需要最少的入职培训和培训。他们使用明确的方法来主动防止用户错误。

另一个挑战是，参与目标通常会随着系统中不同类型的用户交互而变化。例如，对于管理个案的内部用户，您可能有一组目标，对于通过网站上的表格提交信息的外部用户，您可能有一组目标。要设计参与系统，您需要仔细考虑您尝试创建的参与类型，以及用户为什么希望在您开始组装功能和页面之前参与。

与用户体验 (UX) 设计师合作将有助于您在交付引人入胜的应用程序时做出更有效的决策。从架构的角度来看，用户采用和保留是健康系统的重要组成部分。采用架构可以减少用户匆忙完成流程或跳过步骤以避免在不喜欢使用的系统中花费时间而导致数据质量问题的可能性。对于面向外部的系统，引人入胜的架构可以提高收入和留住客户，因为发现您的系统更易于使用的客户会选择与贵组织开展更多业务。

您可以通过专注于提供简化和有帮助的体验来创建更吸引人的应用程序。

简化的应用程序易于导航，清晰显示信息和数据输入任务，并适应各种外形规格。简化的应用程序还具有用户在其他常用应用程序中已经习惯的体验模式。例如，当用户右键单击链接时，大多数 Web 浏览器会将“在新选项卡中打开”显示为顶部选项。包含选项卡的简化应用程序将遵循相同的模式。

低效应用程序体验的影响可能远远超出单个应用程序。糟糕的应用程序体验会削弱用户的 Trust。随着更多类型的业务关键型和面向客户的应用程序转向数字渠道，这会损失公司的关键利益相关者的忠诚度。

您可以通过有意处理应用程序复杂性、外形设计和外形规格来更好地简化您的应用程序。

最小化应用程序复杂性意味着用户只能看到相关的菜单项、选项卡和导航控制。您需要创建用户组、用户权限和正确应用程序体验之间的映射。使用这些映射来了解要向给定用户提供的应用程序体验，然后确保您的应用程序具有提供这种体验所需的逻辑控制。

为用户呈现过于复杂的应用程序会导致各种不良体验：

• 用户经常看到不必要或不相关的选项卡，导航到空白屏幕，并遇到禁用或阻止的链接。
• 不必要或无帮助的说明，例如“如果您的角色是 X...，请忽略此选项卡”显示在培训和支持材料中。
• 混乱的导航菜单迫使用户花费额外的时间来查找完成工作所需的项目。

这些糟糕的体验导致采用率和满意度低。

在确定应用程序复杂性的正确级别时，请考虑以下事项：

• 根据用户所需工作的优先级，组织菜单、选项卡和其他导航控件。
• 避免引入用户必须单独学习的新行为，以便他们可以使用您的应用程序。
• 请勿删除对允许用户自定义用户界面各方面的功能的访问权限。
• 使用权限集提供扩展或减少导航选项。
• 简化 Lightning 页面激活分配。最小化每个应用程序的活动 Lightning 页面数量。使用动态表单、权限集和条件渲染将项目添加到应用程序中的 Lightning 页面。执行此操作，而不是维护由简档激活和分配的多个 Lightning 页面。

以下模式和反模式列表显示了 Salesforce 组织中正确(和差)的应用程序复杂性管理。您可以使用这些来验证或改进您的应用程序设计。

要了解有关可帮助您管理应用程序复杂性的 Salesforce 工具的更多信息，请参阅相关工具。

简化的表单将信息组织成逻辑序列，支持快速数据输入，并最大限度地减少所需的步骤。它们还允许有用的客户端数据验证消息，并消除重复的表单提交周期。

在设计表单时考虑以下事项：

• 将相关字段分组。对与流程或数据输入任务中的相同步骤相关的字段进行分组。删除与当前任务没有直接关联的字段。
• 尽早输入和验证数据。需要用户输入数据的字段应尽早显示在表单中。最佳实践是在字段级别尽快显示数据格式化或缺失数据的问题（即在用户尝试导航到下一步或提交表单之前）。此外，避免在用户有机会将数据输入字段之前显示字段级错误。
• 最小化数据输入任务。预填写或自动填写尽可能多的字段，以最大限度地减少数据输入错误并提高效率。仅要求用户输入重要或关键数据。消除任何与当前业务流程无关的数据输入。尽可能使用选项列表而不是自由格式文本字段来强制选择有效选项，并减少相同答案的变体。
• 最小化对服务器的提交。请勿让多步骤表单多次向服务器提交数据。确保所有自定义 LWC 或 Aura 组件使用客户端缓存来处理导航或分页操作。（Salesforce Lightning Experience 和 Salesforce 移动应用程序默认使用客户端缓存。）设计表单，以便用户仅向服务器提交一次数据。在提交表单之前，验证客户端的用户输入。这将最大限度地减少意外的用户提交，防止重复或脏事务在后端消耗带宽，并帮助您设计更好的数据处理。
• 管理表单状态。客户端缓存不仅有助于导航和分页等行为，还有助于最大限度地减少间歇性连接问题导致的数据丢失。有效地管理状态还意味着应用程序可以适当地编排向服务器提交的数据，防止重复事务，以及根据服务器端操作的状态向用户提供相关和及时的消息。简化的表单仅提交一次数据操作，不需要用户等待服务器上长时间运行的操作完成。
• 遵循无障碍标准。为了最大化应用程序的受众并帮助确保它们包括所有客户，请在表单设计中强制执行可访问性标准。

简化的表单有助于提高应用程序中的数据完整性，以及应用程序对用户的帮助。它们还可以减少支持票证和请求，因为用户能够更好地处理错误并清楚地了解他们的表单提交状态。此外，简化的表单支持快速高效的数据输入，并确保用户无需等待运行时间更长的流程才能完成进一步的工作。

以下模式和反模式列表显示了 Salesforce 组织中正确(和糟糕)的表单设计。您可以使用这些来验证或改进您的表单设计。

要了解有关 Salesforce 工具的更多信息，这些工具可以帮助您构建更简化的表单，请参见相关参与工具。有关为您的用例选择正确表单工具的更具体的指导，请查看架构师使用 Salesforce 构建表单的决策指南。

参与应用程序可以优雅地适应不同的设备和交互类型，或外形规格。根据设备类型，不同类型的用户交互将更容易（或更难），表单和字段的可读性将发生变化。请记住，除了屏幕尺寸之外，外形规格也是指您的用户如何与屏幕交互。越来越多的设备现在拥有触摸屏,一些用户也可能使用特殊设备实现无障碍。在设计表单时，请确保考虑这些因素。

不考虑外形规格的变化会导致各种问题，包括：

• 数据质量差
• 不可用的应用程序界面
• 支持客服人员的更多故障排除或“代表”会话
• 用户采用率低、活跃用户数量少，以及应用程序“放弃”率高

要在 Salesforce 应用程序中设计跨外形规格的互操作性，请考虑以下事项：

• 确定每个应用程序支持的外形规格
• **确定用户的输入方法和可访问性需求。**有关更多信息，请查看可访问性。
• 使用标准功能，尽可能跨设备提供自适应体验。
  • Salesforce 提供的 Lightning 页面模板默认支持不同的外形规格。如果您选择使用 Aura 开发自定义 Lightning 页面模板，开发人员将需要将外形规格信息合并到组件设计文件中。
  • Salesforce 提供的标准页面组件可为您处理跨支持的外形规格的渲染。如果您使用 LWC 或 Aura 创建自定义组件，开发人员将需要处理宽度感知（Aura 和 LWC 之间存在实施差异），并在组件的设计文件中声明外形规格支持。
• **请遵循所有设备上**的简化表单指南。
• **为关键外形规格创建测试计划(和良好测试)。**理想情况下，您会为所有应用程序测试所有设备和外形规格。但是，为外形规格测试设置正确的设备（或设备模拟器）是一项重大投资。如果您知道某个应用程序或一组应用程序将在移动设备或平板电脑上拥有大量用户，请优先考虑在移动设备和平板电脑外形规格上对这些应用程序进行准确测试。

以下模式和反模式列表显示了 Salesforce 组织中正确(和差)外形规格意识的外观。您可以在构建之前使用这些来验证您的设计，或者确定需要重构的页面。

要了解有关适用于有效外形设计的 Salesforce 工具的更多信息，请参阅相关工具。

下表显示了在您的组织中要查找（或构建）的模式的选择，以及要避免或针对补救的反模式。

✨ 在模式和反模式探索器中，发现简化应用程序的更多模式。

有用的应用程序使用户感觉更有力和更有效，干扰或中断更少。

有用的应用程序通过减少手动错误并在用户需要的时间和地点向他们提供反馈来帮助保持数据完整性。它们帮助用户了解他们现在和下一步需要关注什么操作，并提供相关信息来帮助用户更快地解决他们自己的问题。它们提供了用户的行动和有意义的影响或成就之间的明确联系。

您可以通过三个主要习惯构建更有用的应用程序：通知和消息、应用程序内指导以及认可和奖励。

通知和消息帮助用户保持了解。

设计良好的通知和消息传递系统可以通过为用户提供及时做出关键决策所需的信息来提高参与度和生产力。设计不当的通知和消息传递系统——一种既不相关也不及时的消息传递系统——将产生相反的效果。内部用户将快速禁用或忽略通知，导致他们错过可能影响基本业务流程的合法消息。厌倦了毫无意义的通知的客户或其他外部用户可能会决定完全停止使用您的系统。

在决定应用程序如何处理向用户发送通知和消息时，请考虑以下事项：

• **对于错误，作为最后手段使用通知和消息。**通过后端处理设计系统中的错误处理，无需人工干预即可更正特定类型的错误。仅向用户发送有关阻止他们完成任务的关键错误的消息。同样，当业务用户可以（并且需要）采取一些纠正措施时，只向他们发送错误消息。额外的错误消息或详细信息可以通过报表提供和/或使用异步方法发送给技术支持人员，以便进一步跟进。
• **根据相关性、紧迫性和及时性选择消息类型。**不同类型的消息具有不同的阻止或中断行为级别。通知是一种“阻止”类型的消息，因为它们要求用户在能够继续工作之前进行确认。与错误消息一样，应谨慎使用通知。吐司通知是非阻止的，可以有不同的持久性行为，并支持不同类型的消息用例。干扰性最小的消息是应用程序内通知或电子邮件。这些信息最适合用于提供信息，用户可以在选择的时间和方式处理这些信息。
• 考虑接下来需要做什么。虽然一些通知是信息性的（例如成功消息），但其他通知可能需要用户采取某种类型的操作。在设计通知时，请确保不仅考虑通知本身，还要考虑用户可能需要采取行动的任何其他信息。包括明确的说明或链接，以便用户在所有可操作的通知中找到更多信息或完成后续步骤。
• 关注可读性。确保您清楚地传达了每个通知的目的，以及用户需要采取的后续步骤。不熟悉基础系统内部工作原理的业务用户应了解消息。在创建消息时，遵循可访问性标准，并确保本地化，以支持可能显示消息的区域的用户。

在设计标准中包含何时使用通知或不同类型错误的模式，以帮助确保应用程序生成器遵循一致的实践。

下面的模式和反模式列表显示了 Salesforce 组织中正确(和差)的通知和消息传递。您可以在构建之前使用这些来验证您的设计，或者确定需要重构的使用情况。

要了解有关适用于通知和消息传递的 Salesforce 工具的更多信息，请参阅相关工具。

应用程序内指导是揭示复杂工作流神秘面纱(尽管您应该先确保已优化)或帮助新员工入职的强大方式。它可以以自动化和可扩展的方式引入流程更改、突出显示新功能或分发培训。但如果实施不当，应用程序内指导可能会被过度使用。频繁的弹出窗口或警报会为用户带来大量噪音和中断，导致工作效率下降。应用程序内指导也可能使用不足，导致发布和变更管理流程更加繁琐（尤其是对于简单功能）。归根结底，应用程序内指导的过度使用和不足都会导致一系列对业务构成风险的问题，包括：

• 降低数据完整性
• 用户错误增加
• 更高的用户挫败感级别和更低的用户满意度
• 降低用户效率

请记住，您可能想要在不同场景中以不同方式使用应用程序内指导，因为用户的心态将决定指导的“过多”与“不足”的程度。对于首次使用新系统的用户，他们需要的消息传递频率可能高于仅在已熟悉系统中了解新功能的用户。

以下是创建有效应用程序内指导的一些关键：

• 制定设计标准。重要的是要记住，过度暴露应用程序内指导会导致用户开始定期忽略或忽略消息。此时，应用程序内指导会成为一种烦恼，而不是一种资源。定义设计标准，以明确何时使用提示、逐步解说、字段级帮助文本、验证消息、路径、屏幕流等。
• 为指导实施创建优先级系统不是每个应用程序内指导的用例都应实施。相反，请考虑以下问题以确定优先级。在哪些方面，您可以简单地使用更好的字段名称、按钮上更明确的标签、更好的表单设计和流程优化来创建更直观的工作流？在哪里可以向路径添加更多帮助文本或链接？应用程序内指导将对业务成本影响？您想要多久向用户传递一次消息？此外，请确保您的路线图中包含任何实施，以便所有相关方都能看到。
• **将用户映射到有效(和建议的)应用程序内指导。**将用户映射到应用程序内指导将帮助您识别并防止由于为用户显示太多的应用程序内指导而导致的“帮助性过载”。通常，这是孤立开发的结果，因为团队对他们特定的用例考虑得太狭隘。对于大型组织，保持对用户将接触的内容的整体视图尤其重要。在路线图中包含指导实施也会有所帮助。
• 收集并使用反馈进行改进。查看应用程序内指导使用情况的数据，并将其用于判断应用程序内指导部署的有效性。确保为用户提供开放式反馈的方式，以帮助指导生成器。

以下模式和反模式列表显示了 Salesforce 组织中正确(和差)的应用程序内指导。您可以在构建之前使用这些来验证设计，并确定需要重构的实施。

要了解有关适用于应用程序内指导的 Salesforce 工具的更多信息，请参阅相关工具。

将认可和奖励构建到应用程序中有助于使用该应用程序的个人感觉与工作的影响更加相关，并更好地了解他们的贡献、生产力和绩效的价值。这也是释放忠诚度和参与度的有效方式。

不为认可或奖励应用程序体验而设计会导致各种问题，包括：

• 难以了解进度或速度的用户
• 对目标进度或未完成工作的困惑
• 更多没有生产力的用户，他们没有看到他们的任务和“更大的情况”之间的联系
• 在手动、低级别的目标报告上浪费的管理时间

奖励应用程序体验可能难以设计和交付，因为它们取决于公司文化、政策和标准以及个人用户的上下文和首选项。帮助桌面用户感受愉悦或欣赏时刻的功能可能会对移动设备用户或试图在嘈杂繁忙的家庭办公室工作的用户造成刺激。使用应用程序处理私人或高度敏感信息的人员可能不喜欢以五彩纸屑庆祝或徽章的形式交流重大事件。相反，分布式销售团队可能会将这种游戏化视为一种回报适当的应用程序体验。最终，您选择的实施模式可能最好通过与团队中的用户体验 (UX) 设计者合作来确定。

在架构方面，确定应用程序如何以及在哪里实施帮助用户获得认可和奖励的功能非常重要。了解这些功能如何及在何处使应用程序降低可重用性或降低实际业务价值也是至关重要的。

以下是在 Salesforce 应用程序中评估荣誉和奖励时需要考虑的一些问题：

• **用户如何以及在哪里可以看到自己的进度以及团队的整体数据统计？**报表很重要，但它们通常包含的汇总数据可能遗漏了日常工作的上下文。您可以使用 Lightning 应用程序生成器等工具在应用程序上下文的记录屏幕上嵌入图表或仪表板，帮助用户在处理日常任务时了解它们的影响或进度。
• **如何识别用户？**这可能因团队或个人首选项而异。在某些情况下，主管可能想要查看有关用户进度的消息，以便与更大的小组共享。认可也是帮助提高员工士气的一项额外优势。在其他情况下，用户可能只是更喜欢成为唯一知道他们在特定任务或项目上进度的人。

下面的模式和反模式列表显示了 Salesforce 组织中正确(和差)的认可和奖励是什么样子的。您可以在构建之前使用这些来验证设计，并确定需要重构的实施。

要了解有关表彰和奖励的 Salesforce 工具的更多信息，请参阅相关参与工具。

下表显示了在您的组织中要查找（或构建）的模式的选择，以及要避免或针对补救的反模式。

✨ 在模式和反模式探索器中，发现更多帮助应用程序的模式。

帮助我们保持 Salesforce 架构合理与您相关；参加我们的调查，以提供有关此内容的反馈，并告诉我们您接下来想要看到的内容。