Çekilmeden önce doğrulama

1) Özel bir script nedir

Bir kullanıcı komut dosyası, kullanıcının belirli bir bağlamda, net önkoşullar, adımlar, alternatifler ve "başarı olarak sayılan" kriter ile bir sonuca giden açıklanan yoldur. Komut dosyaları "neden" (JTBD/hedef) ve "nasıl" (UX akışı, arayüzler, durumlar) ilişkilendirir.

• Ürün, tasarım, geliştirme, veri ve uyumluluk arasındaki ortak dil.
• Gereksinimlerde daha az tutarsızlık, daha hızlı kabul.
• Özelliklerin iş etkisi ve metriklerle açık bağlantısı.

2) Senaryo Gerekçeleri: Kişiler ve Yapılacak İşler

Kişiler: kim, bağlam, beceri, sınırlamalar (A11y dahil).
JTBD: "Ne zaman [durum], [beklenen sonuç] için [motivasyon] istiyorum".
Bağlam segmenti: cihaz, ağ, yerel/dil, saat dilimi, haklar, çevre kısıtlamaları.

• Bir oyuncu 3G'deki bir cep telefonundan gece kazançlarını çekmeye çalıştığında, 10 dakikaya kadar para almak için kimliğimi arama yapmadan hızlı bir şekilde onaylamak istiyorum.

3) Açıklama formatları: Kullanıcı/İş Hikayesi, Kullanım Örneği, Kabul

3. 1 Kullanıcı/İş Hikayesi (şablon)

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

3. 2 Kullanım Durumu (Basitleştirilmiş)

4) Yol haritaları ve akış yapılandırması

4. 1 CJM (Müşteri Yolculuğu Haritası)

Aşamalar: Farkındalık - Seçim - İlk Eylem - Yinele - Destek - Tut

Her biri için: hedefler, sürtünme, duygular, kanallar, metrikler (dönüşüm, zaman, NPS)

4. 2 Kullanıcı Akışı и Hikaye Haritalama

Kullanıcı Akışı: düğüm (ekranlar/durumlar) ve geçiş (koşullar/olaylar) grafiği.
Hikaye Haritalama: "Ridge" (destanlar/aktiviteler) × "vertical slices" (MVP).

5) Dallanma: mutlu, üzgün, kenar durumları

Mutlu yol: Değere giden minimal yol.
Üzücü yol: öngörülebilir hatalar (geçerlilik, sınırlar, zaman aşımları).
Uç durumlar: nadir ama pahalı: kararsız ağ, kopyalar, iptaller, yarışlar, durum çakışması, yerel/saat dilimi uyumsuzluğu, kullanılabilirlik (fare yerine klavye, ekran okuyucu).

İpucu: Her önemli adım için - en az bir üzücü ve bir kenar senaryosu.

6) UI Durumları

• 'yükleme'/' boş'/' başarı'/' hata'/' kısmi'/' devre dışı'
• İpuçları ve mikro metin yazarlığı; Erişilebilirlik (roller/arya, odak, hedef boyutları); Sayıların/tarihlerin/para birimlerinin yerel ve biçimi.

7) Senaryolarda A11y gereksinimleri

Klavye: tüm eylemler bir fare olmadan elde edilebilir; görünür odak, Sekme sırası.
Ekran koruyucu: uygun etiket rolleri ve bağlantıları; Medya alternatifleri.
Renk/kontrast: ≥ WCAG AA; sadece renk değil.
Motion: 'prefers-reduced-motion' desteği.
Giriş: format/maskeler, ses/ekran klavyesi; Yeterli 40-48 px hedefleri.
Kabul'a bireysel A11y kriterleri ekleyin.

8) Analitik işaretleme ve başarı metrikleri

Senaryo için olayları, parametreleri ve KPI'ları tanımlayın.

8. 1 Olay şeması (JSON örneği)

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 ve hedef eşikleri

Tamamlanma Oranı ≥ % X

Değer Zamanı ≤ Y dakika

Hata Oranı (422/429/5xx ve kullanıcı hataları) ≤ Z %

A11y Geçiş = %100

CSAT/NPS Hedef Adım ≥

9) Veriler, uluslararası yönler ve kurallar

Biçimler: Zaman için ISO-8601 (UTC), kullanıcı için yerelleştirilmiş çıktı.
Para: küçük birimler/ondalık dizeler; para birimi açıkça.
Diller/RTL: kaynaklardaki metinler, yansıtma desteği; dize uzunluğu ve tireleme.
Kısıtlamalar: limitler, yaş, KYC, yaptırımlar - senaryolar için ön koşul olarak.

10) Komut Dosyası Açıklama Şablonu (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) Senaryo Doğrulama Araçları

Fonksiyonel testler (Gherkin/E2E): mutlu/üzgün/kenar.
A11y-audit: manuel (NVDA/VoiceOver) + otomatik bağlayıcılar.
Kullanılabilirlik oturumları: Anahtar senaryoya 5-8 yanıt verenler.
Telemetri: özellik bayrakları, Tamamlama/TTV/Hata panoları.
Dogfooding: Takım içi kontrol listesi çalışır.

12) Senaryo kontrol listesi (hızlı kontrol)

• JTBD takım tarafından formüle edilir ve anlaşılır
• Kişi/bağlam/kısıtlamalar hecelenmiştir
• Kullanıcı Akışı ve Hikaye Haritası hazır; dallanma işaretli
• Kabul Kriterleri (A11y dahil) açık ve test edilebilir
• UI durumları (yükleme/boş/hata) belgelendi
• Analitik olaylar ve tanımlanan KPI'lar
• Yerelleştirme/formatlar/para birimi dikkate alındı
• Açıklanan riskler/sahte dallar ve retray pedleri
• Prototip/Macap geliştirme/veri/uyumluluk ile uyumlu
• Test planı ve kabul tarihi kabul edildi

13) Anti-desenler

"Scriptler = yalnızca mutlu yol" (hataları/kenarı yoksayın).
Okunamaz Kabul (ölçülebilir bir kriter yerine "uygun hale getirin").
Gereksinimlerde A11y ve yerel ayar eksikliği.
İş amacı ve UX uygulamasını karıştırma ("alt TTV" yerine "açılır pencere ekle").
Hiçbir etkinlik şeması yoktur - başarıyı ölçmek için hiçbir şey yoktur.

14) Özlü Kullanıcı Hikayeleri Örnekleri

Yeni bir kullanıcı olarak, oyuna hemen başlamak için telefonumu onaylamadan e-posta ile kayıt olmak istiyorum; Sınırlar aşılırsa - alternatif "misafir'i gösterin.
Bir yönetici olarak, verileri muhasebe ile doğrulamak için raporu filtreler ve proje saat dilimiyle CSV'ye aktarmak istiyorum.

15) Uygulama planı (3 yineleme)

• Hikaye/Kullanım Durumu/Kabul şablonları, birleşik senaryo kaydı, minimum analitik şema, kontrol listesi.

• Anahtar senaryolar için Kullanıcı Akışı + CJM, A11y kriterleri, Tamamlama/TTV/Hata panoları, E2E seti.

• Öykü Haritalama, Etki × Çaba önceliklendirme, A/B hipotezleri, düzenli metrik incelemeler ve CAPA'lar.

16) Mini-SSS

Kişiler mi yoksa sadece JTBD mi?
Her ikisini de kullanın: kişiler bağlam ve sınırlamalar, JTBD - niyet ve değer verir.

Piksele kadar her şeyi tanımlamam gerekiyor mu?
Hayır. Senaryo hedefi, adımları, dalları ve başarı kriterlerini yakalar; pikseller - mizanpajların ve DLS'nin görevi.

Senaryonun "hazır" olduğu nasıl anlaşılır?
Ölçülebilir Kabul, mutlu/üzgün/kenar teminatları, A11y kriterleri, olaylar ve hedef KPI'lar vardır.

Sonuç

Kullanıcı senaryoları bir ürünün "iskeleti'dir: açık amaç (JTBD), tutarlı akış (Kullanıcı Akışı/Hikaye Haritalama), doğrulanabilir kriterler (Kabul), ölçülebilirlik (olaylar ve KPI'lar) ve erişilebilirlik/yerel ayarlara saygı. Bunları tek tip şablonlarda düzeltin, doğrulamayı otomatikleştirin ve bunları gerçek metriklere göre düzenli olarak gözden geçirin - bu şekilde arayüzler tüm kullanıcılar için açık, hızlı ve değerli kalacaktır.