Верстка екранів мобільного застосунку під Android (Material Design)

Material Design 3: чому верстка розходиться з макетом

Макет у Material Design 3 — це не картинка, а набір правил: колірні ролі, типографічна шкала, крок сітки, стани компонентів. Поки екран живе в редакторі, все збігається.

Розходження починається там, де відмальовування екранів Android відтворює лише «ідеальний» стан елемента, а решту домальовує за інтуїцією.

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

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

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

Третє — адаптивна сітка екрана. Малий екран стискає колонки, великий додає другу панель; при цьому довгі підписи в кнопках переносяться на два рядки, а фіксовані висоти обрізають текст.

Різниця видна не в редакторі, а на пристроях — і правки після цього дорожчі, ніж одразу закладена сітка.

Далі розбираємо, як пов’язати стани, відступи й сітку так, щоб готовий екран збігався з макетом під час першого складання, а не після серії переробок.

Єдина бібліотека компонентів: що це прискорює

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

Через два-три релізи в застосунку живуть три різні відступи, дві поведінки завантаження й чотири варіанти однієї картки — і правка макета перетворюється на ревізію всього інтерфейсу.

Швидкість складання нового екрана

Бібліотека на Material Design 3 — це компоненти із заздалегідь описаними станами: кольори, типографіка й відступи беруться з одного джерела, а не підбираються під кожен макет.

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

Єдиний набір станів

Завантаження, порожній список, помилка мережі, офлайн і повільна відповідь описуються один раз і успадковуються всіма розділами.

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

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

Способи відмальовування екранів: порівняння підходів

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

Нижче — чотири варіанти відмальовування інтерфейсу, між якими реально обирають на старті або під час переписування екранів під обмеження платформи Android.

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

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

Етапи впровадження: від аудиту екранів до передавання команді

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

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

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

2. Схема компонентів. Зводимо повтори до базового набору: кнопка, поле введення, картка, список, діалог, навігаційна панель.

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

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

4. Складання бібліотеки. Реалізуємо елементи як повторно використовувані модулі з одним входом: вигляд і поведінка беруться з теми, розмітка екрана — з компонентів. Так оновлення системи надходить у всі застосунки одразу.

5. Поетапна заміна на живих екранах. Не переписуємо застосунок цілком: переносимо екран за екраном, релізи продовжують виходити, а відкат на попередню збірку залишається можливим.

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

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

Результати робіт: бібліотека компонентів і документація

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

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

• Бібліотека компонентів для Android — кнопки, поля введення, картки, списки, діалоги, навігація й стани завантаження зібрані в окремий модуль. Екран збирається з готових блоків, тому той самий елемент не розходиться за відступами й поведінкою на різних екранах.
• Тема оформлення застосунку — кольори, типографіка, заокруглення, тіні й крок сітки винесені в спільні набори значень поверх Material Design 3. Зміна відтінку бренду або щільності інтерфейсу робиться в одному місці й одразу поширюється на всі екрани.
• Правила станів елементів — для кожного компонента зафіксовано, як він виглядає й поводиться в спокої, під час натискання, у фокусі, у завантаженні, при помилці та при недоступності даних. Це прибирає різнобій, через який однакові списки на різних екранах реагують по-різному.
• Документація з інтерфейсу — каталог компонентів із прикладами використання, обмеженнями й антиприкладами: де блок застосовувати не можна і чим його замінити.
• Регламент правок верстки — порядок зміни спільного компонента: хто погоджує, як оцінюється вплив на вже випущені екрани, у яких випадках правка переходить в окремий блок, а не в спільний.
• Інструкції для команди — як підняти проєкт, де лежать значення теми, як додати екран за шаблоном і які перевірки проходять перед випуском.

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

На прийманні це перевіряється наживо — змінюємо компонент і показуємо результат на всіх екранах, де він використовується.

Кейс: єдина бібліотека компонентів для частих релізів

До: кожен екран збирали заново

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

Складання типового екрана займало 3–4 дні, і приблизно половина часу йшла на вирівнювання за макетом після першої перевірки. Дизайн-перевірка стабільно повертала 12–15 розходжень на екран, а вже після релізу надходили повторні правки.

Після: спільна бібліотека компонентів

Ми описали повторювані елементи один раз — теми, токени кольору й типографіки, стани компонентів: звичайний, натиснутий, завантаження, помилка, порожній список. Основою взяли актуальну гілку Material Design 3, щоб сітки й поведінка збігалися в усіх команд.

Складання нового екрана перетворилося на композицію готових блоків і зайняло 1–1,5 дня. Розходжень із макетом на перевірці залишилося 2–4, і майже всі — про патерни, яких у бібліотеці ще не було.

Що змінилося за метриками

Через кілька релізів частка повторних правок інтерфейсу після виходу версії впала приблизно втричі, а дефекти на кшталт «кнопка іншого розміру» або «поле не підсвічує помилку» перестали доходити до користувачів.

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

Material Design чи власна дизайн-система: що вибрати

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

Обмеження починаються там, де бренд вимагає свого: сітка, типографіка, форма кнопок, анімація переходів.

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

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

Обмеження платформи й часті сумніви щодо верстки

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

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

Нижче — сумніви, які найчастіше виринають на прийманні, і те, як ми закриваємо їх технічно. Кожна відповідь спирається на Material Design 3: специфікація задає єдині правила для розмірів, контрасту й станів компонентів, тому спірних місць у верстці стає помітно менше.

Чи потрібен окремий макет під темну тему?

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

Що входить у доступність інтерфейсу?

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

Що станеться при оновленні платформи?

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

Обговоримо задачу: що потрібно від вас для старту

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

• Вихідник макетів із шарами, стилями й компонентами, а не пласкі зображення: за компонентами видно, що використовується повторно, а де кожен екран збирається заново.
• Перелік екранів зі станами: завантаження, порожній список, помилка мережі, офлайн, обмежені права. Кожен неописаний стан — окремий обсяг із відмальовування.
• Доступ до репозиторію на читання або архів робочої гілки: дивимося структуру модулів, тему й те, як підключені елементи дизайн-системи.
• Список пристроїв і версій системи, які підтримуємо, включно з мінімальною. Від цього залежить доступний набір компонентів Material Design 3.
• Схема навігації: де вкладені потоки, де діалоги й шторки, що відбувається при поверненні назад з кожного екрана.
• Посилання на поточну збірку або записи поведінки, якщо логіка переходів не описана текстом.

Надсилати все одразу не обов’язково: для оцінки вистачає макетів, списку екранів і доступу до коду. Передавання макетів і репозиторію цілком іде паралельно — воно потрібне для старту, а не для розрахунку.

У відповідь ви отримуєте оцінку робіт з інтерфейсу з розбивкою за екранами й станами та план робіт по застосунку з черговістю випуску.