Як одна дизайнерська ідея зменшила час розробки на 40%

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

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

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

Так кожен екран потрібно адаптовувати під усі можливі розміри iPhone — від старенького 8-го до найновіших Pro Max. Раніше це означало десятки макетів і години ручної роботи.

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

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

Сім макетів для одного екрану

Ми використовували стандартний дизайн-процес при роботі з масштабуванням дизайн-рішень: для кожного пейволу чи онбордингу я робила ресайзи під iPhone 8, 8+, 13 mini, 13, 14 Pro, 14 Plus, 14 Pro Max. Навіщо? Часто, якщо не слідкувати за тим, як виглядають елементи на різних розмірах девайсів, ключовий елемент інтерфейсу може бути схований у скролі або перекривати інші елементи. Тому важливо, щоб всі ключові кнопки та тексти були перед очима у користувача.

Кожен екран вимагав окремого макета, адаптації компонентів, а іноді й переосмислення логіки розташування елементів. Після цього дев вручну підганяв верстку під кожен розмір, намагаючись досягти того самого pixel-perfect, який ми всі так любимо.

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

З чого почався наш експеримент

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

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

Як працює скейл

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

Для контексту: pixel-perfect передбачає створення окремого макета під кожен розмір екрана з точно вивіреними позиціями та відступами. Це дає максимальний контроль над кожним пікселем, але вимагає колосальних витрат часу як на етапі дизайну, так і під час розробки.

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

5 годин проти 2-3

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

Зараз все інакше: я створюю базовий макет для iPhone 14 Pro і за допомогою Scale в Figma показую, як елементи поводяться на екранах — наприклад, на найменшому iPhone 8 та найбільшому iPhone 17 Pro Max. Прописую логіку скейлу для кожного елемента. Дев бере ці правила і реалізує їх в коді один раз, так вони автоматично працюють для всіх проміжних розмірів.

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

Місяць експериментів

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

Перший пейвол показав обнадійливі результати. Протягом місяця ми поступово перевели на скейл ще 9 пейволів, паралельно фіксуючи витрати часу. Виявилося, що розробка одного пейволу з усіма адаптаціями, яка раніше займала близько 5 годин, тепер вкладається у 2-3 години. Це майже 40% економії часу, який ми відразу почали інвестувати в тестування нових гіпотез та покращення продукту.

Цифри виглядали добре, процес став швидшим. Коли переконалися в стабільності результатів, я запропонувала зробити цей підхід стандартом для всієї компанії. Менеджмент підтримав ініціативу, і тепер всі наші продукти в Kiss My Apps використовують скейл як базову практику адаптації інтерфейсів.

Швидкість — це добре, але головне питання залишалося: чи задоволені користувачі? Чи не втратили ми в конверсії?

Перевірка метриками

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

Тому ми пішли в аналітику. Після першої хвилі релізів ретельно проаналізували поведінку користувачів на різних девайсах і порівняли з попередніми показниками. Результат: конверсія залишилася стабільною. Не було жодних провалів, ні на найменших екранах iPhone 8, ні на Pro-версіях.

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

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

В підсумку

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

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

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

Якщо раніше в місяць ми робили 4 пейволи (близько 48 за рік) на тест на один продукт, то зі скейлом можемо робити 6-7 (близько 72-84 за рік). Це означає, що команда отримала на 50-70% більше тестів щороку, а отже і більше перевірених рішень для масштабування застосунків.

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