Мобільна версія як окремий етап: типові помилки замовника та як їх уникнути

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

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

Помилка 1. Назвати мобільну версію «зменшеною копією»

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

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

Помилка 2. Погодити лише дві контрольні ширини

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

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

Помилка 3. Дозволити приховати «незручний» контент

Найпростіший спосіб прибрати переповнення — сховати блок. Але разом із ним може зникнути ціна, умова, пояснення помилки або функція. Критерій WCAG 2.2 про reflow вимагає, щоб за ширини, еквівалентної 320 CSS-пікселям, контент подавався без втрати інформації чи функціональності та без прокручування у двох напрямках, крім обґрунтованих двовимірних елементів на кшталт карт або складних таблиць.

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

Помилка 4. Передати короткий демонстраційний текст

Картка з двома словами нічого не каже про реальну назву послуги, адресу, помилку валідації або переклад. Після завантаження контенту змінюється висота блоків, кнопки відсуваються, підписи обрізаються. Це не «контентна дрібниця», якщо через неї неможливо виконати дію.

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

Помилка 5. Перевірити форму тільки до появи клавіатури

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

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

Помилка 6. Оцінювати кнопки лише «на око»

Маленька іконка може виглядати охайно, але бути незручною для натискання. WCAG 2.2 на рівні AA встановлює для цілі вказівника мінімум 24×24 CSS-пікселі або достатній інтервал, з переліченими у критерії винятками. Це мінімальна вимога доступності, а не універсальна рекомендація робити всі кнопки саме такого розміру.

Як уникнути: попросіть позначити активну область, а не лише видиму іконку. Перевірте близькі дії на кшталт «видалити» й «редагувати», елементи каруселі, закриття модального вікна та чекбокси. Людина не повинна влучати в один піксель або виконувати перетягування, коли ту саму дію доречно дати звичайною кнопкою.

Помилка 7. Вважати швидкість окремою технічною задачею

Мобільний макет може бути правильним, але важкі зображення, сторонні віджети й складний код роблять його повільним або нестабільним. Core Web Vitals описують різні аспекти реального досвіду: LCP — завантаження основного вмісту, INP — реакцію на взаємодію, CLS — неочікувані зсуви макета. Лабораторний звіт корисний для діагностики, але INP потребує взаємодій реальних користувачів і не вимірюється як повноцінна польова метрика одним статичним прогоном.

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

Помилка 8. Прийняти роботу за скриншотами виконавця

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

Як уникнути: погодьте матрицю приймання до оцінки робіт і повторіть критичні маршрути після виправлень.

Матриця мобільного приймання

Що написати в брифі замість «зробити мобільну версію»

Ключові мобільні маршрути: [ ]. Пріоритет дій і блоків: [ ].
Контрольні компоненти та правила їх перебудови: [ ].
Реальний і граничний контент для тесту: [ ].
Стани меню, форм, фільтрів, таблиць і модальних вікон: [ ].
Вимоги до reflow, збільшення тексту, фокусу й активних областей: [ ].
Підтримувані браузери та пристрої для ручної перевірки: [ ].
Лабораторні й польові перевірки швидкодії: [ ].
Хто готує тестові дані, хто приймає і що входить у виправлення: [ ].

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

Коли звертатися до виконавця

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

Першоджерела

Перевірено 25 вересня 2026 року. Антисписок і матриця — редакційні інструменти; джерела нижче підтверджують вимоги та технічні принципи, на які вони спираються.

• W3C WAI: Understanding Reflow — збереження інформації та функцій без двовимірного прокручування.
• W3C WAI: Target Size (Minimum) — мінімальна активна область, інтервали та винятки.
• web.dev: Responsive web design basics — viewport, гнучкі макети, медіазапити та зображення.
• web.dev: Web Vitals — склад Core Web Vitals і оцінювання польових даних.
• web.dev: Measuring Web Vitals — відмінність лабораторних і польових вимірювань.
• Chrome for Developers: properly size images — використання адаптивних версій зображень.

• Поради та лайфхаки