Что ИИ до сих пор не умеет в дизайне (и почему это важно)
Разрыв между демо и дедлайном
Каждые несколько недель очередной ИИ-инструмент для дизайна выкладывает демо, которое выглядит как магия. Вводишь промпт — получаешь готовый экран. Напишите «онбординг для финтех-приложения, тёмная тема, минимализм» в Galileo AI или Uizard — и меньше чем за минуту получите что-то презентабельное. Я сам регулярно пользуюсь такими инструментами и пишу это не для того, чтобы их обесценить. Но между тем, что показывает демо, и тем, что нужно реальному проекту, есть разрыв — и именно в этом разрыве происходит бо́льшая часть моей настоящей работы.
Клиенты, которые следят за новостями об ИИ в дизайне, часто приходят на созвон с конкретным вопросом, спрятанным под вежливым. Вежливый вопрос звучит так: «что вы думаете об использовании ИИ в процессе?» Настоящий вопрос — «можно ли не платить за часть этой работы?» Это вполне справедливое сомнение. Часть работы действительно можно ускорить. Проработка вайрфреймов, варианты текстов, наборы иконок, даже черновые библиотеки компонентов — год назад это были часы ручного труда, теперь это минуты промптинга и отбора результатов. Это реально, и было бы враньём утверждать обратное.
Но те части проекта, которые на самом деле определяют, выйдет ли продукт в свет и будет ли он работать — то, за что клиенты платят, когда нанимают дизайнера вместо того, чтобы генерировать экраны самостоятельно — почти не затронуты всем этим. Эта статья о том, чтобы конкретно назвать эти части. Не в защитном духе «ИИ никогда не заменит человеческое творчество», а вполне практично — чтобы вы могли понять, что стоит автоматизировать, а на что по-прежнему нужно закладывать время реального человека в бюджете.
ИИ не знает ваш бизнес — и не может спросить
Каждое дизайн-решение, которое чего-то стоит, вытекает из бизнес-ограничения, которое нигде не записано в форме, доступной для чтения ИИ-моделью. Генеративный инструмент может выдать флоу оформления заказа, который следует всем правилам UX-best practices из обучающей выборки. Но он не знает, что ваш платёжный провайдер возвращает подтверждение вебхука через 11 секунд, а значит состояние «обработка» нужно проектировать под гораздо более долгое ожидание, чем это предполагает учебниковый чекаут. Он не знает, что в вашей службе поддержки три человека и каждый лишний экран настроек, который вы выпускаете, генерирует ещё два тикета в неделю. Он не знает, что стейкхолдер, подписывающий этот флоу, полтора года назад обжёгся на редизайне и теперь рефлекторно ветирует всё, что выглядит «слишком иначе».
Ничего из этого не написано в брифе. Это всплывает в разговорах, в те пятнадцать минут после официальной встречи, в сообщении в Slack, отправленном в 11 вечера, в том, как меняется лицо основателя, когда вы показываете версию, технически более удачную, но эмоционально неправильную для бренда, который он строил пять лет. Это не какая-то мистическая «человеческая интуиция» — это просто накопленный, неструктурированный контекст, который живёт в головах людей и в их отношениях, и ни одна модель не имеет к нему доступа, потому что его никогда никто не записал, чтобы на нём можно было обучиться.
Я начал думать об этом как о настоящем продукте дизайнерской работы: не экраны, а перевод неупорядоченной, наполовину невысказанной бизнес-реальности в согласованный набор решений. ИИ чрезвычайно хорош в последней миле этого процесса — превращении решения в пиксели — и полностью отсутствует в первых девяноста процентах, то есть в том, чтобы понять, каким это решение должно быть. Если дать ИИ-инструменту бриф без этого контекста, он уверенно выдаст что-то правдоподобное и неверное. Опасность в том, что «правдоподобное» звучит достаточно убедительно, чтобы это одобрил тот, кто не знает, какие вопросы нужно задавать.
ИИ не может провести дискавери — только заполнить его форму
Дискавери — это не форма для заполнения. Это серия разговоров, которые меняют направление в зависимости от того, что раскрыл предыдущий ответ. Хорошая дискавери-сессия с клиентом выглядит примерно так: вы спрашиваете, зачем им дашборд, они отвечают «чтобы пользователи видели свои данные», вы спрашиваете, какое решение пользователь принимает после того, как увидел эти данные, и клиент замолкает — потому что на самом деле никогда не задумывался об этом так конкретно. Эта пауза — самый ценный момент во всём проекте. Именно тогда пишется настоящий бриф, обычно противоречащий тому, что клиент прислал изначально.
ИИ-инструменты прекрасно генерируют артефакты дискавери — персоны, обзоры конкурентов, матрицы фич, даже правдоподобно звучащие вопросы для интервью с пользователями. Чего они не умеют — замечать, что ответ стейкхолдера противоречит тому, что он сказал десять минут назад, и использовать это противоречие, чтобы открыть настоящий разговор. Они не умеют считывать атмосферу в комнате, когда владелец продукта и руководитель маркетинга расходятся во мнении о том, что значит «успех» для фичи, и мягко вывести это разногласие на поверхность до того, как оно превратится в конфликт спустя три спринта разработки. Суммаризатор транскриптов скажет вам, что было сказано в интервью с пользователем. Он не скажет, что тон пользователя изменился в тот момент, когда вы спросили о цене, или что он ответил на совершенно другой вопрос, потому что настоящий вопрос вызвал у него дискомфорт.
В прошлом году я проводил дискавери-фазу для B2B-платформы логистики, где клиент письменно, три раза подряд настаивал, что приоритет — «современный, чистый интерфейс». Через два воркшопа стало ясно, что настоящая проблема в том, что диспетчеры вводят одни и те же данные в четыре разных экрана, потому что существующие инструменты не связаны между собой. Интерфейс не был уродливым. Он был вполне нормальным. Им нужна была информационная архитектура, устраняющая дублирование ввода, а запрос «современный, чистый интерфейс» был лишь заменой фразы «здесь что-то сломано, а у меня нет слов, чтобы объяснить, что именно». Ни один промпт не вывел бы это на поверхность. Потребовалось две личные встречи и много терпеливых, слегка неудобных вопросов.
Если вы оцениваете, стоит ли сократить дискавери с помощью ИИ-сгенерированных отчётов по исследованию, честный тест такой: может ли этот отчёт противоречить сам себе так, чтобы раскрыть настоящую проблему? Если инструмент выдаёт только внутренне непротиворечивые, аккуратные документы, это не дискавери — это бумажная работа, которая выглядит как дискавери, а бумажная работа не поймает проблему диспетчеров.
ИИ не может сидеть в комнате, где спорят о компромиссах
Любой реальный проект рано или поздно упирается в момент, когда две законные цели вступают в конфликт и кто-то должен сделать выбор. Стоит ли просить платёжные данные в онбординге до того, как пользователь увидит ценность продукта, или после? Стоит ли на странице настроек делать акцент на опытных пользователях или на тех 80%, кто никогда не трогает продвинутые опции? Стоит ли использовать фирменный яркий цвет бренда в кнопке призыва к действию, даже если именно этот оттенок не проходит по контрасту? Это не дизайн-задачи с единственным правильным ответом, лежащим где-то в датасете. Это переговоры между отделами с разными интересами — рост хочет первое, поддержка хочет второе, бренд хочет третье — и настоящая работа дизайнера в этой комнате не «знать правильный ответ», а провести решение, на которое команда действительно согласится и о котором потом не будет тихо жалеть.
ИИ-инструмент может сгенерировать варианты. Он может даже сгенерировать разумно звучащие аргументы за каждый из них, если правильно попросить. Чего он не может — почувствовать, что руководитель роста только что получил неприятную цифру на совете директоров и теперь ведёт переговоры из страха, а не из данных, или что возражение руководителя поддержки по похожему вопросу два месяца назад так и не было по-настоящему решено и теперь всплывает здесь под другим соусом. Он не может нарастить политический капитал, который проведёт по-настоящему лучшее, но непопулярное решение через комнату. Этот капитал нарабатывается месяцами, когда ты оказываешься прав в маленьких, проверяемых вещах, и это одна из настоящих причин, по которым клиенты продолжают платить внешнему дизайнеру, а не пропускают каждое решение через внутренний ИИ-процесс: кто-то заслуживающий доверия должен взять на себя рекомендацию и быть готовым защищать её на встрече, где замешаны эмоции.
«Нам не нужен был кто-то, кто генерирует ещё больше вариантов. Нам был нужен тот, кто примет решение и объяснит почему — так, чтобы отдел продаж принял это без трёхнедельного спора».
Это почти дословная цитата от продакт-лида, с которым я работал над редизайном SaaS-продукта, и это самая точная формулировка того, что клиенты на самом деле покупают, нанимая дизайнера для чего-то большего, чем просто производство. Генерировать варианты теперь дёшево. Взять на себя ответственность за компромисс и защищать его под давлением — нет, и я не вижу правдоподобного пути, по которому это скоро изменится, потому что это не проблема данных — это проблема доверия и ответственности.
ИИ не может построить дизайн-систему, которая переживёт столкновение с реальным продуктом
Дизайн-системы со стороны выглядят как ровно та структурированная, основанная на правилах задача, в которой ИИ должен быть особенно хорош: определи токены, определи компоненты, сгенерируй варианты — готово. И инструменты действительно стали по-настоящему полезны в механической части: генерация шкалы отступов, цветовых градаций с изначально доступным контрастом, каркасов состояний компонентов, которые иначе пришлось бы собирать вручную. Я использую ИИ именно для этого почти в каждом проекте, и это экономит реальные часы.
Проблемы начинаются с управления системой — а это и есть настоящая сложная часть дизайн-системы, и та часть, которую никто не показывает в демо-видео. Дизайн-система — это не библиотека компонентов, это набор решений о том, что делать, когда реальность не вписывается в систему. Что делать, если конкретной продуктовой команде нужна таблица с закреплёнными столбцами, а компонент таблицы в вашей системе для этого не проектировался? Расширить систему, форкнуть компонент или отклонить запрос? У кого есть полномочия принимать это решение, и как удержать сорок дизайнеров и разработчиков из шести команд от того, чтобы они тихо разошлись каждый в свою сторону три спринта спустя, потому что санкционированный ответ пришёл слишком поздно?
Это организационная задача, переодетая в костюм интерфейса. Она требует знать, какая команда игнорирует документацию, какой разработчик от отчаяния соберёт разовый компонент, если тикет провисит слишком долго, какой стейкхолдер использует «система этого не поддерживает» как отговорку, чтобы сорвать запуск, к которому он и не был особо расположен. ИИ может поддерживать красиво задокументированную библиотеку в Figma. Он не может поддерживать общественный договор, из-за которого сорок человек реально ей пользуются, а не обходят её стороной. Я видел, как дизайн-системы проваливались — дорого, после месяцев инвестиций — не потому что компоненты были плохо сделаны, а потому что никто не взял на себя проблему внедрения, а это проблема людей, которую не решить никаким улучшением инструментов.
Если хотите подробнее разобраться, как это проявляется конкретно в процессах на базе Figma, я уже писал о том, почему большинство дизайн-систем умирают из-за проблем с внедрением, а не из-за плохой архитектуры, и эта закономерность сохраняется независимо от того, как были сгенерированы компоненты.
ИИ нельзя привлечь к ответственности — и это меняет то, что ему можно доверить решать
Это наименее обсуждаемое ограничение и, вероятно, самое важное для тех, кто сейчас принимает решение о найме или процессе. Когда дизайнер утверждает флоу, и после релиза выясняется проблема с юзабилити, стоящая клиенту денег — есть человек, с которым можно это обсудить. Он может объяснить свою логику, может ошибиться так, что ошибку разберут и извлекут урок, может потерять доверие клиента — и это имеет последствия, которые формируют то, насколько внимательно он будет работать в следующий раз. Ответственность — это не механизм наказания, это информационная система: именно так организации узнают, что пошло не так, и корректируют, кому какие решения можно доверять в будущем.
Решения, сгенерированные ИИ, не несут этого сигнала. Если сгенерированный флоу приводит к падению конверсии, не с кем сесть и спросить «на что вы ориентировались, принимая это решение?» — потому что решения в осмысленном смысле не было, был статистически вероятный результат на основе паттернов в обучающих данных. Это нормально для низких ставок, легко обратимых решений — цвет кнопки, стиль иконки, заглушка-иллюстрация. Но это серьёзный риск для решений, которые дорого отменять: информационная архитектура, формирующая понимание всего продукта, модель прав доступа в корпоративном инструменте, состояния ошибок в медицинском или финансовом приложении, где неверное решение имеет реальные последствия для реального человека по ту сторону экрана.
Именно поэтому «при поддержке ИИ» и «под ответственностью ИИ» должны оставаться разными категориями в том, как вы формируете бриф и бюджет проекта. Вполне разумно попросить ИИ сгенерировать десять вариантов иллюстрации для пустого состояния и дать человеку выбрать и доработать лучший — человек сохраняет ответственность за решение, даже если труд был делегирован. Совсем другое дело — выпустить сгенерированный флоу в продакшн без человека, который может объяснить и защитить каждый значимый выбор в нём, потому что когда — не «если», а именно когда — что-то в нём окажется неправильным, кто-то должен быть способен объяснить, почему это произошло и что изменится в результате. Клиенты, пропускающие этот шаг, не экономят деньги — они откладывают расходы и убирают механизм, который поймал бы проблему на раннем этапе.
Где ИИ по-настоящему заслуживает своего места в процессе
Всё вышесказанное — не аргумент в пользу игнорирования этих инструментов, и я бы оказал плохую услугу собственным клиентам, если бы делал вид иначе. Честный способ думать об этом такой: ИИ научился очень хорошо сокращать дистанцию между идеей и её видимым черновиком, и это по-настоящему ценно — просто это никогда не было той частью работы, которая была узким местом для компетентного дизайнера. Узкое место никогда не звучало как «как быстро я могу сделать экран». Оно всегда звучало как «откуда мне знать, что это правильный экран». Вот примерно как я на самом деле использую эти инструменты в повседневной работе — и где я осознанно провёл черту:
- Дивергентный поиск, а не финальные решения. Я могу за минуты сгенерировать десяток вариантов раскладки для лендинга, чтобы преодолеть проблему «пустого холста», а затем отбросить большинство из них, как только лучше пойму реальные ограничения клиента. Результат — отправная точка для суждения, а не замена ему.
- Скорость производства на чётко определённых задачах. Как только паттерн утверждён — карточка, состояние формы, пустое состояние — инструменты с ИИ внутри Figma и редакторов кода реально сокращают время производства вариантов и адаптивных состояний. Здесь окупаемость наиболее очевидна и наименее спорна.
- Черновой текст и структура контента. Дойти от нуля до черновика текстов онбординга или сообщений об ошибках быстрее с ИИ, но каждая строка всё равно редактируется под реальный голос бренда и реальные сценарии сбоев, потому что именно в общих формулировках в состоянии ошибки из продукта тихо утекает доверие пользователя.
- Синтез исследований с человеческой проверкой на противоречия. Суммаризация десяти интервью с пользователями — по-настоящему полезная задача для ИИ. Но я всё равно сначала сам читаю сырые транскрипты, потому что резюме сглаживает именно те противоречия и запинки, в которых обычно и содержится настоящий инсайт.
- Проверка доступности и контраста как базовый уровень, а не финишная черта. Автоматические проверки надёжно ловят механические ошибки. Они не ловят опыт использования скринридера, который технически соответствует нормам, но всё равно сбивает с толку — это по-прежнему требует человека, который реально им воспользуется.
Закономерность во всём этом такова: ИИ прекрасен внутри уже принятого решения и ненадёжен в принятии самого решения. Собственно, в этом различии вся статья. Каждое по-настоящему полезное применение выше вытекает из выбора, который сделал человек — о направлении, тоне, приоритете или риске. Уберите человека, принимающего этот выбор, и инструмент не провалится громко — он провалится тихо, выдав что-то правдоподобное, что никто на самом деле не сверил с реальными ограничениями бизнеса, а правдоподобное-но-неверное гораздо дороже поймать после запуска, чем до него.
Для агентств и студий, встраивающих ИИ в свой процесс, практический вывод такой: явно прописывайте в предложении и таймлайне, какие результаты работы — это ускоренное ИИ производство, а какие по-прежнему принципиально основаны на человеческом суждении, и оценивайте и укомплектовывайте их по-разному, вместо того чтобы позволить фразе «мы теперь используем ИИ» тихо стать оправданием для недостаточного ресурса на стороне суждения. Для клиентов, выбирающих дизайнера или студию, полезный вопрос — не «используете ли вы ИИ-инструменты» (сейчас так делает почти каждый компетентный специалист), а «расскажите о решении в недавнем проекте, где сгенерированный ИИ вариант оказался неверным, и как вы это поймали». Если конкретного ответа нет, значит либо эти инструменты используются не всерьёз, либо результат их работы не проверяется всерьёз — и то, и другое должно настораживать больше, чем более медленный, традиционный процесс.
Подробнее о том, как этот сдвиг меняет разговоры о ценообразовании с клиентами, я писал в отдельной статье о том, за что на самом деле стоит брать деньги теперь, когда ИИ сжимает время производства, потому что вопрос об инструментах и вопрос о ценообразовании на деле оказываются одним и тем же вопросом в разных обличьях: вы платите не за экраны — вы никогда по-настоящему не платили за них — вы платите за то, чтобы кто-то был прав насчёт того, какими эти экраны должны быть, и нёс за это ответственность, когда окажется неправ.
