Заранее извиняюсь перед дизайнерами, которые сейчас будут кидаться в меня Figma‑файлами. Тема неприятная, но обсудить её надо.
Более 15 лет я являюсь Lead Product дизайнером в B2B‑командах. И все эти 15 лет в каждом проекте повторялся один и тот же ритуал: дизайнер рисует макет, разработчик смотрит на макет, разработчик делает похоже. Ключевое слово — «похоже».
Дальше начинается известный жанр. «А почему отступ 20, а не 24?» — «Ну там компонент такой». «А почему кнопка серая?» — «А это disabled из старой библиотеки, её никто не трогал с 2021». «А сделай как в макете» — «Так в макете нарисовано то, чего у нас в коде нет».
И вот что обидно: формально виноватых нет. Дизайнер нарисовал по дизайн‑системе. Разработчик собрал из компонентов. Просто дизайн‑система в Figma и дизайн‑система в коде — это два разных документа, которые расходятся тихо, годами, и никто не замечает, пока не начинаешь сверять по пикселям.
Как я вляпался
У меня был проект — SaaS с картами, довольно зрелый фронтенд на React. Я, как обычно, собирал макеты в Figma. Аккуратно, из компонентов, не из прямоугольников. Гордился собой.
А потом выяснилось, что аналитик в этой же команде давно делает по‑другому. Он взял форк фронтенда, поднял Storybook и собирает макеты прямо из настоящих React‑компонентов. Разработчик открывает такой макет и видит не картинку, а готовый JSX, который можно скопировать.
В его инструкции была фраза, от которой мне поплохело: «макет заменяет статичный фрейм в Figma».
То есть моя работа — это то, от чего он уходит.
Интересненько.
Первая мысль была неправильная
Первая мысль была: ну и ладно, пусть код‑макеты, дизайн больше не нужен, надо переучиваться.
Вторая мысль оказалась полезнее. Я сел и сравнил его цвета с моими токенами. Совпали. Все. Тот же синий #4350AF, те же варианты кнопок, та же шкала шрифтов.
Это не две дизайн‑системы. Это одна, просто в двух носителях. И проблема не в том, что кто‑то из нас лишний, а в том, что между носителями нет моста. Каждый ведёт свою копию правды.
У Figma для этого вообще‑то есть штатный механизм — Code Connect, он привязывает компонент в макете к компоненту в коде. Я обрадовался, полез — и упёрся в «нужен план Organization или Enterprise». У меня Professional. Спасибо, до свидания.
Ну ладно. Мост сделаем сами.
Мост
Идея простая до неприличия: завести файл, где для каждого компонента Figma написано, каким компонентом кода он является и как его свойства ложатся на пропсы. Обычный JSON, лежит в репозитории, версионируется.
И вот тут, когда я начал этот файл заполнять, полезло всё, что годами пряталось.
Кнопки. В Figma у меня был один монолитный компонент: Type × Size × State. Внутри Type лежало вперемешку: и Primary/Ghost (это варианты), и Link (а это, оказывается, вообще другой компонент в коде — легаси‑обёртка над MUI), и квадратные иконочные (а это третий компонент). Цвета не было как отдельной оси вообще, хотя в коде она есть.
Состояния. У меня были нарисованы Hover и Active как варианты компонента. В коде их нет и быть не может — это CSS‑псевдоклассы. Я годами рисовал сущности, которых в природе не существует.
Типографика. В Figma 13 текстовых стилей. В коде — 10. Три стиля я исправно применял в макетах, а разработчику приходилось каждый раз что‑то придумывать.
Знаете, что самое неприятное? Ни один разработчик мне за все эти годы про это не сказал. Они просто молча подставляли ближайшее похожее. И были правы — объяснять дизайнеру, что его дизайн‑система врёт, дороже, чем поставить body‑m-400 вместо несуществующего стиля.
Я пересобрал кнопку в Figma заново. Оси назвал ровно как пропсы в коде, значения — ровно как значения в коде, вплоть до регистра: variant, color, size, disabled. Получилось 54 варианта. Hover и Active выкинул. Теперь маппинг тождественный: что видишь в макете — то и пишется в коде, переводчик не нужен.
Что получилось в итоге
Пайплайн сейчас выглядит так.
Я собираю макет в Figma строго из компонентов. Не рисую, а именно собираю — ни одного отсоединённого инстанса, ни одного нарисованного руками прямоугольника, который «выглядит как инпут».
Дальше агент читает этот макет через MCP. Не картинку — структуру: какой компонент, в каком варианте, с каким текстом. По манифесту переводит это в реальные компоненты кода, лезет в репозиторий, читает их настоящие сигнатуры и собирает.stories.tsx.
Потом tsc. Ноль ошибок — значит, я в макете не наврал. Есть ошибки — значит, наврал, и мне это скажут через минуту, а не через две недели на код‑ревью.
Разработчик открывает Storybook и видит готовый JSX из тех же компонентов, которые он и так использует. Копипастит.
Скриншоты в этом процессе не участвуют вообще. Совсем. Это принципиально: как только в цепочке появляется картинка, кто‑то начинает угадывать.
Где нейронка налажала
Раз уж пошли откровения.
Она отрисовала кнопку «Reset to defaults», которой в макете не было. То есть была — но скрытая, отключённая. Агент увидел слой и вывел его. Пришлось отдельным правилом записывать: скрытое не рендерим.
Она вывела счётчики на вкладках, которых я тоже скрыл. Тот же баг, тот же корень.
Она полдня не могла победить горизонтальный скролл в модалке. Я в итоге сам открыл девтулзы и нашёл: у скроллбара стоит min‑width: 100%, а MUI‑шная сетка с отступами рендерится шириной calc(100% + N). Одно упирается в другое, вылезает полоса прокрутки. Агент до этого честно перебрал три неправильные гипотезы.
Она обернула вкладки в свой контейнер с рамкой — а компонент рисует рамку сам. Получилось две полоски.
Ну и половина интерфейса внезапно заговорила по‑русски, потому что в Storybook язык по умолчанию оказался не английский.
Это всё реальные косяки, и я их не прячу. Но обратите внимание на одну деталь: каждый из них я увидел за минуты. Не через месяц в продакшене, не от злого пользователя в поддержке. Потому что макет теперь компилируется и запускается.
Когда я отдавал разработчику картинку, у меня не было ни одного способа проверить, что он собрал именно то. Вообще ни одного. Я мог только смотреть глазами и сравнивать с макетом — то есть заниматься тем же угадыванием, только с другой стороны.
Так это про замену людей?
Нет. И вот здесь я, пожалуй, поясню подробнее.
Разработчиков этот пайплайн не заменяет. Он заменяет передачу макета — тот самый момент, где смысл терялся. Разработчик по‑прежнему пишет продукт, спорит со мной про UX, чинит то, что я собрал криво, и он же должен внести в код те правки, которые я у себя пометил комментарием «для разработчика».
Изменилось другое: теперь мы с разработчиком спорим о продукте, а не о том, чей документ считать правдой. Правда одна — код. Figma держит внешний вид, код держит структуру и поведение. Если они разошлись — это видно сразу, а не через полгода.
По итогу
В стартапах и малом бизнесе нейронки уже успешно заменяют дизайнеров, разработчиков и даже аналитиков. В общем‑то, и коперайтеров тоже.
Комментарии (16)
FurySeer
04.09.2026 10:10В насквозь сгенерированной статье извиняться за то, что спустя 15 лет лидства так и не сумели выстраивать процессы между 2-3 ролями - ну, тоже нужна смелость, конечно
В стартапах и малом бизнесе нейронки уже успешно заменяют дизайнеров, разработчиков и даже аналитиков. В общем-то, и коперайтеров тоже.
Это-то конечно от руки написали, коперайтеры, даже иишные тут не при чем :)
InsiderCrush
04.09.2026 10:10Автор ещё не поймал главный инсайт второго порядка: формально заменить человека ИИ уже можно, но реальные кейсы показывают, что производительность при попытке полной замены может не просто упасть, а упасть катастрофически. У него пока инсайт первого порядка — ИИ может кого-то заменить :) Не судите его строго :)
ntrox Автор
04.09.2026 10:10Ну, потестируем GPT-6 Astra, посмотрим ))) У меня нет цели заменить людей, конечно. Но ускорить узкие места - да. К примеру, на одном проекте мне удалось ускорить скорость передачи макетов фронтам с 1-2 недель до 1-2 дней. А на втором таки удалось давать фронтам сразу Storybook-шаблоны. При этом никого не уволили! Мне кажется какая-то польза тут есть.
InsiderCrush
04.09.2026 10:10Так на то они нам и придуманы, что бы облегчать, улучшать. При нашем контроле. Делюсь своим инсайтом - за любым кодом всегда обязан находится кто то, с кого можно спросить, на кого можно в суд подать, если что. На ллм в суд не подать. Значит крайний тот, кто взял ллм на работу :D
ntrox Автор
04.09.2026 10:10Я раньше очень сильно погружался в детали проектов, упуская очевидные вещи, есть такое )) В том числе и поэтому стараюсь строить разные системы с погружением глубже вайбкодинга. Статью дорабатывал с помощью ИИ - правда, но практика полностью моя.
olku
04.09.2026 10:10Если Figma не принципиальна, можно агенту дать указание на сборку экранов маппингом функционала на компоненты дизайн системы
ntrox Автор
04.09.2026 10:10Да, всё так. Есть только нюанс: у Figma есть функционал авто-маппинга компонентов через Figma Code. Но он доступен, блин, только на тарифе Organization. Поэтому пришлось сделать маппинг руками через манифест. И - да, дизайн-систему сначала кто-то должен сделать. Лучше в Фигме )))
Antar
04.09.2026 10:10Забавный кейс. Вы заменили дизайнеров, получили продукты, которыми, по вашим словам, невозможно пользоваться, и почему-то решили, что эксперимент подтвердил ненужность дизайнеров, а не необходимость посмотреть, что в это время делали оставшиеся разработчики…
Но ещё интереснее, что никаких показателей этих «ужасных продуктов» вы не приводите. Упала конверсия? Вырос churn? Просела выручка? Завалило поддержку? Пользователи перестали проходить ключевые сценарии? Или интерфейс просто не понравился вам?
Потому что «я посмотрел и пользоваться невозможно» — это не оценка продукта, а отзыв одного пользователя. Причём именно ради того, чтобы не принимать такие отзывы за истину, продуктовые команды и придумали аналитику.
Я видел прекрасные интерфейсы, которые не продавали ничего, и довольно страшные, которые годами приносили бизнесу деньги. Поэтому прежде чем хоронить профессию по результатам эксперимента, неплохо бы сначала показать результаты эксперимента.
Иначе из измеримых данных пока есть только количество уволенных дизайнеров.ntrox Автор
04.09.2026 10:10Чего? По моим словам "невозможно пользоваться"? Я что-то пропустил - ткните пожалуйста где это.
Вообще, задача была не заменить дизайнеров, а ускорить один процесс, где дизайн (по сути один и тот же) делался каждый раз заново. Я сократил этот процесс с 2-3 месяцев до 1-2 недель. Освободившееся время я инвестировал в ещё большую автоматизацию — теперь дизайнеры могут деливерить валидные .stories, которые синхронятся в обе стороны - и с дизайн-системой, и с компонентами в коде.
Никакой churn и выручка не могли просесть - я просто не отправил бы сырой дизайн и код в прод. Всё описанное в статье было сделано до прода. Сначала в песочнице, потом на стейдже и только потом на проде. Ну и любая аналитика и UX-решения, разумеется, принимаются ДО дизайна, до кода и, конечно, до автоматизации )))
Продукты показать не могу - там два NDA. Но могу обезличенно рассказывать про то, что сделал. Возможно кому-то будет полезно. А возможно, что кто-то тоже поделится своим опытом ))
С дизайном интерфейсов тоже интересная штука. Я этот "феномен" разбирал в другой статье про дизайн в B2B и пришёл к определённым логичным выводам. В B2B это работает именно так, да. Но это будет меняться.
proxy3d
04.09.2026 10:10Дизайн это все таки не про красивые интерфейсы. В 2000 была книга, Интерфейс. Основы проектирования взаимодействия» (в оригинале About Face: The Essentials of Interaction Design), авторами которой являются Алан Купер, Роберт Рейманн и Дэвид Кронин.
Так вот, там речь шла про простотой и интуитивно понятный интерфейс, который. Там было рассмотрен дизайн iPod, который взяли из радио устройства. Zoom интерфейс для больниц и много всего. Целью было, минимальный и интуитивно понятный.
Дизайнер, если мы говорим про профи, это тот кто может продумать такой интерфейс. В статье вы больше описали про художника и верстка, чем дизайнера. В свое время (сейчас не знаю), продавались специальные очки с камерами, которые следили за взглядом пользователя чтобы понять, якоря и проблемы. Профессиональный дизайнер выстраивает интерфейс опираясь на этот опыт. Нейронная сеть при проектировании опирается на множество готовых шаблонов, на которых обучалась. Так как у некоторых областях цена ошибки огромная. Там пригодился пример с тумблерами на критических объектах, их решении и правильных подписях.
Потому если нужно сделать лендинг, или простой сайт, то да. А если это интернет магазин, маркетплайс, мой сеть, или другой массовый продукт или массовый, то дизайн это огромная работа.
Для примера, последнее время на youtube стало много подкастов и видео про последние статьи из arxive, там сетки автомат генерируют текст и озвучивают и генерируют картинки и видео. Выглядит красочно и прикольно, но смотреть и слушать их просто нереально. Я обычно вижу в целом о чем видео, и затем лезу в статью и разбираю через сетку. И снова в статью, чтобы понять как получены результаты. Дизайн сгенерирован в таких видео, красивый, но ценность его 0.
Это напомнило мне эпоху gif, flash и java applet. Когда они появлялись, обычные сайты начали часто лепить эту красоту. Но ценность была нулевая. Некоторые порой из-за этого предпочитали отключать загрузку, чтобы просто почитать текст в целом.
Если мы говорим про посты в телеграмм или статьях, то там это ещё критичнее. Популистские картинки и схемы делает прекрасно. Хотя и за этим надо подчищать в Photoshop постоянно. Но вот серьезные схемы, там ж... полная.
Для примера, демонстрация выше. Нейрона такое не осилит. Все что сделает это красивый мусор. Но, некоторые части она генерирует неплохо, после их чистки можно вставить в итоговое.
Например, для изображения выше:
Некоторые фрагменты были нейронкой (пирамидка).
Большая часть, это рисуешь рисунок от руки и оцифровываешь сеткой и дальше Photoshop.
Другие важные элементы - чистый Photoshop.
То есть, когда одна простая идея на картинке, то сетка справиться, хотя может переусложнить и надо зачищать в Photoshop. Но если важны детали, то только сеткой не сделать.
Поэтому, если цель получить красивую картинку, то сетка ок.
Если цель получить информативную, понятную картинку, то сетка не справиться. Так косяков будет много, и править нужно дизайнеру или самому. В случае важного UX, тут должно быть понимание, как разместить правильно, а не красиво.
Ручная отрисовка схемы Простой пример схемы, где нейросети не справляются. Красиво рисуют - да, информативно и правильно - нет.
Revertis
04.09.2026 10:10Блин, я только на этом пассаже понял, что статья написана нейронкой :(
Это всё реальные косяки, и я их не прячу. Но обратите внимание на одну деталь: каждый из них я увидел за минуты. Не через месяц в продакшене, не от злого пользователя в поддержке. Потому что макет теперь компилируется и запускается.
InsiderCrush
Интересный подход, мне такие задачи инженерного уровня очень нравятся. Есть идея, попробую описать, может поймете о чем я. Можно ещё немного покопаться в сторону расширения обратной задачи. Не просто Figma - код, но и данные- визуализация- проверка. То есть ЛЛМка сначала получает исходные данные, сама выбирает подходящую форму инфографики, а затем отдельным шагом проверяет, что итоговая визуализация действительно соответствует исходным данным и ничего не искажает. Получается уже не просто генерация, а генерация с валидацией результата. А от дизайнеров реально прилетит за такой заголовок :D
ntrox Автор
Я изначально так и хотел — прям полную автоматизацию )) Но если менять вендоров, можно получить фоновые галлюцинации и упустить момент, когда весь пайплайн станет ошибочным. Пришлось работать с двухпетлевой системой (вроде так называется) - входная инфа летит в нейронку, она работает, присылает результат на проверку, человек правит, снова отправляет в нейронку. В теории, агентский кодинг должен это решить, но пока не вижу кардинальных подвижек ((
InsiderCrush
И это тоже решаемо в рамках одной сесси с ллм. Начните не с описания цели, а с описания мета уровня. Вы даете ей сначала контекст - Дружище Джипити (Джеминай, Кими), сначала пойми что я хочу (и описываете что), а затем уже конкретно ставите ей задачу - возьми, нарисуй, валидируй. Модели с размышлениями сейчас кушают легко такие 2 слоя)
ntrox Автор
Это да. Единственное, на одном проекте была внутренняя минимакс 2. Тупая, как пробка. Ну и я хотел что-то максимально понятное мне архитектурно. Поэтому пришлось через выхлопную трубу немного делать )))