Projector logo
Курси

Чому в епоху AI виграють продукти з характером?

<p>Марко Іваник</p>
Марко Іваник
Head of Design у Reface, працює з командами дизайнерів, проєктує нові продукти та UX, а також бере участь у запуску нових AI-продуктів.
опубліковано: 13 липня 2026тривалість читання: ~1 хв.
Чому в епоху AI виграють продукти з характером?

З успіхом BitePal його почали копіювати. Не лише окремі фічі, як-от лист від єнота, коли його довго не годувати. З'явилися застосунки, які повторюють продукт майже один в один. Тільки замість єнота там білка.

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

Моя відповідь виросла з двох продуктів: Reface і BitePal.

Продукт, який почався не з проблеми

У Petcube, де я працював раніше, все було зрозуміло. Людина переживає за свого пса, коли він сам удома, і продукт розв'язує цю проблему. Саме в Reface я вперше зрозумів дивну річ: не всі продукти починаються з проблеми користувача. У Reface не було проблеми, яку треба вирішити. Була технологія заміни облич.

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

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

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

Інтерфейс Reface: стрічка контенту, результат заміни обличчя з вотермаркою і шеринг у соцмережі

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

Признаюся в найбільшій, мабуть, UX-брехні у своєму житті — пам'ятаєте прогрес у Reface, поки генерувався результат? Він майже нічого не означав. У перших версіях усе трималося на чесному слові: клієнт узагалі не знав, коли сервер поверне результат. Іноді це було 8 секунд, іноді 30. Показувати просто спінер не хотілося, бо після 10 секунд користувач міг вирішити, що застосунок завис. Але й показати справжній лінійний прогрес було неможливо.

Тому ми зробили прогресбар, який математично красиво сповільнювався ближче до кінця і ніколи не доходив до 100%, поки сервер не поверне результат, а щоб користувач остаточно не втратив надію, над прогресом ще й змінювалися підписи. У компанії досі живе внутрішній мем "taking longer then usual...".

Екран завантаження Reface з підписом Taking longer then usual і прогресбаром, який не доходить до 100%

«Прогресбар показував не прогрес. Він показував надію».

Хороший це UX чи маніпуляція? Питання досі відкрите.

Реклама застосунків, яких не існувало

Десь разом із появою Reface стався цілий AI-бум. Виходили нові пейпери, з'являлися відкриті моделі, щотижня хтось в офісі показував: «дивіться, що AI тепер може». І ми постійно думали, який новий продукт можна зробити.

У мене досі лежить окремий файл у Figma з тими експериментами. Генератор мемних підписів до фото. Модель, яка оцінює твій лук. Камера, що пояснює картини. Тамагочі, з яким можна спілкуватися. І ще багато всього.

Але замість того, щоб одразу це програмувати, ми спочатку перевіряли на рекламі, чи взагалі комусь цікава така ідея. Я малював рекламу, яка вела на фейкову сторінку App Store. Там усе виглядало натурально: іконка, скріншоти, опис, відгуки й кнопка download. Якщо люди хотіли скачати застосунок, ми розуміли, що в цієї ідеї є шанс.

Фактично ми продавали продукт, якого ще не існувало.

Фейкова реклама AI-камери CamGPT, яка розпізнає об'єкти на фото Фейкова реклама AI-тамагочі з віртуальним улюбленцем

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

Калорії перемогли — і зламали продукт

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

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

BitePal 1.0 з єнотом Manuela: головний екран, камера для фотографування їжі та оцінка страви замість калорій

Калорії ми свідомо не показували. У рекламі й на скріншотах прямо писали, що це трекер їжі без калорій. Як же ми помилялись.

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

«Продукт, який люди люблять, і продукт, за який вони готові заплатити — це не завжди одне й те ж».

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

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

Два режими BitePal поруч: оцінки їжі та підрахунок калорій, які перемикаються тоглом на головному екрані

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

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

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

BitePal 2.0: підрахунок калорій разом із віртуальним улюбленцем-єнотом

Рішення, які AI не запропонував би

У першому BitePal була дизайнерська ідея, яку я відстоював з піною в роті. Я дуже хотів зробити маску камери для фотографування їжі круглою.

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

Якби я попросив AI намалювати екран камери для логування їжі, він майже напевно зробив би її на весь екран. І був би правий. Але тоді в BitePal, найімовірніше, не з'явилася б ця маленька візуальна деталь.

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

Що кругла камера, що барабан — наслідок одного рішення, яке ми ухвалили на самому початку: фотографування їжі замість пошуку продуктів у базі. Решта інтерфейсних рішень просто логічно випливала з нього.

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

AI-рев'ю домашнього екрана BitePal з висновком, що маскот займає 47% екрана, і рекомендацією зменшити його

Проблема в тому, що люди відкривають BitePal не тільки по цифри макросів і калорії авокадо-тоста. Їм потрібен єнот. Те, що виглядає як погано спроєктований інтерфейс, насправді є частиною причини, чому продукт люблять.

AI дуже добре оптимізує. Він слідує всім евристикам, UX-принципам і здоровому глузду. Але якщо оптимізувати BitePal до кінця, можна отримати дуже правильний трекер калорій. Просто без єнота і круглої камери.

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

Звідси провокативна теза: зараз найкращий кандидат на позицію джуна в UI/UX — це графічний дизайнер. Коли я починав працювати графічним дизайнером, перше, що робив після намальованого логотипа, — відкривав пошук по картинках і дивився, чи немає вже десь схожого. Пізніше, ставши інтерфейсним дизайнером, я перш за все питав себе: «чи це best practice?» І тільки потім питав, наскільки воно красиве чи унікальне. Поки інтерфейсний дизайнер вчив правила, графічний тренував інший м'яз: як знайти рішення, яке буде естетичним, матиме власний характер і відчуватиметься живим. Вони все життя тренувалися шукати не правильне рішення, а цікаве.

Скопіювати продукт не так уже й складно. Значно важче повторити дрібні деталі, з яких він складається: крафтові іконки, тон текстів, чому саме єнот, чому його годують фотографіями їжі і чому під час фастингу його можна покласти спати. Окремо це дрібниці. Разом це характер, який і відповідає на питання «чому оберуть саме мій продукт».

Думаю, з появою AI ми менше конкуруватимемо швидкістю створення MVP і більше — продуктами, які захочеться скачати.

створюйте дизайн який зупиняє скроллна курсі

UX Design Advanced
опануйте повний UX-процес: від kick-off із замовником і глибинних інтерв'ю до прототипування та вимірювання usability — та закріпіть це на двох кейсах для реальних компаній
27.08.20263 місяці
18 000 грн/міс.
Детальніше
досвід

1+ рік комерційного досвіду в UX

старт навчання

27.08.2026

кількість місць

20

тривалість курсу

3 місяці

куратор

Євген Олексюк

реєстрація.
перший крок за вами

зростайте як дизайнерзавдяки новим знанням

дизайн з характеромконцентрат про головне

Що таке product market fit простими словами?
Чи означає любов користувачів, що продукт знайшов product market fit?
Чому швидке створення MVP більше не дає конкурентної переваги?
Що таке AI native застосунок?

ще цікаведля вас

23.06.20261 хвилина читання
Що AI насправді змінює в роботі дизайнера