輸出前驗證
1）什麼是自定義腳本
用戶腳本是用戶在特定上下文中描述的結果路徑，具有明確的前提，步驟，替代方案和「被認為是成功的」標準。腳本鏈接到「為什麼」（JTBD/目標）和「如何」（UX流，接口，狀態）。
目標是：- 產品，設計，開發，數據和合規性之間的通用語言。
- 需求差異較小，接受速度更快。
- 與業務效應和度量指標的明確關系。
2）腳本基礎： 角色和Jobs-to-Be-Done
角色：誰，上下文，技能，限制（包括A11 y）。
JTBD： 「當［情況］時，我希望［動機］得到［預期結果］。」
上下文段：設備、網絡、區域/語言、時區、權限、環境限制。
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次叠代）
叠代1-基礎（1-2周）：- 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）以及對可用性/位置的尊重。將它們固定在單個模板中,自動驗證,並定期根據實際指標進行修訂-因此接口對所有用戶都保持清晰、快速和有價值。