Это было грязнее, медленнее и человечнее, чем я ожидала.
Когда мой руководитель попросил меня разобраться, как дизайн-команда могла бы эффективнее использовать ИИ в ежедневной работе, я согласилась с уверенностью человека, который абсолютно не представляет, во что ввязывается.
Я работаю в B2C-продуктовой дизайн-команде Tripadvisor. Моя зона ответственности — делать работу дизайнеров более гладкой: процессы, инструменты, меньше трения между идеей и результатом. На фоне конференций, постов в LinkedIn и статей о том, что «внедряй ИИ или останешься позади», ИИ казался очевидной точкой вложения усилий. Никто не рассказывал, как именно это сделать: недели документации, которую никто не читает, встречи с инженерами, где никто не сходится в определении «готово», и сообщение в Slack о новом воркфлоу, после которого ты просто ждёшь, попробует ли его кто-то.
Честное начало: воркшоп вместо готовой стратегии
Я начала не с выбора инструмента, а с воркшопа внутри дизайн-команды. Хотелось понять, что на самом деле болит в текущем процессе. Результаты были отчасти предсказуемыми — слишком много времени на повторяющиеся задачи, слишком много пинг-понга с разработкой — и отчасти неожиданными: люди уже использовали ИИ-инструменты, но каждый по-своему, без общего знания и общих правил.
Главное открытие оказалось не в списке болей, а в способе работы. У нас была проблема фрагментации, а не проблема ИИ. Все тихо изобретали велосипед поодиночке и никому об этом не рассказывали.
Вместо покупки очередного инструмента или навязывания единого процесса я решила строить общую инфраструктуру: переиспользуемые навыки для Claude, общее пространство документации, общий репозиторий под версионным контролем и конвейер прототипирования, которого раньше просто не существовало. Дизайнер мог пройти путь от черновой идеи в Claude Design до рабочей сборки в Claude Code и живой ссылки, которую можно отправить продакт-менеджеру или показать реальному пользователю в тот же день. Без инженерного тикета. Без ожидания.
На бумаге это звучало просто. На практике — заметно сложнее.
Что сработало: навыки, которые прижились
Project Bio Writer: от PRD к тикету за один клик
Первым прижился навык Project Bio Writer. Он превращает черновую идею проекта в структурированный бриф: гипотезу, описание, сырые метрики и при необходимости сразу создаёт тикет для отслеживания. Я поделилась им с командой, и люди реально начали им пользоваться. Не все и не сразу, но достаточно для того, чтобы навык закрепился.
Мне кажется, сработало то, что он закрывал конкретную и узнаваемую боль. Все ненавидят писать проектные брифы. Все знают, что их надо писать. Навык, который делает это быстро и достаточно хорошо, продаёт себя сам. По сути, такой навык приближает дизайн-процесс к тому, что в маркетинге называют настройка сквозной аналитики и лидгена, — только для продуктовых экспериментов: результат сразу связан с метриками, а не остаётся в голове автора.
Генераторы иллюстраций: стресс-тест на реальном проекте
Ещё одной настоящей победой стали генераторы иллюстраций. Я собрала навык под 3D clay style Tripadvisor, а затем и под Viator. Перед релизом я прогнала его через реальный проект, сгенерировав около 100 иллюстраций. Это было важно. Не «вот навык, удачи», а «вот навык, который я проверила на боевой задаче, и он держится».
Такой подход сразу задаёт другой уровень доверия. Команда видит не демо-ролик, а готовый артефакт, который уже сработал.
Конвейер прототипирования: самая сложная инфраструктура
Прототипирование заняло больше всего времени и состояло из четырёх частей.
Первое — интеграция Claude Design с дизайн-системами Tripadvisor и Viator. Прототип должен сразу рождаться в бренде: правильные компоненты, правильные стили, без необходимости вручную знать, где это лежит. Для этого пришлось стресс-тестировать саму дизайн-систему через ИИ-промптинг: проверять, насколько имена компонентов, структура и документация понятны Claude, а не только формально доступны.
Второе — обучение дизайнеров git. Звучит как мелочь, пока не посмотришь, как человек, который никогда не открывал терминал, впервые пытается склонировать репозиторий. Для части команды это был самый крутой барьер всей программы.
Третье — набор best practices для Claude Code и навыков деплоя. Чтобы путь от рабочей сборки до живой ссылки не зависел от запоминания правильной последовательности команд каждый раз.
Четвёртое — внешний хостинг прототипов. Внутренние прототипы сидели за VPN, и внешний пользователь не мог ничего протестировать. Мы сделали фреймворк для внешнего размещения, и именно это превратило «у меня на машине работает» в «вот ссылка, попробуйте». Рабочие интерактивные прототипы для тестирования с реальными пользователями, а не Figma-макеты с невидимыми hotspots.
По сути, это тот же принцип, что и при внедрение ИИ-агентов и n8n воркфлоу: ценность появляется не в момент создания скрипта, а когда процесс доходит до конечного результата без ручных передач и лишних зависимостей.
Что не сработало: внедрение, документация и зависимость от инженеров
Внедрение сложнее разработки
Я знала это умом, но по-настоящему почувствовала только когда отправила в общий Slack сообщение о новом навыке и получила в ответ тишину. Проблема была не в равнодушии. Даже действительно полезный инструмент требует энергии активации: нужно помнить, что он существует, иметь задачу, к которой он применим, и достаточно доверия, чтобы попробовать его на чём-то реальном. Если документация хотя бы слегка технически перегружена, вы уже требуете слишком многого.
Разрыв между «я сделала штуку» и «команда пользуется штукой» оказался почти целиком документационной и коммуникационной проблемой, а не технологической. Навыки, которые прижились, имели понятную документацию, честное описание ограничений и личный импульс от меня в Slack. Навыки, которые я просто закинула в репозиторий и пошла дальше, приземлились с тихим стуком.
Документация для того, кто знает меньше всех
Я написала инструкцию по настройке прототипирования так, будто читатель уже два месяца разбирался в теме вместе со мной. Команда сказала, что текст слишком инженерный. Пришлось переписывать для человека, который сталкивается с процессом впервые. Это правило нужно было применить с самого начала: пиши для новичка, а не для себя.
Но даже написать документацию недостаточно. Люди могли прочитать инструкцию к навыку, как структурировать промпт или управлять расходом токенов, и всё равно не понять ценность, пока не использовали его неправильно и не увидели, почему это важно. Рассказывать best practices почти не работало. Показывать — сидеть рядом, когда человек впервые запускает навык, или показывать before/after промпта, который тратил половину контекстного окна на воду, — работало.
Инженерная зависимость и срыв параллельности
Часть самых ценных элементов требовала реального инженерного времени, а оно всегда конкурировало с другими приоритетами. Без выделенного слота на роадмапе такая работа структурно уезжает в следующий квартал, потому что ничто не заставляет принять решение иначе.
Я строила план, предполагая, что задачи будут двигаться параллельно. Они не двигались, потому что ничего не было зарезервировано. Если эта работа достаточно важна, чтобы планировать вокруг неё, ей нужен выделенный слот, а не добровольное обещание добраться до неё когда-нибудь.
Что удивило больше всего
Я ожидала, что самой сложной окажется технология. Это было не так.
Claude, если дать ему правильный контекст, работает на удивление мощно. Создание хорошего навыка — это скорее глубокое понимание проблемы, чем особая техника промптинга. Генераторы иллюстраций потребовали итераций. Навыки для критики и генерации идей — нескольких раундов шлифовки. Но в целом технология делала то, что обещала.
Сложным было всё вокруг: документация, версионный контроль, общий репозиторий, обсуждение с операционной командой, где жить навыкам, тайминг сообщений в Slack, решение, когда процесс уже достаточно хорош для шаринга, а когда ты просто прокрастинируешь бесконечными улучшениями.
Это и есть design operations. Осознав это, я перестала удивляться.
Ещё одно допущение всплыло позже: казалось, что раз мы нашли способ работы, он применим ко всему. Это не так. Некоторые проекты по-прежнему требуют только Figma. Иногда ИИ вообще не нужен. Иногда Figma Make быстрее доводит до тестируемого прототипа, чем Claude Code. Смысл был не в том, чтобы заменить человеческое суждение о выборе инструмента, а в том, чтобы у людей было больше инструментов для этого выбора.
Где мы сейчас
Я дала себе два месяца как пилот, чтобы понять, как далеко мы сможем продвинуться. Сейчас у нас есть общая библиотека навыков для брендов Tripadvisor и Viator, каждый с документацией и версионным контролем. Половина дизайн-команды активно пользуется инфраструктурой прототипирования. Есть общее пространство документации, по которому люди реально навигируют, а не избегают его. Команда получила запрос принять это как способ работы и постепенно начинает его принимать.
Это ещё не финал. Пока мы построили доказательство концепции: оно работает, и им пользуется достаточно людей, чтобы бизнес-кейс состоялся. Превратить это в способ работы всей команды — следующий, более крупный запрос на реальное инженерное время, а не на добрую волю и без того загруженных людей.
Если вы думаете повторить это у себя
Начинайте с боли, а не с инструмента. Навыки, которые прижились, решали задачи, которые у людей действительно были. Те, что не прижились, были решениями в поиске проблемы.
Документируйте для того, кто знает меньше всех, а не больше всех. Ваш текст прочитает человек, который видит процесс впервые. Пишите для него.
Общий репозиторий важнее, чем кажется. Навыки, лежащие в личной папке, не накапливаются. Версионируемые, задокументированные и доступные для всей организации — накапливаются.
Внедрение — это коммуникационная задача. Отличный навык или воркфлоу, о котором никто не знает, не помогает никому. Анонсируйте, объясняйте, собирайте обратную связь. Потом повторите.
Закладывайте в план, что инженерные зависимости займут больше согласованного. Не потому что кто-то плохо работает, а потому что последовательность сложна и приоритеты сдвигаются.
И последнее: всё грязнее, чем это выглядит в LinkedIn. Нет чистого пути от воркшопа до внедрения и нет готового плейбука, который можно целиком перенести из другой компании. Ваши инструменты, привычки команды и инженерные мощности отличаются, поэтому чужой успешный процесс может оказаться лишней нагрузкой. Задача — понять, что реально облегчает жизнь вашей команде, а не добавить ещё один процесс к уже существующим.
Будут Slack-сообщения без ответа, переписывание документации, перенесённые встречи и навыки, которыми почти никто не пользуется. Но будут и моменты, когда юзер-тест проходит на живом прототипе или дизайнер берёт созданный вами навык вместо старта с нуля, — и это делает всё оправданным.
Если вы выстраиваете похожий процесс в дизайне или хотите адаптировать эти принципы к маркетинговой команде, в маркетинговое агентство Dragon Farm можно опереться на готовые подходы к автоматизации, версионированию и внедрению ИИ-инструментов без потери контекста.
