Кэтрин Гонзалес несколько лет строила интерфейсы в продуктовых командах и в какой-то момент сформулировала, за что именно отвечает: «Я полностью владела тем, что мы выпускали. Меня волновал результат, а не дизайн-артефакт». То, что видит пользователь после деплоя, а не макет в Фигме с аккуратными спеками. Её должность, дизайн-инженер, до 2020 года формально не существовала.
На designengineer.io прямо сейчас висит 34+ вакансии. Figma, Raycast, Browser Company. Пять лет назад ни одна из этих компаний не искала человека с таким титулом.
Что случилось?
Шестьдесят артефактов и один вздох
Чтобы понять, откуда взялась эта роль, нужно посмотреть на процесс, который она ломает.
Допустим, ты дизайнер. Ты нарисовал экран, потом адаптацию под мобилку и планшет, потом hover-состояние, состояние загрузки, пустое состояние, ошибку. Всё это упаковал в Фигму с подробными спеками, расставил отступы, подписал токены, залинковал компоненты. Передал разработчику.
Разработчик открыл файл. Вздохнул. Начал воспроизводить увиденное в совершенно другой среде.
Джейсон Григсби, web-стратег и соучредитель Cloud Four, которого Джим Нильсен цитирует в серии The Case for Design Engineers, назвал этот процесс прямолинейно: «Худший из возможных миров. Водопадный процесс, генерирующий десятки артефактов, ни один из которых не отражает, как дизайн будет выглядеть и вести себя в браузере». Шестьдесят с лишним промежуточных файлов. И ни один не показывает, как интерфейс на самом деле ведёт себя в браузере.
Dev Mode в Фигме, Auto Layout, Variables — каждый релиз сужает зазор между макетом и кодом. Но между тем, кто придумывает, и тем, кто строит, всегда теряется нюанс: как ощущается hover, с какой скоростью скроллится лента, за сколько миллисекунд сворачивается панель. Вещи, которые невозможно описать в спеке.
Каждый фронтендер хотя бы раз получал макет, где кнопка при нажатии «плавно трансформируется в модальное окно». Как именно? С каким изингом? За сколько миллисекунд? Дизайнер нарисовал два состояния, «до» и «после». Всё, что между ними, те 300 миллисекунд, которые определяют ощущение от продукта, на усмотрение разработчика. У которого ещё 14 тикетов в спринте.
Результат: transition: all 0.3s ease. Дефолт.
Дизайн-инженер посмотрел на этот конвейер и отказался в нём участвовать. Один человек, который понимает и проблему, и код, и пиксели. Хендофф умирает не из принципа: просто оказалось, что один человек делает это точнее, чем двое с тикетом в Jira между ними.
Думать руками
В 2019 году Крис Койер, основатель CSS-Tricks и CodePen, опубликовал статью The Great Divide. Тезис: фронтенд раскололся надвое. Одни живут в CSS, думают пикселями, чувствуют отступы на уровне рефлексов. Другие пишут бизнес-логику на React, возятся с API и считают стили чем-то второстепенным. Дизайн-инжиниринг вырос на этом разломе — из людей, которые отказались выбирать сторону. Неслучайно создатели Tailwind, Адам Уотан и Стив Шогер, написали Refactoring UI — 218 страниц практических правил для тех, кто думает кодом, но хочет, чтобы результат перестал выглядеть как Bootstrap из коробки.
Шон Войсен руководит дизайн-инжинирингом в Adobe. Его формулировка: «Прототипирование это дизайн в коде» — полноценная среда для решений, а не промежуточный этап после макета.
Джим Нильсен в третьей части серии The Case for Design Engineers приводит аналогию с Кристофером Ноланом, который на съёмках «Тёмного рыцаря» дописывал сцены прямо на площадке, на ноутбуке. Некоторые решения рождаются только в контакте с материалом.
С интерфейсами та же история. Как элемент ведёт себя при ресайзе. Как данные из API ломают твой красивый лейаут, потому что у пользователя имя из 47 символов. Анимация, идеальная в After Effects, на реальном устройстве вызывает тошноту. Точные дизайн-решения приходят в контакте с браузером, не с макетом.
Мэгги Эпплтон, исследователь и дизайнер, бывший head of design в Expand.org, описывает рабочий цикл дизайн-инженера: «Они быстро итерируют, переключаясь между дизайн-исследованием, ресёрчем и живым кодом». Она собрала коллекцию практикующих дизайн-инженеров, почти у каждого личный сайт, который сам по себе дизайн-артефакт. Кастомный, с нестандартной навигацией, с анимациями, которых нет ни в одной UI-библиотеке. Сайт как рабочая тетрадь, одновременно демонстрация навыка и его тренировка.
Если дизайн-инженер думает руками и итерирует в коде, чем он отличается от хорошего фронтендера с развитым визуальным чутьём? Ответ в слове, которое всё чаще звучит в индустрии.
Слоп
Рафаэль Салажа, дизайн-инженер из Ирландии, поработавший в Warp, Family и AV Labs, автор userinterface.wiki. Его доклад The Rise of Design Engineering про вещь, которая в 2026 году звучит всё острее.
AI умеет генерировать интерфейсы — функциональные, аккуратные, работающие и абсолютно пустые внутри.
Салажа называет это слоп. Интерфейсный мусор. Технически ок, но без человека внутри. Никто не подумал, почему отступ 12, а не 16. Почему при наведении карточка приподнимается, а не просто меняет цвет. За каждым таким микрорешением стоит либо намерение, либо дефолт. Слоп целиком состоит из дефолтов.
Вкус и чутьё на микрорешения нельзя описать в промпте и нельзя вывести из данных, потому что вкус про намерение, а не про паттерн.
Попросите Cursor написать toast-уведомление — он выдаст border-radius: 8px, opacity-анимацию и стандартный shadow, всё правильно и всё по гайдлайнам, и всё это вы видели тысячу раз в тысяче разных продуктов. Дефолт до последнего пикселя.
Sonner — toast-библиотека Эмиля Ковальски, дизайн-инженера в Linear, автора animations.dev и десятков open-source UI-компонентов. 15 миллионов загрузок в неделю. Та же задача: показать уведомление. Но с сотней дизайн-решений под капотом. Spring-физика. Стекирование. Жест свайпа, который ощущается правильно. Каждое решение — выбор человека, а не среднее арифметическое из обучающей выборки.
AI генерирует «среднее по больнице». Вкус — это сознательное отклонение от среднего. Пока AI не научился хотеть, чтобы интерфейс ощущался определённым образом, этот зазор закрывают люди.
Четыре роли, одно название
Когда Figma ищет дизайн-инженера, она имеет в виду одно. Когда стартап из пяти человек — совсем другое. М.А. Байтас, исследователь в области HCI и дизайн-инженерии, разложил роль по контекстам, и получилось четыре совершенно разных работы.
В маркетинге это промо-сайты и визуальные истории — ближе к креативному разработчику, который делает продуктовые страницы уровня Apple со скролл-анимациями и WebGL. В продукте: дизайн-системы, UI-полиш, компонентная архитектура. В R&D — прототипирование новых взаимодействий, где 80% уходит в мусорку и это нормально. А в стартапе ты просто единственный, кто и дизайнит, и строит, потому что нанимать двоих дорого.
И внутри самого сообщества нет согласия, что первично. Байтас определяет дизайн-инженера как «инженера с дизайн-навыками». Войсен из Adobe смотрит с противоположной стороны: роль существует, чтобы «результат продуктовой разработки оставался верен дизайн-замыслу». Если дизайн-инженер — инженер, он сидит в инженерной команде и подчиняется CTO. Если служит дизайну — в дизайн-команде, отчитывается перед руководителем дизайна. От ответа зависят бюджет, метрики, карьерная лестница.
ZeroHeight провёл опрос: те же люди в разных компаниях называются Design Engineer, UX Engineer, Creative Technologist, Design Technologist — четыре титула на одну работу. Трис Мадфорд подмечает: «Мне нравится в названии Design Engineer то, что оно целиком сфокусировано на рукопожатии между двумя другими ролями». Название фиксирует связь, а не принадлежность.
Марсель, один из авторов коллекции, формулирует жёстче: «Будущее вычислений требует от дизайнеров писать код, чтобы поспевать за растущими требованиями к интерактивности». Дизайнерам приходится кодить. Или смириться с тем, что результат будет отличаться от замысла в каждом спринте, на каждом хендоффе.
Первые формальные команды дизайн-инженеров появились около 2020 года — в Shopify и GitHub. Тогда же InVision выпустил Design Engineering Handbook с кейсами из NYT, Mailchimp и Indeed — честный взгляд на роль до хайпа. К 2022 роль начала мелькать в вакансиях. К 2024 стала мейнстримом в продуктовых компаниях Кремниевой долины.
Произвольные штуки, которые мы придумали
Наталья Шелберн: «Роли — это произвольные штуки, которые мы сами придумали».
Когда-то кто-то решил, что люди, которые придумывают интерфейсы, и люди, которые их строят — это разные люди. Отделы, инструменты, язык, всё разное. Между ними процесс передачи, хендофф, который теряет половину смысла по дороге. Дэвид Лур, accessibility-инженер и автор блога о дизайн-системах, в The Origins of Design Engineering показал: разделение дизайна и разработки не закон природы. Организационное решение ради масштабирования. Решение, которое породило целую индустрию инструментов передачи макетов, от Zeplin до Figma Dev Mode.
Дизайн-инжиниринг — коррекция этой ошибки. Один человек вместо конвейера из двух специалистов с тикетами в Jira между ними.
Вопрос, которого нет в источниках: а что если дизайн-инженер это просто хороший фронтендер? Не новая роль, а сеньорный уровень, на котором ты и так чувствуешь дизайн?
Все источники «за» роль. Ни одного скептика. Ни одного «мы попробовали, не сработало». И ни одного кейса за пределами веб-продуктовки Кремниевой долины — ни мобильной разработки, ни энтерпрайза, ни рынков за пределами США и Европы.
Figma, Linear, Browser Company — компании, которые продают инструменты для дизайнеров и разработчиков. Конечно, им нужны дизайн-инженеры. Работает ли это в продуктовой команде из Берлина, Сингапура, Москвы? В аутсорс-конторе на 200 человек? В банке с легаси на jQuery?
Мнение Claude
Дизайн-инжиниринг — навык, за который платят. Компании нанимают, люди вроде Ковальски и Салажи доказывают ценность каждым проектом, кодом, а не манифестами. Но это не новая каста и не отдельная профессия. Это фронтенд, в котором искусственное деление на «думающих» и «делающих» перестало работать. Теперь за это платят отдельно.