«Страх — це баг». Чому психологічні гачки мобільного геймдеву є абсолютним табу в дитячих освітніх іграх

За понад 12 років у геймдеві Product/UX-дизайнер Євген Кавалеров здобув досвід роботи як із глобальними спортивними франшизами, так і з комплексними освітніми продуктами. У його портфоліо — розробка інтерфейсів для NBA 2K25, Olympic Games Jam: Beijing 2022 та NASCAR Manager. А зараз він працює над масштабними системами комерції та будує інтерфейс для освітньої RPG Prodigy Math Game.

В інтервʼю з Євгеном ми поговорили про те, як ігри адаптують під складні системи письма та кирилицю, як грамотне прототипування рятує лайв-сервісні ігри від дизайн-хаосу, і чому під час створення UX для дітей класичні маніпулятивні механіки перетворюються на абсолютне табу.

«Інтерфейс має говорити мовою спорту так само вільно, як і мовою ігор». Про глобальні спортивні проєкти та роботу над локалізаціями

— За понад дванадцять років у геймдеві ви працювали над кількома спортивними проєктами. Як це — проєктувати UX/UI для глобальних брендів із суворими гайдлайнами й аудиторією, ширшою за «класичних геймерів»?

Спортивні проєкти з’явилися у моїй кар’єрі не випадково. Ключовими тут є три. Перший — Olympic Games Jam: Beijing 2022, мобільна гра для iOS та Android від nWay у співпраці з МОК, до якої я долучився через Devoted Studios. Другий — UI для NASCAR Manager (також через Devoted Studios у партнерстві зі студією Hutch, відомою за F1 Clash). І третій, у 2024 році — NBA 2K25 у співпраці з Visual Concepts, де моя робота була ближчою до візуального та графічного дизайну в межах дуже усталеної візуальної мови.

Головне, чого навчив мене цей досвід: дизайнити для великого спортивного бренду та вигадувати айдентику з нуля — це дві різні професії. Ти не починаєш із чистого аркуша, а успадковуєш величезний шар сенсів ще до того, як поставиш на екран першу кнопку.

У самому спорті вже є ідентичність. У ліги своя, у команд та атлетів своя, а у спонсорів дуже конкретні вимоги. У продукті, який існує роками, вже закладено патерни взаємодії, які впізнають мільйони гравців. Аудиторія приходить з очікуваннями ще до того, як побачить твій екран.

Тому брендбук — це не просто дизайн-побажання, під які підлаштовують візуальний стиль наприкінці. Він визначає типографіку, колір, іміджеві матеріали, розміщення логотипів, фотографії, видимість спонсорів, а іноді навіть те, як взагалі можна показувати атлетів, команди чи змагання. Робота UI/UX-дизайнера полягає в тому, щоб поважати всі ці рамки й не дати бренду задавити юзабіліті.

Спортивні продукти відрізняються від решти ігор саме аудиторією. Хтось відкриває такий тайтл, бо він геймер із дитинства, а хтось просто тому, що любить баскетбол. Те саме з олімпійськими видами спорту чи автоспортом.

Я не можу припускати, що всі користувачі знають ігрові конвенції. Інтерфейс має говорити мовою спорту так само вільно, як і мовою ігор. Якщо людина з реального життя вже розуміє, що таке команди, турніри, рейтинги, екіпірування чи статистика, я спираюся на ці ментальні моделі замість того, щоб вчити її ще одній абстракції.

Звідси принцип, який я виніс із цих проєктів на всю подальшу кар’єру: сильний UX робить складне знайомим. У випадку з відомим спортивним брендом гравець уже щось знає про продукт ще до його запуску, і це знання — потужний дизайнерський актив.

— Лайв-сервісні ігри запускаються в десятках країн. З якими UX-викликами ви стикалися, адаптуючи інтерфейси під різні мови?

Тема локалізації має для мене два виміри: технічний і дуже емоційний. З емоційного боку, сильна локалізація це ще одне творче прочитання оригіналу. Коли я граю українською, то проживаю трохи іншу версію тієї самої роботи. Сюжет не змінився — змінився ритм жартів, характер персонажа посунувся, назва предмета стала поетичнішою. Тому я можу подивитися фільм чи пограти сюжет англійською, а якщо він мені дуже сподобався — ще раз українською, щоб почути, як інший автор прочитав той самий матеріал. Є просто технічно правильний переклад, а є локалізація, після якої здається, що продукт від початку написали для тебе: з рідним ритмом, гумором і тоном. І це два різних досвіди.

Технічний бік далекий від цього ідеалу. Більшість продуктів, над якими я працював, робили для компаній, орієнтованих на США та Європу. Зазвичай дизайнери там створюють базовий інтерфейс і роблять його достатньо гнучким, щоб він підтримував різні довжини рядків. Команди локалізації працюють зі стрінг-таблицями, глосаріями та ресурсами локалізації на рівні рушія, а далі стрінги підключаються до гри через рушій або контент-пайплайн.

Моя робота як UI/UX-дизайнера — створити систему, яка витримає локалізацію: гнучкі контейнери, розумне перенесення, безпечні мінімальні розміри, масштабовані компоненти, коректний фолбек шрифтів, запас місця для мов, довших за англійську. Якщо компонент працює лише з англійським реченням з Figma — він крихкий.

Найважче адаптувати інтерфейси під мови, що ламають канони латиноцентричного UI:

• CJK (китайська, японська, корейська): потребують величезних наборів символів та мають зовсім інші правила перенесення рядків.
• Мови Південно-Східної Азії (тайська, лаоська тощо): не використовують пробіли між словами.
• RTL-мови (арабська, іврит): вимагають віддзеркалення всього лейауту, напрямку навігації та іконок.

Кирилицю технічно інтегрувати легше, але візуально це той ще квест. Залежно от гарнітури, кирилиця (особливо у геометричних та капсових шрифтах) дає щільнішу, прямокутнішу й часто монотонну текстуру порівняно з латиницею. Тож простої позначки «підтримує кирилицю» замало — потрібно перевіряти реальні гліфи, кернінг і насиченість. З мого досвіду, виразну кирилицю часто легше вписати в антикви чи гуманістичні системи, ніж у жорсткі геометричні гротески. Саме тому вона так природно почувається в RPG та стратегіях, де типографіка є частиною світобудови, і важче — у щільних спортивних інтерфейсах.

Тому я розділяю мовну локалізацію та інтернаціоналізацію UI. Переклад може бути ідеальним, а інтерфейс усе одно провалиться. UI має бути спроєктований під саму систему письма.

Для української мови один із найпомітніших прикладів — це Baldur’s Gate 3. У діалоговій RPG мова не лежить поверх гри, а є частиною ігрової системи. Характер персонажів, гумор, квести, лор, стосунки, описи предметів, тон фентезі — усе проходить через текст. Тому хороша українська локалізація дає інший культурний погляд на ту саму гру. Локалізація перестає бути галочкою в налаштуваннях і стає частиною творчого досвіду.

Інший важливий крок — додавання українського інтерфейсу в Epic Games Store у червні 2025 року. Це нормалізує мову на рівні екосистеми та сигналізує: ця аудиторія достатньо помітна, щоб заслуговувати на повноцінний інтерфейс.

Цікавим потенційним кейсом став би Brawl Stars. У разі появи української версії це буде ідеальний іспит для мобільного UI: як зберегти мультяшну енергію та «панч» компактного, сильно брендованого латинського шрифту в кирилиці?

Під час планування системи я орієнтуюся на глобальні продукти, які вже розв’язали подібні задачі. Для спортивного/динамічного UI це Rocket League, Overwatch, Asphalt Legends; для фентезі та текстомістких ігор — Baldur’s Gate 3, Genshin Impact; для грайливої та читабельної типографіки — Fall Guys, Fortnite та тайтли Supercell.

Локалізація не має заходити в розмову наприкінці. Якщо дизайнер будує інтерфейс навколо одного ідеального англійського рядка й одного латинського шрифту, команда локалізації проведе решту продакшену у війні з дизайном. Якщо мислити глобально від початку, питання інші. Чи переживе кнопка напис на сорок відсотків довший? Чи має шрифт справжню українську кирилицю, а не лише технічно присутні гліфи? Чи віддзеркалиться лейаут для арабської? Чи зможу я міняти дисплейний шрифт для кожної писемності, не руйнуючи бренд? Це дизайнерські питання. Команда локалізації може перекласти рядки, але не може врятувати інтерфейс, який не проєктували для локалізації.

Саме тому український локалізаційний ландшафт мені сьогодні такий цікавий. Для гравців у ньому емоційна й культурна цінність — бачити, що до мови ставляться серйозно. Для дизайнерів — технічний виклик: узяти глобальну айдентику і зробити так, щоб українська кирилиця відчувалася її частиною від самого початку. Коли це вдається, ти не відчуваєш, що хтось переклав інтерфейс, а що гра органічно так говорить.

«Це найбільша помилка в дизайні лайв-сервісу: розв’язувати кожен новий запит як незалежну фічу». Про дизайн-хаос, критичність прототипування та wireframes

— У лайв-сервісних іграх щомісяця з’являються нові механіки та івенти. Як не допустити хаосу в інтерфейсі й зберегти гнучкість дизайн-системи?

Один івент приносить нову картку, наступний — інший модальник. Ще одна команда робить нове оформлення валюти, інша фіча — свою систему ревардів, а нова категорія магазину отримує ще один патерн навігації. Кожне рішення локально осмислене. Через кілька років продукт накопичує шари дизайн-історіїі це найбільша помилка в дизайні лайв-сервісу: розв’язувати кожен новий запит як незалежну фічу.

Проблема тут не косметична. Візуальна неконсистентність — лише верхівка, оскільки далі йде операційна складність: гравці кілька разів вчаться схожим взаємодіям, дизайнери пам’ятають винятки, інженери підтримують паралельні реалізації, у QA більше станів, а лайв-опс залежить від дизайну й інженерії там, де все мало б бути конфігурованим.

Тому я розділяю дизайн фічі та дизайн системи. Щоразу, додаючи щось нове, важливо запитати: це справді унікальне рішення чи ще одна варіація вже наявного патерну? Чи можна зробити перевикористовуваний компонент, який лайв-опс зможе конфігурувати сам, а інженерія — зібрати в єдину структуру? І що станеться, коли через пів року у фічі з’явиться 20 нових варіацій?

Ці питання стали визначальними в моїй роботі над системами комерції та бандлів для Prodigy Math Game. Метою було створити не один привабливий екран оферу, а фреймворк, який підтримує різні комбінації предметів, цінові структури й стани володіння без потреби щоразу вигадувати все заново.

Зрілий продукт також учить поважати легасі: чинний UI — це роки інженерії, звичка гравців та готові асети. Перевикористання тримає вартість розробки під контролем, тож задача дизайнера — визначити, що має залишатися консистентним, а де нова фіча дійсно заслуговує окремих інвестицій. Відповідно змінюється й роль дизайнера: ти менше думаєш «я малюю ці екрани» і більше — «я визначаю, як поводиться система». Senior-дизайнеру в лайв-сервісі потрібне розуміння ігрової економіки, аналітики, інженерної архітектури, виробництва контенту, монетизації й бізнес-цілей. Дизайнер стає сполучною тканиною між дисциплінами.

— Чому підхід «спочатку прототип» критичний для сучасної розробки ігор і скільки часу й ресурсів він реально заощаджує на препродакшені?

Що ми будуємо? Чи це технічно здійсненно? Скільки коштуватиме? І чи варте воно того? Це найдорожчі питання в геймдеві, і прототип дає на них відповіді до того, як команда проінвестує значні ресурси. Прототипування — це не окремий етап, а спосіб зменшувати невизначеність протягом усього пайплайну.

Свіжий приклад з моєї практики — Prodigy Math Game. Перш ніж команда візьметься за реалізацію фічі, прототип створює спільне розуміння досвіду й підсвічує проблеми на етапі, коли їх найдешевше виправити. Ідея, яка має сенс на рівні менеджменту, завжди стикається з жорсткою реальністю продукту. У розробці беруть участь продакти, геймдизайнери, інженери, UI/UX-дизайнери, артисти, QA та дослідники і кожен бачить свої обмеження та можливості. Корисний прототип — це переклад високорівневої гіпотези у конкретну форму з урахуванням технологій, контенту, вартості та поведінки гравців.

Залежно від задачі прототип може мати різний вигляд:

1. Proof of Concept — перевірка технічної здійсненності.
2. Інтерактивний UX-прототип — тестування флоу гравця та моушну.
3. Vertical Slice — валідація всього ігрового досвіду.

Тестування не мусить починатися з гравців. Внутрішній плейтест або звичайний «коридорний» тест ловлять очевидне: незрозумілі флоу, зламані припущення, проблеми з темпом, юзабіліті, відсутні стани, взаємодії, які просто не відчуваються правильно.

Гравці стають потрібними тоді, коли на питання вже не може чесно відповісти сама команда. Розуміння, мотивація, складність, емоційна реакція — це питання для репрезентативних гравців. У цій точці внутрішнє знання перетворюється з переваги на упередження. Команда вже знає, як працює фіча. Це неможливо «розізнати».

Тож я не прив’язую момент тестування з гравцями до виробничого майлстоуна. Я прив’язую його до питання. Команда може перевірити гіпотезу сама — тестуємо усередині. Гіпотеза залежить від поведінки чи сприйняття гравців — кличемо гравців. Для Prodigy це особливо важливо: доросла команда розробки не може надійно замінити семирічну дитину.

Процес перевірки гіпотез варто розділяти на два послідовних етапи:

1. Ізольоване UX-дослідження (на прототипі): Використовується контрольоване середовище (скриншоти легасі-екранів, baked анімації, симульовані дані, шорткати, фейкові стани, спрощена логіка), щоб перевірити, чи розуміють гравці дизайн-концепт. Тут ми перевіряємо дизайнерську гіпотезу, і тільки її. Якщо респонденти стабільно виконують задачі, розуміють досвід і досягають бенчмарку, визначеного для дослідження, доказів достатньо, щоб виправдати подальшу розробку.
2. Продуктова валідація: Коли фічу імплементовано в код, її випускають як експеримент (A/B-тест) на обмежену частину аудиторії. Тут аналітики оцінюють вплив на бізнес-метрики та економіку продукту: конверсію, монетизацію, retention та залученість.

Лайв-сервіс — це жива система. Перемога в окремому A/B-тесті не гарантує довгострокового зростання всієї гри. Тому продуктова аналітика завжди має поєднуватися зі стратегічним баченням та якісними дослідженнями.

З появою генеративних ШІ-інструментів ми наближаємося до швидкої генерації легких грабельних білдів. Це дозволяє симулювати не просто один екран, а довгий життєвий цикл гравця: як відчувається прогресія через тиждень чи місяць гри, що неможливо оцінити зі статичного макета чи таблиці.

Та прототипування — це континуум і деталізація має підвищуватися лише відповідно до питань, на які треба відповісти:

• Low-Fidelity (Пінкбоксинг/Грейбоксинг): Тут не доводять фінальний візуал. Тут роблять обсяг видимим: лейаут, ієрархія, блоки копі, віджети, попапи, стани — швидка, напівнаочна інвентаризація того, чим фіча взагалі є.

Я віддаю перевагу «пінкбоксингу» (рожевим акцентним блокам поверх існуючого UI гри) — це миттєво демонструє команді, що саме пропонується змінити, а що залишається легасі-кодом. Головна мета тут — побудувати розуміння між продактом, геймдизайнером та інженерами за мінімальний час.

• Анімація та Моушн: Перша перевірка реальністю. Статика заохочує графічний овердизайн. Анімація ж одразу показує конфлікти уваги: який елемент задомінує екран, чи не перебиває ефект нагороди основну кнопку навігації.
• High-Fidelity інтерактивність: Поєднує реальні асети, динаміку, живий копірайтинг та інтерактивні стани. Потрібна для оцінки гейм-філу, реального таймінгу та складних переходів.

Гравець не купує UI, а купує світ, персонажів, фантазію, контент, прогресію та емоцію. UI цей досвід підтримує. UI-дизайнерам буває важко це прийняти, але інтерфейс не герой більшості ігор. Герой — це арт.

Тому ігровий UI не можна дизайнити ізольовано від арту. Відполірований інтерфейс поверх незавершеного або несумісного арту не дає команді оцінити досвід. Найкраща робота з ігровим UI, яку я бачив, народжувалася в тісному зв’язку з арт-дирекцією: потрібен хоча б key art, репрезентативне оточення чи готові асети, щоб зрозуміти щільність, колір, текстуру, масштаб і настрій. UI може відділяти себе від світу контрастом, мовою форм, глибиною, кадруванням, матеріалом, але має лишатися частиною того самого продукту. Якщо UI виглядає імпортованим з іншої гри, щось не так.

«Люди судять презентацію за найслабшим компонентом»

На лайв-опс контенті це очевидно. Гелловінський івент, умовний Pumpkin Fest: базова UI-система та сама, кнопки консистентні, а хедер, рамка, банер, фон і акценти — тематичні. Коли ревюїш такий UI, не клади відполірований інтерфейс поверх грубого скрибла художника, якщо можеш цього уникнути. Візьми зачищений репрезентативний арт або цілісний спрощений фон. Люди судять презентацію за найслабшим компонентом, тож необхідно тримати деталізацію оточення на рівні роботи, яку просиш оцінити.

Більшість моєї кар’єри пройшла віддалено — трохи офісів на початку, далі розподілені команди. Тому я думаю про зустріч як про інтерфейс. Колеги дивляться на тебе через 23- чи 27-дюймовий монітор. Твій розшерений екран займає лише частину дисплея, бо Zoom чи Google Meet з’їдають решту. Цей вюпорт — твій презентаційний носій і він має обмеження, навколо яких можна дизайнити.

П’ятнадцять UI-екранів одночасно не прочитає ніхто. Для стандартного флоу практичний максимум — приблизно чотири екрани або стани на один стабільний вид; далі все надто дрібне. Це корисне обмеження: фокус створює ясність, ясність економить час. Те саме з навігацією. Кожен неочікуваний зум, скрол чи стрибок по канвасу змушує аудиторію переорієнтовуватися, і за довге ревю це накопичується в когнітивне тертя. Тому вюпорт має стояти на місці.

Практична схема: той самий файл Figma відкритий у кількох вкладках браузера, кожна заздалегідь наведена на свою групу екранів. Шариться браузер, а не робочий стіл; між контекстами перемикаєшся вкладками. А нативний застосунок Figma відкритий приватно на іншому екрані або під розшереним вікном — там я і нотую, і витягую скриншоти з гри, і додаю кнопку, і збираю наступну версію пінкбокс-прототипу. Коли зміна готова, вона виходить у презентацію. Команда відчуває, що продукт реагує на розмову в реальному часі, а зустріч при цьому лишається візуально спокійною.

ШІ вже транскрибує зустрічі, пише підсумки і дедалі частіше перетворює нотатки на дизайн-артефакти. Це справді захопливо: можна уявити воркфлоу, де після зустрічі вайрфрейм сам з’являється у Figma. Але між тим, що народилося під час розмови, і тим, що згенеровано після, є різниця.

«З ШІ межа між прототипом і реалізацією розмивається»

Артефакт «після» потрапляє в чергу на ревю. Усі, хто щойно був у розмові, мають повернутися в контекст пізніше — завтра, за три дні, або асинхронно в тікеті. У лайв-сервісі організація — це пайплайн, і в ньому кожна така затримка коштує: обмежений час на ревю, обмежений час на зустрічі, багато фіч у боротьбі за увагу.

Живий прототип згортає цю петлю. Обговорити, візуалізувати, змінити й підтвердити напрямок за одну сесію. Наприкінці лишається одне питання: «Ми узгоджені щодо того, що бачимо?». Прототип стає візуальним записом рішення. Цілий раунд інтерпретацій — прибраний.

З ШІ межа між прототипом і реалізацією розмивається. Так, промпт не дає production-ready ігровий білд, безпечний і підтримуваний як треба. Безпека, архітектура, масштабованість, інтеграція — усе це досі має величезне значення. Але дизайнер сьогодні може згенерувати достатньо функціонального коду, щоб отримати щось значно ближче до MVP, ніж візуальний мокап. Справжні змінні, адаптивна поведінка, структури даних, взаємодії — і достатньо логіки, щоб оголити продуктові питання, які раніше неможливо було дослідити без інженерів.

— Наскільки деталізованим має бути UX-прототип ігрової механіки, щоб вважати гіпотезу перевіреною? Чи достатньо сірих wireframe-макетів у Figma, чи обов’язково залучати інтерактивні прототипи безпосередньо в ігрових рушіях?

Деталізація прототипу має визначатися питанням, на яке він відповідає. Висока деталізація не є кращою за замовчуванням: іноді достатньо швидкого «грейбоксу» чи «пінкбоксу», іноді — Figma чи ProtoPie, а іноді єдиний чесний інструмент — сам ігровий рушій. Виробнича мета визначає прототип.

Повноцінний хай-фай прототип в іграх складається з чотирьох шарів:

1. Візуал: UI, арт, композиція, типографіка та контент близькі до фінального продукту.
2. Моушн: переконливе відображення анімованих персонажів, VFX, переходів, айдл-станів та анімацій нагород.
3. Логіка: ігри рідко лінійні. Гравець володіє предметом — кнопка робить одне. Предмет заблокований — інше. Лічильник дійшов до нуля — новий стан. Змінилася змінна — той самий клік дає іншу відповідь.
4. Надійність: прототип, який іде в дослідницьку сесію, має працювати стабільно. Красивий прототип, який не завантажився, коли учасник його відкрив — це фейл. Надійність — частина деталізації.

Гравці під час UX-досліджень надзвичайно чутливі до будь-яких технічних огріхів. Вони не опишуть проблему термінами, а просто відволікуться, втратять упевненість або почнуть оцінювати баги прототипу замість самої гіпотези. Мета хай-фай — прибрати це тертя, щоб гравець перестав думати про інструмент і просто грав.

У своїй практиці я застосовував різні рівні деталізації залежно від задач проєктів:

• Прототипування з ШІ та вебом (Prodigy Math Game): Під час розробки систем інвентарю та екіпірування ручне створення десятків предметів у Figma чи ProtoPie зайняло б забагато часу. Використання вебанімацій, структурованих JSON-даних та підказок для ШІ дозволило швидко зібрати прототип з «мізками», де гравець міг порівнювати характеристики 30+ предметів у реальному часі.
• ProtoPie для складних UI-симуляцій (Prodigy, Olympic Games Jam: Beijing 2022, NASCAR Manager): У цих проєктах інструмент дозволив відтворити точну «хореографію анімацій» та таймінги. Мій головний принцип тут — bake everything: у відео або картини все, що не є прямою гіпотезою тесту, аби не перевантажувати файл.
• Застосування стриманості (NBA 2K25): Робота з Visual Concepts над NBA 2K25 вимагала іншого підходу. Оскільки гра вже має зрілий бренд та усталену ігрову мову, головне завдання полягало у візуальному дизайні, типографіці та роботі з легасі-асетами. Складне інтерактивне прототипування тут просто не було потрібне.

У Prodigy сильна культура дослідження користувачів, і це дає прототипу чітку мету. Ми не робимо презентаційні артефакти. Гіпотеза — досвід — репрезентативні гравці — спостереження — зміна продукту на основі доказів. Здорова петля. Вона заохочує експериментувати і з самим пайплайном: якщо з’являється кращий спосіб тестувати — ProtoPie, ШІ-код, нові дослідницькі інструменти, то його можна застосувати. Прототип найцінніший, коли він є частиною культури рішень.

Не кожному проєкту потрібне однакове прототипування. NBA 2K25 — корисний контрприклад. Моя робота там була ближчою до візуального й графічного дизайну в межах усталеної мови. NBA 2K уже має ідентичність, патерни, системи та зрілий бренд. Тут працюєш із типографікою, стилістикою, лейаутом, існуючими асетами і питанням, як зробити свіже, не ламаючи впізнаване. Не кожна дизайн-проблема — проблема взаємодії. Іноді експертиза це стриманість, ієрархія, типографіка, спадкоємність бренду та розуміння того, як далеко можна штовхнути систему.

Це і є відповідь на питання щодо деталізації. Прототип має бути настільки детальним, наскільки це вимагає невизначеність. Не більше й не менше.

«Дорослі добре компенсують слабкий UX». Про перехід в EdTech-ігри та стандарти UX/UI для дитячої аудиторії

— Що вас зацікавило у ніші EdTech-ігор та чи розробка інтерфейсів для дитячої аудиторії принципово відрізняється від UX для дорослих?

Prodigy — освітній продукт, але структурно це RPG: персонажі, прогресія, системи, екіпірування, наратив, валюти, нагороди, магазини, довготривала поведінка гравців. Дизайнерські проблеми тут упізнавано геймдизайнерські. Тож перехід не був розривом із казуальними іграми, спортом, кросплатформними продуктами, системним UI та монетизацією — всім, що я робив раніше. Змінилася відповідальність. Аудиторія — діти, і це змінює стандарт майже для кожного рішення.

П’ятирічна і дванадцятирічна дитина технічно належать до однієї аудиторії — з драматично різними навичками читання, тривалістю уваги, моторикою, цифровою грамотністю і розумінням абстрактних систем. Дорослий дизайнер легко переоцінює «очевидне». Ми десятиліттями вчили цифрові конвенції. Дитина — ні. Символ, «універсальний» для дизайнера, для неї може не означати нічого. Другорядна дія, яку дорослі знаходять миттєво, фактично невидима. Коротке для нас речення — надто складне для молодшої частини аудиторії.

Тому дослідження в Prodigy — не презентаційний ритуал, а частина культури. Гіпотеза, досвід, репрезентативні гравці, спостереження, зміна продукту на основі доказів. Замість «чи я думаю, що семирічна дитина це зрозуміє?» ми дивимося, куди клікає дитина. На що дивиться? Що ігнорує? Як називається фіча? Чи розуміє, що станеться, до натискання? Чи відновлюється після помилки? Чи впізнає нагороду?

Дизайн для дітей зробив мене дисциплінованішим. Діти дуже швидко викривають неоднозначність. Дорослі добре компенсують слабкий UX. Діти часто менш охочі або просто менш здатні це робити.

Є й ширша відповідальність. Залученість, утримання, прогресія, комерційні результати — усе важливе. Але в освітній грі ці цілі співіснують із навчанням і з відповідальністю за молоду аудиторію. Жодне рішення не оцінюється однією бізнес-метрикою. Досвід має залишатися зрозумілим, доречним і підтримувати стосунки гравця з продуктом.

— Як ви працюєте з візуальними стандартами доступності для дітей, які ще не вміють або тільки вчаться читати?

Перший принцип: важливі взаємодії не повинні залежати від уміння читати. Текст важливий, але зміст іде кількома каналами: формою, позицією, іконографікою, ілюстрацією, анімацією, ієрархією та консистентними патернами.

Зони натискання враховують моторику молодших гравців. Кілька малих елементів щільно поруч і UI створює невдачі, які не мають стосунку до розуміння фічі. Дитина розуміє, що робити. Вона просто не може влучити.

Типографіка задає ієрархію сама. Дитина не повинна читати кожне речення, щоб знайти головну дію. Що є головною дією? Що тут є нагородою? Що є допоміжним? Як працює валюта? Що можна ігнорувати? Якщо всі мають однакову вагу, ми просимо дитину побудувати ієрархію самостійно.

Іконографіка потребує обережності. «Універсальні» іконки — насправді вивчені конвенції, які дорослі бачили багато років. Тому важлива іконка потребує підтримки: тексту, анімації, розташування, повторення або контексту.

Є і специфічний ігровий виклик. Prodigy навмисно яскрава: персонажі, оточення, частинки, текстури, анімації, нагороди, рамки — усе змагається за увагу. UX не може стати гучнішим за все інше. Якщо кричить усе, то ієрархії немає ні в чому. Мета — функціональний шар, читабельний і не перетворює гру на бізнес-софт.

Моушн тут важить так само як і скрізь. Статичний інтерфейс збалансований, а потім один анімований персонаж, світиться нагорода або зациклений VFX повністю змінює ієрархію уваги. Тому я люблю анімовані прототипи: доступність оцінюється в умовах, близьких до реальних.

І кросплатформність. Гравці Prodigy присутні на дуже широкому спектрі пристроїв. Планшет замість десктопа, інший розмір екрана, інша продуктивність, тач замість миші. Доступність у справжній грі має бути варіативною, а не лише виглядати правильно в одному ідеальному фреймі у Figma.

«Хук, на якому тримається половина мобільного ринку, тут практично не працює». Про прозору монетизацію та табу під час розробки

— В освітніх іграх дитина грає, а батьки платять. Як ви будуєте purchase flows та монетизаційні екранні системи, щоб вони були прозорими для дорослих, але не лякали дитину й не блокували її навчальний процес?

У застосунку між дитиною та покупкою відображається екран «Спитай батьків». Це не UX-рішення на смак дизайнера — це вимога федерального законодавства США про захист дітей онлайн і правил платформ. Дитина не може самостійно зайти в комерційний флоу. Parental gate перевіряє, що далі йде дорослий, і саме дорослому показують ціну, вміст, умови та підтвердження. Так закон проводить ту межу, яку я в будь-якому разі провів би як дизайнер: гравець і той, хто платить, це різні люди, і їхні ролі не повинні змішуватися.

Для дитини монетизація не має перетворювати гру на низку фінансових бар’єрів. Для дорослих ціна, стан покупки, володіння й підтвердження мають бути чіткими та передбачуваними. Обидві частини живуть в одному продукті, і саме тому магазин — не суто візуальна задача. Зміни в інтерфейсі впливають на поведінку клієнтів, а зміни в економіці — на те, як вони сприймають інтерфейс. Дизайнер має розуміти, що саме оптимізується і який ризик бере на себе команда.

Водночас сам онбординг у Prodigy — це взаємодія трьох людей, а не однієї. У казуальному F2P онбординг — це один гравець і один екран, тоді як у Prodigy ми маємо три ролі: дитина грає, вчитель призначає Prodigy класу (і значна частина нових гравців приходить саме через школу) і батьки, які дізнаються про гру вже після того, як дитина в ній живе.

«Легка монетизація для нас — це принцип, а не слабкість»

Тому воронка тут не «встановив — заграв — купив», а «клас → гра в школі → гра вдома → батьки бачать, що відбувається».

Кожен перехід між цими ролями треба проєктувати окремо: що бачить дитина, що бачить вчитель, а що — дорослий, який відкрив гру вперше і хоче зрозуміти, чому син уже годину, граючи, розв’язує рівняння.

Саме звідси й береться конверсія. Головне джерело — не офер у грі, а батьки, які бачать цінність того, що дитина проводить час у Prodigy і покращує математику. Членство для них — це нагорода дитині за навчання, а не покупка під тиском. Продукт має підтримати саме цю логіку: показати дорослому прогрес, показати, що дитина отримає, і залишити рішення дорослому.

Легка монетизація для нас — це принцип, а не слабкість. Prodigy свідомо не «продавлює»: ми не виснажуємо ігрову економіку дитини, щоб змусити її просити гроші. Офери й моменти витрат розподілені по всьому місячному циклу членства, а не зосереджені в перших сесіях. Контент і прогресія спроєктовані окремо для кожного з трьох рівнів членства — так, щоб перехід з одного рівня на інший був природним продовженням досвіду для дитини, а для батьків — зрозумілим і нешкідливим апсейлом. Дитина не має відчувати, що гра зламалася без покупки, а дорослий, що його підштовхують.

«Етичний дизайн і комерційний результат часто описують як конфлікт»

Це і є моя рамка «безпека покупки як частина архітектури», а не надбудова після дизайну монетизації. Що відбувається після покупки? Чи очевидне володіння? Чи можна випадково купити те саме ще раз? Де закінчується перегляд і починається транзакція? Що буде, якщо транзакція не пройде? Чи чітке підтвердження? У який стан дитина повертається?

Іноді ця рамка вимагає йти проти власної дизайн-системи. Коли ми запускали новий уніфікований магазин, у нього зайшли value-бандли — набори з високою цінністю для гравця і, відповідно, з відносно високою ціною порівняно з рештою вітрини. Стандартний патерн покупки в грі — один клік на кнопці з ціною, але для бандлів він був занадто легким: одне випадкове натискання коштувало б дорого. Тому для дорогих кнопок магазину ми створили кастомний патерн подвійного підтвердження. Перший клік показує, що саме і за скільки купується, а другий — підтверджує. Це додаткове тертя рівно там, де незворотність рішення найдорожча, і саме тому воно виправдане. У дешевих покупках це було б зайвим, а в дорогих — помилкою.

Етичний дизайн і комерційний результат часто описують як конфлікт, але мій досвід із системами одноразових покупок у Prodigy доводить протилежне: зрозуміла логіка покупки і здорові показники не суперечать одне одному. Прозорість підтримує довіру, передбачуваність зменшує фрустрацію, а чітке володіння зменшує плутанину. Батьки, які розуміють, що купують і за що винагороджують дитину, набагато здоровіші довгострокові клієнти, ніж ті, кого інтерфейс притиснув або заплутав.

— У мобільному геймдеві часто використовують психологічні гачки (FOMO, механіки терміновості). Які з них є абсолютним «табу» під час розробки проєктів для дітей, і що є дійсно питанням етики та відповідальності самого дизайнера у цьому контексті?

Я розрізняю мотивацію і маніпуляцію. Ігри за своєю природою — це поведінкові системи: прогресія, цілі, нагороди, колекціонування, очікування, виклик, святкування, соціальні механіки. Усе це впливає на поведінку гравця, і в цьому немає нічого від початку неетичного. Розуміти мотивацію означає створювати якісну гру. Проблема починається тоді, коли інтерфейс свідомо експлуатує нездатність гравця усвідомити наслідки своїх дій. А коли ми працюємо з дітьми, ця межа стає принципово іншою за своєю природою.

В освітній грі страх — це не інструмент, це баг. У комерційному мобільному геймінгу страх чудово працює: таймер, який відраховує секунди до завершення оферу; «ти втратиш серію»; «твій прогрес зникне»; скриня, яка випарується, якщо не відкрити її просто зараз. Усе це побудовано на єдиній механіці — уникненні втрат. Вона ефективна, і саме тому настільки поширена. Проте в освітній грі будь-яка подібна механіка — це суворе табу, і причина тут не лише етична, а й функціональна.

«В освітній грі страх — це не інструмент, це баг»

Коли дитина в Prodigy розв’язує математичну задачу, стрес блокує процес пізнання. Мозок, який боїться, не вчиться — він захищається. Математична тривожність — це добре описане наукове явище. Гра, яка додає до розв’язання задач таймер, штраф чи загрозу втрати, не мотивує дитину, а вчить її асоціювати математику зі страхом. Це прямо суперечить меті освітнього продукту. Саме тому наш головний орієнтир — це навчання без стресу: жодного «встигни, поки не пізно», жодного шантажу втратою прогресу та жодного покарання за помилку, яке відчувалося б як таке. Помилка в математиці є природною частиною навчання, і гра має реагувати на неї так, як це робить мудрий вчитель: спокійно та з наступною спробою.

Варто бути чесними: у Prodigy є таймери та обмежені в часі офери. Це стандартний інструмент LiveOps — контент повинен ротуватися, а вітрина — оновлюватися. Але класичні FOMO-тригери у випадку з дитячою аудиторією виявляються малоефективними з простої причини: більшість молодих гравців ще не володіють абстрактним поняттям часу. Для дитини шести чи семи років напис «залишилося 2 години 14 хвилин» не є аргументом — це просто цифри, що змінюються. Хук, на якому тримається половина мобільного ринку, тут практично не працює.

Тому наше рішення — не тиск, а ротація. Офер з’являється як поп-ап превю саме тоді, коли він релевантний до поточних дій дитини. Через коротку тривалість уваги дитина реагує на те, що їй показали в цю секунду, а не на порівняння кількох альтернатив чи таймерів. Замість маніпулятивного «поспішай, бо зникне» працює чесне «ось що є сьогодні». Це краще сприймається дитиною та дає змогу ротувати контент без психологічного тиску, а остаточне фінансове рішення все одно приймає дорослий, який бачить повну картину, а не зворотний відлік.

«Віртуальна валюта корисна для внутрішньої економіки, але створює дистанцію між гравцем і реальними грошима»

Звідси формується й решта списку табу для дитячих продуктів: штучна терміновість витрат, оманлива ієрархія кнопок, маскування покупки під геймплей, захована кнопка відмови та повторювані переривання до переходу в комерційний флоу. Кожен із цих патернів експлуатує те, що у дітей ще перебуває у стані формування, здатність вчасно зупинитися та зважити наслідки дій.

Окремої уваги заслуговує віртуальна валюта. Вона корисна для внутрішньої економіки, але створює дистанцію між гравцем і реальними грошима. Що абстрактнішим є цей зв’язок, то більша відповідальність лежить на продукті: межа реальної транзакції має бути максимально чіткою та обов’язково вести до дорослого.

Етична відповідальність за такі рішення не належить комусь одному. Продакт визначає цілі, геймдизайн будує системи, аналітика вимірює, інженерія реалізує, керівництво задає напрям, а юристи й комплаєнс контролюють вимоги. Проте саме дизайн відповідає за те, наскільки ці рішення стануть видимими та прозорими для гравця: що домінує на екрані, наскільки легко відмовитися, чи пояснені наслідки, чи інтерфейс інформує, чи примушує, і скільки завад стоїть перед незворотним рішенням?

Саме в цьому контексті підхід «спочатку прототип» перетворюється з технологічного інструменту на етичний. Якщо чутливу взаємодію можна протестувати до релізу на велику дитячу аудиторію це обов’язково потрібно зробити. На UX-дослідженнях з дітьми видно не лише те, чи зрозуміли вони екран, а й те, чи вони напружилися. Прототип береже не лише ресурси розробки та метрики KPI, він береже досвід дитини.

Поведінкова психологія — це потужний інструмент. Вона чудово працює для побудови мотивації, прогресії, активації, утримання та дизайну нагород. Але розуміти поведінку означає також знати межу, за якою оптимізація стає неприпустимою. Особливо якщо ваш гравець дитина, і особливо коли ця дитина вчиться.

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини