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

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

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

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

Фуууух.. видихаю. Сподіваюсь ви ше тут.

Накидайте в коментарях, про що хотіли б, щоб я розповів детальніше. А то там одні курвоботи коментять (хто не курвобот і вже прокоментував — ви супер).

Тепер давайте інтерактив. В ріфейсі я вперше стикнувся з тим що немає апки де можна підглянути UX технології заміни обличчя. Як ви вже зрозуміли на той момент я був не те щоб інтерфейсним дизайнером зі стажем. І ця задача давалась тяжко. Флоу вийшов наступний:

1. Обираєш контент
2. На контенті визначаємо скільки облич є на відео. Під кожне обличчя даємо контрол заміни на інше
4. Лоадер
5. Результат

Проблема була в тому що щоб повернутись назад до вибору контенту потрібно було двіччі натиснути ⬅️ назад. Це не зручно, бо в наших інтересах дати людині подивитись побільше контенту з власним обличчям. Як би ви вирішували цю проблему?

Сьогодні вдалося трохи раніше перестати працювати й сісти за постики. Спробую протягом дня поділитись власним досвідом по роботі з AI в продуктах.

Саме в Reface я вперше зрозумів одну дуже дивну штуку — не всі продукти починаються з проблеми користувача.

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

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

Тому спочатку ми навіть не хотіли давати користувачам можливість завантажувати свої відео. Пізніше навіть зробили окрему AI-модель, яка могла визначити, чи було відео заріфейшене. Доводилося одночасно придумувати і продукт, і правила його використання.

Про AI native застосунки зараз не говорить хіба що лінивий. Термін уже встиг побувати в кожному другому подкасті, статті й навіть на сайті Reface *самоіронія — це теж моє*

Мені здається, найцікавіше в AI native навіть не сам AI. Це радше про можливість заново подивитися на речі, які роками здавалися очевидними.

Наприклад, застосунок для підрахунку калорій. Роками все виглядало приблизно однаково: відкрив застосунок → знайшов продукт у базі → ввів вагу → побачив калорії. Якщо робити схожу апку, то ваша конкурентна перевага — або кращий UX пошуку, або красивіший UI (ну або все разом).

А що, якщо людина взагалі не повинна нічого шукати? Що, якщо точкою входу стане не пошук, а фотографія?

AI дозволяє заново поставити питання: "Чи цей інтерфейс — найкращий спосіб допомогти юзеру досягти мети?"

І як гарно було б зараз написати: "Саме з цього й почався BitePal." Але в реальності ми були на стадії: "AI щось вміє... а-а-а! Що тепер із цим робити?" *біжить кричить*

Ок, давайте лайтовий пост, щоб закінчити цей день.

Признаюсь вам у може найбільшій UX брехні в моєму житті.

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

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

Прогресбар показував не прогрес. Він показував НАДІЮ.

І тепер питання.
Це хороший UX чи маніпуляція?

Сьогодні планую більше розповісти про BitePal. Як ми робили анти-трекер калорій, а в результаті все одно зробили трекер калорій.

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

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

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

Після посту про перший BitePal в коментах спитали, чи була тоді дизайн система. Якщо чесно, ні. Був радше дизайн-кіт: шрифти, кольори, кнопки, іконки та базові компоненти. Ми взагалі не були дуже послідовними, й одні й ті самі UX рішення могли виглядати по-різному.

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

Є навіть жарт: спочатку дизайн систему не роблять, бо ще рано, потім бо вже запізно *ми зараз тут*

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

Дизайн системи тоді ще не було. Але характер у продукту був. Кирило, дякую!

BitePal 1.0 реально сподобався людям (в коментарях до першого сьогоднішнього посту є живі підтвердження, і я нікому не платив).

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

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

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

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

На головному екрані з'явився тогл який перемикав режими: або калорії, або наша стара оцінка їжі. І за замовчуванням усе ще були саме оцінки.

Здавалося, що це елегантний компроміс.

BitePal 2.0

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

Але калорії повністю зламали продукт.

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

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

Тоді ми зрозуміли, що будуємо не найточніший, а найказуальніший трекер калорій. Для людей, які ненавидять класичні трекери калорій. Ще й з єнотом!

Вас, мабуть, дістали вже розмови про AI. Тому сьогодні теж трохи про AI.

Але почну здалеку. В першому BitePal була одна дизайнерська ідея, яку я відстоював з піною в роті. Добре, що тоді всі були сильно зайняті пошуком product market fit і не мали сил зі мною сперечатись.

Я дуже хотів зробити маску камери для фотографування їжі круглою.

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

Так і сталося. Частину рішень я дизайнив одразу, а частина народилася вже значно пізніше.

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

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

Рубрика АІ-філософія від Марка Іванюка (моє альтер его)

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

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

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

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

Раз вже вечер п'ятниці, ось вам мій хот тейк.

Зараз найкращий кандидат на позицію джун UI/UX дизайнер — це графічний дизайнер.

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

Пізніше, коли я став інтерфейсним дизайнером, перше питання майже завжди було: "чи це best practice?". І тільки потім — наскільки воно красиве чи унікальне. Треба було прочитати всі статті на Nielsen Norman Group і навчитися не вигадувати велосипед.

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

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

Поки ви відпочиваєте, я вам трохи відео контєнту приніс. Про клод, чуйку і помідори.

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

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

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

Loom в мене безкоштовний, тому замість одного відео серія з трьох частин:

01 - Задача
02 - Рішення
03 - Результат

Після вчорашніх відео в коментах було цікаве питання.

— Чому інші трекери калорій не придумали такий самий контрол для редагування ваги?
— Тому що вони вирішували іншу задачу.

У класичних трекерах людина зазвичай вже знає вагу їжі. Їй треба швидко ввести 110г. Тому фокус одразу на інпуті і відкрита клавіатура абсолютно логічне рішення.

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

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

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

Дякую що коментуєте.