Різнобій в іконках мобільного застосунку: де ламається інтерфейс
Іконки мобільного застосунку рідко потрапляють до плану релізу окремим завданням — їх готують в останній тиждень, між збіркою та відправленням на перевірку.
Дизайнер віддає значки одним набором, розробник підставляє їх як є, і в застосунку з’являється різнобій графіки: частина значків обрізана по краях, частина розрахована на світлу тему й зникає на темній, частина витягнута під пропорції чужої платформи.
Далі долучається розбіжність інтерфейсу між платформами. Один і той самий значок на iOS і Android відмальовується за різними масками: на одній системі він вписаний у коло, на іншій — у квадрат зі заокругленням.
Якщо набір готували під одну платформу й просто перенесли до другої, половина значків втрачає поля по краях, а дрібні деталі зливаються в пляму на реальному екрані.
Ціна такої розбіжності — повернення збірки з перевірки.
Правила оформлення в Apple Human Interface Guidelines і в Material Design описують поля, сітку та поведінку значка в темній темі; якщо набір їм не відповідає, збірку повертають, а виправлення впирається в нову збірку й повторну чергу на модерацію. Під час релізу в обидві системи цикл проходиться двічі.
Окремий біль — правки іконок після релізу. Замінити один значок у магазині не можна: він зашитий у збірку, тому виправлення чекає наступного релізу й знову проходить повний цикл перевірки. Помилку в графіці, яка видна на першому екрані, доводиться терпіти тижнями.
Розбираємо, як це закривається: як з одного джерела збираються коректні набори під обидві платформи, світлу й темну теми, і чому тоді правки перестають бути аварійними.
Що дає єдиний набір графіки: швидкість збірки та менше правок
Єдине джерело графіки замість ручного зведення версій
Іконки живуть як бібліотека компонентів у Figma: один майстер на глиф, векторне відмальовування, вирівнювання за піксельною сіткою.
Екран збирається з посилань на майстер, а не з копій файлів, тому правка іконки розходиться по всіх макетах одразу — ручне зведення версій між екранами й платформами зникає з процесу.
Єдине джерело графіки економить час не в момент відмальовування, а на кожному наступному екрані: новий макет збирається з готових символів, а не малюється заново.
Частка макетів, які повертаються на доопрацювання через розбіжності між екранами, падає — правки стають точковими, а не каскадними.
Спільна система символів знімає цілий клас помилок
Щільності екрана та розміри іконок експортуються з одного майстра, тому не з’являється «з’їхалих» товщин обведення й різної оптичної маси між платформами.
Стани — активний, неактивний, натиснутий — описані варіантами компонента, а не окремими наборами файлів: розробник не збирає іконку по частинах і не вгадує відступи під час верстання.
Швидкість виведення екранів зростає завдяки передбачуваним розмірам і точкам прив’язки, на які спирається верстання.
Консистентність графіки перестає залежати від того, хто саме малював конкретний екран, — нова людина в команді підключається до готової системи, а не відновлює її за розрізненими файлами.
Варіанти постачання набору: окремі комплекти чи єдине джерело
Набір іконок можна постачати по-різному, і від вибору залежить, як правки доходять до релізу. Окремі комплекти під iOS і Android живуть незалежно, єдине джерело збирається у формати обох платформ з одних вихідників, а між ними є гібридний шлях із ручним доопрацюванням.
Окремі комплекти під iOS і Android
Кожна платформа отримує власний набір растрових і векторних файлів, файл-майстер лежить поруч. Так роблять, коли вимоги платформ розходяться за формою знака й спільний рисунок однаково довелося б розсинхронізовувати.
Обмеження передбачуване: правку повторюють у кожному комплекті, розбіжності накопичуються й виринають на перевірці перед публікацією.
Єдине джерело та збірка під платформи
Векторні вихідники зберігаються одним набором, з якого збірка розкладає розміри, щільності та формати під кожну платформу. Правка в джерелі розходиться по всьому набору одразу, історія змін залишається в системі контролю версій.
Платформна адаптація графіки тут робиться параметрами збірки, а не руками — це й є основне обмеження варіанта.
Гібридний шлях із ручним доопрацюванням
Спільне джерело відповідає за базову форму й колір, а окремі знаки доопрацьовуються під платформу вручну й зберігаються як перевизначення. Підходить, коли більша частина набору спільна, але кілька іконок потребують індивідуальної оптики.
| Варіант постачання графіки | Коли підходить | Обмеження |
|---|---|---|
| Окремі комплекти | Вимоги платформ розходяться за формою знака | Правки дублюються, версії розходяться між собою |
| Єдине джерело зі збіркою | Більшість знаків спільні, релізи часті | Платформне доопрацювання обмежене параметрами збірки |
| Гібрид із ручним доопрацюванням | Спільна база плюс окремі знаки під платформу | Потрібен порядок у перевизначеннях, інакше розсинхрон |
Як ми збираємо та впроваджуємо іконки: етапи роботи
Набір іконок ламається не на етапі малювання, а на впровадженні: файли надходять із різними іменами, частину форматів не підхоплює збірка, а на реальному екрані іконка провалюється за контрастом у темній темі.
Ми ведемо цю роботу як інженерний процес із фіксованими точками контролю — від інвентаризації графіки до приймання набору.
Як влаштовані етапи впровадження набору іконок
- Інвентаризація графіки. Розбираємо поточні каталоги ресурсів і матеріали в магазинах застосунків: знаходимо дублі, застарілі версії та графіку, намальовану під конкретний екран. На виході — реєстр іконок із зазначенням, де кожна застосовується.
- Схема іменування файлів. До збірки фіксуємо структуру каталогів і правила іменування: ім’я відображає призначення, розмір і тему, а не автора. Це прибирає ручне перейменування під час наступного релізу.
- Збірка комплектів. Готуємо векторні вихідники та похідні растрові набори під потрібні режими відображення, окремо — варіанти для темної теми, виділеного стану та вітрин магазинів.
- Перевірка на реальних екранах. Проганяємо набір на живих пристроях і в емуляторах: дивимося читабельність на малій і великій діагоналі, поведінку в темній темі, вирівнювання за сіткою.
- Приймання набору. Звіряємо результат із реєстром: усе на місці, імена збігаються, зайвих файлів немає. Розбіжності закриваємо до передачі.
- Передача та навчання. Віддаємо вихідники, каталог ресурсів, реєстр і правила іменування, показуємо команді замовника, як додати нову іконку, не порушивши структуру.
Що залишається на боці замовника
Комплект підключається до проєкту без ручної правки імен, а реєстр і правила іменування далі працюють як внутрішній стандарт. Нова іконка додається за один крок — без розбору чужих шарів і перезбирання всього набору.
Що передаємо на руки: вихідники, правила оформлення та регламент
Зібрати іконку — половина роботи. Друга половина в тому, щоб за пів року новий розділ у застосунку не потребував перемальовувати весь набір, а збірка під кожну платформу не залежала від чиєїсь пам’яті про потрібні розміри.
Тому набір передаємо не картинками на виході, а робочим комплектом: вихідники, правила та регламент, за яким його можна розширювати без нас.
Що входить у комплект
- Робочі вихідники — векторні файли з розкладеними шарами, окремими символами й майстер-сторінками: правка однієї фігури розходиться по всьому набору, а не по десяти копіях.
- Зібрані комплекти під платформи — готові набори в потрібних форматах і розмірах, з коректною прозорістю та без ручного доопрацювання на боці розробки.
- Правила оформлення графіки — сітка й відступи, товщини ліній, радіуси, поведінка дрібних деталей на мінімальних розмірах.
- Правила іменування — єдина схема імен файлів і символів, щоб елемент знаходився пошуком, а не перебором папок.
- Документація по набору — короткий довідник: де лежить, як зібрати, що робити при розбіжності версій.
Правила та порядок роботи
- Опис прав доступу до сховища графіки — власник, редактори, читачі та порядок видачі прав новій людині.
- Регламент оновлення набору — як додається новий символ, хто затверджує, у які терміни та як фіксується версія.
Такий комплект закриває типовий сценарій: набір живе й розширюється всередині вашої команди, а ми залишаємося на підхваті — наприклад, коли символів стає стільки, що потрібен редизайн усієї системи.
Кейс: єдине джерело графіки прибрало розбіжності між платформами
Ситуація до
Замовник приносив графіку вивантаженням із макетів: кожен символ у трьох розмірах, частина — растром, частина — контуром, товщина обведення й заокруглення виставлялися вручну окремо під кожну платформу.
Новий символ малювався двічі, файли підключалися за іменами, і до кінця циклу випуску накопичувалося 8-12 правок — розходилися сітка, оптичний розмір і колір активного стану.
Що змінили і що вийшло
Ми зібрали майстер-набір у Figma як єдине джерело: сітка, ключові лінії, товщина обведення й розміри винесені у змінні, експорт у векторні формати йде однією командою.
Іконка стала компонентом із варіантами станів, тому новий символ збирається з готових частин, а не малюється заново.
Частка розбіжностей між платформами впала з третини набору до нуля — невідповідності ловить автоматична перевірка під час збірки, а не замовник на прийманні.
Час на додавання нового символу скоротився з кількох годин до 20-30 хвилин разом з експортом і підключенням в обидва проєкти. Кількість правок за цикл випуску — з 8-12 до однієї-двох, і ті стосуються сенсу іконки, а не її геометрії.
Відгук замовника: «перестали сперечатися, який файл актуальний» — набір іконок оновлюється з одного місця, і обидві платформи отримують однаковий результат.
Чим відрізняється адаптація графіки під iOS від Android?
Різниця починається з того, кому належить форма. В iOS маску із заокругленнями накладає сама система, тому дизайнер віддає повний квадрат, а кути зрізаються вже на пристрої — прозорості у вихіднику бути не повинно, фон є частиною іконки.
В Android використовується двошарова схема: фон і символ лежать окремо, форму задає оболонка пристрою й може змінювати її від круглої до квадратної із заокругленням, додаючи нахил при повороті екрана.
Ключова розбіжність — у безпечних зонах. В Android символ зобов’язаний поміщатися у внутрішнє коло, яке помітно менше за полотно: решта кільця йде під маску й паралакс.
В iOS маска зрізає куди менше, тому той самий рисунок, щільно укладений в андроїдну зону, на iOS виглядає дрібним і загубленим. Звідси й береться окрема версія під платформу — питання не смаку, а геометрії.
Другий шар — оптична вага символу. На iOS іконка частіше лежить на однотонній підкладці, і тонкі лінії на ній втрачають контраст; на Android символ ковзає над рухливим фоном, і ті самі лінії розвалюються при нахилі.
Стокові товщини доводиться розводити: на одній платформі штрих ущільнюємо, на іншій розвантажуємо, композицію підтискаємо до центру.
Один спільний файл працює там, де знак простий, центрований, із запасом по краях, на спокійному фоні без градієнтів і без елементів біля межі безпечної зони.
Окрема версія потрібна, якщо силует тримається на формі кутів, є дрібні деталі, складний фон або потрібна підтримка темної теми й монохромного режиму — там маска й перефарбовування ламають початковий задум.
Перед здачею ми накладаємо макети на реальні маски платформ, проганяємо контраст на світлому й темному фоні та дивимося іконку в дрібному розмірі, де й проявляється розбіжність за вагою. Це і є перевірка вимог платформ до графіки — до того, як застосунок піде в публікацію.
Часті технічні сумніви: масштабування, фон, оновлення
Графіка — та частина релізу, де правки після випуску коштують найдорожче, тому питання щодо неї краще зняти заздалегідь.
Нижче — найчастіші: оновлення набору в уже опублікованому продукті, часткове перемальовування, розходження комплектів під час синхронізації, втрачені вихідники та віддалена робота з командою замовника.
Застосунок уже випущено, а набір іконок застарів. Можна оновити лише графіку?
Так. Ми збираємо новий комплект під поточний дизайн, узгоджуємо контрольні розміри й віддаємо його окремим пакетом — решта коду релізу не зачіпається. Важливо лише звірити силует з уже опублікованим варіантом, щоб упізнаваність не загубилася.
Потрібно перемалювати одну іконку з набору — доведеться переробляти все?
Ні. Якщо майстер-файли з шарами збережені, правиться лише потрібний знак, решта залишається недоторканою. Ми синхронізуємо його із загальною сіткою й оптичною вагою сусідів, інакше один елемент починає «випадати» з ряду.
Що робити, якщо комплекти для різних платформ під час оновлення розходяться?
Ми тримаємо єдиний майстер-файл, з якого генеруються обидва набори, тому розходження виключене за побудовою. Окремо задаються правила масштабування та підкладки: як знак поводиться на світлому й темному фоні та що потрапляє в системні розміри.
Вихідники загубилися. Набір можна відновити?
Можна. Ми перемальовуємо знак векторно за растровим еталоном і заново вибудовуємо шарувату структуру, звіряючи результат за контрольними розмірами. На виході замовник отримує редаговані файли, а не лише готові картинки.
Наша команда працює віддалено. Як проходить узгодження?
Узгоджуємо за контрольними листами: один і той самий знак показуємо в кількох розмірах і на різних підкладках, щоб рішення приймалися за фактом, а не за збільшенням. Правки фіксуються в спільному архіві, тому в обох сторін завжди актуальна версія.
Обговоримо задачу та повернемося з планом: склад, терміни, порядок робіт
Щоб розмова була предметною, до першої зустрічі достатньо зібрати мінімум ввідних: ми дивимося поточний набір, звіряємо його з вимогами магазинів застосунків і повертаємося з оцінкою та планом робіт із графіки. Нижче — що підготувати, щоб обговорити задачу одразу по суті й не витрачати ітерації на уточнення.
- Платформи та охоплення: iOS, Android, планшети, годинники й носимі версії — від цього залежить кількість розмірів, набір масок заокруглення та склад постачання.
- Поточні вихідники: векторні майстер-файли, шари, шрифти, палітра. Якщо майстер-файла немає, плануємо відновлення геометрії за растром.
- Приклади проблемних екранів: де іконка губиться на темній темі, зливається з док-панеллю або обрізається в круглій масці.
- Вимоги перевірки: непрозорий фон, поля безпеки, коректне заокруглення — автоматика магазину відхиляє збірку, якщо набір не проходить перевірку.
- Точки узгодження: хто приймає рішення з графіки, хто затверджує фінальний набір і в які дати це відбувається.
- Порядок передачі набору: репозиторій або архів, формати майстер-файлів і експорту, права на використання, як вносити правки після релізу.
- Дати релізу збірки: від них рахуємо план робіт із графіки та терміни на узгодження.
Якщо частину пунктів поки не зібрано — це не блокує розмову: за описом продукту ми допоможемо визначити, що запросити в дизайнера або підрядника, який робив набір раніше. Опишіть задачу — повернемося з оцінкою, складом постачання та порядком робіт.
