产品规格使用场景
- 产品规格作者将身份验证需求转化为有序的交付简报。
- 身份平台团队连接安全控制、发布阶段和未解决的实施决策。
- 产品与设计负责人统一负责人、范围、衡量方式和面向用户的身份验证优先级。
- 企业就绪团队结合采用率和支持方面的考量，界定客户安全阻碍。
身份验证简报亮点
- 问题界定将企业评审阻碍与身份验证缺口联系起来。
- 明确范围将拟议的发布目标与有意延期的工作分开。
- 发布目标将预期结果与示例目标及四个发布阶段配对。
- 已分配问题通过负责人和日期，让未解决的策略决策保持可见。
产品规格逐节解读
1 / 6
Northwind 2FA 简报
这份官方 OpenDesign 示例是 Northwind 应用中双因素身份验证的示例性产品规格。开篇将文档确立为 Draft v0.4，列出负责人、更新日期和四位评审者，随后陈述提案：在登录流程中加入 TOTP 和安全密钥验证因子。
视觉构成将这一请求置于规划细节之前。一行元数据显示 Identity Platform 为小组，Priya Banerjee 为工程负责人，Sasha Lin 为设计负责人，目标发布为 End Q4 (Dec 18)，预估工作量为 ~6 eng-weeks。这样的顺序让读者在阅读问题之前，先了解负责人和交付压力。
接着，Problem 部分说明提案存在的理由。文档描述最近六次企业安全评审中有三次指出缺少第二因素，随后单独引用了 Pioneer Robotics 的 Maya Reddy 的话。这段引语让商业压力变得清晰，同时没有取代更广泛的安全论证。
三种身份验证行动
示例 User Stories 部分列出了三项工作：工作区管理员希望为明确的控制评审目标要求启用 2FA；日常成员希望在不到两分钟完成 TOTP 验证器绑定；支持工程师希望拥有不绕过第二因素的恢复路径。这些是文档中的规划要求，并不是身份验证有效或合规已实现的证据。
这些故事以三个编号的横向行呈现，每句话中都突出显示人物短语。这种重复结构便于比较各方职责差异，同时保留 “so that” 从句，以说明每项请求背后的运营原因。
这种排序也揭示了一项设计取舍。管理首先出现，因为工作区强制执行定义了策略界面；随后是验证器绑定，因为这是成员要采取的即时行动；恢复支持最后出现，因为它描述的是例外路径。因此，文档将安全视为一个共享系统，而不只是一个登录界面。
工作区管理员
要求所有成员启用 2FA，以支持控制评审。
日常成员
快速完成 TOTP 验证器绑定，无需离开日常工作。
支持工程师
协助恢复，同时不削弱新增的安全控制。
目标、衡量方式与阶段
文档的中段顺序从范围推进到评估，再推进到交付。“Goals & non-goals” 使用勾选和乘号来区分 TOTP、WebAuthn、工作区强制执行、恢复代码和审计条目，以及 SMS、SSO 替换、按操作触发的额外认证和白标部署中的自定义品牌文案语气等排除项。
这种划分很有用，因为它避免提案将每一项身份验证请求都视为本次发布的一部分。文档明确支持 Authy、1Password 和 Google Authenticator，为 TOTP 目标划定了具体边界；同时，WebAuthn 仅限 Enterprise 计划。这个取舍有意限定了覆盖范围：规格获得了明确的首个版本，同时将相邻的身份工作保持独立。
Success Metrics 表格包含四行示例规划数据：解除阻塞的交易（3 of 3）、付费工作区采用率（至少 60%）、滚动 30 天账户接管事件（最多 1 起）以及恢复支持负载（少于工单的 1.5%）。这些是目标，而不是已测量的结果。其采用率公式使用验证因子绑定事件除以 DAU，但没有定义独立成员去重；事件基线则写作 “4 last quarter”。在这张表格能够衡量真实发布之前，还需要协调时间窗口和计数规则。
Rollout Milestones 将这些指标转化为四个由功能开关控制的规划阶段：TOTP 验证器绑定、登录流程、WebAuthn 与管理员强制执行，以及 正式发布（GA）及发布沟通。每个阶段都列出工作量估算和具体内容，因此读者可以看到哪些决策会影响设置、登录、策略和支持材料。
| 指标 | 基线 | 目标 (90D) | 衡量方法 |
|---|---|---|---|
| 弥补 2FA 缺口后解除阻塞的企业交易 | 3 笔中的 0 笔 | 3 笔中的 3 笔 | 销售流程备注 + 已签署合同数量 |
| 成员 2FA 采用率（付费工作区） | n/a | ≥ 60% | auth.factor_enrolled 事件 / DAU |
| 账户接管事件（滚动 30 天） | 上季度 4 起 | ≤ 1 | 安全事件跟踪器（SEV-3+） |
| 2FA 恢复产生的支持负载 | n/a | 少于工单总量的 1.5% | Zendesk 中标记为 auth-2fa |
仍待决的事项
最后一部分让不确定性保持可见，而不是将规格呈现为已完成的实施方案。三个问题分别分配给 Devon Park、Priya Banerjee 和 Sasha Lin，截止日期为 十月 28 日、29 日和 30 日：成员是否在 TOTP 与安全密钥之间自行选择；受信任设备 Cookie 应持续多久；管理员可以在哪里查看成员的 2FA 状态。
这与里程碑顺序形成了有意义的对应。发布计划提到了受信任设备 Cookie 和管理员强制执行，但待决问题表明，它们的策略细节尚未在文档中确定。将这些问题与负责人和日期放在一起，为团队提供了一个与所述 十月 31 日截止日期相连的决策队列。
验证因子选择
决定是由成员选择验证因子，还是直接为其提供可用的最强验证因子。
受信任设备
确定受信任设备 Cookie 的有效期策略。
管理员可见性
在用户列表状态和审计日志可见性之间做出选择。
如何在 OpenDesign 中创建身份验证产品规格设计
界定身份验证问题
从产品请求、受影响的受众以及具体的安全或商业压力开始。当这些细节已知时，加入一行简洁的负责人信息，包括小组、负责人、目标发布和工作量。
定义范围和衡量方式
先将拟议的发布目标与非目标分开，再添加基线、目标和衡量方法。让规划值与已验证结果保持区分，并在调整示例公式之前统一报告窗口和独立用户计数方式。
建议提示词创建一份 Northwind 风格的双因素身份验证产品规格，包含草稿页眉、负责人信息行、Problem 部分、Goals 和 Non-goals、一个四列的 Success Metrics 表格、三个编号的 User Stories、四个带日期的 Rollout Milestones，以及已分配负责人的 Open Questions。展示 TOTP、Enterprise WebAuthn、工作区强制执行、恢复代码、审计条目和所述的能力限制；不要暗示存在在线服务或已测量结果。
检查决策顺序
将文档作为一条规划路径进行审阅：问题、范围、指标、用户故事、里程碑和待决问题。确认每个里程碑都有具体内容，并确保未解决的策略细节仍然可见，而不是被呈现为已确定的行为。
导出并获取分享链接
导出完成的设计稿，然后在 OpenDesign 中使用「Share」功能获取分享链接。在单独的浏览器窗口中打开链接，确认目标版本及其资源均可正常访问后，再将链接发送给他人。
