Фигма выкатила агентов. Первое, что мы сделали, — это попросили покреативить на тему сайта забега RunIt (кстати, забег уже вот-вот, торопитесь!).

Получилось вот такое как на картинке. Ну что, дизайнеры, теперь то мы приплыли или ещё побарахтаемся?

Фигма выложила майский 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) ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Дилан Филд говорит о дизайне не как о финальной упаковке интерфейса, а как о новом рабочем слое между идеей, кодом и продуктом. В эпоху ИИ важнее становится не просто написать промпт, а уметь визуально управлять намерением: быстро пробовать варианты, смотреть на результат, отбрасывать лишнее и сходиться к решению. Главная мысль в том, что дизайнер не исчезает из процесса. Наоборот, его роль становится шире: нужен вкус, ремесло, точка зрения, понимание пользователей, умение работать с прототипами, кодом, агентами и обратной связью от реальных клиентов. ИИ может ускорить перебор вариантов, но выбор направления, качество решения и ответственность за продукт всё равно остаются за человеком. Внутри: – Почему «дизайн как новый код» не означает замену дизайнеров; – Как Фигма пытается соединить canvas, код, прототипы и продуктовую разработку; – Почему прямые визуальные манипуляции могут быть сильнее одних промптов; – Зачем дизайнерам и лидерам быстрее включаться в прототипирование; – Как агенты ИИ помогают исследовать варианты, но не принимают продуктовые решения; – Почему процесс разработки всё меньше похож на линейную цепочку; – Как слияние ролей может быть полезнее гиперспециализации; – Почему вкус, ремесло и точка зрения становятся важнее в эпоху доступных инструментов. ➡️ Смотреть видос (EN) ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Теперь переносить макеты из Figma в Zero Block можно практически в пару кликов, а главное — без ограничений по количеству импортов и независимо от вашего тарифа в Фигме. Для этого достаточно установить наш официальный плагин. О том, как работает новый импорт, рассказываем в карточках поста 👉 Подробная инструкция в Справочном центре: https://help-ru.tilda.cc/zero/figma-import 🎨 Плагин Figma to Tilda: https://www.figma.com/community/plugin/1641181103081348397/figma-to-tilda А вы ждали возможность импорта без лимита? Делитесь впечатлениями в комментариях! 💬 #tildaupdates

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

В этом разговоре Брайан Ловин из Ноушн очень точно описывает, куда вообще сдвигается роль дизайнера. Границы между дисциплинами размываются, и все меньше смысла делить работу на «это дизайн», «это код», «это продукт». Если хочешь влиять на результат, приходится понимать, как устроены инструменты, как думают инженеры, где заканчиваются возможности моделей и почему одни идеи в проде разваливаются, а другие нет. Самое важное здесь не в очередном наборе AI-инструментов. Главное, что дизайнеру теперь нужно уметь выходить за пределы макета: собирать прототипы в коде, разбираться в ограничениях Фигмы, понимать, как ИИ читает структуру интерфейса, и держать в голове не только красивую картинку, но и всю систему целиком. Не ради моды, а потому что иначе влияние на продукт быстро заканчивается. Внутри: – Почему дизайнеру уже недостаточно оставаться только в рамках интерфейсов; – Как в Notion прототипы все чаще уходят из Фигмы в рабочую кодовую базу; – Почему общение с инженерами стало частью нормального дизайн-процесса; – Зачем понимать реальные ограничения AI-моделей, а не фантазировать про их будущее; – Как хорошие примитивы, имена слоев и структура помогают ИИ работать точнее; – Почему доработка в IDE часто полезнее, чем бесконечные промпты; – Как непоследовательность ИИ одновременно ускоряет работу и создает хаос; – Почему способность глубоко сосредоточиться становится отдельным конкурентным преимуществом. ➡️ Смотреть видос (EN) ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

А ведь настоящие продуктовые проблемы часто скрываются на стыке команд. Между поиском и корзиной. Между онлайном и оффлайном. Между ожиданиями пользователя и реальностью бизнеса. Дизайнер, который долго работает внутри одной части продукта, часто перестаёт замечать эти проблемы. Что делать? 🔵Пользоваться собственным продуктом. Возможно в B2B/B2E сегментах это и не всегда возможно, но если мы имеем дело с B2C — грех не быть пользователям сервиса доставки, такси, почты или банка; 🔵Проектировать дизайн, учитывая все корнер кейсы, отражая в Фигме все состояния системы и условия поведения пользователя; 🔵Собирать кликабельный прототип и проходить его перед показом дизайна. Делать это можно и стандартными средствами Фигмы и с помощью ИИ; 🚤 И ещё кое-что. Устроившись в продукт я обычно рисую blueprint-схему работы продукта — она помогает не только вникнуть в процессы, попутно обнаруживая точки роста и проблемы продукта, но и познакомиться с большинством ключевых команд. Дизайнер, который видит весь end-to-end опыт ценнее того, кто знает только свой кусок продукта. 🌊🌊

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

#Уроки

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

Бонусом делюсь с вами новым дизайном Утопии. Кто-то надо мной угарал, что я делаю новую фигму. Теперь он не будет надо мной больше смеяться. Мы действительно делаем новую фигму в мире ИИ😂

Пока у команды нет общей структуры, каждый экран собирается заново: где-то основной текст 14 px, где-то 16 px, где-то межстрочный интервал выставлен руками, где-то тот же жирный стиль выглядит иначе. В макетах это еще терпимо, а в разработке быстро превращается в хаос. Олуватосин Обалана показывает практичный подход, как собрать типографику через примитивные и семантические токены и масштабировать ее на веб, планшет и мобильный в Фигме. Ценность статьи в том, что это не просто теория про читаемость, а пошаговая схема: как назвать токены, как разложить роли текста, как связать стили с переменными и переключать режимы без дублей. Внутри: – Какие принципы держат типографику в порядке: удобство, ясность, иерархия; – Какие базовые требования по доступности стоит заложить сразу: размер текста, контраст, межстрочный интервал, масштабирование; – Что такое примитивные токены и какие свойства туда выносить: семейство, вес, размер, межстрочный и межбуквенный интервалы; – Зачем нужны семантические токены и почему они снимают ручные правки по всему продукту; – Как назвать токены по иерархии, чтобы дизайнеры и разработчики говорили на одном языке; – Как разложить роли текста: Display, Heading, Subheading, Body, Caption, Label; – Как считать межстрочный интервал через коэффициенты для крупных и мелких размеров; – Как настроить в Фигме режимы для разных экранов и не плодить отдельные стили под каждый размер. ➡️ Читать статью ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

скоро глоуапнем название и аватарку по причине «новый сезон» — не пугайтесь и снимайте мьютики 👄 ⚪️ ai-сезон — 6 недель контента о том, как мы используем нейронки в команде. показали, как в соло доносить проект от макета до netlify, вайбкодить сайты, генерить гиперреалистичную кожу и собирать свои тулзы. выжали максимум — вам осталось просто взять и сделать ⚪️ зеленый сезон — полный бэкстейдж большого редизайна: рассказали как концептили, дизайнили, вайбкодили новую главную для зелёного банка и что такое web os. показали то, чего не видел даже клиент ⚪️ дизайн 360 — собрали для вас шоты с проектов прагматики. можно бесконечно скроллить, вдохновляться, чекать приёмы в своих проектах и расширять фан реф-базу ⚪️ неделя с мемами — рассказали, как податься на гражданство фигмы в связи с количеством проведенных в ней лет (мы пошутили) накиньте бустов, коллеги!

TechCrunch написал про Dessn. Это новый дизайн-инструмент, который поднял $6 млн и предлагает дизайнерам работать ближе к реальному продукту: запускать проект в облаке, подтягивать кодовую базу и менять интерфейс через ИИ. Кажется, что это опять очередной заход на тему «мы сейчас заменим Фигму». Но у Dessn фокус другой. Он полезен командам, у которых уже есть продукт, код, компоненты и рабочий интерфейс. Это не про генерацию с нуля как в Lovable или v0. У Dessn история приземлённее: быстро потрогать изменение там, где продукт уже живёт. В моих проектах этот разрыв всплывает постоянно. В макете всё чисто: нормальные имена, ровные карточки, аккуратные состояния, никаких внезапных ошибок. А потом открываешь прод, и там фамилия на 28 символов, картинка сломалась, тариф закончился, кнопка уехала, а бэкенд вернул что-то весёлое. Фигма в этом смысле прекрасная штука, но она очень легко превращает продукт в красивый симулятор продукта. Вроде всё выглядит убедительно, команда согласовала, можно идти дальше. А потом выясняется, что компонент так не умеет, данные приходят другие, состояние забыли, разработчик смотрит на макет и говорит: «ну это сложно сверстать». Dessn пытается сократить именно это расстояние. Сидеть отдельно в файле и представлять, как оно будет работать, уже мало. Хочется быстрее проверить идею на живом продукте. В таком сценарии пользы больше, чем в ещё одном генераторе красивых карточек. Хотя тут легко представить и обратную сторону. Если дать всем возможность быстро менять интерфейс через ИИ, в команде сразу начнётся спор за ответственность. Дизайнер поправил, разработчик не понял, продакт попросил ещё три варианта, кто-то на встрече сказал «а давайте попробуем», и вот уже продукт превращается в песочницу для идей. Поэтому без нормальных правил такое тоже быстро поедет. Основатели Dessn, кстати, не хотят делать связку с Фигмой. Считают, что это снова утащит команды от прода. Спорная мысль, но логика понятная. Они хотят строить инструмент вокруг места, где продукт уже работает, а идеальный макет остаётся в стороне. У них ещё в планах связки со Слаком и заметками со встреч. Типа обсудили что-то в команде, и из этого можно быстрее собрать прототип. С этим я пока осторожен, потому что «из созвона сразу в интерфейс» звучит красиво только до первого созвона, где все говорили разное и никто ничего не решил. В целом мне такие инструменты интереснее, чем очередные генераторы красивых карточек. Меньше вау на демке, зато ближе к реальной работе. Главное, чтобы это не превратилось в режим «каждый накидал по промпту, а потом разработка разгребает». Но мне нравится то, что щас все намекают дизам на то, что пора начать разбираться в коде) И скоро диз без этого навыка будет уже не так хорош. ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

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

Задолбала фигма??? Покажем как делать опупенную графику внутри привычного инструмента!!! 23 мая в 12:00 что будет??? - покажем эффекты и фишки Figma, которые можно применять не только в интерфейсах - разберём, как через простые инструменты находить неожиданные визуальные решения - соберём общий коллаборативный арт из работ участников кто научит??? Лёша Рябикин, графический дизайнер и музыкант. участник Саунд, графический дизайнер в Щёлочи и BetBoom. Благодаря эфиру вы получите: детальное понимание возможностей софта за пределами интерфейсного дизайна + готовый незаезженный приём для собственных проектов. регистрируйтесь, всего 10 мест 😳

Lovable за последние апдейты начал собирать вокруг себя что-то вроде продуктовой комнаты. Можно править интерфейс прямо в превью, оставлять комментарии на элементах, отправлять тред агенту, искать по истории чата, а в десктопном приложении подключать локальные MCP, чтобы агент видел контекст из Фигмы и других инструментов. По отдельности всё вроде мелочь. Комменты уже сто лет есть в Фигме. Визуальные правки есть почти в любом конструкторе. Поиск по истории вообще обычно замечаешь только после того, как он один раз спас тебе день. Но в сумме получается любопытная штука. Вайбкодинг перестаёт быть одиноким чатом, где ты сидишь и уговариваешь модель «ну сделай нормально, пожалуйста». Он начинает обрастать рабочими слоями: экран, обсуждение, история решений, контекст из соседних инструментов, правки по месту. Агент поменял кнопку. Через неделю команда пытается понять: это было решение, эксперимент или чей-то случайный промпт? Вот это для меня главный вопрос во всей истории. В hirehi такое и без агентов всплывает постоянно. Где-то идея лежит в Фигме, где-то обсуждение в чате, где-то правка уже в коде, где-то я сам себе написал «потом поправить» и, конечно, через неделю не помню, что именно хотел поправить. Если рядом появляется агент, который может реально менять интерфейс, бардак получает турборежим. Поэтому комментарии в превью тут важнее, чем кажутся. Продакт ткнул в конкретное место. Дизайнер поправил состояние. Агент получил задачу рядом с экраном. Разработчик хотя бы видит, откуда прилетела правка. Уже меньше шансов, что всё превратится в длинный промпт на 40 строк, где половина смысла живёт только в голове человека, который его писал. С историей чата похожая тема. Если приложение собирается через диалог, переписка становится частью продукта. Там лежат решения, компромиссы, откаты и странные моменты типа «вчера просили сделать ярче, сегодня срочно верните как было». Потерял историю, и потом продукт выглядит так, будто его собирали несколько людей, которые общались через стену. Десктопное приложение с локальным MCP добавляет ещё больше контекста. Агент может смотреть в Фигму и другие локальные штуки. В теории это прям хорошо, потому что он меньше угадывает. На практике появится новый вопрос: а что именно он прочитал? Макет? Старый файл? Обсуждение? Какой-то черновик, который вообще никто не хотел тащить в продукт? Вот тут Lovable может стать правда полезным, если не развалит ответственность. Потому что дать всем возможность быстро править интерфейс легко. Сложнее сделать так, чтобы команда понимала, кто что поменял, зачем поменял и почему это теперь считается нормальным решением. Такие апдейты мне ближе, чем очередной генератор приложения мечты за один запрос. Тут обычная продуктовая рутина: ткнуть в экран, обсудить, поправить, откатить, найти старое решение, передать агенту контекст. Скучнее для демки, зато намного ближе к реальной работе. ——— 💻 Курс по поиску работы 😍 Про дизайн 🔥 Вакансии дизайнерам 🎨 Референсы

Что такое WCAG 😗 и критерии уровня соответствия А, АА, ААА.