Коротко
Процессы продуктового дизайна создавались в эпоху, когда узким местом был выпуск кода. Теперь, когда разработка ускорилась, сдерживающим фактором стал дизайн. Продуктовый дизайнер Виталий Хоменко выступает за новый рабочий процесс, в котором дизайнеры выпускают продукт быстрее, сочетая системное мышление с итерациями при поддержке ИИ, а передача в разработку происходит раньше, а не после долгой шлифовки.
По его собственным подсчётам, за плечами Виталия Хоменко более 250 клиентских проектов — как в агентстве, так и в штате компаний, — и он видел продуктовые команды изнутри. В этом материале он обосновывает необходимость нового рабочего процесса дизайна, созданного для эпохи ИИ, и объясняет, почему времени на адаптацию меньше, чем думает большинство основателей.
Последние десять лет любой разговор в стартапе о скорости рано или поздно сводился к разговору о разработке. Нанять больше разработчиков, урезать объём работ, выбрать более простой стек — почти всегда проблема была на стороне разработки. Виталий Хоменко, ведущий дизайнер Orizon Design и основатель Fluente LLC, утверждает, что это больше не так. И у него есть конкретное мнение о том, что командам следует делать вместо этого.
Взгляды Хоменко сформированы характером его опыта. Он работал и как внешний специалист, привлечённый для выполнения задач, и как штатный дизайнер, связывающий продукт, бренд и реализацию. По его словам, это позволяет ему видеть, где на самом деле возникают трения внутри продуктовых команд, а где — нет.
Он работал как с стартапами на ранней стадии, которые ищут свой первый визуальный язык, так и с известными брендами, управляющими сложными междисциплинарными дизайн-системами. Во всём этом диапазоне повторяются определённые закономерности. И та из них, которую в этом году стало невозможно игнорировать, привела его к выводу, меняющему его представление о том, как на самом деле должен быть устроен современный рабочий процесс дизайна.
Узкое место не исчезло. Оно сместилось. И рабочий процесс должен сместиться вместе с ним.
Что не так с тем, как сейчас работают дизайн-команды
Когда выпуск кода шёл медленно, существующий процесс дизайна был оправдан. Несколько раундов правок, пользовательское тестирование, итерации — всё это естественно вписывалось во временное окно, пока разработка догоняла. Теперь этого окна нет, а большинство процессов дизайна так и не были обновлены с учётом этого.
«Основатели просят дизайн-команды двигаться с той же скоростью, что и конвейер разработки с поддержкой ИИ, но дизайн не сжимается так же, как код», — говорит Хоменко. В итоге получается процесс, построенный вокруг ограничения, которого больше не существует, и применяемый к конвейеру, который вокруг него принципиально изменился.
Вынужденный выбор между качеством проработки и скоростью, с которым сейчас сталкиваются продуктовые команды, как концепция не нов. Новое — то, насколько остро он встал и насколько напрямую он связан с проблемой процесса, а не людей. «Поскольку разработка теперь дешёвая и быстрая, постоянно есть давление сразу же выпускать следующее, — объясняет он. — Но пользователей по-прежнему удерживают продукты, в которых детали были тщательно продуманы. Меньшее число раундов правок — это не улучшение процесса, если в результате вы выпускаете продукт с трениями, которых можно было избежать».
Хоменко наблюдал это в достаточном количестве команд и на достаточном количестве этапов, чтобы конкретно указать, где ломается существующий процесс. Проблема не в дизайнерском суждении. Она в том, где это суждение находится в процессе и в каком формате от него ждут результата в конце.
Почему передача макетов из Figma стала узким местом
Чтобы понять предлагаемое Хоменко решение, полезно точно разобраться, где буксует текущий процесс. В большинстве продуктовых команд финал дизайн-процесса выглядит так: дизайнер готовит в Figma отшлифованные, готовые к разработке экраны и передаёт файл разработчикам. Те интерпретируют экраны, переводят визуальные решения в код и строят продукт на этой основе.
Именно этот этап перевода — из файла Figma в работающий код — теперь и ломает конвейер. Разработка с поддержкой ИИ резко ускорила саму сборку. Но этап перевода не изменился. Инженеру по-прежнему нужно прочитать файл Figma, разобраться с отступами, извлечь ресурсы, принять решения о структуре компонентов и написать реализацию с нуля. Этот процесс занимает столько же времени, сколько и всегда.
«Ручной процесс внутри Figma просто не поспевает за разработкой, ускоренной ИИ, — говорит Хоменко. — Передача дизайна незаметно становится тем, чего все ждут».
В результате получается конвейер, в котором всё вокруг передачи ускорилось, а сама передача стала единственной точкой торможения. Иными словами, Figma создавалась для мира, где медленной частью была разработка. Она не была рассчитана на конвейер, где разработка движется со скоростью ИИ.
Решение: финальная поставка в коде, а не в Figma
В этом суть предложения Хоменко, и это более значительный структурный сдвиг, чем может показаться на первый взгляд.
В его процессе Figma не исчезает. Она смещается. Вместо того чтобы служить одновременно средой исследования и финальным артефактом поставки, Figma становится исключительно слоем визуального исследования: местом, где формируется айдентика бренда, прорабатывается логика компоновки и проверяется направление дизайна. Она остаётся правильным инструментом, чтобы понять, как что-то должно выглядеть и ощущаться.
Но финальная поставка — артефакт, который действительно уходит в разработку, — это код. А именно компоненты, собранные в подготовленные библиотеки, с которыми разработчики могут работать и масштабировать их напрямую, без какого-либо промежуточного этапа перевода.
Вся суть — в разнице в скорости реализации. Когда дизайнер передаёт библиотеку компонентов в коде, а не файл Figma, разработчикам не нужно ничего интерпретировать. Решения уже выражены на том языке, на котором они пишут. То, что раньше инженеру приходилось прочитать, интерпретировать и воссоздать по визуальному референсу, теперь приходит готовым к использованию. В конвейере, работающем на разработке с поддержкой ИИ, эта разница быстро накапливается.
«Figma по-прежнему правильное место, чтобы исследовать, как что-то должно выглядеть и ощущаться, — говорит Хоменко. — Но передать файл Figma и попросить разработчиков его реализовать — теперь это медленный путь. Поставка в коде — быстрый путь. В этом и состоит сдвиг».
Какой дизайнер для этого нужен
Для такого процесса нужен другой тип дизайнера, и Хоменко говорит об этом прямо. Превращение UI/UX-дизайнера в Design Engineer, по его оценке, — не отдалённая перспектива. Это вопрос времени, и команды, которые считают это делом будущего, а не текущей реальностью, скорее всего, и застрянут на этапе передачи.
Но Хоменко столь же чётко говорит и о том, чего этот сдвиг не означает. Поставка в коде — одна часть роли, а не вся роль. Полный цикл дизайна никуда не денется. Применение бренда к изображениям, создание анимаций, подготовка маркетинговых материалов — всё это остаётся важнейшими творческими задачами, требующими широкого и разнообразного инструментария далеко за пределами кода. «Дизайнер ближайшего будущего не просто генерирует код, — говорит он. — Он работает на всём цикле — бренд, моушн, маркетинг, продукт, — и дизайн-инжиниринг становится важной и растущей частью этого набора, а не его заменой».
Меняется то, что готовая к коду поставка становится ключевым ожиданием внутри этого набора. Дизайнер, который может свободно переходить от визуального исследования в Figma к поставке компонентов в коде, сохраняя при этом брендовое мышление, моушн и маркетинговую креативность, которые отличают продукты на том уровне, с которым пользователи реально взаимодействуют, — вот профиль, которого требует новый процесс.
Честно о текущем положении дел
Хоменко откровенно признаёт, что ни одна версия этого процесса пока полностью не стандартизирована. Каждая команда ищет свой путь. Инструменты развиваются, ожидания от передачи меняются, а процессы, которые команды выстраивают вокруг всего этого, существенно различаются. Готового сценария нет.
Поработав со многими командами на разных этапах и пережив несколько циклов смены инструментов, Хоменко говорит, что некоторые закономерности уже ясны, даже если детали ещё меняются. «Процесс каждой команды на этом этапе по-настоящему индивидуален, — говорит он. — Но некоторые общие черты того, как это будет выглядеть в ближайшем будущем, уже видны».
Эти закономерности неизменно указывают в одном направлении: дизайнерское суждение смещается на более ранние этапы, финальная поставка переходит в код, а роль дизайнера расширяется в техническом плане, оставаясь широкой в творческом. Конкретные инструменты и последовательности будут меняться и дальше. Но базовая логика процесса, который описывает Хоменко, уже формируется в командах, наиболее внимательно следящих за происходящим.
Что основателям стоит сделать уже сейчас
Для основателей и руководителей продуктов процесс, описываемый Хоменко, напрямую влияет на то, как комплектуются, финансируются и структурируются команды.
Переносите дизайнерское суждение в начало. Главный рычаг в новом процессе — не более быстрое исполнение, а более точная постановка задачи до начала генерации. Подключайте опытных дизайнеров раньше, когда они могут влиять на то, что будет создано, а не шлифовать уже сделанное.
Разделяйте исследование и поставку. Figma и этап визуального исследования служат иной цели, чем слой финальной поставки. Относитесь к ним как к отдельным этапам с разными ожиданиями, а не сводите их в один шаг, от которого ждут всего сразу.
Переводите ожидания от поставки в код. Будь то найм специалистов уровня Design Engineer, развитие этих навыков внутри команды или перестройка передачи — на выходе дизайн-конвейер должен давать результат в форме, с которой разработчики могут работать напрямую. Этап перевода — это место, где теряется время, и теперь это самая легко устранимая часть процесса.
Сохраняйте полный творческий набор. Дизайн-инжиниринг важен как никогда. Однако это не вся работа. Команды, сводящие дизайн к генерации кода, потеряют брендовое мышление, моушн и маркетинговую креативность, которые отличают продукты на том уровне, с которым пользователи реально взаимодействуют.
Сохраняйте гибкость. Процесс всё ещё формируется. Команды, которые закладывают жёсткость в свои процессы сейчас, в течение года будут переделывать эту работу. Правильно действуют те команды, которые закладывают в свои структуры достаточно адаптивности, чтобы впитать то, что ещё впереди.
«Передача макетов из Figma имела смысл, когда медленной частью была разработка, — говорит Хоменко. — Разработка больше не медленная часть. Поставка в коде — это не будущее процесса дизайна. Для внимательных команд это уже настоящее».
Виталий Хоменко — ведущий дизайнер Orizon Design и основатель Fluente LLC. Он работал со стартапами ранней стадии и известными брендами — как внешний специалист агентства и как штатный дизайнер.
Опубликовано 10 ноября 2026 - 23:00 Наверх
