Як ми зменшили кількість багів у релізі в 5 разів за допомогою одного AI-інструмента

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт! Я Софія — продакт-дизайнерка в компанії-платформі Kiss My Apps. Працюю там, де дизайн — це не тільки про «красиво», а про «працює», масштабується та інтегрується з усіма етапами розробки.

У Kiss My Apps кожен екран проходить через призму маркетингу, локалізації, аналітики та продуктової логіки. Наш дизайн — це екосистема, яка враховує всі ці виміри. Завдяки цій системності ми успішно запускаємо багатомовні продукти, якими користуються ком’юніті з сотень мільйонів людей.

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

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

Отже, далі я хочу поділитися кейсом про те, як невеликий зсув у робочому процесі та використання AI-інструмента в Figma допомогли нам зменшити кількість локалізаційних правок у релізі в 5 разів. Найцікавіше, що це рішення не вимагало складних інтеграцій чи розширення команди — воно виявилося максимально простим. Але про все по порядку.

Початкова ситуація: знайомий сценарій

Щоб зрозуміти, як ми дійшли до рішення, варто розібратись, як виглядав стандартний флоу в Kiss My Apps раніше:

1. Дизайнер створює макет.
2. Розробник інтегрує.
3. Локалізатор перекладає.
4. QA тестує.
5. Виявляються баги в локалізації.
6. Команда збирається на міт, обговорює: скорочуємо текст, скейлимо, переносимо блоки.
7. Локалізатор → дев → QA → і поїхали по колу ще раз.

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

Типові локалізаційні баги: знайомі всім приклади

Нижче — реальні приклади багів, які команда ловила на етапі тестування. У більшості випадків причини ті самі:

• Фрази, які виглядають ідеально англійською, розсипають весь макет німецькою, італійською або польською.
• Текст виходить за межі контейнера.
• Кнопки перетворюються на три рядки.
• Заголовки зсувають компоненти.

  

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

Момент усвідомлення: коли я зупинилась і подивилась на флоу збоку

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

А що, якщо б ми побачили цю проблему ще до початку розробки — її могло б і не бути? Це усвідомлення привело мене до ключової ідеї: перенести проблему на початок процесу, в зону, де я можу на неї вплинути.

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

Рішення: Figma AI Translate To як інструмент превентивного дизайну

Саме для цього ідеально підходила функція Figma AI Translate To. Ця нова AI-функція дозволяє автоматично перекладати текстові об’єкти на макетах потрібною мовою просто всередині редактора.

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

Що це дає на практиці:

• Підтримка багатьох мов — інструмент працює з більшістю популярних мов, дозволяючи швидко адаптувати UI для локалізації.
• Переклад усіх текстових об’єктів у кілька кліків — Figma автоматично знаходить усі текстові шари на вибраній сторінці та переводить їх одразу в макеті.
• Збереження структури та стилів — під час перекладу зберігається оригінальна верстка: шрифти, розміри, стилі, auto layout тощо.

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

Головна відмінність — тепер я перевіряю макети з AI-перекладом ще до розробки (кроки 2-3). Це займає хвилину, але економить дні на фіксах.

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

Кейс: як це працює на реальному прикладі

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

Але тепер я роблю одну просту річ — затримуюсь із передачею всього на одну хвилину:

1. Копіюю макет і виношу в окрему секцію.
2. Вмикаю Figma AI Translate to, обираю потрібні мови — і буквально за 10 секунд бачу реальну картину того, як приблизно виглядатиме інтерфейс після локалізації.

Нижче невеличка інструкція:

Тепер я відразу бачу:

• де текст виходить за рамки;
• де шрифт зменшився до мікроскопічного;
• де все ламається або переклад не в тему.

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

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

Результати

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

1. Кількість локалізаційних багів зменшилася в 5 разів і більшість із них виявлялися ще до того, як потрапляли до розробки.
2. Обговорення фіксів майже зникли — просто тому, що не залишалося, що фіксити.
3. Проблеми вирішувалися до передачі макетів девам, що знімало навантаження з усіх наступних етапів.
4. Зекономлено щонайменше 10–12 годин командної роботи щомісяця — раніше цей час ішов на обговорення, правки, синки та рев’ю.

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

Бонусні можливості: ще кілька корисних застосувань

Figma AI Translate To — це не тільки про макети продукту. Якщо подивитися ширше, цей інструмент спокійно масштабується на всі сценарії, де потрібно заздалегідь побачити, який вигляд має текст іншою мовою:

App Store / Google Play скріншоти — можна за секунди перевірити, як виглядатиме адаптований заголовок різними мовами, ще до передачі в руки локалізатору. Це дозволяє не витрачати час на переклад усіх елементів в мокапі інтерфейсу, а зосередитись на головному — сенсі заголовків, які дійсно впливають на конверсію.

Маркетингові банери, email-и, креативи — тестувати, як поводиться текст у візуалі, ще до того, як усе піде в продакшн. Це допомагає уникнути обривів тексту, зайвих переносів чи надто довгих заголовків у критично важливих маркетингових матеріалах.

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

Висновки

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

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

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

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

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

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