出金前の確認

1）カスタムスクリプトとは

ユーザースクリプトは、明確な前提条件、ステップ、選択肢、および「成功としてカウントされるもの」基準を持つ、特定のコンテキスト内の結果へのユーザーの記述されたパスです。スクリプトは「why」 （JTBD/target）と「how」 （UXストリーム、インターフェイス、ステート）を関連付けます。

• 製品、設計、開発、データおよびコンプライアンス間の共通言語。
• 条件のより少ない相違、より速い受諾。
• ビジネス効果とメトリクスによる機能の明示的な接続。

2）シナリオの根拠： 人と仕事-Be-Be-Done

人：誰、コンテキスト、スキル、制限（A11yを含む）。

JTBD： 「［状況］があれば、［モチベーション］を［期待される結果］にしたい」

コンテキストセグメント：デバイス、ネットワーク、ローカル/言語、タイムゾーン、権利、環境制限。

• プレイヤーが3Gでモバイルから夜間に賞金を引き出そうとすると、私は10分までお金を得るために電話なしで自分の身元をすばやく確認したいと思います。

3）説明形式： ユーザー/ジョブストーリー、ユースケース、受け入れ

3.1ユーザー/ジョブストーリー（テンプレート）

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

3.2ユースケース（簡略化）

4）パスマップとフロー構造

4.1 CJM（カスタマージャーニーマップ）

ステージ： 意識→選択→最初のアクション→やり直し→サポート→ホールド

それぞれのために： 目標、摩擦、感情、チャンネル、メトリクス（変換、時間、NPS）

4.2ユーザーフローストーリーマッピング

ユーザーフロー：ノード（画面/状態）と遷移（条件/イベント）グラフ。
ストーリーマッピング：「リッジ」（叙事詩/活動）×「垂直スライス」（MVP→拡張）。

5）分岐： 幸せ、悲しい、端の場合

ハッピーパスス値への最小のパス。
悲しいパス：予測可能なエラー（有効性、制限、タイムアウト）。
エッジケース：まれですが高価：不安定なネットワーク、重複、キャンセル、レース、状態競合、ロケール/タイムゾーンの不一致、可用性（マウス、スクリーンリーダーの代わりにキーボード）。

ヒント：各キーステップ-少なくとも1つの悲しいと1つのエッジシナリオ。

6） UIの状態

• 'loading'/'empty'/'success'/'error'/'partial'/'disabled'
• ヒントとマイクロコピーライティング；アクセシビリティ（ロール/アリア、フォーカス、ターゲットサイズ）；ロケールと数字/日付/通貨の形式。

7）シナリオのA11y要件

キーボード：すべてのアクションはマウスなしで達成可能です。目に見える焦点、タブの順序。
スクリーンセーバー：適切なラベルの役割と接続；メディアの選択肢です。
色/コントラスト：≥ WCAG AA；色だけではありません。
Motion： 'prefers-reduced-motion'サポート。
入力：フォーマット/マスク、音声/画面上のキーボード；十分な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パス=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）： happy/sad/edge。
A11y-audit：マニュアル（NVDA/VoiceOver）+オートリンタ。
ユーザビリティセッション：主なシナリオに対する5〜8人の回答者。
テレメトリー：フィーチャーフラグ、完了/TTV/エラーダッシュボード。
Dogfooding：チーム内チェックリストが実行されます。

12）シナリオチェックリスト（クイックチェック）

• JTBDはチームによって策定され、理解されます
• 人/コンテキスト/制限はスペルアウトされています
• ユーザーフローとストーリーマップの準備ができています。マークされたブランチ
• 受け入れ基準（A11yを含む）は明確であり、テスト可能です
• UI状態（読み込み/空/エラー）文書化
• 分析イベントとKPIの定義
• ローカライズ/フォーマット/考慮される通貨
• 説明されているリスク/偽のブランチとリトレイパッド
• プロトタイプ/Macapが開発/データ/コンプライアンスに準拠
• テストプランと受付日の合意

13）アンチパターン

「Scripts=happy path only」（エラー/エッジを無視）。
読み取り不可能な許容（測定可能な基準ではなく「便利にする」）。
要件のA11yとロケールが不足しています。
ビジネス目的とUX実装を混在させる（「lower TTV」ではなく「add popup」）。
イベントスキームはありません→成功を測定するものはありません。

14）簡潔なユーザーストーリーの例

新しいユーザーとして、すぐにゲームを開始するために私の電話を確認せずに電子メールで登録したいです。制限を超えた場合-代替の「ゲスト」を表示します。
マネージャーとして、レポートをCSVにフィルターとプロジェクトタイムゾーンでエクスポートして、会計でデータを検証したいと思っています。

15）実施計画（3つの反復）

• ストーリー/ユースケース/受け入れテンプレート、統合シナリオレジスタ、最小分析スキーム、チェックリスト。

• 主なシナリオ、A11y基準、完了/TTV/エラーダッシュボード、 E2Eセットのユーザーフロー+CJM。

• ストーリーマッピング、インパクト×努力の優先順位付け、A/B仮説、定期的なメトリックレビュー、およびCAPA。

16） ミニFAQ

人または唯一のJTBD？
両方を使用してください：人はコンテキストと制限を与えます、JTBD-意図と価値。

ピクセルまでのすべてを記述する必要がありますか？
いいえ、そうではありません。スクリプトは目標、ステップ、ブランチ、成功基準をキャプチャします。pixels-レイアウトとDLSのタスク。

スクリプトが「準備ができている」ことを理解するには？
測定可能なAcceptance、ハッピー/サード/エッジカバレッジ、A11y基準、イベント、ターゲットKPIがあります。

［結果］

ユーザーシナリオは、製品の「スケルトン」です。明確な目的（JTBD）、一貫したフロー（ユーザーフロー/ストーリーマッピング）、検証可能な基準（Acceptance）、測定可能性（イベントおよびKPI）、アクセシビリティ/ロケールの尊重。ユニフォームテンプレートでそれらを修正し、検証を自動化し、実際の指標に従って定期的に確認します。これにより、インターフェイスはすべてのユーザーにとって明確で迅速かつ価値のあるものとなります。