Привет! Я Оля, лид дизайн‑системы Альфа‑Банка на мобильных платформах и я всерьёз считаю, что знания о вёрстке незаслуженно списали со счетов, особенно в 2026 году, когда дизайнеры всё чаще думают, что ИИ сделает за них всю работу, а вёрстку вообще можно не трогать.
Увы и ах. Вёрстка — это не просто «разложить прямоугольники на макете». Это мост между дизайном и кодом.
И — спойлер: ИИ тоже нужно учить, и учить на правильных примерах, но сначала стоило бы научиться вёрстке самому. Про ИИ в этой статье не будет — но зато будет много про православную ручную вёрстку: расскажу, почему считаю важным обращать на неё внимание при создании макетов и заранее закладывать правила, по которым она формируется. Особенно в эпоху, когда конкуренция высока, а ИИ кажется волшебной таблеткой.
А если ты всё ещё думаешь, что дизайнер не может повлиять на конечный код на этапе макета — надеюсь, к концу статьи ты усомнишься в своей уверенности, ведь в ней я:
Покажу, как с помощью макетов дотащить свою концепцию до прода с минимальными потерями.
Попробую настроить дизайнеров и разработчиков на продуктивное взаимодействие друг с другом.
И попробую замотивировать дизайнеров погружаться в технические аспекты разработки интерфейсов.
Что такое вёрстка?
Для начала давай обозначим, что такое «вёрстка».
Безусловно, термин многогранный. Для кого-то это «процесс создания структуры кода по отрисованному макету», для кого-то «она определяет, как элементы макета пользовательского интерфейса (UI) будут отображаться на экране устройства и как пользователь будет с ними взаимодействовать». Есть и те, что знают термин «вёрстка» как «монтаж макета газеты или книги из подготовленного материала — текста, таблиц, изображений, который потом отправляется в печать».
Но в моей статье под словом «вёрстка» скрывается финальный макет (или набор макетов), который дизайнер передаёт в разработку, а также его реализация на фронте, которую разработчик возвращает на проверку дизайнеру.
Если прям совсем коротко (и ясно), то это «Ready to dev макет»: когда дизайнер жмёт те самые зелёные треугольные скобки рядом с именем фрэйма.
На изображении выше слева — макет от дизайнера, а справа — его реализация в коде от разработчика. Обычно от разработчиков, которые забирают на проверку вёрстку от дизайнеров, и от дизайнеров, что сталкиваются с результатом от разработчика, я слышу один и тот же вопрос: «Что это?».
И пока каждый из них объясняет, что он не верблюд, перекладывает ответственность на другого, я сижу посередине и не понимаю, как всё это прекратить. Ведь на деле что макет дизайнера, что экран разработчика так себе.
Но почему? Потому что, глядя на них, я не могу оценить ни качество пользовательского опыта, ни интерактивность, ни наличие анимации, ни, тем более, её параметры. Я вижу и могу оценить только статичную вёрстку — картинку.
И в воздухе зависает вопрос…
Да что в такой простой задаче могло пойти не так?
Надеюсь, ни для кого не будет сюрпризом, если я скажу, что платформы iOS и Android обладают рядом технических особенностей и ограничений, каждая из которых формирует уникальный опыт у пользователя?
А помнит ли об этом дизайнер при проектировании интерфейса?
Если нет, то он неосознанно использует одинаковые паттерны как на iOS, так и на Android и старается сформировать у пользователя общие паттерны использования одного и того же приложения, независимо от платформы.
Если да, значит, он осознанно натягивает паттерны одной платформы на другую. Чаще всего это касается продуктов, которые поддерживаются на обеих платформах. На примере наших банковских приложений можно проследить данное желание (а может, даже потребность).
И всё становится ещё сложнее, когда к мобильным платформам начинает подключаться ещё и веб, веб-десктоп, веб-мобайл, горизонтальные ориентации, планшет iPadOS, планшет Android и даже такое страшное слово, которым родители пугают маленьких дизайнеров, как веб-вью. Бу.
В этой ситуации дизайнер пытается усидеть уже не на двух стульях, а на четырёх, пяти и более, чтобы угодить всем пользователям и дотащить общую продуктовую концепцию с минимальными потерями.
Давай посмотрим, к чему это приводит на примере реальных ошибок — не только в рамках одного экрана, но и в целых сценариях.
Глубина понимания вёрстки: чему я научилась на своих ошибках (и ваших тоже)
Не будем сейчас разбирать, кто на самом деле верблюд виноват — дизайнер, разработчик или процесс. Моя задача — сделать так, чтобы дизайнер смотрел на свои макеты внимательнее (а разработчик это ценил).
Какие-то ошибки покажутся тебе мелочами. С чем-то ты не согласишься. Отлично. Значит, будет дискуссия.
Но мой опыт говорит: когда этих ошибок нет — дизайнер не переделывает (или переделывает реже), а разработчик не задаёт глупых вопросов (или задаёт более важные).
Перейдём к моей коллекции — от простого к сложному.
Уровень 1: разметка элементов интерфейса
Как часто ты, дизайнер, обращаешь внимание на расположение элементов навигации или области контента на макете? Посмотрим на иллюстрацию ниже.
Верх, низ, контент, скролл — теперь весь макет можно затолкнуть в Auto layout и обозначить, что сверху у нас будет верхняя навигация, снизу — нижняя, а контент где-то посередине. Auto layout расслабляет. 🫠
Однако технически на интерфейсе не всё собирается через таблицу или стэк. Применять только Auto layout невозможно, потому что технически часть элементов может помещаться как в таблицу, так и настраиваться через констрэйнтсы (кто-то про них ещё помнит?).
Но даже если принять во внимание, что мы целиком собираем макеты на Auto layout, как часто мы следим за поведением областей относительно макета или экрана?
Да, в твоём продукте (как и у многих в нашей компании) может не поддерживаться планшетная версия. Но частенько дизайнер забывает про демонстрацию интерфейса на более широком или более узком экране. А какие-то продукты могут поддерживать даже горизонтальную ориентацию на телефоне. У нас, например, Android так могёт (по крайней мере, раньше мог).
Контентная область может иметь скролл, причём как вертикальный, так и горизонтальный. Какие-то элементы на экране могут закрепляться поверх всего контента, являясь при этом его частью. И если всё это учесть, то один макет будет работать с любой вёрсткой: широкой, узкой, горизонтальной, вертикальной.
Ещё один из моих любимых примеров, о котором дизайнер не помнит — изображение, что должно сохранять соотношение сторон. Забывая об этом, дизайнер сталкивается с очень большими картинками на широких экранах (да, одна такая торчит на скриншоте выше).
Уровень 2: паттерны навигации
Копнём глубже. Ты же знаешь, что такое Push и Present навигация? Закрой текст ниже ладошкой и проверь свои знания.
Если кратко, Push — это паттерн линейной навигации на iOS, Present — паттерн модальной навигации на iOS. А если ещё короче, Push — стрелочка «назад», а Present — крестик. Это не просто технические детали. Это пользовательский опыт. Перепутал — пользователь закроет экран (и повезёт, если только 1 экран) вместо того, чтобы вернуться назад.
Если представить паттерны схематично, получится что-то похожее на изображении ниже.
Замечу, что паттерны возможно комбинировать друг с другом: например, в модальной навигации можно использовать линейную (но тогда пользователь сможет совершить ошибку и закрыть весь флоу, по которому двигался в модальности).
Должен ли дизайнер это знать? Да, дизайнер, работающий с интерфейсами, напрямую влияет на пользовательский опыт и должен знать, какие решения платформа, интерфейс под которую он делает, предоставляет. Это знание позволит подготовить рабочую вёрстку прямо в редакторе интерфейсов.
Иначе дизайнер не только может нарушить платформенные принципы и требования к навигации, но и обескуражит пользователя, который не сможет пользоваться приложением так, как привык. Помни: разница между платформами и разница в рамках одной платформы влияют на поведение вёрстки.
Где брать эту бесценную практику? В технической литературе для разработчиков (подчеркнула 2 раза).
К сожалению, документации HIG и Material дают лишь поверхностное представление о том, каким принципам должны подчиняться интерфейсы на платформах и с помощью каких компонентов эти принципы можно поддержать
В своё время разобраться в паттернах нативной навигации мне помогли:
Учебник по Swift UI «Kodeco: iOS and SwiftUI for Beginners».
Курс от iOS-разработчика «Beginning iOS 13 Programming with Swift (Simon NG)».
Курс от Android-разработчика «Kodeco: Android & Kotlin for Beginners».
А также разговоры по душам с разработчиками.
К технической литературе я обращаюсь и по сей день.
Мой тебе совет: если у вас есть паттерны, которые вы закладываете в свой продукт, заведите шаблоны под каждый из них в редакторе макетов и переиспользуйте. Так меньше вероятность совершить ошибку, можно обучать новичков. Разработчикам тоже станет легче, потому что они будут сразу понимать, какой паттерн используется.
А если «масштабировать» рекомендацию, то в целом сформируйте правила, гайдлайны, свой личный ГОСТ по вёрстке макетов, по сборке компонентов, по описанию паттернов, которые невозможно продемонстрировать. Если у вас выстроена коммуникация с разработкой, то есть и правила, по которым вы с ними работаете — просто оформите их. О коммуникации с разработчиками пара рекомендаций также будет ниже.
Уровень 3: типы элементов на экране
Копаем ещё глубже: посмотрим на элементы интерфейса внутри контента.
Если выбор элемента делегировать разработчику, то этот поиск проходит полный круг и разработчик возвращается к дизайнеру с той же задачей, но с дополнительным множеством «неудобных» вопросов: «Элемент интерактивный или статичный? Нативный или кастомный? Это виджет? Должен ли он нажиматься? Он будет отображать состояние ошибки или загрузки? Будет ли в нём динамический контент? А где это написано? А как ты его нарисовал?»
И здесь важно сказать, что понимание типов элементов также влияет на вёрстку: какие-то элементы обладают своими собственными состояниями и могут отображать ошибку и загрузку, а какие-то этого не умеют и являются статичными; какие-то элементы можно комбинировать друг с другом на одном экране, а какие-то — нет, и далее-далее.
К тому же само понятие «тип» варьируется от компании к компании. В наших продуктах, например, используются разные типы элементов, каждый из которых технически обладает разными свойствами. Их сложно передавать через Фигму разработчику, но мы это делаем в нашей дизайн-системе.
На изображении выше представлена часть мобильных типов элементов в Альфе
Уровень 4: типы экранов и технологии
Самый сложный уровень, который влияет на качество вёрстки — понимание технологии, с помощью которой продукт будет реализовываться.
В современном мире много технологий, но я разделяю их на три условные группы:
Вёрстка на фронте (фронтовая),
Вёрстка на бэке (серверная),
Комбинированная вёрстка.
В наших продуктах применяется всё: и нативная вёрстка на простых и интерактивных компонентах, и виджетная вёрстка на виджетах, и вёрстка с помощью бэка, и комбинированная вёрстка, которая позволяет объединять несколько вышеперечисленных технологий на одном экране.
Что ценно в некоторых этих технологиях, так это возможность передавать одну информацию на все платформы, сохраняя визуальные отличия между элементами. Например, на изображении ниже представлены мобильный интерфейс, мобильная версия в вебе и десктоп (в вебе).
И конечно, каждая их этих технологий имеет свои ограничения и особенности.
Например, серверная технология требует использовать определённый тип или типы элементов, или не позволяет влиять на экран целиком, потому что это полноценный модуль и его можно только переиспользовать. Если дизайнер не будет этого учитывать, то не сможет быть уверенным в том, что макет, который передаёт разработчику, совпадёт с реализацией.
Вернёмся к экрану из начала статьи и ответим на вопрос: «Что с ним не так?». Он демонстрирует, что дизайнер не учёл или типы компонентов, или технологию. В итоге — некачественное ТЗ, самодеятельность разработчика и дизайн-ревью, которое ничего не спасло.
На мой взгляд, самое распространённое заблуждение — когда дизайнер не считает должным быть внимательным к тому, с помощью чего и как он проектирует интерфейс, при передаче сценариев в разработку.
В какой момент дизайнер в IT потерял важность матчасти и подготовки технической стороны своего проекта?
Ведь дизайнер интерьеров (или архитектор) не рисует просто эскизы, а потом отдаёт их прорабам, мол, крепитесь с этим сами? Нет, все эти дизайнеры готовят техническое задание и оформляют несколько этапов своих проектов. Иначе мы оказываемся в ситуации с классическим ремонтом «под ключ»: чертежи сделаны халтурно — прораб с командой уже всё по ним сделали — проверять и переделывать долго и бесценно.
Посему считаю, что если дизайнеру важно увидеть результат, соответствующий его идее, если дизайнеру важно в момент передачи быть уверенным в технической реализации, он не должен забывать о необходимости готовить качественное техническое задание для разработчиков, коим являются его макеты.
Стоит заметить, что качественно подготовленное техническое задание также является залогом качественно-проведённого дизайн-ревью перед попаданием продукта в продакшн. А вот как понять, что техническое задание выполнено по канону, по правилам — это результат вашего общения с разработчиками 😊 (об этом дальше).
Итого, 4 важных тейка, которые мы сегодня разобрали:
Разметка элементов интерфейса.
Паттерны навигации.
Типы элементов.
Технология реализации.
Все примеры, которые я продемонстрировала выше — мои личные наблюдения за макетами, которые передаются в вёрстку и примеры из моего личного взаимодействия с дизайнерами и разработчиками в разных компаниях.
А если уделять вёрстке внимание?
Если уже на этапе дизайна уделять внимание такой концепции, как «платформа», учитывать её потребности и ограничения, то:
Это позволит нам сохранить общую чистоту макетов, которая будет нам понятна в любой момент времени. Откроете макет хоть через год и будете точно понимать, что там происходит.
Это точно сэкономит время дизайнера при подготовке адаптивной вёрстки или демонстрации поведения элементов интерфейса.
Позволит сохранить консистентность между дизайном и кодом.
У вас будет «рабочий» макет прямо там, где вы его собираете.
И если мы получаем рабочий макет, если знаем про ограничения со стороны дизайна на платформах, то у нас есть определённая зона влияния на интерфейс — мы сами можем управлять тем, как интерфейс должен выглядеть.
И последний, но не по значимости, пункт — обучение новичков, старичков, и всех остальных. Если у вас есть готовые правила, по которым вы верстаете и они учитывают ограничения платформ, вы можете спокойно визуально продемонстрировать это всем, кому понадобится
Как начать относиться к вёрстке внимательнее?
Вот что реально работает (делюсь нашим опытом в Альфе и тем, что может сделать любой дизайнер).
Что можно сделать самому:
1. Общайтесь с разработчиками. Не стесняйтесь задавать «глупые» вопросы: «А здесь точно будет крестик, а не стрелочка?» Это формирует общие правила игры. Чем раньше спросите — тем меньше переделок. Мы регулярно общаемся с коллегами на общих консультациях и личных встречах, задавая глупые вопросы и вырабатывая общие процессы и правила работы.
2. Установите Xcode или Android Studio. Посмотрите, как работают нативные паттерны навигации. Один час в среде разработки даст больше, чем большинство книг по дизайну.
3. Ходите на митапы разработчиков (или смотрите записи). Там рассказывают о сложностях и практиках простым языком (обычно).
4. Изучайте техническую литературу. Не бойтесь — это не значит «стать разработчиком», это значит «понимать, о чём они говорят».
Что можно сделать в команде (если есть ресурсы):
5. Фиксируйте документацию. Заведите общую базу знаний, куда записываете правила вёрстки, паттерны, решения. Это помогает не забыть, не стать узким горлышком и поделиться с новичками. Например, мы ведём несколько проектов в общей базе знаний и разрабатываем общий внутренний портал.
6. Проводите внутренние лекции и воркшопы — дизайнеры учат разработчиков, разработчики — дизайнеров. Работает в обе стороны. В Альфе мы пошли дальше: у нас есть отдельные комитеты по направлениям, внутренние каналы и дайджесты. Но это уже опция для крупных команд. Главное — начать с первых четырёх пунктов
Заключение
Что ж, по моему мнению, любой продукт отталкивается от ограничений. Рождается в ограничениях. И чем раньше ты, дизайнер или разработчик, о них узнаешь — тем быстрее учтёшь и внедришь.
Мы постоянно ищем отражение своей работы во фреймворках, выстраиваем взаимосвязи, находим прямые и косвенные проекции, нащупываем общие механики и методы, пытаемся привести профессиональные термины к единому определению. Ищем отражение общего решения в наших инструментах — Фигме и коде.
А что такое код? Это язык представления информации. Это закодированная информация в виде символов определённого языка программирования и его правил. А что такое Фигма? Разве это не язык? Язык. Язык представления той же информации, но с другими правилами.
И наша с вами цель, как дизайнера и разработчика, научиться правильно распознавать язык и и интерпретировать его в наши инструменты. Ведь качественный продукт не получится без коммуникации между разными компетенциями.
А всё, что прошло этап систематизации и документирования, можно автоматизировать (и отдать ИИ). Вот и думайте.