Мобильная адаптивность для интерфейсов, созданных ИИ: аудит макета

Что обычно ломается на мобилях (простыми словами)

Когда говорят, что страница «не дружит с мобилой», обычно имеют в виду простую вещь: она загружается, но пользоваться ею на настоящем телефоне неудобно или невозможно.

Симптомы вы узнаете сразу:

• Можно свайпать вбок, потому что что‑то шире экрана
• Текст обрезается или накладывается друг на друга
• Кнопки и ссылки слишком маленькие, слишком близко друг к другу или частично вне экрана
• Макет подпрыгивает при загрузке изображений или при открытии клавиатуры
• Меню, модалы или выпадающие списки появляются не там, где нужно, и «ловят» пользователя

Это часто происходит с прототипами, созданными ИИ: многие инструменты делают интерфейс, который выглядит нормально в превью на десктопе, а затем держат его вместе хрупким CSS — фиксированными ширинами, абсолютным позиционированием и пиксельной подгонкой. Также предполагается один размер шрифта, одна длина контента и один размер вьюпорта. Телефоны быстро ломают эти допущения.

Реалистичный пример: экран онбординга использует двухколоночный макет внутри фиксированного контейнера шириной 900px. На десктопе он аккуратный. На телефоне правая колонка выталкивается за край, появляется горизонтальная прокрутка. Кнопка «Continue» оказывается ниже видимой области, а юридический текст накладывается на поле ввода, когда открывается клавиатура.

Если хотите адаптивность — не редизайньте сначала. Сначала проведите аудит, потом чините по порядку: найдите, что заставляет страницу быть шире экрана, уберите CSS, который «закрепляет» элементы, и только потом подгоняйте отступы и цели касания.

Быстрый, реалистичный тест

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

Выберите 3–5 экранов, которые представляют всё приложение (не каждую страницу). Хорошая стартовая подборка: главная/дашборд, вход, настройки/профиль и один «денежный» экран — чек-аут, апгрейд или бронирование. Починка этих чаще всего упрощает остальное.

Выберите несколько распространённых размеров и придерживайтесь их, чтобы можно было сравнить до и после. Не нужно покрывать все устройства, только те, что выявляют слабые решения макета:

• Маленький телефон: 360 x 800
• Большой телефон: 390 x 844
• Плюс‑сайз телефон: 414 x 896
• Планшет: 768 x 1024
• Один промежуточный размер из вашей аналитики (если есть)

Определите, что значит «хорошо», прежде чем трогать CSS: нет боковой прокрутки, текст читается без зума, кнопки удобно нажимать, и ключевые сценарии можно завершить одной рукой.

Практическое правило: если вы не можете завершить вход и основное действие на реальном телефоне за минуту — макет не готов.

Найдите источники переполнения и горизонтальной прокрутки

Боковая прокрутка почти всегда означает, что какой‑то элемент шире экрана.

Воспроизведите проблему на узком вьюпорте. Если вы можете перетащить страницу влево‑вправо хотя бы немного — что‑то переполняет.

Один быстрый способ найти виновника — временно обвести все элементы рамками, потом прокрутить вбок и посмотреть, что выглядывает. Когда заметите «таинственную» карточку или кнопку, торчащую за край, инспектируйте её ширину, padding и дочерний контент, который мог её расширять.

Повторяющиеся причины: фиксированные ширины (например, контейнер задан как 420px), большие изображения или SVG, которые не уменьшаются, длинные неразрываемые строки (почты, ID, ключи), широкие таблицы и абсолютно позиционированные элементы, выходящие за вьюпорт.

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

Правило, экономящее время: предпочитайте гибкие размеры до добавления новых breakpoint'ов. Прежде чем навешивать @media-правила, уберите жёсткое ограничение, которое заставляет макет быть широким.

Пример: в онбординге модал «Verify code» задан шириной 480px, а placeholder в поле кода очень длинный. На телефоне 375px модал переполняет. Поменяв ширину модала на max-width: 90vw и позволив placeholder переноситься, вы убираете прокрутку без редизайна.

Убираем хрупкий CSS, из‑за которого макет ломается

Большинство мобильных провалов в AI‑генерированном фронтенде происходят из‑за CSS, предполагающего один размер экрана. Быстрые победы обычно приходят, когда вы убираете эти допущения.

Ищите фиксированные ширины и высоты, которые «выглядят нормально» на десктопе, но не могут ужаться. Частые виновники: width: 1200px, min-width: 900px, height: 100vh на контейнерах, которые должны расти, и инпуты/кнопки с жёстко заданными размерами. Если карточке нужно быть определённой ширины, она выталкивает всё остальное в боковую прокрутку.

Ещё одна проблема — «обёртка на обёртке». Инструменты ИИ часто наслаивают контейнеры, у каждого из которых padding, max-width и центрирование. Три обёртки по 24px каждая съедают удивительное количество полезного пространства на маленьком телефоне.

Если видите абсолютное позиционирование ради выравнивания, «магические числа» типа left: 37px, отрицательные margin'ы или глобальные правила вроде white-space: nowrap — относитесь к ним с подозрением. Замените их гибкими правилами, которые дышат: max-width: 100% вместо фиксированных ширин, height: auto где возможно и gap вместо ручных наборов margin'ов.

Пример: на онбординге кнопка «Continue» абсолютно позиционирована внизу карточки. На маленьком устройстве открывается клавиатура и кнопка перекрывает форму. Переключение карточки на flex‑колонку и отталкивание кнопки с помощью margin-top: auto удерживает её на месте без перекрытий.

Адаптируйте макеты с помощью flexbox и grid

Код, сгенерированный ИИ, часто «работает» только потому, что примерный контент идеальной длины. На реальном телефоне текст длиннее, кнопки переносятся, и макет сваливается в наложение или горизонтальную прокрутку.

Простое правило: используйте flexbox для одномерных раскладок (ряд или колонка) и grid для двумерных (строки и колонки, которые должны выравниваться). Заставлять всё работать одним инструментом обычно делает код хрупким.

Flexbox хорош для навбаров, тулбаров, строк с кнопками и «иконка + текст + действие». Grid удобен для галерей карточек, страниц настроек с метка/значение и дашбордов, где колонки должны выравниваться по строкам.

Две CSS‑опции решают большую часть проблем с реальным контентом: разрешите перенос (wrapping) и дайте тексту ужиматься без разрушения строки.

/* Card rows that wrap without odd gaps */
.cards {
  display: flex;
  flex-wrap: wrap;
  gap: 12px;
}
.card { flex: 1 1 260px; }

/* Grid that adapts to screen size */
.grid {
  display: grid;
  gap: 12px;
  grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
}

/* Mixed content row: icon + long title + button */
.row { display: flex; align-items: center; gap: 8px; }
.title { min-width: 0; flex: 1; }
.action { flex: 0 0 auto; }

Конкретный пример: в онбординге длинное название плана и кнопка «Continue». Если заголовок не может ужаться, он выталкивает кнопку за экран. Установка min-width: 0 на заголовке и сохранение кнопки как flex: 0 0 auto предотвращают переполнение без редизайна.

Улучшите читаемость и цели касания без полного редизайна

Большая часть мобильной боли — это не сложный макет, а слишком мелкий текст, схлопнувшиеся отступы и элементы, которые тяжело попасть пальцем.

Начните с нескольких скучных значений, которые делают любой экран спокойнее: 16px для основного текста с межстрочным интервалом 1.4–1.6, заголовки масштабируйте так, чтобы они не доминировали, и единообразные отступы по контейнерам (часто 16px), чтобы контент не прилипал к краям.

Цели касания — следующий быстрый выигрыш. Многие AI‑интерфейсы рисуют красивые кнопки, которые на телефоне физически крошечные. Стремитесь к минимуму 44x44px для интерактивных элементов, держите 8–12px между отдельными действиями и добавляйте padding текстовым ссылкам, чтобы по ним было удобно тапать. Также убедитесь, что фокусные стили остаются видимыми, а не обрезаются.

Формы ломаются чаще, чем лендинги. Держите метки рядом с полями, избегайте двухколоночных форм на маленьких экранах, если они действительно не вмещаются, и делайте поля ввода во всю ширину на мобиле. Зарезервируйте место для ошибок, чтобы страница не подпрыгивала при появлении валидации.

Смещения макета часто вызывают тосты, баннеры и встроенная валидация. Если сообщения появляются и исчезают, постарайтесь держать высоту консистентной или используйте оверлейную область, чтобы контент не прыгает.

Пример: на онбординге «First name» и «Last name» рядом часто сжимают оба поля до нечитабельной ширины. Переключение на одну колонку, метки над полями и предоставление кнопке Continue реального размера касания делают экран законченным без изменения дизайна.

Укрощаем проблемные компоненты: изображения, таблицы и модалы

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

Изображения, которые раздувают контейнеры

Если изображению задана жёсткая ширина (например, 800px), оно может заставить страницу стать шире телефона.

Позвольте изображениям уменьшаться, но не расти. В большинстве случаев ставьте max-width: 100% от контейнера и позволяйте высоте следовать соотношению сторон. Если дизайну нужен фиксированный по высоте герой, безопасно кропьте с помощью object-fit, чтобы изображение не растягивалось.

Длинные неразрываемые строки вызывают ту же боковую прокрутку. ID пользователей, email'ы, ссылки‑приглашения, номера заказов и блоки кода часто отказываются переноситься. Применяйте правила переноса в зонах контента, чтобы длинные строки ломали строки, а не толкали макет.

Таблицы без боли

Таблицы тяжело показывать на маленьких экранах. Выберите одну стратегию для каждой таблицы в зависимости от того, что людям реально нужно делать на мобиле: горизонтальная прокрутка таблицы внутри собственного контейнера, стэкинг каждой строки в карточный вид или показ краткого резюме с детальным просмотром.

Запишите выбранный подход и причину. Иначе позднее правка может тихо вернуть переполнение.

Модальные окна и выдвижные панели, которые остаются удобными

Модалы часто ломаются из‑за фиксированной высоты, при этом страница позади них всё ещё скроллится. Более безопасный паттерн: ограничить высоту модала размером вьюпорта, сделать тело модала прокручиваемым и держать шапку (заголовок и крестик) видимыми.

Быстрые проверки, которые ловят большинство багов:

• Кнопка закрытия видима и легко нажимаема на маленьком экране
• Контент модала прокручивается, а фон — нет
• Клавиатура не прячет основную кнопку действия

Пример: модал регистрации с длинным абзацем условий должен скроллиться внутри модала, а не расширяться за экран.

Пошаговый аудит макета, который можно повторять на каждой странице

Скорость важна. Самый быстрый путь — аудировать по одному экрану и исправлять одну вещь, которая выбивает макет из колеи.

Выберите экран, который явно ломается на телефоне. Опишите симптомы как баг‑репорт: «надо прокручивать вбок», «основная кнопка обрезана», «модал уходит за экран», «текст накладывается на поле ввода». Это не даст вам метаться и менять случайный CSS.

Дальше изолируйте минимальный элемент, который вызывает аварию. В DevTools поочерёдно выключайте элементы, пока проблема не исчезнет. Часто это один дочерний элемент с фиксированной шириной, длинная неразрываемая строка или компонент, игнорирующий контейнер.

Повторяемый поток действий:

• Найти первый элемент, который превышает ширину вьюпорта
• Убрать фиксированные размеры (жёсткие px‑значения, фиксированные left/right) и дать ширину контролировать родителю
• Предпочесть гибкие правила типа max-width: 100% и width: 100% там, где уместно
• Добавить перенос для длинного контента (имена, email'ы, тексты ошибок)
• Перетестировать на реальном телефоне, затем на одном планшете

Конкретный пример: на онбординге кнопка Continue уходит за экран на iPhone. Вы проверяете футер и находите контейнер с width: 480px. Удаление этого правила и переход на width: 100% убирают горизонтальную прокрутку и возвращают кнопку.

Частые ловушки, из‑за которых исправления потом ломаются

Быстрые мобильные фиксы часто выглядят нормально на одном размере, а потом разваливаются, когда появляется реальный контент. Хорошее правило: если вы угадали пиксель — это, скорее всего, сломается позже.

Обычная ошибка — добавлять всё новые breakpoint'ы вместо исправления базового макета. Breakpoint'ы полезны, но если базовый лейаут зависит от фиксированных ширин или десктоп‑обёртки, вы будете гоняться за новыми проблемами на каждом устройстве. Начните с гибких контейнеров, потом добавьте один‑два breakpoint'а для крупных изменений.

Ещё ловушка — использовать overflow: hidden, чтобы скрыть горизонтальную прокрутку. Это может скрыть симптом, но обрезать кнопки, сообщения об ошибках или контуры фокуса. На формах это может даже скрыть текст валидации, так что пользователи не смогут завершить поток.

Жёстко заданные высоты тоже ломкие. Карточка с height: 420px будет клиповать контент при длинном имени, появившейся ошибке или включённом большем масштабе текста. Предпочитайте естественный поток контента и позвольте странице скроллиться.

Конфликтующие правила отступов могут тихо свести на нет вашу работу. AI‑компоненты часто приносят свои margin, padding и line‑height, а глобальный CSS добавляет ещё. Когда один компонент выходит с другими предположениями по отступам, выравнивание съезжает и переполнение возвращается.

Не забывайте тёмную тему и большой масштаб текста. Быстрые проверки, которые ловят ошибки рано: увеличьте текст до 200% и проверьте формы и модалы, переключитесь в тёмную тему и поищите невидимые границы и подсказки, протестируйте один маленький и один большой телефон.

Быстрый чеклист мобильной удобности

Используйте это после того, как убрали переполнение и хрупкий CSS. Он ловит то, что делает страницу неудобной на настоящем телефоне, даже если на десктопе всё выглядит нормально.

Убедитесь, что страница никогда не заставляет двигаться вбок. Откройте ключевые экраны (лендинг, вход, дашборд, настройки) и попробуйте свайпнуть влево и вправо. Если что‑то движется — что‑то всё ещё шире вьюпорта.

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

Простой набор проверок:

• Нет горизонтальной прокрутки на ключевых экранах (включая модалы)
• Текст переносится естественно (нет обрезанных заголовков или блоков с фиксированной шириной)
• Цели касания безопасны (кнопки и ссылки не сжаты)
• Формы остаются удобными (поля, выпадающие списки и состояния ошибок остаются на экране)
• Сценарии одной руки работают (меню и модалы не требуют точных нажатий)

После любого изменения UI проверьте несколько вещей: 320px‑й вьюпорт всё ещё работает, при открытой клавиатуре вы можете добраться до следующего поля и кнопки отправки, состояния ошибок остаются видимыми, загрузочные состояния не растягивают контейнеры, и тёмная тема остаётся читаемой.

Пример: если AI‑сгенерированная страница настроек добавляет новый «Upgrade to Pro» pill, он может тихо вызвать переполнение. Поймайте это рано, повторяя свайп‑тест и проверку 320px.

Пример: спасаем сломанный экран онбординга

Типичный случай: экран онбординга выглядит нормально на десктопе, но на iPhone карточка обрезана, страница прокручивается вбок, а кнопка «Continue» оказывается под клавиатурой.

В одном спасении три корневые причины создали основную проблему. Главная карточка имела фиксированную ширину (например, 520px) и жёсткий левый margin, поэтому она не могла ужаться. Поле email позволяла длинным адресам выходить за пределы карточки, потому что строка ввода не могла корректно ужаться. А модал «Terms» использовал фиксированную высоту без внутренней прокрутки, из‑за чего он переполнял экран.

Аудит начинается с воспроизведения ошибки на реальных размерах, затем поиска первого элемента, который выглядывает. Дальше поднимаетесь по дереву родителей, пока не найдёте контейнер, который отказывается ужиматься.

Исправления были небольшими и сосредоточенными на удалении принудительных размеров. Карточка перешла с фиксированной ширины на max-width с гибкой подгонкой, margin'ы стали отзывчивыми (центрирование с авто‑отступами), строка ввода получила правила, позволяющие ужиматься без выталкивания соседей, а модал поменялся с фиксированной высоты на максимальную высоту вьюпорта с внутренней прокруткой.

Проверки приёма на телефоне и планшете были простыми:

• Нет горизонтальной прокрутки нигде, даже при фокусе на полях
• Основная кнопка остаётся видимой над клавиатурой
• Модал помещается на экран и прокручивается внутри себя
• Текст читаем без зума, цели касания удобны

Следующие шаги, если AI‑созданный UI продолжает ломаться

Если мобильные баги продолжают возвращаться, проект обычно лишён общих правил макета. Несколько решений сейчас предотвратят следующий раунд откатов.

Напишите короткую заметку «правила для мобайл» и держите её рядом с кодом. Будьте конкретны:

• Никаких фиксированных ширин на контейнерах уровня страницы (предпочитать max-width и гибкие размеры)
• Любой компонент, который может переполнять, должен делать это осознанно (перенос, усечение или прокрутка)
• Одна система отступов (небольшой набор gap'ов и размеров шрифтов)
• Кнопки и поля должны оставаться удобными для большого пальца (комфортная высота и понятные ярлыки)

Фиксируйте в порядке, который даёт стабильность: сначала уберите горизонтальную прокрутку, затем исправьте формы (поля, ошибки, поведение с клавиатурой), и только потом полируйте второстепенные экраны.

Если вы унаследовали AI‑сгенерированный фронтенд и постоянно натыкаетесь на одни и те же ошибки макета, бывает быстрее получить чистую диагностику того, что реально вынуждает переполнение и хрупкое позиционирование. FixMyMess (fixmymess.ai) фокусируется на ремонте AI‑созданных приложений из инструментов вроде Lovable, Bolt, v0, Cursor и Replit, и быстрый аудит кодовой базы может точно сказать, что ломается на реальных устройствах, прежде чем вы потратите время на лечение симптомов.