철회 전 검증

1) 사용자 정의 스크립트 란 무엇입니까

사용자 스크립트는 명확한 전제 조건, 단계, 대안 및 "성공으로 간주되는 것" 기준을 갖춘 특정 컨텍스트의 결과에 대한 사용자의 설명 된 경로입니다. 스크립트는 "이유" (JTBD/대상) 및 "방법" (UX 스트림, 인터페이스, 상태) 을 연관시킵니다.

• 제품, 디자인, 개발, 데이터 및 규정 준수 간의 공통 언어.
• 요구 사항의 불일치, 더 빠른 수용.
• 비즈니스 효과 및 지표와 기능의 명시 적 연결.

2) 시나리오 부지: 사람과 일할 일

사람: 누가, 상황, 기술, 한계 (A11y 포함).
JTBD: "[상황] 일 때 [예상 결과] 에 [동기 부여] 를 원합니다".
상황 세그먼트: 장치, 네트워크, 로컬/언어, 시간대, 권리, 환경 제한.

• 플레이어가 3G의 모바일에서 밤에 상금을 인출하려고 할 때, 최대 10 분의 돈을 얻기 위해 전화없이 내 신원을 신속하게 확인하고 싶습니다.

3) 설명 형식: 사용자/직업 스토리, 사용 사례, 수락

3. 1 사용자/작업 스토리 (템플릿)

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

3. 2 사용 사례 (간소화)

4) 경로 맵 및 흐름 구조

4. 1 CJM (고객 여행지도)

단계: 인식 → 선택 → 첫 번째 행동 → 다시 시작 → 지원 → 보류

각 목표: 목표, 마찰, 감정, 채널, 지표 (변환, 시간, NPS)

4. 2 사용자 흐름 스토리 매핑

사용자 흐름: 노드 (화면/상태) 및 전환 (조건/이벤트) 그래프.
스토리 매핑: "릿지" (에픽/액티비티) × "세로 슬라이스" (MVP → 확장).

5) 분기: 행복하고 슬프고 가장자리 케이스

행복한 길: 최소한의 가치 경로.
슬픈 경로: 예측 가능한 오류 (유효성, 한계, 타임 아웃).
에지 케이스: 드물지만 비싸다: 불안정한 네트워크, 중복, 취소, 레이스, 상태 충돌, 로케일/시간 영역 불일치, 가용성 (마우스 대신 키보드, 스크린 리더).

팁: 각 핵심 단계마다-적어도 하나의 슬프고 하나의 에지 시나리오.

6) UI 상태

각 화면/단계마다 다음을 수정하십시오

'로딩 '/' 빈 '/' 성공 '/' 오류 '/' 부분 '/' 해제'

힌트와 마이크로 카피 라이팅; 접근성 (역할/아리아, 초점, 목표 크기); 숫자/날짜/통화의 로케일 및 형식.

7) 시나리오의 A11y 요구 사항

키보드: 모든 동작은 마우스없이 달성 할 수 있습니다. 눈에 보이는 초점, 탭 순서.
화면 보호기: 적절한 레이블 역할 및 연결; 미디어 대안.
색상/대비: 단순한 색상이 아닙니다.
모션: '감소 모션 선호' 지원.
입력: 형식/마스크, 음성/화면 키보드; 충분한 40-48 px 대상.
수락에 개별 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%

가치 시간

오류율 (422/429/5xx 및 사용자 오류)

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): 행복/슬픈/가장자리.
A11y 감사: 수동 (NVDA/VoiceOver) + 자동 인린터.
사용성 세션: 주요 시나리오에 대한 5-8 명의 응답자.
원격 측정: 기능 플래그, 완료/TTV/오류 대시 보드.
Dogfooding: 팀 내 체크리스트가 실행됩니다.

12) 시나리오 체크리스트 (빠른 점검)

• JTBD는 팀에 의해 공식화되고 이해됩니다
• 개인/컨텍스트/제한이 명시되어 있습니다
• 사용자 흐름과 스토리 맵이 준비되었습니다. 표시된 분기
• 수락 기준 (A11y 포함) 은 명확하고 테스트 가능합니다
• UI 상태 (로딩/빈/오류) 문서화
• 분석 이벤트 및 KPI 정의
• 현지화/형식/통화 고려
• 위험/가짜 가지 및 리트레이 패드 설명
• 개발/데이터/규정 준수와 일치하는 프로토 타입/Macap
• 테스트 계획 및 수락 날짜 동의

13) 반 패턴

"스크립트 = 행복한 경로 만" (오류/가장자리 무시).
읽을 수없는 수락 (측정 가능한 기준 대신 "편리하게").
A11y 부족 및 요구 사항의 로케일.
비즈니스 목적과 UX 구현 혼합 ("낮은 TTV" 대신 "팝업 추가").
성공을 측정 할 이벤트 체계가 없습니다.

14) 간결한 사용자 이야기의 예

새로운 사용자로서, 게임을 즉시 시작하기 위해 휴대 전화를 확인하지 않고 전자 메일로 등록하고 싶습니다. 한계를 초과하면 대체 "게스트" 를 표시하십시오.
관리자로서 회계를 통해 데이터를 확인하기 위해 필터와 프로젝트 시간대를 사용하여 보고서를 CSV로 내보내려고합니다.

15) 구현 계획 (3 회 반복)

• 스토리/사용 사례/수락 템플릿, 통합 시나리오 등록, 최소 분석 체계, 체크리스트.

• 주요 시나리오, A11y 기준, 완료/TTV/오류 대시 보드, E2E 세트의 사용자 흐름 + CJM.

• 스토리 매핑, 임팩트 × 노력 우선 순위, A/B 가설, 정기적 인 메트릭 리뷰 및 CAPA.

16) 미니 -FAQ

사람 또는 JTBD 만?
두 가지 모두를 사용하십시오: 사람은 상황과 한계, JTBD-의도와 가치를 제공합니다.

픽셀까지 모든 것을 설명해야합니까?
아니요, 그렇지 않습니다. 스크립트는 목표, 단계, 지점 및 성공 기준을 캡처합니다. 픽셀-레이아웃 및 DLS 작업.

스크립트가 "준비" 되었음을 이해하는 방법?
측정 가능한 수락, 행복/슬픈/에지 보장, A11y 기준, 이벤트 및 대상 KPI가 있습니다.

결과

사용자 시나리오는 제품의 "골격" 입니다: 명확한 목적 (JTBD), 일관된 흐름 (사용자 흐름/스토리 매핑), 검증 가능한 기준 (수락), 측정 가능성 (이벤트 및 KPI) 및 접근성/로케일 존중. 균일 한 템플릿으로 수정하고 검증을 자동화하고 실제 메트릭에 따라 정기적으로 검토하십시오. 이러한 방식으로 인터페이스는 모든 사용자에게 명확하고 빠르며 가치가 있습니다.