Mobile-First Design: как проектировать интерфейс от маленького экрана

Чем Mobile-First отличается от адаптивной вёрстки, как расставить приоритеты контента, какие размеры сенсорных целей требуют Apple, Material и WCAG 2.2, как делать формы, изображения и навигацию для смартфона.

Mobile-First — это не «сделать мобильную версию», а порядок проектирования: сначала решить, что человеку нужно на маленьком экране с пальцем вместо курсора и нестабильной связью, и только потом добавлять то, что уместно на большом мониторе. Такой порядок заставляет принять трудные решения о контенте в самом начале, когда они ещё дёшевы, и в итоге улучшает обе версии интерфейса. Ниже — как устроен подход на практике: чем он отличается от адаптивной вёрстки, как расставить приоритеты контента, какие размеры сенсорных целей требуют стандарты, где на экране удобно размещать действия, как проектировать формы, изображения и навигацию для смартфона и как проверить результат. Статья о методе проектирования; о том, как интерфейс в целом влияет на заявки, — отдельный материал о UX/UI-дизайне, который продаёт . Почему мобильный экран — отправная точка Причин три, и все проверяемые. Доля трафика. По данным StatCounter, в апреле 2026 года на мобильные устройства приходилось около 53% мирового веб-трафика. В отдельных нишах доля заметно выше или ниже, поэтому смотреть нужно в аналитику собственного сайта — но в среднем смартфон уже основной экран. Индексация. 31 октября 2023 года Google объявил о завершении перехода на mobile-first индексацию: для ранжирования и индексации по умолчанию используется мобильная версия страниц. Контент, который есть только на десктопе, для поиска фактически не существует. Ограничения дисциплинируют. Если элемент не помещается на экран шириной 360 пикселей, приходится ответить, нужен ли он вообще. Десктопный макет такого вопроса не задаёт — место есть всегда. Для B2B это тоже актуально: первое знакомство с компанией часто происходит со смартфона — по ссылке из мессенджера, после встречи, в дороге. Решение о покупке может приниматься за рабочим компьютером, но отбор кандидатов начинается раньше. Mobile-First и адаптивная вёрстка: в чём разница Адаптивность (responsive design) — свойство результата: интерфейс корректно работает на экранах разной ширины. Mobile-First — порядок, в котором к этому результату приходят. При подходе «от десктопа» сначала рисуют широкий макет, а потом ужимают: колонки складываются в одну, меню уходит в бургер, часть блоков прячется. На телефоне получается уменьшенная копия с тем же количеством контента, но хуже организованная. При Mobile-First базовый макет — узкий. Он содержит только необходимое, выстроенное в одну колонку в порядке важности. Широкие экраны получают дополнительное пространство: вторую колонку, развёрнутую навигацию, расширенные таблицы. В CSS порядок отражается в медиазапросах: базовые стили пишутся для узкого экрана, а правила для широких добавляются через min-width . /* Базовые стили: узкий экран */ .cards { display: grid; gap: 16px; padding: 16px; } /* Шире 48em — две колонки */ @media (min-width: 48em) { .cards { grid-template-columns: repeat(2, 1fr); gap: 24px; padding: 32px; } } /* Шире 75em — три колонки и ограничение ширины */ @media (min-width: 75em) { .cards { grid-template-columns: repeat(3, 1fr); max-width: 1200px; margin-inline: auto; } } Точки перелома лучше выбирать по контенту — там, где макет начинает «ломаться», — а не под популярные модели устройств. Для компонентов, которые живут в колонках разной ширины, современный инструмент — контейнерные запросы: компонент перестраивается по ширине своего контейнера, а не окна. Подробно — в статье о CSS Grid и Flexbox . Прогрессивное улучшение Прогрессивное улучшение — стратегия, при которой основа работает у всех, а возможности добавляются там, где их поддерживает устройство и позволяет соединение. Основа: текст, ссылки, формы и навигация работают даже при медленной связи и до загрузки всех скриптов. Улучшения: анимации, интерактивные виджеты, отложенная подгрузка — для устройств и браузеров, которые их поддерживают. Отдельные сценарии для широких экранов: сложные сравнительные таблицы, многоколоночные панели, расширенные фильтры. Практическая проверка: откройте страницу при медленном мобильном соединении в инструментах разработчика браузера. Если несколько секунд человек видит пустой экран или кнопку, которая не реагирует, пока не догрузится скрипт, основа зависит от улучшений. Приоритизация контента Первый шаг — инвентаризация: выписать всё, что есть на странице, и для каждого элемента ответить, насколько он важен пользователю и бизнесу. Удобно разложить элементы по четырём группам. Группа Что сюда входит на странице услуги Как показывать на смартфоне Критично Что предлагается, для кого, главное действие, контакт Первый экран Важно Ключевые кейсы, процесс, ориентир по цене Сразу после первого экрана Полезно Подробности, команда, статьи Ниже или в раскрывающихся блоках Второстепенно Детальные сравнительные таблицы, декоративные блоки Упростить, вынести на отдельную страницу или убрать Два правила. Первое: контент, важный для поиска, не удаляется из мобильной версии — Google индексирует именно её. Сворачивание в аккордеон допустимо, удаление — нет. Второе: если элемент «второстепенный» на всех экранах, скорее всего, он не нужен и на десктопе. Скрыть или не загружать display: none прячет элемент визуально, но не отменяет его загрузку: изображения в скрытых тегах img браузер, как правило, всё равно скачивает, а скрипты скрытых виджетов выполняются. Если блок на смартфоне не нужен, лучше не загружать его вовсе — подключать компонент условно или отдавать разные изображения через srcset и picture . Сенсорные цели: размеры и расстояния Палец менее точен, чем курсор, и закрывает то, на что нажимает. Требования к размеру интерактивных элементов различаются в зависимости от источника, и их полезно знать точно. Apple Human Interface Guidelines: минимальная область касания — 44×44 точки. Material Design (Google): 48×48 dp. WCAG 2.2, критерий 2.5.8 (уровень AA): не меньше 24×24 CSS-пикселей или достаточный отступ до соседних целей, с рядом исключений, например для ссылок внутри текста. Критерий 2.5.5 уровня AAA требует 44×44. На практике для основных кнопок и пунктов меню разумно ориентироваться на 44–48 пикселей, а 24 пикселя считать нижней границей, ниже которой нельзя опускаться. Иконка может быть визуально 24×24, но область нажатия расширяется отступами: .icon-button { display: inline-grid; place-items: center; min-width: 44px; min-height: 44px; padding: 10px; } .icon-button svg { width: 24px; height: 24px; } Не менее важно расстояние между целями: две маленькие ссылки вплотную — гарантированные промахи. Особенно это касается ссылок в подвале, фильтров-«таблеток» и иконок в строке таблицы. Как держат телефон и где размещать действия Стивен Хубер в исследовании для UXmatters (2013) описал 1333 наблюдения за людьми, пользующимися телефонами на улице, в транспорте и кафе. Примерно половина держала телефон одной рукой, остальные — придерживая одной рукой и нажимая пальцем другой или обеими руками. Хват меняется по ходу использования, поэтому интерфейс не должен рассчитывать на одну позу. Из этого следуют умеренные выводы, а не жёсткие «красные зоны»: частые действия удобнее размещать в нижней и средней части экрана — отсюда популярность нижней панели навигации в приложениях и закреплённой кнопки действия; редкие и опасные действия (удалить, выйти) не стоит ставить туда, где на них легко нажать случайно; важные элементы не должны прятаться за краем экрана и системными жестами — нижняя закреплённая панель учитывает безопасные зоны через env(safe-area-inset-bottom) ; закреплённые элементы съедают высоту экрана: шапка и нижняя панель вместе не должны оставлять контенту половину экрана. Жесты Используйте жесты, которые пользователи уже знают: прокрутка, горизонтальный свайп в каруселях, pull-to-refresh в лентах, масштабирование щипком для изображений и карт. У любого жеста должна быть видимая альтернатива — кнопка или ссылка: жест не виден на экране, а часть пользователей им не владеет. WCAG 2.2 отдельно требует, чтобы действия, выполняемые перетаскиванием, были доступны и одиночным нажатием (критерий 2.5.7). Типографика на маленьком экране Размер основного текста — от 16 пикселей. Отдельная техническая причина: Safari на iOS автоматически увеличивает масштаб страницы при фокусе на поле ввода, если размер шрифта в поле меньше 16 пикселей, и после этого пользователю приходится возвращать масштаб вручную. Масштаб заголовков на мобильных меньше, чем на десктопе, иначе заголовок из пяти слов занимает весь экран. Плавное изменение размера удобно задавать через clamp() . Межстрочный интервал для основного текста — около 1,5. Размеры в rem , а не в фиксированных пикселях для текста, чтобы учитывалась настройка размера шрифта в браузере. Контраст — не ниже 4,5:1 для обычного текста и 3:1 для крупного по WCAG. Крупным считается текст от 18 пунктов (примерно 24 CSS-пикселя) или от 14 пунктов полужирного начертания. Смартфоном часто пользуются на улице, где запас контраста особенно важен. h1 { font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3rem); line-height: 1.15; } body { font-size: 1rem; line-height: 1.5; } Формы на смартфоне Набирать текст на телефоне дольше и неудобнее, поэтому каждое поле на мобильном стоит дороже. Помимо сокращения полей, помогает правильная разметка — она определяет клавиатуру и автозаполнение. label for="phone" Телефон /label input id="phone" name="phone" type="tel" autocomplete="tel" label for="email" Email /label input id="email" name="email" type="email" autocomplete="email" label for="inn" ИНН компании /label input id="inn" name="inn" inputmode="numeric" autocomplete="off" label for="code" Код из SMS /label input id="code" name="code" inputmode="numeric" autocomplete="one-time-code" type и inputmode открывают нужную клавиатуру: цифровую, с символом @, телефонную. autocomplete позволяет браузеру подставить сохранённые данные, а one-time-code — предложить код из SMS. Поле для ИНН или номера договора — не type="number" : такое поле может отбросить ведущие нули и показать стрелки увеличения значения. Подписи — над полями, в одну колонку; кнопка отправки — на всю ширину и не прячется под открытой клавиатурой. Навигация Меню-бургер экономит место, но прячет разделы: то, чего не видно, используют реже. Поэтому 3–5 ключевых разделов или главное действие стоит оставить видимыми, а в меню убрать остальное. Для сайта услуг это может быть кнопка связи в шапке; для личного кабинета или веб-приложения — нижняя панель с основными разделами. Длинные страницы выигрывают от внутренней навигации: оглавления в начале или закреплённых вкладок разделов. Кнопка «Наверх» полезна на очень длинных списках, но не заменяет структуру. Изображения и производительность На мобильных устройствах медленнее и сеть, и процессор, поэтому производительность — часть дизайна. Адаптивные изображения. Через srcset и sizes браузер выбирает файл под ширину экрана и плотность пикселей, вместо того чтобы скачивать изображение шириной 2400 пикселей для экрана в 390. Современные форматы. WebP по данным Google в среднем на 25–34% меньше сопоставимого по качеству JPEG; AVIF обычно сжимает ещё сильнее. Оба формата поддерживаются актуальными браузерами. Размеры заранее. Атрибуты width и height или aspect-ratio резервируют место и предотвращают смещение макета. Приоритеты. Главное изображение первого экрана загружается сразу (можно с fetchpriority="high" ), остальные — отложенно через loading="lazy" . img src="/img/case-800.webp" srcset="/img/case-400.webp 400w, /img/case-800.webp 800w, /img/case-1600.webp 1600w" sizes="(min-width: 75em) 33vw, (min-width: 48em) 50vw, 100vw" width="800" height="500" loading="lazy" alt="Интерфейс личного кабинета на смартфоне" Ориентиры — Core Web Vitals, которые Google оценивает по 75-му процентилю реальных пользователей: LCP (отрисовка крупнейшего элемента) до 2,5 секунды, INP (задержка отклика на действия, заменил FID в марте 2024 года) до 200 миллисекунд, CLS (смещения макета) до 0,1. Проверять стоит отдельно для мобильных пользователей: на десктопе цифры почти всегда лучше. Подробный разбор оптимизации — в статье о производительности веб-приложений . Частые ошибки Горизонт