გადამოწმება დასკვნამდე

1) რა არის მომხმარებლის სცენარი

მომხმარებლის სცენარი არის მომხმარებლის აღწერილი გზა შედეგისკენ კონკრეტულ კონტექსტში, მკაფიო წინაპირობებით, ნაბიჯებით, ალტერნატივებით და კრიტერიუმით „რაც წარმატებულად ითვლება“. სკრიპტები ასოცირდება „რატომ“ (JTBD/მიზანი) და „როგორ“ (UX ნაკადი, ინტერფეისი, მდგომარეობა).

• საერთო ენა პროდუქტს, დიზაინს, განვითარებას, მონაცემებსა და შესაბამისობას შორის.
• ნაკლები შეუსაბამობა მოთხოვნებში, უფრო სწრაფი მიღება.
• აშკარა კავშირი ფიჩთან ბიზნეს ეფექტთან და მეტრიკებთან.

2) სკრიპტების საფუძვლები: პიროვნებები და Jobs-to-Be-Done

პირები: ვინ, კონტექსტი, უნარები, შეზღუდვები (მათ შორის A11y).
JTBD: „როდესაც [სიტუაცია], მინდა [მოტივაცია], რომ [მოსალოდნელი შედეგი]“.
კონტექსტის სეგმენტი: მოწყობილობა, ქსელი, ლოკალი/ენა, დროის ზონა, უფლებები, გარემოს შეზღუდვები.

• როდესაც მოთამაშე ცდილობს მოგება ღამით 3G- ზე მიიტანოს, მინდა სწრაფად დავადასტურო პიროვნება ზარის გარეშე, რათა 10 წუთამდე მიიღოთ ფული.

3) აღწერილობის ფორმატები: User/Job Story, Use Case, Acceptance

3. 1 Muser/Job Story (შაბლონი)

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

3. 2 Use Case (გამარტივებული)

4) გზის რუკები და ნაკადის სტრუქტურა

4. 1 CJM (Customer Journey Map)

ეტაპები: ცნობიერება - არჩევანი - პირველი მოქმედება - გამეორება - მხარდაჭერა - შენარჩუნება

ყველასთვის: მიზნები, ხახუნის, ემოციები, არხები, მეტრიკა (კონვერტაცია, დრო, NPS)

4. 2 User Flow и Story Mapping

User Flow: კვანძების გრაფიკი (ეკრანები/სახელმწიფოები) და გადასვლები (პირობები/მოვლენები).
Story Mapping: „ქედი“ (ეპიკური/აქტივობა) × „ვერტიკალური ნაჭრები“ (MVP გაფართოება).

5) ფილიალი: ბედნიერი, sad, edge cases

ბედნიერი პატივი: ფასეულობის მინიმალური გზა.
Sad path: პროგნოზირებადი შეცდომები (შესაბამისობა, ლიმიტები, ტაიმაუტები).
Edge cases: იშვიათი, მაგრამ ძვირი: არასტაბილური ქსელი, დუბლიკატები, გაუქმება, რბოლა, სახელმწიფო კონფლიქტი, იდაყვის/დროის ზონის შეუსაბამობა, წვდომა (კლავიატურა თაგვის ნაცვლად, სკრინერი).

რჩევა: თითოეული საკვანძო ნაბიჯისთვის - მინიმუმ ერთი sad და ერთი edge სცენარი.

6) ინტერფეისის მდგომარეობა (UI სახელმწიფოები)

• `loading` / `empty` / `success` / `error` / `partial` / `disabled`
• მინიშნებები და მიკრო საავტორო უფლებები; (როლების ხელმისაწვდომობა/aria, ფოკუსი, ტარგეტების ზომა); ნომრების/თარიღების/ვალუტის ლოკალური და ფორმატი.

7) A11y მოთხოვნები სცენარებში

კლავიატურა: ყველა მოქმედება მიიღწევა მაუსის გარეშე; ხილული ხრიკი, ბრძანება Tab.
Scrinrider: ეტიკეტის სწორი როლები და კავშირები; ალტერნატიული მედია.
ფერი/კონტრასტი: WCAG AA; არა მხოლოდ ფერი.
Motion: მხარდაჭერა 'prefers-reduced-motion'.
შეყვანა: ფორმატი/ნიღბები, ხმა/ეკრანის კლავიატურა; საკმარისი ტარგეტები 40-48 px.
დაამატეთ ინდივიდუალური A11y კრიტერიუმები Acceptance- ში.

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 და მიზნობრივი ბარიერები

Completion Rate (წილი, რომელმაც დაასრულა სცენარი) არის X%

დრო (საშუალო შედეგამდე) - Y წუთი

Error Rate (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): happy/sad/edge.
A11y აუდიტი: სახელმძღვანელო (NVDA/VoiceOver) + მანქანების ლინტერი.
Usability სესიები: 5-8 გამოკითხული საკვანძო სცენარისთვის.
ტელემეტრია: ფიჩე დროშები, დაშბორდები Completion/TTV/Error.
Dogfooding: შიდა გუნდის ზოლები ჩეკების სიებში.

12) სკრიპტის სია (სწრაფი შემოწმება)

• JTBD ჩამოყალიბდა და გუნდს ესმის

ასახულია პიროვნება/კონტექსტი/შეზღუდვები

• მომხმარებელი Flow და Story Map მზად არიან; აღინიშნება ფილიალები
• Acceptance Criteria (მათ შორის A11y) გასაგებია და ტესტირება
• UI (loading/empty/error) სახელმწიფოები დოკუმენტირებულია
• ანალიტიკური მოვლენები და KPI

გათვალისწინებულია ლოკალიზაცია/ფორმატები/ვალუტა

• აღწერილია რისკები/სახის ფილიალები და რელიეფის აღლუმები
• პროტოტიპი/მაკაპი შეთანხმებულია განვითარებასთან/მონაცემებთან/შესაბამისობასთან

შეთანხმებულია ტესტირების გეგმა და მიღების თარიღი

13) ანტი შაბლონები

„სკრიპტები = მხოლოდ ბედნიერი პატჩი“ (შეცდომების უგულებელყოფა/edge).
არ არის წაკითხული Acceptance („გააკეთე მოსახერხებელი“ გაზომილი კრიტერიუმის ნაცვლად).
A11y- ს არარსებობა და პრეტენზიები.
ბიზნეს მიზნის და UX- ის განხორციელების ნაზავი („დაამატეთ პოპი“ ნაცვლად „შეამცირეთ TTV“).
არ არსებობს ღონისძიების სქემა, წარმატების გაზომვა არაფერი აქვს.

14) ლაკონური მომხმარებლის ისტორიების მაგალითები

როგორც ახალი მომხმარებელი, მსურს ელექტრონული ფოსტის დარეგისტრირება ტელეფონის დადასტურების გარეშე, რომ დაუყოვნებლივ დაიწყოს თამაში; თუ შეზღუდვები აღემატება, აჩვენეთ ალტერნატივა „სტუმარი“.
როგორც მენეჯერი, მსურს CSV- ს ანგარიშის ექსპორტირება პროექტის ფილტრებითა და დროით, ბუღალტრული აღრიცხვით მონაცემების შესამოწმებლად.

15) განხორციელების გეგმა (3 გამეორება)

• Story/Use Case/Acceptance შაბლონები, ერთი სცენარის რეესტრი, მინიმალური ანალიტიკური სქემა, შემოწმების სია.

• User Flow + CJM საკვანძო სცენარებისთვის, A11y კრიტერიუმები, დაშბორდები Completion/TTV/Error, E2E ნაკრები.

• Story Mapping, პრიორიტეტული Impact × Effort, A/B ჰიპოთეზა, მეტრიკის რეგულარული გამოსხივება და CAPA.

16) მინი-FAQ

პიროვნებები თუ მხოლოდ JTBD?
გამოიყენეთ ორივე: ადამიანი იძლევა კონტექსტს და შეზღუდვებს, JTBD არის განზრახვა და ღირებულება.

უნდა აღწეროთ ყველაფერი პიქსელამდე?
არა. სცენარი აფიქსირებს მიზანს, ნაბიჯებს, ფილიალს და წარმატების კრიტერიუმებს; პიქსელები - განლაგების დავალება და DLS.

როგორ გავიგოთ, რომ სცენარი მზად არის?
არსებობს გაზომილი Acceptance, საფარი happy/sad/edge, A11y კრიტერიუმები, მოვლენები და მიზნები KPI.

შედეგი

მომხმარებლის სკრიპტები არის პროდუქტის „ჩონჩხი“: მკაფიო მიზანი (JTBD), შეთანხმებული ნაკადი (Story Mapping), შემოწმებული კრიტერიუმები (Acceptance), გაზომვა (მოვლენები და KPI) და ხელმისაწვდომობის/ლოკალის პატივისცემა. ჩაწერეთ ისინი ერთ შაბლონებში, ავტომატურად გადაამოწმეთ და რეგულარულად გადახედეთ რეალურ მეტრებს - ასე რომ, ინტერფეისები დარჩება გასაგები, სწრაფი და ღირებული ყველა მომხმარებლისთვის.