🧱 Адаптивность не обязана держаться на брейкпоинтах

Amit Sheen пишет о проблеме, которую легко не замечать по привычке: мы всё ещё часто проектируем адаптивность от ширины экрана, хотя современные интерфейсы давно живут компонентами. Один и тот же блок может оказаться в ленте, сайдбаре, модалке, карточке дашборда или внутри другого компонента. В такой ситуации глобальный брейкпоинт часто отвечает не на тот вопрос. Вместо постоянных условий «если экран шире 768px, сделай так» автор предлагает начинать с более гибких решений в CSS. Сетка может сама набирать столько колонок, сколько помещается. Отступы и шрифты могут плавно меняться через clamp(). Компонент может смотреть на размер своего контейнера, а не всего окна. А медиазапросы лучше оставить для того, где они правда нужны: возможности устройства, наличие ховера, точность указателя, пользовательские настройки и режим отображения. Внутри: – Почему брейкпоинты хорошо работали для страниц, но хуже подходят для компонентных систем; – Как auto-fit и minmax() помогают строить сетки без ручного числа колонок; – Зачем использовать плавные значения вместо скачков между размерами; – Как clamp() заменяет несколько медиазапросов для шрифтов и отступов; – Почему контейнерные единицы полезнее ширины экрана для переиспользуемых компонентов; – Когда контейнерные запросы нужны для реального изменения структуры; – Почему медиазапросы не исчезают, а меняют роль; – Как такой подход делает адаптивный интерфейс проще для поддержки. ➡️ Читать статью ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Install

Забирайте 🔠 Mac OS 27 🔠 IOS 27 Вообще они одни из немногих, кто вот так открыто пушит все компоненты и прочее бесплатно и не просит ни рублика. Респект в общем ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Знакомая боль: просишь агента собрать экран по твоей ДС. На первый взгляд всё аккуратно. Потом смотришь ближе: компонент не из библиотеки, цвет левый, отступы странные, состояние придумано на ходу. И уже проще руками пересобрать, чем чинить за ним. С маленькой библиотекой это ещё можно пережить. В большой ДС начинается цирк: сотни компонентов, варианты, токены, состояния, правила. Команда годами всё это собирала, а агент ведёт себя так, будто открыл первый попавшийся файл и начал импровизировать. Без подготовки он просто угадывает. Ему нужно нормально объяснить систему: где компоненты, какие состояния существуют, какие правила важны, что брать в первую очередь. Иначе зрелая дизайн-система превращается для AI в красивую папку, которую он почти не понимает. 😇 24 июня в 18:00 мск Даниил Шишко из Pixel Perfect покажет, как это настроить. Возьмёт одну из самых больших публичных дизайн-систем, подключит её к агенту и соберёт экраны прямо на эфире. Тем, кто будет онлайн, Даниил отдаст скилл, который сканирует дизайн-систему и готовит её к работе с агентом. То есть можно будет взять свою ДС и повторить у себя. Если у вас агент тоже каждый раз «немного дизайнер» и тащит в макет свои компоненты, я бы посмотрел. AI-навыки уже всё чаще всплывают в вакансиях, и лучше разобраться с этим сейчас, пока все ещё пытаются понять, как оно вообще должно работать. 🔠 Эфир в канале 🔠 Эфир в канале

Install ️

Кейс NDA. Поэтому, увы, покажу вам бокал, но зато расскажу как это было и как можно получить действительно качественный результат. ⚡️ Дано: презентация pptx на 18 слайдов со сложными схемами. В некоторых схемах 3х-ступенчатый уровень вложенности (кто сталкивался — поймет КАК это больно верстать). 💥 Результат: лендинг на 18 экранов в Claude Design за 3(!) часа с сохранением контента, стиля компании, анимациями и интерактивными схемами 🏃‍♂️ Что получилось: — дословный перенос контента — сохранение фирменного стиля компании — сложные, многоэтажные, статичные схемы стали интерактивными. И это стало главным вау-эффектом для заказчика — спецэффекты без боли: анимации появления экранов и отдельных блоков, эффекты стекла и плавные переходы. 🥲 Главное в этом кейсе — это скорость и возможность повторить алгоритм на других презентациях. Напоминаю, эту красоту со сложнейшим контентом удалось сотворить (десктоп+моб версии) за 3(!) часа. По моему скромному мнению, это — невероятный результат. И наконец-то реальный кейс с эффективным использованием ИИ. Кстати, коллегам так зашло, что на встрече с заказчиком показывали именно лендинг, а не классическую статичную презентацию. 💥 Что нужно на вход, чтобы попробовать применить у себя: — собственно оформленная презентация, сохраненная в .pdf. Но если у вас совсем нет времени, то супер базовая верстка и отдельно прикрепить визуалы. 👀 Важный нюанс: все визуалы прикрепляю отдельными вложениями и прописываю на каком экране какой визуал должен быть. — UI-кит стиля компании. Причем я делала компонентами не так много вещей: палитру, типографику и плашки) Все! Никакие skills, референсы и специальные промпты не давали такого результата, как ui-кит и базово оформленная презентация. Пишите в комментариях, если будут вопросы по алгоритму действий 🙏

Скрин от моего технического директора, как он с ними общается (первая строчка текста на скрине) Нейронки применяем плотно уже больше полугода. Но важно использовать их с умом. Это когда хорошая дизайн-система, все разложено по компонентам и есть системная архитектура. Тогда нейронке легче делать новые компоненты на основе уже заложенного фундамента. Также важно не рассчитывать на нейронку и постоянно перепроверять ее. Потому что она дает много ошибок в первой, второй, третьей... итерации. И может довести до того, что хочется ударить по столу😅 ➡️ Делюсь внутрянкой, так как вчера поставили много сердечек, вижу вам интересно. Поставите еще – продолжу дальше. Кстати, Алексей, мой тех дир, говорит, что лучший критерий, заменит нейронка прогеров или нет, – это когда он перестанет на них ругаться матом.

После Апрока я устроилась в продуктовую команду, и наконец собрала кейс по одной из рабочих задач. Показываю, как в реальном продукте перерабатывала чат: от анализа и UX до компонентов и подготовки к разработке. Если интересно, чем занимается UX/UI в продукте после курса, заглядывайте) Буду рада вашей поддержке и лайкам ❤️ Beh

Команда дизайна и исследований Делимобиля собрала гайд по безопасным интерфейсам для сервисов, которыми могут пользоваться в машине. Это не только про карты и навигацию. Сюда же попадают звонки, музыка, заправки и любые сценарии, которые человек хотя бы теоретически может открыть во время движения. Важная рамка здесь простая: сначала нужно спросить не «как сделать удобнее», а «должен ли водитель вообще делать это за рулём». Если нет, функция должна уходить в режим стоянки или автоматизироваться. Если да, интерфейс проектируется по другим правилам: меньше действий, выше читаемость, крупнее цели, понятнее состояние, меньше визуального шума. На скорости 60 км/ч одна секунда взгляда в экран это уже 16 метров без полноценного внимания к дороге. Внутри: – Почему водительский интерфейс нельзя считать упрощённой версией мобильного приложения; – Как решить, можно ли вообще оставлять сценарий доступным во время движения; – Почему лучшая функция для водителя часто та, которая не требует действия; – Какие правила помогают оценивать читаемость, контраст, шрифты и анимации; – Что разрешено делать за рулём, а какие сценарии лучше блокировать до стоянки; – Из каких компонентов собирать безопасные экраны для машины; – Почему дизайн-решения здесь оцениваются не только по удобству, но и по риску отвлечения; – На какие стандарты опирается гайд: ГОСТ, ISO, NHTSA и Android Automotive. ➡️ Читать гайд ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Фигма выложила майский Workflow Lab про Code to Canvas. Если коротко: прототип, который вы собрали в коде через Cursor, Codex, Claude Code или другой агент, можно затащить обратно в Фигму как редактируемые экраны. Дальше уже смотреть флоу целиком, править компоненты, токены, состояния и при желании пушить изменения обратно в код. Сама связка «дизайн-код-дизайн» не новая. Интереснее другое. Последний год все очень радостно продавали вайбкодинг как короткий путь: написал промпт, получил интерфейс, запустил, погнал дальше. Типа Фигма больше не нужна, дизайнеры мешают скорости, агент сам всё соберёт. А потом выясняется, что быстро собранный экран всё равно надо где-то нормально посмотреть. Вайбкодинг быстро даёт экран, но плохо показывает продуктовый сценарий целиком В браузере ты видишь один экран. Иногда пару состояний, если не лень потыкать. В коде видишь компоненты, файлы, стили, условия. А продуктовый флоу целиком обычно расползается по вкладкам, роутам и «сейчас я тебе покажу, только сначала залогинюсь». Для разработки ок, для обсуждения интерфейса так себе. У меня так постоянно. Быстро сделал фичу, локально вроде работает, в голове всё ясно. Потом открываешь рядом несколько экранов и видишь: • кнопка называется иначе • пустое состояние забыто • фильтр ведёт себя странно • мобильная версия поехала • пользователь попадёт в тупик и будет смотреть на экран как на квест от плохого диза И всё. Твоя «почти готовая» фича уже не такая готовая В доке Фигма прямо описывает похожий сценарий. Агент берёт локальный прототип, переносит уникальные экраны на холст, использует компоненты и стили из дизайн-системы, добавляет страницу с саммари. Потом дизайнеры уже могут смотреть и чинить: где лишний элемент, где лучше взять нормальный компонент, где просела иерархия, где токены уехали итд Это хорошая роль для Фигмы. Она не обязана быть местом, где всё начинается. Иногда она может быть местом, куда продукт возвращается на проверку. Быстро накидали в коде, положили на холст, посмотрели весь сценарий, привели в чувство, отправили обратно в разработку. Тут, кстати, спор «фигма или код» становится совсем уставшим. В реальной работе чаще нужен круг: 1. быстро собрать рабочий вариант 2. увидеть весь флоу рядом 3. поправить продуктовую логику 4. вернуть изменения туда, где это реально живёт Главное, чтобы этот круг не превратился в новый ритуал ради ритуала. Типа сначала агент сделал экран, потом агент перенёс его в Фигму, потом агент поправил, потом агент вернул в код, а команда всё это время сидела и смотрела на красивую автоматизацию. Дизайнерское решение всё равно кто-то должен принять. Пока что, желательно человек. Что думаете? ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Карина Веласкес рассказывает историю не про то, как Claude Code «сам собрал дизайн-систему», а про то, как накопленное знание наконец получило быстрый способ материализоваться. На работе она не могла использовать Claude Code, сервер Фигма MCP и другие инструменты из-за политики безопасности, поэтому взяла личный ноутбук, пустой файл в Фигме и за один пятничный день собрала Prisme, личную дизайн-систему с токенами, темами, компонентами и плагином для синхронизации. Самое интересное здесь не скорость сама по себе, а то, почему эта скорость сработала. Карина уже понимала архитектуру токенов: где нужны глобальные значения, где живут брендовые темы, как должен работать семантический слой, почему алиасы важны и чем нативный формат переменных Фигмы отличается от Token Studio JSON. Claude Code не придумал это за неё. Он просто оказался достаточно быстрым исполнителем, чтобы описание превращалось в структуру, структуру можно было сразу проверить, а ошибки быстро поправить. Внутри: – Почему сильный результат с ИИ начинается не с промпта, а с внутренней модели; – Как Фигма MCP позволяет работать с переменными и токенами без ручного кликанья в интерфейсе; – Зачем дизайн-системе нужны глобальный, брендовый и семантический слои; – Почему токены, которые живут только в Фигме, остаются артефактом, а не инфраструктурой; – Как Prisme Bridge переводит данные между Token Studio JSON и переменными Фигмы; – Почему кнопка стала хорошей проверкой всей токенной архитектуры; – Как Claude Code помог собрать компонент с размерами, состояниями, вариантами и заменяемыми иконками; ➡️ Читать статью (EN) ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

📱Глянуть UI Kit📱 #uikit

Большая коллекция самых нужных бесплатных компонентов для вашего UI Install ️

Фигма 28 мая выкатила важный апдейт Make: теперь инструмент можно подключить к локальной кодовой базе. Открываешь существующий проект, выбираешь элемент на экране, правишь свойства, отступы, цвет, размер, раскладку, а агент уже находит нужное место в коде и вносит изменения. Пока это ограниченная бета в десктопном приложении для Mac. И сама Фигма честно пишет, что лучше всего это подойдёт дизайнерам, у которых уже есть доступ к кодовой базе компании. Раньше вайбкодинг в дизайне чаще был про быстрый черновик. Собрал экран, показал идею, выбросил половину, что-то утащил в работу. Вроде полезно, но всё равно чуть отдельно от настоящего продукта. А теперь Фигма Make пытается работать с тем местом, где продукт уже живёт. Самый важный вопрос теперь: кто имеет право двигать кнопку, если эта кнопка уже в коде? Потому что визуальная правка реального интерфейса звучит очень соблазнительно. Увидел, что отступ кривой, выбрал блок, поправил. Текст не тот, поменял. Цвет уехал, вернул. Не надо писать разработчику «можешь тут 8 пикселей вместо 12», ждать, объяснять, показывать скрин, потом снова смотреть, что получилось. Но чем ближе дизайнер подходит к коду, тем быстрее появляются взрослые вопросы: 1. кто проверяет такие изменения 2. что считается безопасной правкой 3. где начинается логика, а где просто внешний вид 4. кто отвечает, если агент поменял не тот компонент 5. как откатиться, если всё поехало Фигма это понимает, поэтому делает не «пуш в прод», а нормальный путь через разработку. Изменения сначала лежат как локальные коммиты. Можно создавать ветки, смотреть историю, откатываться, а потом открыть пулл-реквест, чтобы инженеры проверили правку как обычное изменение в коде. И это, по-моему, правильная часть новости. Не сам факт, что дизайнер может подвигать блок в живом проекте. А то, что Фигма пытается встроить это в нормальный процесс разработки. Через ветки, коммиты, проверку и возможность отката. Потому что без этого будет весело примерно два дня. Потом кто-то визуально поправит карточку, агент заденет общий компонент, уедет ещё десять экранов, разработчик откроет код и спросит, кто вообще это сделал. Но я бы не хотел, чтобы это стало режимом «дизайнеры теперь сами чинят фронт». Скорее это должно быть как быстрый слой для понятных UI-правок. Поправить отступ. Проверить состояние. Подкинуть вариант. Открыть пулл-реквест. Дальше уже обычная проверка. Ещё важная штука: Фигма разрешает копировать экраны из Make обратно на холст как слои, обсуждать с командой и потом приносить решения назад в код. Это уже похоже на нормальный круг: продукт живёт в коде, команда думает на холсте, изменения возвращаются через понятный процесс. Если Фигма сможет удержать этот круг без бардака, будет сильно. Потому что дизайнеру часто не нужен ещё один генератор красивого прототипа. А вот дизайн-ревью проводить и за качеством прода следить гуд, ибо разработчики лажают оч часто. ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Я никогда не любил работать с ДС и компонентами, особенно, когда АИ ещё не было в целом. Дизайн-система это такая штука, которая никогда не заканчивается. Сегодня добавили новый компонент, завтра поменяли состояние, потом где-то в продукте уже уехала версия, а в библиотеке всё ещё живёт старый вариант. И начинается обычная рутина. Проверить состояния. Сверить компоненты. Понять, что отстало от продакшна. Поправить в нескольких местах. Убедиться, что дизайнеры не разнесли всё по разным файлам. Работа важная, но максимально не самая весёлая) И вот это как раз очень похоже на задачу, которую можно отдавать AI-агенту. Не творческую часть, где надо думать головой, а именно поддержку порядка: сверять, находить расхождения, подтягивать правила, дополнять состояния, помогать не превращать ДС в свалку. Даниил из Pixel Perfect 3 июня в 18:00 мск покажет, как это работает на практике. Будет не учебный кейс, а живой AI SaaS-стартап для голосовых агентов. Он соберёт дизайн-систему через Claude Code и Figma MCP, а потом на её базе сверстает экраны продукта. 😎 Что будет полезного Покажет, как собирать ДС через Claude Code и Figma MCP, даст 4 скилла для Claude Code под сборку и поддержку своей дизайн-системы, и разберёт, какую рутину реально можно отдать агенту. Если работаете с дизайн-системами или просто устали руками вылавливать одни и те же расхождения залетайте посмотреть. Ща отставать уже не модно, нужно быть в трендах инструментов и снимать с себя кучу рутины ✨ Эфир пройдёт в канале, приходите Кстати, кто уже занимается ДС через клод, какой у вас пайплайн? Как работаете? 🔠 Подписаться на канал Даниила 🔠 Подписаться на канал Даниила 🔠 Подписаться на канал Даниила

Готовый UI Kit фитнесс приложения, компоненты которого вы можете взять за основу своего проекта. 📱Скачать UI Kit📱 #uikit

Теперь можно чекать цвета, компоненты и прочее на соответствие вашей ДС и стилей. Имба ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Install ️

Чел взял модули из Фигмы, подключил Claude Code через MCP и попробовал собрать из этого React-компоненты. Получилось, кстати, нормально: чистая структура файлов, аккуратный код, визуально близко к макету. Только перед этим он целый день объяснял Claude, что вообще происходит. Это опыт Росса Любе. Он не просто кинул макет агенту и получил готовый продукт. Сначала пришлось дать вводные по проекту, дизайну, сборке, компонентам и правилам. И вот после этого Claude Code смог выдать приличный результат. В этой истории хороша именно приземлённость. Без сказок про замену дизайнера и разработчика. Обычная рабочая реальность: агент может помочь, если ему нормально объяснить задачу. Примерно как с младшим разработчиком. Дал структуру, показал правила, потом проверил руками. Дал мутный макет и надежду на чудо, получил лотерею. С Фигмой тут тоже всё становится интереснее. Раньше неаккуратный файл мог жить годами. Дизайнер голосом объяснял, что имел в виду, разработчик сам догадывался, продакт что-то уточнял в чате. Все как-то вывозили. С агентами такой номер проходит хуже. Если в Фигме всё названо как попало, компоненты живут в трёх версиях, состояния забыты, а рядом лежит слой Rectangle 4827, агент просто ускорит бардак. Он быстрее соберёт не то и быстрее принесёт результат, который выглядит почти правильно. А «почти правильно» в интерфейсе иногда бесит сильнее, чем совсем плохо. Я в Hirehi, к слову. использую тоже связку, только не Claude, а Codex + MCP. Макет теперь собираю за минуту на фронте, потом остаётся чуть пофиксить и готово. Но и в Фигме там порядок) Долго я этого избегал, и очень-очень зря. Получается, что Фигма для агента уже не просто картинка. Ему нужны нормальные следы работы: 1. Понятные названия 2. Компоненты без хаоса 3. Состояния 4. Токены 5. Пояснения и ограничения Всё то, что раньше часто считалось скучной уборкой после дизайна. Теперь это становится входными данными для ИИ. Самый смешной момент в статье вообще про людей. Автор пишет, что мутная часть процесса всё равно остаётся до Фигмы и Claude: обсуждения, субъективщина, согласования, разное понимание задачи. Можно подключить хоть десять агентов, но если на созвоне все говорили разное и никто ничего не записал, агент просто красиво автоматизирует недосказанность. Claude Code + Фигма MCP проверяет не только силу ИИ. Он ещё показывает, насколько у команды всё прибрано до прихода агента. Что будет больнее для дизайнеров: научиться работать с агентами или впервые нормально прибраться в своих файлах? ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

• 130+ виджетов Install ️