Сначала был громкий тезис: «ИИ заменит дизайнеров». Потом пришел другой, помягче: мол, ничего он не заменит, наоборот — открыл возможности, дизайн теперь может больше. Звучит добрее, а врет сильнее.
«Может» — слово с лазейкой. Оно намекает на выбор: хочешь — берешь новые инструменты, не хочешь — работаешь как привык. Но выбора нет. Дело не в том, что кто-то работает хуже: если рядом коллега проходит тот же путь заметно быстрее, разрыв в скорости рано или поздно заметят — сначала команда, потом рынок. Вопрос только в том, когда это коснется вас.
Я продуктовый дизайнер в Cloud.ru, проектирую интерфейсы для ИИ-агентов. У нас в компании активно внедряют ИИ-инструменты в работу, и между дизайнерами принято делиться практиками — кто что попробовал, что зашло, что нет.
Эта статья из таких: показываю свой опыт. Недавно я с нуля собрал раздел проверки безопасности для одного из наших продуктов. Раньше задача в таком виде заняла бы у меня недели полторы — здесь я уложился в три рабочих дня до согласованного флоу макетов. Разберу по шагам, где ИИ сократил путь, а где встал намертво и заставил все объяснять руками. Если вы продуктовый дизайнер и пока приглядываетесь к этим инструментам со стороны — статья для вас.
Где терялось время раньше
Разработка фичи у продуктового дизайнера — это далеко не только макет в Figma. Сначала исследование: разбираешься в задаче, изучаешь, как ее решают другие. Потом аналитика и проработка логики: кто пользователь, каким путем он идет, какие экраны ему нужны. Дальше макеты. И только потом передача в разработку. Время уходило на каждом из этих шагов. А на сложных задачах при передаче в разработку еще и начиналась игра в испорченный телефон: что-то трактовали иначе, что-то упрощали. На простых обходилось — все зависело от того, насколько запутанный сценарий.
Раньше между «описал словами, что нужно» и «готовый работающий экран» стояла прослойка ручного труда: нарисовать статичные макеты, отдать в разработку, дождаться кода. LLM эту прослойку убрала. Инструменты вроде Cursor и Claude Code берут текстовый запрос и за несколько итераций возвращают кликабельный прототип. Не «делают все за тебя»: итераций хватает, и править их приходится. Плюс в другом — идею можно быстро визуализировать и проверить еще на старте обсуждения. Сразу показать живую логику и поймать тонкости, которые на статичной схеме не видны, вместо того, чтобы рисовать стрелочками гипотетический флоу. Поэтому Figma и переехала в конец процесса: раньше я собирал в ней первые макеты, теперь логику собираю с ИИ, а к Figma возвращаюсь на финале.
Задача: раздел оценки безопасности навыков с нуля
Пользователи у нас создают и хранят навыки (skills) для ИИ-агентов. Задача звучала коротко: спроектировать раздел оценки безопасности навыка. У пользователя есть понятная потребность — убедиться, что навык, который он подключает, безопасен. Валидировать его нужно по нескольким направлениям:
-
CVE (Common Vulnerabilities and Exposures, база известных уязвимостей) зависимых библиотек, инструментов и модулей;
-
статический анализ самого навыка и его зависимостей;
-
проверка через LLM-as-a-Judge (модель-судья как набор guardrails).
Оценка запускается вручную или автоматически после каждого изменения навыка и отвечает на один вопрос: безопасен ли навык для использования.
Сразу было понятно одно: любой сложный отчет нужно подать просто и читаемо — так, чтобы пользователь одним взглядом понимал, что происходит и насколько все серьезно. А как именно его устроить, на какие части резать и что выносить наверх, предстояло понять не из головы, а после ресерча.
Discovery (исследование): Perplexity, Claude и пользовательский путь вместо макета
Сначала мне надо было разобраться в теме: что такое оценка безопасности навыка, как она устроена, кто ее обычно проводит, какие решения уже есть и как это ложится на наш продукт. Искал через Perplexity, структурировал в Claude. Готовой документации под задачу почти не было — тема свежая и подходящую информацию приходилось собирать по крупицам. Ближе всего оказалась тема оценки самих агентов (Eval-агентов), от нее и отталкивался.
Из собранной структуры я набросал в FigJam пользовательский путь, чтобы взглянуть на раздел сверху, оценить масштаб и понять, какие экраны понадобятся. Ни одного макета на этом этапе еще не было, только текст и схема.
Всю эту работу: отобрать источники, отсеять мусор, перепроверить факты и уложить найденное в структуру, ИИ за меня не сделал. Нет волшебной кнопки: написал «найди лучшие примеры, как это реализовано» и получил готовый ответ — так не работает. У модели нет контекста вашего продукта, поэтому каждый вопрос, каждую гипотезу и каждую проверку я пропускал через себя. Помните тезис из начала: «дизайнеры больше не нужны, ИИ все сделает сам»? На discovery он и не сработал.
Cursor: почему я пишу промпты файлами
Оговорюсь сразу: просто диктовать Cursor запросы у меня не вышло. Запрос вида «сделай таблицу с такими-то колонками и мини-дашборд сверху» возвращает странную смесь несвязанных компонентов. Что-то он делает, но это что-то мимо.
Поэтому я развел правки по размеру. Мелочь вроде «подвинуть кнопку» или «поменять цвет плашки» правлю точечным промптом прямо в Cursor, так быстрее, чем расписывать файл. А крупное — новая логика раздела, новый экран, перестроить то, что вышло не так, как я ждал, — готовлю отдельным .md-файлом в Claude. Cursor читает его как полноценное техзадание: структура раздела, сущности, состояния, ограничения. После первого же .md-файла Cursor собрал связный флоу довольно серьезного раздела: реестр запусков проверки, детальная страница отчета, переходы между ними.
Чтобы собрать весь этот флоу короткими промптами и ручными описаниями, понадобилось бы куда больше времени, правок и токенов. Discovery и первый прототип вместе заняли один рабочий день. Прототип был далек от идеала, но это уже работающее решение, которое можно показать команде и предметно обсуждать. Кликабельная логика, а не статичная картинка.
Дальше — проверка. Я прогонял прототип через UX-тесты в Claude и Cursor с помощью скиллов. Проходил по сценарию, пусть и далекому от идеала, и задавал себе вопросы с позиции пользователя: что тут непонятно, где он застрянет, чего не хватает. Строил гипотезы, смотрел на результат, снова все структурировал. Итог проверки опять сворачивался в .md-файл и уходил в Cursor следующей итерацией.
Где ИИ не вывез
Теперь к проблемам, с которыми я столкнулся, без драматизации и приукрашивания.
Первое и главное. ИИ не вывозит бизнес-логику продукта. Он не знает, как у вас устроены сущности и их связи, какую задачу решает пользователь и почему один сценарий важнее другого. Дело не в уме модели — она не живет вашим продуктом. А продуктовый дизайнер живет: держит в голове контекст, историю решений, ограничения, метрики, по которым продукт двигают вперед. Вот здесь вас не заменит никакой ИИ, особенно на сложных, высоконагруженных продуктах, где половина логики держится на нюансах, которых нет ни в какой документации. Рамки и правила задаете вы даже в самых простых концептах.
Второе. Без точечного пояснения, как что-то оформить, ИИ тупит. Стоит не уточнить деталь — получаешь лишнюю колонку в таблице, не ту иконку, компоненты, слепленные без оглядки на логику раздела.
Третье, и для меня пока самое упрямое. Чистый UI на вайбкодинге у меня пока не получается. Я подключаю скиллы Cursor, чтобы он сверялся с переменными и токенами отступов из репозитория нашей дизайн-системы, прописываю в промпте конкретные компоненты из Storybook, и все равно вылезают артефакты: неравномерные отступы, поехавшая вертикальная типографика, кривые иконки. Важно: это не минус Cursor или ИИ. Это область, в которой мне еще расти, — я только учусь заставлять инструмент держаться дизайн-системы. Отсюда правило, которое сэкономит вам немало времени:
если цель не в том, чтобы выкатить готовый сервис с вылизанным UI, не тратьтесь на полировку. Соберите MVP, который фиксирует логику и понятен разработчику или респонденту на интервью. Этого хватит, чтобы объяснить кейс, собрать обратную связь и идти дальше.
Figma в конце: сборка на дизайн-системе
И здесь Figma вернулась в процесс финальным инструментом. Логика согласована на живом прототипе, спорные места отловлены, картина ясна. Осталось собрать чистовую версию: я работал на продуктовых компонентах нашей дизайн-системы и локальных компонентах продукта, из них финальный дизайн сложился быстро. С ним я и пошел на согласование.
Прототип на скриншотах выше кривоват, и это нормально: его работа закончилась в тот момент, когда команда согласовала логику. Финальные макеты я уже рисовал по готовому эскизу, а не вслепую — на паттернах и компонентах нашей дизайн-системы, чего мне пока не удалось добиться от Cursor. И это еще не финал-финал: задача комплексная, небольшие детали на макете еще могут измениться, но логика и форма уже согласованы.
Что по времени. Точного замера секундомером у меня нет. Раньше я бы сильно декомпозировал эту задачу на части и шел по ним по очереди — и, оглядываясь назад, думаю, что в том виде, в котором я сделал ее через ИИ, она в лучшем случае заняла бы полторы недели рабочего времени. Здесь от старта до согласованного первого варианта флоу макетов в дизайн-системе, с полным бизнес-сценарием, прошло три рабочих дня, из них discovery и первый прототип заняли один день. Цели покрыть все корнер-кейсы не было: они уйдут отдельными доработками поверх этой задачи.
И дело даже не в скорости самой по себе. Раньше отрисовка концепта отнимала время, потому что возишься с мелкой моторикой: даже если кнопка пока серый блок, ты все равно руками собираешь эти детали, экран за экраном. Здесь видишь раздел целиком и сразу отмечаешь, как на ревью, что поправить. Концепт становится тем, что можно сразу смотреть и обсуждать.
Почему без опыта это не повторить
Может показаться, что весь рецепт — «оформи подписку на пару ИИ-инструментов». Это не так. Я ни в коем случае не отдал свою работу на аутсорс искусственному интеллекту и не призываю к этому. Наоборот, показываю, как встроил эти инструменты в постоянную рабочую рутину и какой опыт из этого вынес. Инструменты у каждого могут быть свои — суть не в них. Рутина уходит к инструментам, а у меня освобождается фокус на дополнительные задачи. Но работает это только потому, что на каждом шаге решает не инструмент, а опыт.
В discovery опыт решает, какие вопросы задавать и каким источникам верить. Perplexity вернет что угодно; отличить релевантное от мусора может только тот, кто понимает домен.
В прототипе опыт решает, что писать в .md-файл: структуру раздела, сущности, состояния, разбивку отчета по секциям. Все это — ваше знание продукта: его особенностей, метрик, бизнес-процесса. Оно подсказывает, что искать, какой вопрос задать Perplexity, как уложить найденное в структуру, которую соберет Claude и которую вы отдадите в Cursor.
В проверке опыт решает, чему верить. ИИ одинаково уверенно выдает и дельные варианты, и ерунду. Если вы не можете провалидировать результат, вы не работаете с ИИ — вы подписываете не глядя. Тот самый оператор кнопки «Принять».
ИИ умножает то, что у вас уже есть. Есть опыт — он множится на скорость. Нет опыта — ноль остается нулем, просто быстрее.
Какие шаги у меня получились в итоге
Мой пайплайн, свернутый в порядок действий. Все это — только мой опыт, у вас он может быть другим. Пригодится, когда заходите в новую фичу или область, где еще предстоит разобраться.
-
Начните с исследования, но со своими вопросами. Поиск и сбор данных — Perplexity, структурирование — Claude. Здесь решает знание продукта: оно подсказывает, что искать и как верифицировать находки. Когда картина собрана, сформулируйте образ результата — какой раздел, для кого, на какой вопрос отвечает интерфейс. Фиксируйте все в файл, а не в памяти чата: токены заканчиваются, контекст теряется.
-
Постройте пользовательский путь (CJM). Схема маршрута пользователя (у меня — FigJam) показывает дыры в сценарии до того, как вы начнете рисовать экраны. Это не про пиксели, а про то, чтобы увидеть путь целиком.
-
Крупное только структурированным .md-файлом. Новая логика, новый экран, перестройка раздела — если диктовать это короткими запросами, Cursor вернет несвязанные компоненты. Файл-техзадание: структура экрана, сущности, состояния, запреты.
-
На прототипе не гонитесь за чистым UI. Его задача — зафиксировать логику и собрать обратную связь, отделку оставьте дизайн-системе на финале. А мелочь вроде цвета кнопки правьте точечным промптом прямо в Cursor — это быстро.
-
Проверяйте себя через ИИ, но не верьте на слово. Проходите сценарий с позиции пользователя, просите слабые места, альтернативы и риски. Найденное сворачивайте в следующий .md — это и есть итерация.
-
Figma — в конце. Финальная сборка на компонентах дизайн-системы по уже согласованному эскизу. Здесь правок про логику быть не должно — только про форму.
-
Ответственность за результат — ваша. Каждое решение, ушедшее на согласование, должно быть таким, которое вы можете защитить без ссылки на «так предложила модель».
Экспертиза не исчезла, а переехала
Вернемся к вопросу из заголовков, с которого все началось. ИИ не заменил меня ни в одной точке, где требовалось решение. Он заменил меня там, где требовалось время: поиск, структурирование, перевод описания в кликабельный прототип. Инструмент усилил меня, а не забрал мои функции себе — сработал напарником, который забрал рутину и оставил мне суждение.
Но кое-что изменилось, и делать вид, что нет, нечестно. Меняется не степень ответственности: за то, как решение работает, я отвечал и раньше — рисовал, вел, проверял на проде. Меняется сам финальный артефакт. Раньше это был статичный макет, который кто-то другой переводил в код. Теперь все чаще — живой прототип, рабочую логику которого можно потрогать еще до первой строки продакшен-кода. Дизайнер дотягивается дальше по стеку: не описывает, как должно работать, а показывает это работающим. Понимание фронтенда, работа с Git, умение собрать прототип своими руками — это уже часть базового набора дизайнера.
Вспомните, как дизайн-процесс расписывают в учебниках: Research, CustDev, CJM, User Story, UI Design, Test, Analyse, Develop, Release. Каждая стадия стоила времени — интервью, карты пути, гипотезы, макеты, прогоны. Связка инструментов это сжала: Perplexity, Claude, Cursor забрали рутину тех самых стадий — долгий ресерч, перекладывание структуры, ручную отрисовку концептов. Именно рутину, а не суждение. Слепо доверять их ответам нельзя — валидировать все равно вам. Поэтому экспертиза никуда не девается, она просто эволюционирует: профессия меняется вместе с инструментами, которыми работает.
ИИ не отменил профессию — он сдвинул ее центр тяжести. Решает по-прежнему человек.
Расскажите, как устроен ваш процесс: пробовали ли двигать прототипирование до Figma, на чем собираете логику и где ИИ подводил сильнее всего? Особенно интересен опыт тех, кто пытался заставить вайбкод держаться дизайн-системы, — у меня пока счет не в мою пользу.
Автор: e_shvlv
