تایید قبل از برداشت

1) یک اسکریپت سفارشی چیست ؟

یک اسکریپت کاربر یک مسیر توصیف شده کاربر به یک نتیجه در یک زمینه خاص است، با پیش نیازها، مراحل، گزینه ها و معیار «آنچه که به عنوان موفقیت» محسوب می شود. اسکریپت ها «چرا» (JTBD/target) و «چگونه» (جریان UX، رابط ها، حالت ها) را مرتبط می کنند.

• زبان مشترک بین محصول، طراحی، توسعه، داده ها و انطباق.
• اختلاف کمتر در الزامات، پذیرش سریعتر.
• اتصال صریح از ویژگی های با اثر کسب و کار و معیارهای.

2) زمینه های سناریو: افراد و کارهایی که باید انجام شود

افراد: چه کسی، زمینه، مهارت ها، محدودیت ها (از جمله A11y).
JTBD: «وقتی [وضعیت]، من می خواهم [انگیزه] به [نتیجه مورد انتظار]».
بخش زمینه: دستگاه، شبکه، محلی/زبان، منطقه زمانی، حقوق، محدودیت های محیطی.

• هنگامی که یک بازیکن تلاش می کند تا برنده در شب از یک تلفن همراه در 3G برداشت، من می خواهم به سرعت هویت من بدون تماس به منظور دریافت پول تا 10 دقیقه تایید می کنند.

3) فرمت های توضیحات: داستان کاربر/شغل، مورد استفاده، پذیرش

3. 1 داستان کاربر/شغل (قالب)

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

3. 2 مورد استفاده (ساده شده)

4) نقشه های مسیر و ساختار جریان

4. 1 CJM (نقشه سفر مشتری)

مراحل: آگاهی → انتخاب → اولین اقدام → Redo → پشتیبانی → نگه دارید

برای هر یک: اهداف، اصطکاک، احساسات، کانال ها، معیارها (تبدیل، زمان، NPS)

4. 2 جریان کاربر и نقشه برداری داستان

جریان کاربر: گره (صفحه نمایش/حالت) و انتقال (شرایط/رویدادها) گراف.
نقشه برداری داستان: «خط الراس» (حماسه/فعالیت) × «برش عمودی» (MVP → پسوند).

5) شاخه: خوشحال، غمگین، موارد لبه

مسیر شاد: یک مسیر حداقلی برای رسیدن به ارزش

مسیر غم انگیز: خطاهای قابل پیش بینی (اعتبار، محدودیت ها، وقفه ها).
موارد لبه: نادر اما گران قیمت: شبکه ناپایدار، تکراری، لغو، نژادها، درگیری دولت، عدم تطابق محلی/منطقه زمانی، در دسترس بودن (صفحه کلید به جای ماوس، صفحه نمایش خوان).

نکته: برای هر مرحله کلیدی - حداقل یک سناریوی غم انگیز و یک لبه.

6) کشورهای UI

• 'loading '/' empty '/' success '/' error '/' partial '/' disabled'
• نکات و میکرو copywriting ؛ قابلیت دسترسی (نقش/آریا، تمرکز، اندازه هدف) ؛ محل و فرمت اعداد/تاریخ/ارز.

7) الزامات A11y در سناریوها

صفحه کلید: تمام اقدامات بدون ماوس قابل دستیابی است ؛ تمرکز قابل مشاهده، سفارش تب.

محافظ صفحه نمایش: نقش برچسب مناسب و اتصالات ؛ جایگزین های رسانه ای

رنگ/کنتراست: ≥ WCAG AA ؛ فقط رنگ نیست.
حرکت: پشتیبانی از حرکت کاهش یافته را ترجیح می دهد.
ورودی: فرمت/ماسک، صفحه کلید صوتی/روی صفحه نمایش ؛ اهداف 40-48 پیکسل کافی است.
معیارهای 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: متون در منابع، پشتیبانی از آینه ؛ طول رشته و hyphenation.
محدودیت ها: محدودیت ها، سن، 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-audit: دستی (NVDA/VoiceOver) + خودکار خطوط.
جلسات قابلیت استفاده: 5-8 پاسخ دهنده به سناریوی کلیدی.
تله متری: پرچم های ویژگی، داشبورد تکمیل/TTV/خطا.
Dogfooding: چک لیست در تیم اجرا می شود.

12) چک لیست سناریو (بررسی سریع)

• JTBD فرموله شده و درک شده توسط تیم
• شخص/زمینه/محدودیت ها بیان می شود
• جریان کاربر و نقشه داستان آماده هستند ؛ شاخه مشخص شده است
• معیارهای پذیرش (از جمله A11y) روشن و قابل آزمایش هستند
• حالت UI (بارگیری/خالی/خطا) مستند شده است
• رویدادهای تحلیلی و KPI ها تعریف شده است
• محلی سازی/فرمت/ارز در نظر گرفته شده
• خطرات/شاخه های جعلی و پد های retray شرح داده شده است
• نمونه اولیه/مکاپ با توسعه/داده/انطباق هماهنگ شده است
• برنامه آزمون و تاریخ پذیرش توافق

13) ضد الگوهای

«Scripts = happy path only» (نادیده گرفتن خطاها/لبه).
پذیرش غیر قابل خواندن («آن را راحت» به جای یک معیار قابل اندازه گیری).
کمبود A11y و محل در الزامات.
مخلوط کردن اهداف کسب و کار و پیاده سازی UX («اضافه کردن پنجره» به جای «TTV پایین»).
هیچ برنامه ای برای اندازه گیری موفقیت وجود ندارد.

14) نمونه هایی از داستان های مختصر کاربر

به عنوان یک کاربر جدید, من می خواهم به ثبت نام از طریق ایمیل بدون تایید گوشی من برای شروع بازی حق دور; اگر محدودیت بیش از - نشان می دهد جایگزین «مهمان».
به عنوان یک مدیر، من می خواهم گزارش را به CSV با فیلترها و منطقه زمانی پروژه صادر کنم تا داده ها را با حسابداری تأیید کنم.

15) برنامه پیاده سازی (3 تکرار)

• داستان/استفاده از مورد/قالب پذیرش، ثبت نام سناریوی یکپارچه، حداقل طرح تحلیلی، چک لیست.

• جریان کاربر + CJM برای سناریوهای کلیدی، معیارهای A11y، داشبورد تکمیل/TTV/خطا، مجموعه E2E.

• نقشه برداری داستان، اولویت بندی تأثیر × تلاش، فرضیه های A/B، بررسی منظم متریک و CAPA ها.

16) مینی سوالات متداول

افراد یا فقط JTBD ؟

از هر دو استفاده کنید: افراد زمینه و محدودیت ها، JTBD - قصد و ارزش را ارائه می دهند.

آیا باید همه چیز را تا پیکسل توصیف کنم ؟

نه، اينطور نيست این اسکریپت هدف، مراحل، شاخه ها و معیارهای موفقیت را در بر می گیرد. پیکسل - وظیفه طرح بندی و DLS.

چگونه بفهمیم که کتاب «آماده» است ؟

پذیرش قابل اندازه گیری، پوشش شاد/غمگین/لبه، معیارهای A11y، رویدادها و KPI های هدف وجود دارد.

نتیجه گیری

سناریوهای کاربر «اسکلت» یک محصول هستند: هدف روشن (JTBD)، جریان ثابت (جریان کاربر/نقشه برداری داستان)، معیارهای قابل تایید (پذیرش)، اندازه گیری (رویدادها و KPI ها) و احترام به دسترسی/محلی. آنها را در قالب های یکنواخت ثابت کنید، تأیید خودکار کنید و به طور مرتب آنها را با توجه به معیارهای واقعی بررسی کنید - به این ترتیب رابط ها برای همه کاربران روشن، سریع و با ارزش خواهند بود.