输出前验证

1）什么是自定义脚本

用户脚本是用户在特定上下文中描述的结果路径，具有明确的前提，步骤，替代方案和"被认为是成功的"标准。脚本链接到"为什么"（JTBD/目标）和"如何"（UX流，接口，状态）。

• 产品，设计，开发，数据和合规性之间的通用语言。
• 需求差异较小，接受速度更快。
• 与业务效应和度量指标的明确关系。

2）脚本基础： 角色和Jobs-to-Be-Done

角色：谁，上下文，技能，限制（包括A11 y）。

JTBD： "当［情况］时，我希望［动机］得到［预期结果］。"

上下文段：设备、网络、区域/语言、时区、权限、环境限制。

• 当玩家试图在3G手机上拿出晚上的胜利时，我想快速确认身份而无需打电话，以便在10分钟内获得金钱。

3）描述格式： User/Job Story, Use Case, Acceptance

3.1 User/Job Story（模板）

Как <роль/персона>, я хочу <действие/результат>, чтобы <ценность>.
Контекст: <устройство, сеть, язык, права>
Ограничения: <регуляторика, лимиты, A11y>
Гипотеза ценности: <какой KPI улучшится и на сколько>

3.2使用桉例（简化）

4）路径图和流程结构

4.1 CJM (Customer Journey Map)

阶段： 意识→选择→第一动作→重播→支持→保留

针对每个目标： 目标、摩擦、情绪、渠道、指标（转换、时间、NPS）

4.2 User Flow и Story Mapping

用户流：节点图（屏幕/状态）和过渡（条件/事件）。
故事映射："山脊"（史诗/活动）×"垂直切片"（扩展→ MVP）。

5）分支： 快乐,sad, edge cases

快乐路径：最小价值路径。
Sad path：可预测的错误（有效性，限制，时间限制）。
Edge cases：稀有但昂贵：网络不稳定、重复、取消、竞赛、状态冲突、地方/时区不匹配、可用性（键盘而不是鼠标、屏幕阅读器）。

提示：每个关键步骤-至少一个脚本和一个边缘脚本。

6）接口状态（UI States）

• `loading` / `empty` / `success` / `error` / `partial` / `disabled`
• 线索和微写作；可用性（角色/aria，焦点，目标大小）；数值/日期/货币的位置和格式。

7）脚本中的A11 y要求

键盘：无需鼠标即可实现所有动作；可见焦点，Tab顺序。
屏幕阅读器：标签的正确角色和链接；媒体替代品。
颜色/对比度：≥ WCAG AA；不只是颜色。
动作：支持"prefers-reduced动作"。
输入：格式/掩码、语音/屏幕键盘；足够的40-48 px目标。
在Acceptance中添加单独的A11y条件。

8）分析标记和成功指标

定义脚本的事件、参数和KPI。

8.1事件方案（示例JSON）

json
{
"event": "withdrawal_kyc_step",
"props": {
"step": "face_capture",
"device": "mobile",
"net": "3g",
"locale": "ru-RU",
"result": "success    fail    timeout",
"duration_ms": 74200
},
"user": { "seg": "new    returning", "a11y": "sr    kb    none" }
}

8.2 KPI和目标阈值

完成率（完成脚本的比例）≥ X%

时间到价值（结果中位数）≤ Y分钟

错误率（422/429/5xx和用户错误）≤ Z%

A11y Pass（仅键盘脚本）=100%

CSAT/NPS ≥目标级别步骤

9）数据，国际方面和规则

格式：时间ISO-8601 （UTC）、用户本地化输出。
金钱：小单位/十进制行；货币显然。
语言/RTL：资源文本，镜像支持；行长度和传输。
限制：限制，年龄，KYC，制裁-作为场景的预言。

10）脚本描述模板（YAML）

yaml id: SCN-0023-withdrawal-kyc-mobile-3g title: Верификация перед выводом (мобайл, 3G)
persona: "Игрок-новичок"
jtbd: "Когда хочу быстро вывести выигрыш ночью, пройти KYC без звонка, чтобы получить деньги за 10 минут."
context:
device: mobile network: "3g"
locale: "ru-RU"
timezone: "Europe/Kyiv"
preconditions:
- "Пользователь авторизован"
- "Баланс >= минимального порога"
- "Документы готовы"
flow:
- step: "Открыть экран вывода"
ui_state: ["loading","ready","error"]
analytics_event: "withdrawal_open"
- step: "Старт KYC"
alt: ["нет камеры -> перейти на загрузку фото", "ошибка сети -> ретрай"]
analytics_event: "kyc_start"
- step: "Съемка лица"
alt: ["недостаточно света", "таймаут", "отказ разрешений"]
analytics_event: "kyc_face_capture"
- step: "Результат и ETA"
analytics_event: "kyc_result"
acceptance:
- "KYC завершен < 2 минут в 3G"
- "Вся последовательность проходима клавиатурой; фокус не теряется"
- "Тексты локализованы; валюта и формат дат корректны"
- "Ошибки с actionable подсказкой"
metrics:
completion_rate: ">= 0.85"
ttv_median_min: "<= 10"
error_rate: "<= 0.03"
a11y:
keyboard_only: true contrast_wcag: "AA"
reduced_motion_supported: true risks:
- "Нестабильная сеть -> оффлайн режим/ретраи"
- "Ложные отказы KYC -> fallback на ручную проверку"

11）场景验证工具

功能测试（Gherkin/E2E）：快乐/sad/edge。
A11 y审计：手动（NVDA/VoiceOver）+自动林特。
可用性会议：关键场景的5-8位受访者。
遥测：fiche标志，dashbords Completion/TTV/Error。
Dogfooding：按支票单进行团队内部运行。

12）脚本支票清单（快速验证）

• JTBD由团队制定和理解
• 人物/背景/限制规定
• 用户流和故事地图已准备就绪；分支标记为
• Acceptance Criteria（包括A11y）是可以理解和测试的
• UI状态（加载/empty/error）已记录
• 分析事件和KPI定义
• 本地/格式/货币计入
• Retrais的风险/假树枝和阅兵场描述
• 原型/宏与开发/数据/合规一致
• 测试计划和验收日期达成一致

13）反模式

"脚本=仅快乐路径"（忽略错误/边缘）。
不可读验收率（"方便"而不是可测量的标准）。
需求缺乏A11y和位置。
业务目标与UX实现的混合（"添加流行音乐"而不是"降低TTV"）。
没有什么可以衡量成功→事件模式。

14）简洁的用户故事示例

作为新用户，我想通过电子邮件注册而无需电话确认即可立即开始游戏；如果超过限制-显示"客人"的替代方案。
作为经理，我想将报告导出到CSV，其中包含过滤器和计时项目，以便将数据与会计核对。

15）实施计划（3次迭代）

• Story/Use Case/Acceptance模板、单一脚本注册表、最小分析电路、支票清单。

• 用于关键脚本的User Flow+CJM，A11 y标准，Completion/TTV/Error dashboard，E2E集。

• 故事映射，Impact × Effort的优先级，A/B假设，定期的指标评论和CAPA。

16）迷你常见问题

角色还是仅JTBD？
使用两者：角色给出上下文和限制，JTBD给出意图和价值。

是否需要将所有内容描述为像素?

没有。该脚本记录了目标，步骤，分支和成功标准；像素是布局和DLS问题。

如何理解脚本"准备好了"？
有可测量的Acceptance，happy/sad/edge覆盖，A11 y标准，事件和目标KPI。

结果

自定义脚本是产品的"骨架"：明确目标（JTBD），协调流（用户流/故事映射），可验证标准（接受），可测量性（事件和KPI）以及对可用性/位置的尊重。将它们固定在单个模板中,自动验证,并定期根据实际指标进行修订-因此接口对所有用户都保持清晰、快速和有价值。