ИИ для интерфейсов: что он делает вместо проектирования
Каждый месяц выходит сервис, который обещает «сгенерировать интерфейс по описанию». Я смотрю на них и вижу одно и то же: они хорошо собирают типовое и не умеют проектировать. Это не разочарование в технологии — это описание того, где именно она стоит.
Тезис
Проектирование интерфейса — это не рисование экранов. Это череда решений: что здесь главное, чем можно пожертвовать, как система поведёт себя в неудобном случае, кто отвечает за то, что получилось. Ни одного из этих решений модель принять не может, потому что у неё нет ни контекста продукта, ни права на решение.
Нейросеть не проектирует интерфейсы. Она снимает рутину вокруг проектирования — и это меняет профессию сильнее, чем если бы она рисовала экраны.
Дальше — почему я так считаю и где, по-моему, проходит граница.
Аргументы
Проектирование — это выбор, а не рисование
Когда дизайнер садится за макет, восемь десятых работы происходит до первого прямоугольника: понять задачу, договориться о границах, представить, что случится при пустых данных, при ошибке, при отмене, при плохой связи. Экран — уже следствие этих договорённостей.
Модель видит только формулировку, которую вы ей дали. Она не знает, что в вашем продукте есть легаси-ограничение, что отдел поддержки ненавидит модальные окна и что в прошлом квартале похожее решение откатили. Проектирование без этого контекста превращается в угадывание — иногда удачное, но всегда случайное.
Модель сильна там, где правило можно записать
А вот вокруг проектирования лежит большой слой работы, которая правилам подчиняется: разложить согласованный сценарий на состояния, размножить экран по вариантам, проверить соответствие компонентам и отступам, подготовить подписи и тексты ошибок. Здесь модель работает быстро и предсказуемо, потому что ей есть на что опираться.
Модель хорошо делает то, что можно описать правилом. Всё, что описывается плохо, она делает уверенно и неверно.
За пределами правил начинается выдумка
Как только модель выходит за формализованную часть, начинаются три типовые ошибки. Она придумывает паттерны, которых в продукте нет: красивые, но чужие. Она игнорирует домен: интерфейс для врача и для курьера получит одинаковую вежливую нейтральность. И она воспроизводит популярное решение вместо подходящего — потому что училась на среднем по интернету.
Заметьте: это не «модель плохая». Это следствие того, что её просят сделать то, для чего у неё нет входных данных.
Что меняется в самой работе
Меньше рисования — больше постановки задачи и проверки. Дизайнер всё чаще формулирует, что должно получиться, и всё реже двигает прямоугольники: черновик приходит готовым, а дальше начинается содержательная часть — принять, переписать, отклонить.
Дизайнер становится постановщиком и редактором. Это другая профессия, чем «человек, который красиво рисует макеты», и она сложнее.
Возражения
«Но генерация экранов уже работает»
Работает — внутри дизайн-системы и по уже принятым решениям. Это сборка, а не проектирование: модель разворачивает то, что вы описали, и не спорит с вами о границах. Полезно, быстро, экономит дни. Но если описание неверное, генерация просто быстрее приведёт вас к неверному результату.
«Значит, дизайнеров станет меньше»
Изменится состав работы, а не количество людей. Рутинная часть — размножение состояний, подготовка текстов, сверка с каноном — сжимается. Освободившееся время уходит не в отпуск, а в разбор решений: то, что раньше откладывалось на потом, потому что руки не доходили.
«Модель заменит джунов»
Скорее поднимет планку входа. Раньше junior учился на рутине: рисовал состояния, правил отступы, собирал макеты по чужим решениям — и постепенно начинал понимать логику. Если эту ступень забирает модель, входить в профессию придётся сразу через понимание задачи. Это не плохо и не хорошо, это новая реальность, к которой пока никто не придумал учебную программу.
Что из этого следует
Три следствия, которые я вижу в своей практике.
Канон важнее инструмента. Если правила, компоненты и антипаттерны не записаны, модель не может ни следовать им, ни проверять их. Команды, у которых канон лежал в головах, получают от ИИ случайные результаты и делают вывод «технология не готова». Дело не в технологии.
Решения остаются на человеке. Как только граница размывается и «модель же умная» становится аргументом, качество падает: никто не проверяет, потому что проверять нечего — все согласны с генерацией.
Учить стоит другому. Не инструментам — они меняются каждые полгода, — а постановке задачи и умению объяснить, почему решение верное. Это ровно те навыки, которые нельзя сгенерировать.
Вывод
Профессия не исчезает. Она смещается в сторону постановки, формализации и проверки — то есть в сторону того, что и раньше отличало сильного дизайнера от исполнителя. Разница в том, что теперь это перестало быть опцией.
Выигрывают не те, кто быстрее рисует, а те, у кого правила записаны и решения объяснены.
Как это устроено в полном процессе — от требований до прототипа — в статье «ИИ в аналитике и UXUI: пайплайн от требований до прототипа». А с чего начать формализацию правил — в «ИИ-агент за вечер».
Помогаю командам дизайна формализовать канон так, чтобы им могли пользоваться и люди, и модель. Телеграм: @darkclaus