Создание сайтов

Mobile First
Сначала 360px и смысл блоков. Десктоп — расширение, не исходник, который потом давят.
Не техника ширин, а порядок решений
Mobile First — способ проектировать страницу, начиная с узкого экрана. Сначала решают, что человек обязан увидеть и нажать, когда места мало. Потом добавляют колонки, боковые блоки, декорации. Это не синоним адаптивной вёрстки: адаптивный дизайн описывает, как блоки перестраиваются. Здесь — зачем вообще начинать с 360px, а не с «большого макета, который потом сожмём».
Desktop First выглядит привычно: артборд 1440, герой на весь экран, три колонки преимуществ, слайдер клиентов, форма в подвале. На телефоне из этого остаётся каша: то, что было «воздухом», становится километром прокрутки, а заявка — на дне.
Узкий экран заставляет назвать приоритет вслух. Если приоритет не назван, его назначит случай: что влезло в шапку макета.
Почему узкий экран — честный фильтр
На ширине телефона нельзя спрятать слабую иерархию декорациями. Нет места на пять равнозначных кнопок. Нет места на слайдер из шести смыслов. Нет места на меню из пятнадцати пунктов без пряток.
Это ограничение полезно продукту. Оно совпадает с тем, как люди реально заходят: из поиска, из мессенджера, из рекламы, одной рукой, в шуме. Сценарий «найти услугу → понять условия → оставить контакт» должен жить в этом контуре. Как проверять этот сценарий — в статье как сделать сайт удобным. Mobile First говорит, что сценарий проектируют здесь, а не «добавят в мобильную версию потом».
Ещё один эффект: тяжёлые решения всплывают рано. Видеоавтоплей, карусель, веб-шрифт на кириллицу в четырёх начертаниях, карта на весь первый экран — на узком это сразу боль. На десктопе боль маскируется шириной канала в офисе дизайнера.
Скорость и стабильность отрисовки на телефоне связаны с поисковыми сигналами и с отказом. Разбор метрик — в материале как скорость сайта влияет на SEO. Для проектирования достаточно правила: то, что не влезает в первый смысл узкого экрана, не должно грузиться в первую очередь.
Как выглядит процесс
- Список задач страницы: одна главная, две вспомогательные. Не двенадцать «и ещё про нас».
- Прототип узкой колонки: заголовок, смысл, доказательство, действие. Без карусели «пока не решили».
- Навигация: что в видимой зоне, что за кнопкой меню. Если в меню нельзя выбрать услугу за пару нажатий — услуг в шапке слишком много или имена плохие.
- Расширение к планшету и десктопу: вторая колонка, оглавление, больше примеров рядом, не сверху ещё один баннер.
- Только потом визуальный декор, который на узком не мешает чтению.
Если блок нельзя объяснить на ширине телефона одной фразой «зачем он здесь», на десктопе он тоже лишний. Широкий экран не создаёт смысл, он даёт ему место.
Прототип узкой ширины дешевле спора про тени. Его можно согласовать текстом и рамками. Макет «сразу красивый десктоп» согласовывает настроение и прячет дыры в составе блоков.
Что меняется в составе страницы
Первый экран. На десктопе туда пихают фото офиса, слоган и три CTA. На узком остаётся слоган, который никто не понял, и кнопки впритык. Mobile First требует: один оффер, одно действие, доказательство рядом, не «листайте карусель».
Навигация. Гамбургер — не победа. Это признак, что пункты не влезли. Иногда это нормально. Часто это лень приоритизировать. Телефон компании и заявка не должны жить только внутри спрятанного меню, если это основной канал.
Контент ниже. Десктоп прощает длинные «о компании» до услуги. Узкий экран не прощает: человек не доскроллит. Услуга и условия поднимаются. История бренда опускается.
Таблицы и калькуляторы. Их не выкидывают, но проектируют как последовательность шагов, а не как Excel на 12 колонок. Иначе адаптив потом героически «скроллит таблицу», хотя задачу можно было собрать карточками.
Типичные подмены
«У нас Mobile First, потому что в CSS сначала min-width». Порядок медиазапросов можно сделать любым. Если макеты и контент родились на 1440, это Desktop First с инверсией скобок.
«Сделаем десктоп, потом адаптируем». Адаптировать — значит выкидывать и переставлять после согласования. Согласованный десктоп почти никогда не отдают резать. В итоге мобильный — сжатый компромисс.
«Отдельное приложение важнее сайта». Иногда да. Часто это способ не решать приоритет блоков на сайте, которым пользуются из поиска. Приложение не заменяет посадочную по запросу.
«На мобильном другой оффер». Опасная развилка: человек из рекламы и из поиска должен узнать тот же смысл. Меняется плотность и порядок, не обещание.
«Спрячем лишнее через display:none». Блок, который на узком скрыт, всё равно в DOM: картинки и скрипты часто грузятся. Это не приоритет, а два интерфейса в одной странице. Mobile First выкидывает лишнее из состава, а не прячет его CSS-ом.
Зона большого пальца. Заявка и звонок ближе к естественному хвату, чем мелкий крестик в верхнем углу. Если главное действие только в шапке, на узком его легко не заметить за «гамбургером».
Как принимать Mobile First, а не отчёт
Смотрите прототип и контент на живом телефоне до утверждения «большого» визуала. Задайте четыре вопроса:
- Что человек должен сделать за первый экран? Это одно действие?
- Что можно убрать, и страница останется честной?
- Что добавится на широком экране — польза или заполнение пустоты?
- Что грузится до того, как виден оффер?
Если ответы расплывчатые, проектирование ещё не началось. Сетка потом это не спасёт.
Сборка такого контура — не «нарисовать телефон в Figma». Это договор о составе страниц, который потом верстают. Он входит в постановку дизайна и сайта вместе со структурой разделов.
Ограничения подхода
Есть интерфейсы, где широкий экран — родная среда: сложные таблицы мониторинга, конструкторы, личные кабинеты с многими панелями. Там Mobile First не значит «убить плотность». Значит: мобильный сценарий для этих ролей проектируют отдельно (просмотр, согласование, тревога), а не делают вид, что двенадцать колонок «как-нибудь сложатся».
Есть заказчики, которые живут в презентациях 16:9. Им узкий прототип кажется «бедным». Это нормальное сопротивление. Бедность прототипа — цена ясности. Богатство без приоритета дорого обходится на трафике с телефона.
Mobile First не отменяет доступность клавиатуры и не отменяет десктопных пользователей. Он задаёт, с какого конца резать лишнее. Резать всё равно придётся: место, внимание и канал ограничены.
Частые вопросы
Если половина заявок с десктопа, Mobile First не нужен?
Нужен. Узкий экран — жёсткий фильтр приоритета: что обязано попасть в первый экран. Десктоп этот приоритет не отменяет, он даёт больше воздуха тем же блокам. И доля мобильного трафика у большинства коммерческих сайтов уже не «дополнение».
Это то же самое, что адаптив?
Нет. Адаптив — как сетка перестраивается по ширине. Mobile First — с какого конца вы принимаете решения о составе страницы. Можно сверстать адаптив, начав с десктопа и выкидывая блоки — получится другой сайт, обычно хуже.


