IZUM.STUDY

Идеальный макет для разработчика — миф или реальность? В среду в 16:00 проводим совместный эфир с Сергеем Телидченко. Разбираем по шагам, как подготовить макет к вёрстке. Андрей покажет типичные ошибки и разберет как подготовить макет в Figma правильно: адаптивы, скрытые элементы, UI-kit, состояния интерфейса и анимации. Всё покажем на реальном Figma-файле, по которому уже свёрстана методичка IZUM. Сергей подключится со взглядом дизайнера, чтобы обсудить, как эти правила работают в реальных проектах. Покажем, как сберечь нервы всей команде. Ссылку на эфир опубликуем отдельным постом и продублируем в нашей закрытой группе STUDY.

«UX-дизайн» — спецноминация от IZUM на Dprofile Award 2026 Эта номинация для проектов, где дизайн в первую очередь работает на пользователя. Оцениваться будет: понятная архитектура, предсказуемость действий, забота о времени посетителя сайтов, пользовательская логика и реальная работа интерфейса. Кураторы — команда IZUM. В агентстве они создают современные сайты, где дизайн и фронтенд работают вместе. А в обучающем проекте IZUM.STUDY учат разработчиков делать веб-проекты руками, системно и правильно. Главная фишка спецноминации: судить работы будут разработчики — те, кто каждый день работают с макетами и сразу видят, где интерфейс продуман, а где держится только на красивом мокапе. Сайт IZUM Портфолио IZUM на Dprofile Оценивать работы будут: — Дмитрий Упит, основатель; — Андрей Упит, сооснователь и главный разработчик. — Тигран Шагоян, фронтенд-разработчик; — Алина Болгерт, фронтенд-разработчик. Какие проекты можно подавать: — Сайты, промо-проекты и корпоративные порталы; — Интернет-магазины и e-commerce проекты; — Мобильные приложения и сложные веб-сервисы; — Концепты, если в них глубоко и детально показан путь пользователя. Как команда IZUM будет оценивать работы: «Мы будем смотреть на то, как вы раскрыли проект. Понятно ли из кейса, какую задачу вы решали, почему интерфейс получился именно таким и как он помогает пройти нужный путь без лишней боли. На что будут обращать внимание: 1) Архитектура и навигация: легко ли ориентироваться на сайте и понятно ли куда нажимать. 2) Техническая реализуемость: можно ли этот дизайн нормально сверстать и логично собрать в коде, или он красиво выглядит только на одном «идеальном» мокапе. 3) Общий пользовательский путь: понимает ли посетитель, где он находится, что происходит дальше и какое действие от него ждут. Несколько советов для подающих: — Покажите не только красивые экраны, но и логику. Нам важно увидеть, как посетитель проходит через интерфейс: от первого касания до целевого действия. — Не прячьте UX за мокапами. Красивые 3D-рендеры и эффектные обложки не спасут проект, если внутри непонятная структура и слабый сценарий. — Используйте реальные данные. Не заменяйте контент рыбным текстом и случайными заглушками. Нам важно видеть, как интерфейс работает с материалами, которые действительно будут использоваться в проекте.» Подать проект на Dprofile Award 2026 ⬅️ Ждем ваши работы. Докажите, что ваш дизайн не только классно выглядит, но и безупречно работает!

🦢 SVH или DVH: что юзать в мобильных адаптивах? ⠀ На десктопе собрать полноэкранный блок проще простого. Ставим 100vh — и готово, секция занимает весь монитор. На мобилках эта магия ломается: в игру вступают адресная строка, нижняя навигация и другие панели браузера. ⠀ 👨‍💻 Как работает 100svh? Единица считается от минимальной высоты экрана, когда все панели открыты. Блок аккуратно встаёт в видимую зону, а контент не прячется под интерфейсом браузера. ⠀ Но есть подвох. При скролле панели исчезают, экран становится больше, а высота блока остаётся прежней. По итогу снизу может появиться пустота. ⠀ ⚡️ Что происходит с 100dvh? Здесь всё работает в динамике. Панели ушли — блок вытянулся. Вернулись — сжался. Топ для секций, которые должны всегда занимать всю доступную высоту экрана. ⠀ Но и тут не всё так сладко. Браузер постоянно пересчитывает высоту, поэтому контент может дёргаться и смещаться прямо во время скролла. ⠀ Что ставить на практике: • svh — берём ради стабильной высоты, когда важно показать весь контент; • dvh — юзаем, если блок должен чётко заполнять текущую видимую зону; • vh — оставляем запасным значением, если небольшой заезд контента под панели не критичен. ⠀ Например, svh отлично встанет на экран с важной кнопкой внизу. А dvh — топ для обложки или визуальной секции, которая всегда должна занимать 100% экрана. ⠀ 🖥 Height или min-height? Для обычных секций чаще лучше юзать min-height, а не жёсткий height. ⠀ При height: 100svh блок фиксируется наглухо. Добавили больше текста, включили локализацию или открыли сайт на слишком низком экране — контент вывалился за границы. ⠀ min-height: 100svh задаёт нужную базу, но не мешает секции расти вместе с контентом. Жёсткий height оставляем только там, где объём контента полностью контролируется. ⠀ 💡 По итогу Главная ошибка — искать одну волшебную единицу под весь адаптив. Её нет. ⠀ На одной странице абсолютно нормально миксовать svh для стабильного интерфейса и dvh для полноэкранных секций. Сначала решаем, как должен вести себя конкретный блок, и только потом выбираем единицу. Без магии и костылей — чисто под задачу.

🦢 Почему Header, Nav, Main и Section — не просто красивые названия? В визуальном конструкторе легко собрать всю страницу из обычных div’ов. Пользователь разницы почти не заметит: блоки стоят на месте, ссылки работают, дизайн совпадает на 100%. Но вот для браузера и поисковых систем такая структура — это темный лес. Семантические теги как раз объясняют роли элементов: • Header — верхняя часть страницы; • Nav — основная навигация; • Main — главный контент; • Section — самостоятельный смысловой раздел; • Footer — нижняя служебная и навигационная часть. Это не магическая кнопка для SEO. Один тег сам по себе не выведет ваш сайт в топ поисковика. Но он делает документ логичнее, помогает роботам разбирать страницу и упрощает работу скринридеров. Главное — не превращать семантику в религию. Не каждый блок обязан быть Section, и не каждую группу ссылок нужно оборачивать в Nav. Тег должен соответствовать своей реальной роли, а не ставиться просто ради галочки. По итогу: Семантика не меняет визуал, но прокачивает базу. Пользователь видит тот же интерфейс, а браузер получает четкую и ясную карту страницы. Как часто запариваетесь с семантикой на своих проектах? 👇

Салют! 🤘 Добрались до финала. Девятый урок бесплатного курса по Taptop уже в боте. ⠀ Закрываем лендинг ГКВ. Мы прошли путь от пустого экрана и UI-kit до полностью сверстанных блоков и адаптивов. Осталось вдохнуть в проект жизнь. ⠀ В новом уроке работаем с анимациями и шлифуем верстку: • Подключаем Lenis для плавного скролла. • Анимируем заголовки через маску и выезд букв ГКВ. • Работаем с настройками easing и delay. • Скрываем элементы при скролле и меняем фон хедера. • Настраиваем анимацию футера и переносим эффекты на планшеты и мобилки. • Добиваем мелкие правки и проверяем весь сайт. ⠀ Мы показываем реальный подход. Нельзя накидать эффекты на глаз. Нужно публиковать, проверять, подгонять триггеры, offset и z-index под реальный скролл. Урок объемный, так что разделили его на 3 части. ⠀ Кто прошел всё от и до — поздравляем 🎉 Вы собрали сложный лендинг, который можно использовать как фундамент для новых проектов. ⠀ Не пугайтесь, если что-то не получилось с первого раза. Это норма. Sticky, попапы, ховеры и CMS всегда требуют отладки. Главное уловить саму логику работы в Taptop. ⠀ Финальный урок уже ждёт вас в боте: @Izum_Study_bot

🪗 Что такое vh и зачем он нужен? Если vw работает с шириной, то vh зависит от высоты экрана. Тут всё просто: 1vh равен 1% от высоты окна браузера. Звучит банально, но в вёрстке без этой единицы никуда. Например, когда нужно растянуть секцию строго на весь экран. Обложки, стартовые заставки, полноэкранные меню или декоративные фоны. Ставим высоту 100vh, и блок уверенно занимает всю видимую область. Но есть серьезный нюанс. На мобилках с высотой всё намного хитрее. Там постоянно мешает сам браузер со своей адресной строкой и нижней панелью навигации. Эти элементы умеют появляться и исчезать от скролла. Из-за этого базовые 100vh часто ведут себя криво. Мобильное меню вроде открывается на весь экран, но кусок полезного контента просто прячется под панелью браузера. Высота считается совсем не так, как вы задумывали. Поэтому для мобильных экранов и важных полноэкранных блоков лучше использовать не обычный vh, а более гибкий dvh. Классический vh отлично работает для привязки к высоте окна на десктопе. А вот на смартфонах нужно быть внимательнее. Там 100vh далеко не всегда дает идеальное попадание в видимую зону. По итогу: vh круто решает задачи с полноэкранными секциями, которые жестко завязаны на высоту монитора. Но при работе с планшетами и мобилками всегда проверяйте поведение на реальных телефонах. Именно там начинается всё самое интересное 😅

Салют, друзья! 🤘 ⠀ Открываем восьмой урок бесплатного курса по Taptop. ⠀ На этот раз добираемся до финала лендинга и собираем footer. ⠀ Казалось бы, что там делать: логотип, пара ссылок и всё. Но нет, footer тоже умеет подкинуть задачек. ⠀ Внутри соберём графический знак ГКВ из двух частей, настроим нижнюю сетку со ссылками и меню, добавим hover-состояния и сделаем popup для юридических документов. ⠀ Popup, кстати, будем собирать без готового макета — прямо по ходу урока. Заодно покажем, как подключать PDF-файлы через ресурсы Taptop и открывать их в новой вкладке. ⠀ Отдельно настроим анимацию графического знака при скролле: две части будут съезжаться друг к другу и собираться в готовую форму. ⠀ В финале, как обычно, пойдём в адаптивы: планшет, мобильная версия, popup, hover-анимации и тот самый горизонтальный скролл, который появляется, когда элементы выезжают за пределы секции. ⠀ Новый урок уже доступен в боте: @Izum_Study_bot ⠀ Смотрите, пробуйте повторить и пишите в закрытую группу, если что-то непонятно или хочется обсудить ❤️

🧩 Что такое vw и как мы делаем флюид Для флюидной вёрстки vw это база. Единица жестко привязана к ширине окна браузера. Экран шире, значит блок больше. Экран уже, блок меньше. Дубовые пиксели так не умеют: задали 40px, и они застрянут в одном размере на всех мониторах. Благодаря vw всё масштабируется плавно, без резких скачков между брейкпоинтами. Это идеально для флюида. Но верстать всё напрямую в vw это настоящая боль. В Taptop встроенный калькулятор корректно работает только при верстке на разрешении макета. Будете писать всё в vw, жестко привяжетесь к одному разрешению (например, к 1600px). И если вы перейдете на 1440px, но попытаетесь вбить значение из макета на 1600px, калькулятор переведет всё в vw неверно. Так верстать не очень-то и удобно. Плюс на всех новых брейкпоинтах придется пересчитывать каждое значение в vw. Вероятность ошибиться и что-то упустить просто огромная. Поэтому на менторстве мы используем другой подход. Берем rem и специальный скрипт, который сам цепляет rem к ширине экрана. Что это дает: • сохраняется полная флюидность • все элементы зависят от ширины окна • мы работаем с нормальными значениями в rem • быстро переносим размеры из Фигмы без сломанных расчетов Вместе они дают идеальный флюид. Сайт тянется, а верстальщик не тратит часы на перепроверку математики 😎

Салют, друзья! 🤘 ⠀ Открываем седьмой урок бесплатного курса по Taptop. ⠀ На этот раз собираем блок FAQ. Урок получился объёмный, поэтому разбили его на 6 частей. ⠀ Внутри будет две зоны: аккордеон с вопросами и ответами, а ниже карточка UI-kit, которая появляется при скролле. ⠀ Сначала собираем основу раздела: сетку, декоративные линии, боковые колонки с буквами ГКВ и центральную часть под контент. ⠀ Дальше разбираем два подхода к аккордеону: сначала нативный виджет Accordion в Taptop, потом более гибкий вариант через div-структуру и CMS-коллекцию. ⠀ Отдельно настраиваем кастомный скрипт, чтобы аккордеон открывался плавно, стрелки работали аккуратно, а лишние элементы закрывались автоматически. ⠀ Во второй части блока собираем карточку UI-kit: верстаем изображение, текст, кнопку, добавляем маску и небольшой параллакс при скролле. ⠀ В финале адаптируем блок под планшет и мобильную версию, правим z-index, overlay-плашку и добавляем no-break скрипт, чтобы предлоги не висели в конце строки. ⠀ Новый урок уже доступен в боте: @Izum_Study_bot ⠀ Смотрите, пробуйте повторить и пишите в закрытую группу, если что-то непонятно или хочется обсудить ❤️

🔥 Начинаем большую перезагрузку IZUM.STUDY 🔥 Мы выросли из старого формата. Проект трансформируется в масштабную экосистему для разработчиков с глубокой базой знаний, библиотекой скриптов и профильным комьюнити. Под такие амбиции нам был нужен соответствующий стиль: смелый и узнаваемый. За брендинг отвечал Саша Лагута. Представлять его долго не нужно: сооснователь Dprofile, автор дизайн-клуба «Плюс к уровню» и абсолютный тяжеловес UI/UX (больше 90 наград на Behance и 50+ на Dprofile). Экспертиза железобетонная. Вместе с Сашей мы ушли в дерзкий гиковский стиль. Пиксель-арт, брутальная сетка, строгая типографика и кислотные акценты на 100% попадают в нужный вайб. Прямо сейчас на основе этого стиля мы вовсю пилим новый сайт IZUM.STUDY. А пока работа кипит, залетайте на Dprofile — там уже лежит большой кейс, где можно рассмотреть наш обновлённый визуал в макетах и на мерче. 🔗 Оценить проект: https://dprofile.ru/case/183324/izumstudy Что скажете по стилю? Как вам такой шаг в сторону диджитал-эстетики? Пишите в комменты 👇

👀 Когда дополнительные breakpoint’ы реально нужны? Есть ощущение, что чем больше разрешений в макете, тем лучше будет сайт. 1280, 1366, 1440, 1600, 1920, планшет, мобилка, маленькая мобилка — звучит так, будто «мы предусмотрели всё». На практике это не всегда так. Дополнительный breakpoint нужен не тогда, когда «давайте ещё одно состояние на всякий случай». Он нужен, когда на этом разрешении реально меняется поведение интерфейса. Например: • перестраивается сетка • меняется композиция блока • элементы ведут себя по‑другому • появляется другая логика меню • контент нужно распределить иначе • флюид уже не даёт нормальный результат Вот тогда отдельное состояние имеет смысл. Если же структура остаётся той же, элементы нормально тянутся, пропорции не разваливаются — новый breakpoint чаще всего просто добавляет работы. Потому что каждый breakpoint — это не красивый экран в Figma, а ещё одно состояние, которое нужно сверстать, проверить, поддерживать и не сломать при следующих правках. Другое дело, если, например, на 1920 у вас действительно другая композиция, более широкая сетка или дополнительные блоки. Тогда да, макет под это разрешение нужен. Верстальщик должен точно понимать, как сайт должен вести себя на больших экранах. По итогу: breakpoint добавляем не ради красоты в презентации, а под конкретную задачу. Если интерфейс меняется — отдельное состояние оправдано. Если всё просто аккуратно масштабируется — не плодим лишние. Меньше хаоса в макете, меньше костылей в вёрстке 😎

⚠️ Почему em может быть неудобен в отступах ⚠️ em — рабочая единица измерения. Но в отступах она часто ведёт себя неочевидно. em всегда зависит от размера шрифта конкретного элемента. Звучит безобидно, пока не начинаешь ставить отступы. Например, задаём margin 3em. У текста с font-size 16px получаем одно расстояние. У заголовка с font-size 56px те же 3em превращаются уже в совсем другой отступ. Технически всё верно. Но визуально начинается хаос: в настройках одно и то же значение, а на экране — разные расстояния. Чем больше текстовых стилей в проекте, тем сложнее держать систему под контролем. Особенно если хочется, чтобы отступы были предсказуемыми. 💡 В этот момент на сцену выходит rem rem не завязан на конкретный текст. Он зависит только от корневого элемента. Поэтому 3rem остаются понятным, стабильным значением для разных блоков. Отступ не прыгает только потому, что внутри другой размер шрифта. Это сильно упрощает жизнь в вёрстке: – не нужно каждый раз вспоминать, какой сейчас font-size у элемента – не нужно заворачивать текст в лишние обёртки ради «нормальных» отступов; – не нужно гадать, почему одинаковое число выглядит по-разному. По итогу: em полезен в своих задачах, но для базовых отступов в лендинге он может быть неудобен. Если нужна предсказуемая система размеров, rem обычно спокойнее. Меньше сюрпризов, меньше ручных правок и меньше ощущения, что отступы живут собственной жизнью 😎

Салют, друзья! 🤘 ⠀ Открываем шестой урок бесплатного курса по Taptop. ⠀ На этот раз собираем большой блок «Чеклист». Урок получился объёмный, поэтому разбили его на 5 частей. ⠀ Внутри будет 4 раздела, у каждого свой цвет фона, своя структура контента, а заголовки фиксируются, пока правая часть движется при скролле. ⠀ Первые два раздела собираем в более спокойной логике: заголовок фиксируется, а контент движется при скролле. ⠀ Дальше переходим к большим разделам, где контент выходит за пределы экрана и появляется из-под нижней пунктирной линии. Для этого отдельно собираем закрывающую плашку, настраиваем sticky, z-index, декоративные элементы и аккуратное перекрытие контента. ⠀ Отдельный важный момент урока — Custom Properties. Разбираем, где они помогают и как с ними работать. ⠀ В финале собираем навигационное меню внутри чеклиста: фиксируем его при скролле, добавляем переходы по якорям, активные состояния пунктов и небольшую анимацию со скобками. ⠀ Новый урок уже доступен в боте: @Izum_Study_bot ⠀ Смотрите, пробуйте повторить и пишите в закрытую группу, если что-то непонятно или хочется обсудить ❤️

👀 Perfect pixel или флюид? Perfect pixel звучит красиво. Взяли макет, перенесли всё пиксель в пиксель. Получили идеальное совпадение. Но есть нюанс. Сайт живёт не в одном размере экрана. У пользователей мониторы на 1280, 1366, 1440, 1600, 1920. Плюс куча промежуточных вариантов, планшеты, мобилки, разные браузеры и высоты окон. Если держать всё строго в пикселях, быстро вылезает проблема. На одном разрешении всё ровно, а на другом уже нужно отдельно править. И чем жёстче подход, тем больше состояний придётся собирать. Сначала делаем идеально на 1280. Потом отдельно на 1366. Потом на 1440, 1600 и 1920. Плюс планшет и мобильные версии. Так для одного лендинга набирается 10–12 состояний. И всё это только ради того, чтобы выглядело «как в макете». Флюидная вёрстка решает задачу иначе. Мы не прибиваем элементы к жёстким размерам. Мы задаём логику, по которой всё пропорционально меняется вместе с шириной экрана. Это не значит, что можно забыть про аккуратность. Наоборот. Флюид требует чёткого понимания: от какого разрешения строим базу, как всё масштабируется, где реально нужен breakpoint, а где он будет лишним. Зато сайт ведёт себя спокойнее. Он не скачет от одного жёсткого макета к другому. Не требует ручных правок на каждом промежуточном размере. И не превращает адаптив в бесконечный список исключений. Perfect pixel отлично работает там, где размер всегда фиксированный. Но сайты почти никогда не живут в одном размере. Поэтому для современных сайтов флюид удобнее. Это меньше ручной подгонки, минимум лишних breakpoint’ов и полный контроль над интерфейсом между экранами 😎

🧩 UI-kit не обязан быть огромной дизайн-системой Иногда кажется, что если мы говорим “UI-kit”, то там обязательно должна быть большая система: цвета, отступы, сетки, состояния, компоненты, правила, варианты, документация и ещё маленькая энциклопедия сверху. Но для небольшого лендинга это не всегда нужно. В простом проекте UI-kit может быть очень компактным. Главное, чтобы он помогал верстать быстрее и чище, а не превращался в отдельный проект внутри проекта. Обычно базово хватает нескольких вещей: • типографика • кнопки • ссылки Типографика нужна, чтобы не собирать каждый заголовок руками. Если у нас есть H1, H2, body, menu, number и другие текстовые стили, их лучше один раз настроить и дальше спокойно использовать по проекту. Кнопки и ссылки тоже лучше собрать заранее. Они повторяются в разных блоках, и даже если работать через классы, каждый раз собирать элемент с нуля всё равно отнимает время. Когда кнопки и ссылки лежат в UI-kit, ты всегда знаешь, где их взять и где внести правки, чтобы изменения отразились по всему макету в нужных местах. А вот огромную систему отступов, палитр и компонентов не всегда есть смысл делать заранее. Если проект небольшой, такая подготовка может не ускорить работу, а наоборот забрать лишнее время. Особенно если половина системы потом нигде не используется. Хороший UI-kit для лендинга — это не про “сделать побольше”. Это про “сделать то, что реально поможет в сборке”. Чтобы дальше не гадать, какой стиль применить. Не копировать элементы вручную из разных мест. Не чинить одинаковые кнопки по всему сайту. И не вспоминать через час, какой размер был у обычного текста. По итогу: UI-kit должен быть не большим, а полезным. Иногда несколько аккуратно собранных элементов дают больше порядка, чем огромная система, сделанная просто “чтобы была”.

Салют, друзья! 🤘 Открываем пятый урок бесплатного курса по Taptop. На этот раз собираем блок «Красные флаги». Это не обычный слайдер с кнопками или свайпом, а блок, который работает по скроллу. Урок разбили на 2 части. Сначала собираем статику: структуру блока, линии, декоративные квадратики, контентную часть, карточки и визуалы. Потом переходим к самому интересному: настраиваем и разбираем позиционирование sticky, отключаем pointer-events там, где это нужно, и собираем анимацию смены слайдов по скроллу. В итоге получается блок, который фиксируется на экране, а карточки, номера, заголовки и описания меняются во время движения страницы. Новый урок уже доступен в боте: @Izum_Study_bot Смотрите, пробуйте повторить за Андреем и пишите в закрытую группу, если что-то непонятно или хочется обсудить ❤️