生成式人工智能用户体验--为企业开发创新使用案例

实用设计创新

一个用于设计创新且合适的企业生成式AI体验的框架

为了创建用户会采用和使用的创新生成式AI体验，我们需要确保这些体验能够提供适当的响应。为此，这些体验需要接受如何运作的业务培训，如何进行评估，公司的目标、流程和过程，如何在不同情境中讨论公司，以及如何将活动如计划和项目相互关联。

消费者使用场景往往简单且专注于满足个人需求。复制简历美化体验并不能帮助企业创建创新的生成式AI体验。企业需要生成式AI来解决跨复杂流程的公司目标。鉴于生成式工具为用户提供了比基于逻辑的体验（如表格和表单）更多的灵活性，我们需要重新评估用户对工作的思维方式，以便提供适当的响应、主动性和可预测且可操作的后续行动。

相反，在企业生成式AI体验中，以不合适的语气或提供非权威信息的问题比在消费者体验中严重得多。我们需要确保信息来自明确指定给模型的权威和适当来源，而不是从域中可能存在的任何文档中推断出来的，其中一些文档可能是正在进行的工作，而不是已完成的、达成一致的决策。

我们需要有意向地收集信息以解决生成式AI问题。这篇文章描述了我们在收集信息以完成框架时需要考虑的生成式AI系统的权威数据难题。

构建创新的企业体验涉及许多角色理解生成式AI的能力和局限性。用户体验团队成员可以帮助提取用户在不同情境中想要的信息以及适当的响应。内容管理人员可以确保有足够的适当内容，以便生成式AI体验提供预期和期望的结果。开发人员可以帮助微调模型并建立与数据源的适当连接，使系统可以访问权威数据。

以下框架提供了这些角色合作的方法，以提取这种理解，创建用户尚未意识到的生成式工具所能提供的用户体验，确保公司的需求得到满足，工具适当且可信。

无论生成式AI体验可能采取何种设计方向，以下框架提供了帮助提取用户工作方式和想象生成式AI可以提供价值的方法。我们希望收集信息，目的是生成式AI可能是一种解决问题的方式，然后在生成式AI擅长和失败的背景下评估用户的目标和问题。

框架

此框架为企业构建 LLM 工具的团队提供了理解评估模型、微调模型以及设计体验以提供适当响应所需的方法。

框架中的方法并不是为了提取企业功能或应用的每一项能力。它们是一种练习，帮助团队提取最有用和最全面的能力，使生成式 AI 能够帮助用户实现目标，同时保持公司的目标和声誉。

收集和综合信息以创建满足复杂企业应用需求的生成式 AI 体验需要深思熟虑的努力。

[T]he framework can help me capture information that is needed upfront to evaluate and prioritize gen AI use cases and needed later to develop the actual capabilities.

我可以想象使用该框架来结构化多学科工作组的工作会议，这些工作组的任务是创建这些知识。

— Francesca Barrientos

像下面这样的电子表格是一种可交付的成果，用于评估数据需求、微调模型并提供提示或方向，以使生成式工具更加有效，并可用作支持 QA（质量保证）的检查清单，真正价值在于理解用户目标与生成式 AI 之间的关系。

我们捕获的信息、捕获的原因以及我们可能如何使用它 (WMWDWI)

以下是我们希望确保在生成式人工智能体验中正确处理的方面。我们希望收集有关这些方面的信息，以帮助我们创建创新且合适的体验。为此，我们捕获信息（what）以了解这些方面（why），从而可以利用这些信息来做出关于体验的决策（wmwdwi）。

问题 / 目标

WHAT — 我们希望捕捉并传达用户请求的意图——他们想要回答的问题或尝试实现的目标。如果体验仅允许输入文本，我们希望捕捉用户在提出请求时可能会使用的措辞。

WHY — 尽管用户可以用多种方式询问同一主题的问题，但这一栏应为团队提供一个很好的总体概念，了解需要解决的领域。这应该代表用户可能提出的问题。使用下面的 For each question 部分来开发用户可能提出的变化，并确定这些变化是否需要单独捕捉。

WMWDWI — 这些信息将用于评估我们是否有数据来回答或采取行动，用户可能拥有的上下文信息我们是否需要支持，可能需要的提示工程的形状，以及开发质量保证工作。

期望的响应

WHAT — 我们需要捕捉用户期望的响应内容、语气和格式。我们还需要捕捉用户可能偏好的响应显示格式——句子、几段文字、列表、表格、可视化、活动的开始等。

这个请求是否可能在移动设备上提出？对于移动设备，他们是否更倾向于语音响应，而对于桌面设备，是否更倾向于详细的文字响应？

WHY — 在生成式AI可以提供的广泛响应中，某些特定结果可能难以描述。仍然需要有一个可以测试的期望。记录期望的响应在移动设备和桌面设备之间是否存在差异也很有价值，以便在开发过程中考虑到这些差异。

WMWDWI — 在企业环境中，这些信息用于根据公司的目标和流程来塑造特定的响应。某些响应，如涉及法律、财务或人力资源的响应，具有法律和其他影响，需要满足特定要求。

会话的一部分

WHAT — 请求是否可能是会话的一部分？如果是，它是否可能是更大目标或过程的一部分？如果是，我们可能会期待哪些后续请求？

假设初始请求可能是更广泛过程的开始，例如旅行请求、营销活动的创建或需要多次分析问题的复杂项目的状态。会话可能会是什么样子？

考虑用户希望系统表明后续问题可能有助于提供更好的答案的可能性，或者系统是否应该预先尝试回答用户可能有的问题。

WHY — 我们越早确定用户希望的方向，就越能主动提供有助于他们高效达成目标的响应。

WMWDWI— 如果请求可能是更大问题的一部分——例如关于旅行、修复硬件或需要多个步骤的项目状态，而系统能够确定这一点，那么响应可以主动包含有助于用户更全面理解或下一步行动的方面。

这个问题涉及复杂的情况，您应该考虑将用户引导到一个专注于帮助他们完成过程的体验中。在这种情况下，用户可以利用生成式 AI 的会话能力提出复杂请求，系统则提供一个点击式体验来操作结果。

数据

WHAT — 系统监控、内容源或可用于满足请求的数据表。是否正确标记了数据，以便系统知道哪些是权威数据。

WHY — AI 工具失败的最大原因之一是生产环境中不存在正确的数据。

有意为之而不是寄希望于数据存在，对于创建可行且成功的企业的生成式 AI 项目至关重要。

WMWDWI — 产品管理和工程可以使用此方法评估访问权限和 API，以支持所需的系统。此外，还可以解决上述提到的问题和补救措施。

语调

WHAT — 确保系统以适合受众的语调（企业、金融、法律、品牌、随意、友好）回应每个请求——法律、金融、客户、向人力资源提问的员工等。还需要考虑该回应是否可能用于新闻稿或具有法律影响。

WHY — 许多回应可能是事实性的或权威的，但因为语调不适合受众而不适当。这在媒体和法律相关的请求中尤为重要。

我曾参与一个因受众为媒体而被停止的生成式AI项目，系统采用的标准语调不符合金融新闻稿的品牌和适当性要求。

WMWDWI — 此信息将用于通过微调或提示工程来确定回应的语调。

创造力 (Temperature)

WHAT — 系统在回答中能有多大的创造力。这在响应必须符合法律适当性时尤为重要。

• None — 系统应逐字回答。如果不能，应告知用户，系统无法回答该问题。
• Some (默认) — 如果对来源有信心，根据语气构建响应并提供标准免责声明；否则，构建带有强烈免责声明的响应。
• Lots — 使用标准免责声明，系统可以重新构建响应。

WHY — 创造力是系统产生幻觉的一个方面，更高的创造力使系统在采样内容和创建响应时具有更大的灵活性。温度越低，系统越被迫使用来源数据，而不是从来源数据空间之外采样。因此，温度越低，系统的权威性越高。

WMWDWI—此信息用于标记某些类型的请求需要低温度，以便系统能够适当响应。如果响应无法满足某些法律或面向公众的标准，您可能还需要系统不进行响应。

收集信息的一些帮助

以下是一些生成电子表格行的方法——思考用户可能希望启用的问题、请求、活动或对话类型。我们这样做是因为预测用户可能向AI提出什么样的请求实际上需要深入思考用户在做什么以及他们提出请求的背景。

用户研究 / 用户旅程图 / 待完成任务

当然，你的第一站应该是你的 UX/XD 团队。他们可能有用户旅程图或待完成任务的交付物，这些交付物提供了用户在不同工作阶段的需求和愿望，以及他们如何思考这些需求。

通用问题

以下问题旨在引导用户期望生成工具能够回应的应用领域。示例非常简单，您可以期待用户会提出更详细的问题。在考虑每个问题的理想回答时，请考虑组织的背景如何影响回答。

用户可能会提出哪些流程问题？

• 我如何提交服务请求？
• 我如何启动招聘流程？
• 如何启动新项目？
• 我们的开发流程是否使用标准的SDLC？ — Software Development Lifecycle
• X项目的利益相关者是谁？

用户可能会提出哪些状态/状况问题？

• X项目预计何时完成？
• 我们离满负荷运行还有多远？
• 我们是否接近招聘到[职位]的候选人？
• 我们对[问题]是否有相关法规？

用户在其领域内可能会进行哪些操作（创建/读取/更新/删除等）？

• 为[客户类型]创建一个[产品]的营销活动。
• 本月应该有多少贷款结清？
• 将所有[某事]项目的工期延长5天。
• 删除[某事]角色的用户分配。

用户可能会提出哪些分析问题？

• 00/00/00前后是否有任何事件发生？
• 我们是否有足够的[部件]来生产300个[产品]？
• 获得大拇指向下评价的文章最常见的原因是什么？
• [新功能]的采用趋势如何？

用户可能想了解系统中的主要对象的哪些信息？

• 营销 — 我的[某事]营销活动进展如何？
• 销售 — 我上次与[客户]接触是什么时候？
• 人力资源 — [经理]手下有多少员工？

我们需要考虑用户可能会如何利用这些答案以及他们可能会采取哪些行动。

每个问题的类型是什么？

思考用户提出的问题的性质有助于我们确定满足他们需求的回复或体验的性质。

确定某物是否存在 — 例如：是否存在一个包含……的营销计划？

了解某个事物或一组事物的信息 — 例如：描述、状态/状况、数量、变化/差异。

了解如何进行某项活动 — 例如：请求一台笔记本电脑、请求访问某个系统、按照公司规定计划旅行、启动项目、提出建议等。

了解事物之间的关系 — 例如：层次结构（这是子项、父项、几个分支之外？）、相等、大于、小于、统计关系（最小值、最大值、平均值、通常、异常、常态、事件）、分类关系（属于某个组、不属于、相关、以特定方式标记）等。

应用/功能/页面-中心问题

生成系统将让用户能够自动化许多任务，因为基于代理的系统在推理和遵循步骤方面变得更好。我们并不是要复制特定应用、功能或页面的具体操作，而是要利用这些界面周围的活动来考虑用户可能期望能够做什么。

我们希望考虑一个应用、功能或页面的复杂性，以决定是否需要考虑提供对话支持来帮助用户使用它，或者其功能是否会很可能被纳入生成式AI流程或代理中。

此外，虽然我们可以预期生成式AI工具能够从与应用、页面或功能相关的系统中找到内容，但最好将生成式AI具体连接到它应该用来响应的权威学习内容或知识文章。

为了了解用户可能想了解的企业应用的哪些内容，可以考虑提出以下类型的问题。

对于页面，如果页面是：

表单

• 编辑有多复杂？用户会想到以对话的方式解决吗？
• 系统如何帮助用户以对话的方式完成它？
• 这与更大的目标有什么关系？

表

• 他们可能会要求对数据进行哪些活动？
• 有多少个？
• 是否存在？
• 处于什么状态？
• 所有的值是多少？

仪表板

• 用户期望回答哪些问题？
• 用户从某些数据状态出发会遵循哪些查询路径？
• 仪表板所代表的思维是否在某个地方（如知识图谱）被捕获，以便 AI 可以访问并推导出答案？

复杂页面（包含卡片、表格、轮播图、日历等内容的混合页面）

• 这个页面支持什么流程？学习内容或知识文章是否支持该流程，以便生成式 AI 能够帮助回应？
• 用户是否会请求特定部分的信息？
• 用户是否会请求跨部分的信息？

结论

构建创新的企业生成式 AI 体验需要不同的角色来理解用户需求和业务目标是否能够得到满足。参与者需要权衡生成式 AI 的优势和缺点。与基于逻辑的体验不同，生成式 AI 体验还伴随着信任、控制和自主性问题。为了创建生成式 AI 能够适当增值的创新产品，团队需要重新评估确定和定义产品的过程。该框架提供了一些调整过程所需的结构。

感谢 Andrew Avedian、Francesca Barrientos 和 Andersson J Christoffer 的编辑支持。