Автоматизация правок в дизайне с помощью ИИ: что реально работает
Цикл правок — вот где настоящие затраты
Все говорят о времени на дизайн применительно к первому варианту. Приходит бриф, дизайнер исчезает на несколько дней, и вот уже презентуется концепция. Именно эту часть видят клиенты, и именно вокруг неё агентства строят смету. Но если вы достаточно долго вели студию или работали на фрилансе и реально считали часы, вы знаете: первый вариант — это редко то место, куда уходит время. Оно уходит во второй раунд, в третий, и в тот самый раунд «ещё одна маленькая правка», который почему-то занимает больше времени, чем первые три вместе взятые.
В большинстве клиентских проектов, с которыми я работал, правки съедают от трети до половины всех дизайнерских часов. Не потому что работа сложная, а потому что сам цикл устроен неэффективно: фидбэк приходит вразнобой — через почту, Slack, комментарии в Google Docs; кто-то должен перевести фразу «пусть это выглядит подороже» в конкретные изменения пикселей; дизайнер перерабатывает файл; файл уходит обратно; кто-то находит опечатку, которая была там с самого начала; и по кругу. Ничего из этого не является творческой работой в том смысле, в каком творчеством можно назвать питч концепции. Это перевод, согласование и механическое повторение — а именно такую работу ИИ-инструменты и должны выполнять хорошо.
Поэтому, когда агентства спрашивают, стоит ли им «использовать ИИ для правок в дизайне», мой ответ всегда один и тот же: вы уже это делаете, оформили вы это как процесс или нет, потому что половина вашей команды тихо вставляет фидбэк в ChatGPT, чтобы в нём разобраться. Реальный вопрос не в том, использовать ли ИИ в цикле правок. Вопрос в том, какие именно части этого цикла реально ускоряются, а какие лишь выглядят быстрее, незаметно делая всё хуже.
Это различие важнее, чем может показаться, потому что значительная часть разговоров об ИИ в дизайне сейчас трактует «автоматизацию» как один рычаг, который можно просто дёрнуть. Это не так. Некоторые задачи в рамках правок механические и чётко определённые — изменить размер под двенадцать рекламных форматов, заменить цветовой токен на сорока фреймах, сгенерировать alt-текст для всей библиотеки компонентов. С такими задачами ИИ справляется хорошо, стабильно и с минимальным контролем. Другие задачи, оформленные как механические запросы, на деле являются решениями, требующими вкуса — «сделай поярче», «дай мне варианты», «что-то здесь не так», — и от применения модели они быстрее не становятся. Они становятся шумнее.
Что ИИ реально ускоряет — а что нет
Полезно разделить работу над правками на два типа: трансформационные задачи и интерпретационные. Трансформационные задачи берут уже существующее, утверждённое решение и воспроизводят его по разным параметрам — размер, формат, язык, платформа, цветовая схема. Интерпретационные задачи берут неоднозначный человеческий фидбэк и превращают его в конкретное дизайнерское решение. ИИ прекрасно справляется с первой категорией и в лучшем случае посредственно, а в худшем — вредно работает со второй. Почти каждая история провала в духе «ИИ должен был ускорить нашу работу, но нет» в итоге сводится к тому, что кто-то использовал его для интерпретации вместо трансформации.
Вот где ускорение реально, из проектов, в которых я сам так работал:
- Адаптация под множество форматов. Как только герой-макет утверждён, генерация шестнадцати и более производных размеров для платной рекламной кампании — квадрат, сторис, лидерборд, скайскрейпер — раньше занимала полдня ручной работы на кампанию. Инструменты компоновки на базе ИИ, понимающие ограничения (сохранить защитное поле вокруг логотипа, держать текст внутри безопасных отступов), способны сделать первый проход по большинству этих форматов за считанные минуты, оставляя дизайнеру время на те три-четыре формата, которые действительно требуют переосмысления, а не все шестнадцать.
- Замена текста и локализация. Замена заголовков в десяти вариантах для A/B-теста или адаптация макета под язык, текст на котором на 30% длиннее, — это механическая работа по снижению рисков. Модель способна заметить, что немецкий текст вылезет за пределы кнопки, ещё до того, как человек откроет файл.
- Генерация редлайнов и документации для передачи разработчикам. Перевод готового файла Figma в спецификации по отступам, цветам и типографике для команды разработки раньше был отдельной полудневной задачей, которую делали нехотя прямо перед дедлайном. Теперь инструменты автоматического редлайнинга генерируют значительную часть этой документации прямо из файла — задача не исчезает, но исчезает утомительная часть переписывания вручную.
- Проверки на доступность и контраст. Автоматические проверки контраста, черновики alt-текста и флаги порядка фокуса до того, как дизайн уйдёт клиенту, отсекают целую категорию запросов на доработку — «юристы отметили проблему с доступностью» — ещё до того, как они превратятся в отдельный раунд. Это не ускорение раунда, а полное его устранение.
- Суммаризация длинных, хаотичных обсуждений фидбэка. Когда клиент пересылает сорок сообщений в Slack и три email-цепочки с «мыслями», модель, выдающая чистый список уникальных пунктов фидбэка ещё до того, как дизайнер всё это прочитает, реально экономит время — не потому что модель принимает дизайнерские решения, а потому что она выполняет сортировку.
А вот где это не помогает, как бы это ни преподносилось:
- Разрешение расплывчатого фидбэка. «Сделай подороже» — это не проблема промпта. Это разговор, который дизайнеру нужно провести с клиентом, чтобы выяснить, что «подороже» значит для него — более тёмная палитра, больше воздуха, конкретный конкурент, которым он восхищается, материальная метафора. Загрузка этой фразы в генератор изображений и показ клиенту шести вариантов не сокращает этот разговор. Он его откладывает и добавляет лишний раунд.
- Вкус и понимание бренда. ИИ-инструменты обучены на агрегированных паттернах. Они хорошо понимают, «как обычно выглядит современный лендинг SaaS-продукта», и плохо — «как должен выглядеть именно этот, отличающийся от других бренд, с его конкретной историей и конкретной конкурентной позицией». Правки, которые на самом деле касаются защиты узнаваемости бренда, требуют человека, впитавшего именно этот бренд, а не модель, впитавшую все бренды сразу.
- Проблемы согласования между стейкхолдерами, замаскированные под дизайнерские проблемы. Огромная доля «лишних» раундов правок вообще не связана с дизайном — это конфликт между вице-президентом по маркетингу и руководителем продукта, где файл с дизайном становится полем битвы. Никакое количество вариантов, сгенерированных ИИ, не решит проблему внутреннего несогласия на стороне клиента. Более того, больше вариантов — это просто больше боеприпасов для каждой из сторон внутреннего спора.
- Новые, нетипичные задачи по компоновке. Если бриф действительно новый — паттерн дашборда, который ещё никто толком не решал, взаимодействие, для которого нет сорока готовых примеров, — генеративные инструменты склонны скатываться к среднему по всему, что они видели, а это ровно противоположно тому, что нужно для нетипичной задачи.
Закономерность в обоих списках одна и та же: ИИ ускоряет правки, когда решение уже принято, а задача — воспроизвести или растиражировать это решение. Он замедляет процесс, или хотя бы не помогает, когда задача заключается в том, чтобы это решение впервые принять.
Ловушка: больше вариантов — не значит меньше раундов
Самая распространённая ошибка, которую я вижу — и на которую я бы в первую очередь обратил внимание руководителя любой студии, — это восприятие «генерировать больше вариантов быстрее» как самоцели. Это ощущается как автоматизация. Это выглядит как автоматизация в кейс-стади. Но более быстрая генерация вариантов не сокращает цикл правок; во многих случаях она его растягивает, потому что каждый новый вариант — это новое решение, которое кому-то нужно принять, а большинство клиентов не умеют быстро выбирать между шестью сгенерированными ИИ героями-картинками, не имея никакого фреймворка для их оценки.
Я наблюдал, как это проявилось в студии среднего размера, которая только что внедрила ИИ-инструмент для генерации изображений на этапе концепции. Там, где раньше они представляли два тщательно продуманных направления для героя лендинга — каждое с чёткой аргументацией, — они перешли к показу восемнадцати сгенерированных ИИ вариаций, «чтобы клиент мог выбрать то, что откликнется». Клиент не выбрал. Он не смог. Восемнадцать вариантов без выраженной позиции дизайнера читались как отсутствие у дизайнера собственного мнения — а именно для того, чтобы не формировать это мнение самостоятельно, клиенты и нанимают дизайнеров. В итоге проекту понадобился дополнительный полноценный раунд, чтобы вернуться к двум отобранным направлениям — именно туда, откуда дисциплинированный процесс должен был начинаться.
Коренная ошибка здесь — путать скорость генерации со скоростью принятия решения. У цикла правок есть узкое место, и это узкое место почти никогда не «как быстро мы можем произвести пиксели». Это «как быстро мы можем прийти к решению, с которым все согласны». Если ускорить производство пикселей в десять раз, оставив скорость принятия решений прежней, вы просто создадите в десять раз больше пикселей, лежащих в чьём-то инбоксе в ожидании того же самого медленного решения. Это не победа. Клиент часто воспринимает это как больше работы для себя, а не меньше для вас, и это подрывает то, что на самом деле оправдывает вашу ставку: способность принимать за клиента взвешенные, продуманные решения.
Есть и вторая, менее заметная версия этой ловушки, которая проявляется не в генерации концепций, а в сборе фидбэка. Команды настраивают ИИ-виджет для сбора фидбэка, позволяющий каждому стейкхолдеру со стороны клиента оставлять свободные комментарии прямо на живом прототипе. Это кажется эффективным — фидбэк поступает непрерывно, а не порциями по раундам. На практике это часто приводит к большему объёму фидбэка в целом, большему количеству противоречий в нём и отсутствию механизма для разрешения этих противоречий, потому что никто больше не отвечает за этап синтеза. Младший маркетолог и CMO могут оставить по пять комментариев каждый на одну и ту же кнопку, и теперь дизайнеру приходится разрешать спор, о существовании которого ни одна из сторон со стороны клиента даже не подозревает. Автоматизация сбора фидбэка без автоматизации или назначения ответственного за его синтез просто сдвигает узкое место на шаг ниже по потоку, делая его менее заметным.
Решение — не в том, чтобы избегать этих инструментов. А в том, чтобы осознанно выбирать их место в цикле. Инструменты генерации должны применяться до того, как выбран единственный отобранный вариант, внутри студии, как вспомогательное средство для размышления — а не перед клиентом в качестве реальной поверхности для принятия решения. Инструменты сбора фидбэка должны работать на этапе приёма и сортировки, сжимая шум в короткий список — а не как открытый, никем не регулируемый канал, умножающий число голосов, которые дизайнеру приходится удовлетворять по отдельности.
Арт-директор, с которым я работал вместе, после того проекта с лендингом сформулировал это прямо: «Мы не ускорили принятие решения. Мы просто создали больше поводов для него».
Процесс, который реально сокращает цикл
Если цель — меньше раундов и меньше времени на раунд, а не больше сырого вывода, процесс нужно выстраивать вокруг этой цели явно. Вот версия, которую я использую, адаптированная под несколько клиентских проектов, где ИИ выступает как инфраструктура, а не как творческий двигатель.
1. Структурированный приём фидбэка до того, как что-либо попадёт в файл с дизайном. Фидбэк не обрабатывается, пока он не нормализован в короткий, конкретный список. Это может быть простым общим документом с обязательным форматом: в чём проблема, где именно (экран/компонент), какое есть предложение по направлению, если оно есть, кто это поднимает. Если клиент вместо этого присылает неструктурированную простыню текста, это момент, чтобы прогнать её через суммаризацию, которая выделит отдельные пронумерованные пункты, а затем отправить этот список клиенту на тридцатисекундное подтверждение, прежде чем начинать работу над дизайном. Один этот шаг устраняет целую категорию впустую потраченных раундов: когда дизайнер отрабатывает семь пунктов, а клиент возвращается со словами «ах да, я ещё имел в виду вот тот восьмой пункт, который упомянул в третьем абзаце своего первого письма, и его пропустили».
2. Сразу разделять механические изменения и решения, требующие вкуса. Как только список готов, разделите его на две колонки. Механическое: изменить размер, цвет, отступы, исправить контраст, обновить текст, перегенерировать ассеты под новое соотношение сторон. Требующее решения: всё, что связано с иерархией, эмоциональным тоном, соответствием бренду или реальным разногласием по направлению. Направьте механическую колонку в любой автоматизированный инструмент, который справится с ней быстрее всего — пакетное изменение размеров, переключение тем на основе токенов в вашей дизайн-системе, автоматические сканеры доступности, — и пусть это работает параллельно, пока человек начинает со второй колонки. Именно в этой параллелизации кроется основная реальная экономия времени, а не в том, что какой-то отдельный инструмент «умнее».
3. Использовать генеративные инструменты как личное средство для поиска идей, а не как меню для клиента. Когда пункт из колонки «решение» требует нового исследования — например, клиент хочет «больше энергии» в дашборде, — вполне нормально приватно сгенерировать дюжину черновых направлений, чтобы сдвинуть с места собственное мышление. То, что в итоге уходит клиенту, должно по-прежнему оставаться двумя-тремя вариантами, отобранными человеком, каждый с короткой строкой обоснования, почему именно он отвечает на конкретный полученный фидбэк. ИИ-инструмент проделал здесь реальную работу — просто сделал это до того, как клиент это увидел, что прямо противоположно тому, как многие студии применяют его сейчас.
4. Автоматизировать передачу, а не решение. Как только правка утверждена, перевод её в спецификации, готовые для разработчиков, обновление документации компонентов и чек-листы для QA — это почти полностью механическая работа, которую стоит автоматизировать от начала до конца. Это применение ИИ-инструментов с самой высокой отдачей и самым низким риском во всём цикле, потому что здесь нет неоднозначности, которую нужно разрешать — дизайнерское решение уже принято, а задача — точно воспроизвести его в другом формате.
5. Проводить предварительную проверку до того, как раунд увидит клиент. Прежде чем любая правка уйдёт клиенту, прогоните её через автоматические проверки контраста, alt-текста и адаптивных брейкпоинтов. Обнаружить проблему с контрастом на этом этапе стоит пять минут. Обнаружить её после того, как её отметил юрист клиента или специалист по доступности, стоит целого раунда и, часто, удара по репутации — клиент начинает задаваться вопросом, что ещё было упущено.
Ничего из этого не требует экзотических инструментов. Почти всё это достижимо с помощью хорошо настроенного набора плагинов Figma, языковой модели для суммаризации, скриптованного пакетного процесса для вариаций форматов и команды, дисциплинированно понимающей, в какую колонку попадает та или иная задача. Дисциплина важнее выбора инструмента — я видел команды со скромным набором инструментов и строгими правилами процесса, которые работали быстрее команд с установленными всеми существующими ИИ-плагинами, но без правил о том, когда какой из них использовать.
Как сохранить доверие клиентов к автоматизации
Здесь есть измерение доверия, которое легко недооценить. Клиенты платят за точку зрения, а не просто за результат, и если они чувствуют, что ИИ незаметно принимает решения, за которые, как им казалось, они платят человеку, отношения портятся, даже если результат объективно хорош. У меня были клиенты, которые полушутя-полусерьёзно спрашивали, была ли конкретная правка сделана «роботом или вами». Честный ответ важен, и важно опередить этот вопрос прежде, чем он прозвучит с оттенком защитной подозрительности.
Практика, которая сработала для меня, проста: явно указывать — в заметках к результату работы или прямо в презентации — какие части правки были сгенерированы механически, а какие обдуманы. «Шесть платформенных кропов были сгенерированы автоматически из утверждённого десктопного макета» — это фраза, с которой клиенты обычно нормально воспринимают: звучит как грамотный процесс. «Мы использовали ИИ, чтобы проработать три новых направления для героя лендинга с учётом вашего фидбэка о тоне, и сузили их до этих двух» — это тоже нормально, потому что в конце названо решение, принятое человеком. Доверие подрывает именно молчание — когда работу, к которой прикасался ИИ, подают так, будто она создана точно так же, как всё остальное, а клиент позже узнаёт, обычно из питча конкурента или случайного комментария, что значительная часть «вашей» работы над правками была сгенерирована, а не создана вручную.
Такая прозрачность также приносит пользу на стороне фидбэка: она приучает клиентов давать более качественный ввод. Если клиент понимает, что изменение размеров и варианты текста были обработаны механически и быстро, он перестаёт относиться к каждому раунду правок как к одинаково ценному и начинает сосредотачивать внимание на решениях, которые действительно этого требуют. Я видел, как качество обратной связи от клиентов заметно улучшалось, как только команда начинала маркировать раунды таким образом — меньше комментариев по тому, что никогда не вызывало вопросов, больше сфокусированных комментариев по двум-трём реально открытым решениям.
Стоит также быть честным с клиентами относительно того, где ИИ-ассистированный приём фидбэка уместен, а где нет. Структурированная форма фидбэка с суммаризацией от ИИ хорошо работает для маркетинговой команды, дающей вводные по кампании. Она плохо работает для исполнительного спонсора, который хочет чувствовать, что его услышали лично, и воспринимает ответ в духе «ваш фидбэк был суммирован в следующие три пункта» как обезличенный. Умение считывать эту разницу — понимать, какому стейкхолдеру нужна эффективная версия процесса, а какому — версия с личным вниманием, — само по себе решение, требующее вкуса, и это ещё одна причина, по которой дизайнер или ведущий по аккаунту должен оставаться активно вовлечённым в то, как подаётся автоматизация, а не позволять инструментам молча работать в фоне.
Один клиент, руководитель продукта в SaaS-компании среднего размера, прямо сказал на стартовом звонке по редизайну: «Мне всё равно, трогал ли ИИ макеты. Мне важно понять, что вы действительно подумали о том, почему так».
Это разумная планка, и её полезно держать применительно к собственному процессу. Вопрос не в том, «коснулся ли этого ИИ», а в том, «есть ли ещё внятная, обоснованная причина за финальным выбором». Если дизайнер может объяснить, почему было выбрано именно это направление — даже если инструмент помог сгенерировать исходный материал, — отношения с клиентом остаются целостными. Если честный ответ — «модель выдала шесть вариантов, и мы выбрали тот, который никому не вызвал отторжения», — это проблема процесса, которую никакое раскрытие информации не исправит.
Как понять, что это действительно работает
Последний пункт, который большинство студий пропускает, — это измерение. Легко почувствовать, что процесс стал быстрее, потому что отдельные задачи видимо занимают меньше времени — изменение размера, которое раньше занимало двадцать минут, теперь занимает две. Но то, что на самом деле важно для маржи студии и терпения клиента, — это количество полных раундов правок на проект и общее время до финального утверждения, а они не улучшаются автоматически просто потому, что отдельные шаги стали быстрее.
Вот несколько показателей, которые стоит отслеживать — хотя бы неформально — на нескольких проектах до и после внедрения ИИ-инструментов в цикл правок:
- Количество раундов правок на проект. Не часы — раунды. Раунд, который занимает два часа, но провоцирует ещё один раунд из-за неправильно обработанного фидбэка, хуже, чем раунд, который занимает четыре часа, но закрывает вопрос.
- Время от получения фидбэка до сдачи правки, на каждый раунд. Это позволяет изолированно понять, действительно ли разделение на механическое и требующее решения сокращает срок выполнения, независимо от количества раундов.
- Соотношение механических часов и часов на решения. Примерно отслеживайте, сколько часов на проект уходит на трансформационные задачи, а сколько — на интерпретационные. Если автоматизация работает, это соотношение должно сдвигаться: меньше времени на механическую работу, столько же или больше — на решения, требующие вкуса, потому что именно там ценность и именно там должны концентрироваться оплачиваемые часы.
- Доля утверждения первого представленного варианта правки клиентом. Если клиенты стали чаще утверждать первый же раунд правок, чем раньше, — это сильный сигнал того, что процесс приёма и сортировки фидбэка работает: фидбэк интерпретируется правильно с первого раза, а не методом итеративного нащупывания.
- Доработки после передачи разработчикам. Отслеживайте, как часто команда разработки возвращает спецификации на уточнение после автоматизированной передачи. Если этот показатель растёт, значит автоматизация на стороне документации создаёт другой вид цикла правок дальше по потоку, что сводит на нет экономию, достигнутую раньше.
То, что вы хотите увидеть через несколько проектов: меньше общего числа раундов, примерно такое же или меньшее время на раунд, и сдвиг в том, куда уходят часы — от механического воспроизведения к той горстке реальных решений, которые изначально требовали человека. Чего вы не хотите видеть — и что сигнализирует о том, что студия попала в ловушку, описанную выше, — это больше сгенерированного вывода на раунд при том же или большем числе раундов. Это признак того, что инструменты используют для более быстрого производства, а не для более быстрого принятия решений, и стоит остановиться и заново проверить, в какую колонку — механическую или требующую решения — на самом деле попадает каждое применение ИИ.
Всё это не аргумент против использования ИИ в цикле правок. Это аргумент за точность в понимании того, для чего он нужен. Цикл правок медленный по вполне определённым причинам — неоднозначный фидбэк, механическая рутина, замаскированная под решения, слишком много стейкхолдеров при слишком малой степени их согласованности, документация, съедающая часы, не требуя при этом никакого вкуса. ИИ-инструменты действительно устраняют некоторые из этих причин. Для других они не делают ничего, а для некоторых — лишь ухудшают ситуацию при неосторожном применении. Студии и фрилансеры, которые реально возвращают себе время, — это не те, у кого больше всего ИИ-инструментов в арсенале. Это те, кто достаточно тщательно разобрал свой цикл правок, чтобы точно знать, какие его части никогда и не были сложными, и кто перестал тратить человеческий вкус и суждение на задачи, которые с самого начала были чисто механическими.
