How to get your entire team prototyping with AI

Как вовлечь всю команду в прототипирование с помощью AI

Руководство по созданию AI-прототипов, соответствующих вашему бренду и интегрированных в каждый этап жизненного цикла разработки

👋 Добро пожаловать в 🔒 выпуск только для подписчиков 🔒 моей еженедельной рассылки. Каждую неделю я разбираю вопросы читателей о создании продуктов, стимулировании роста и развитии карьеры. Больше материалов: Lenny's Podcast | How I AI | Lennybot | Курсы | Мерч

Годовые подписчики теперь получают бесплатный год Bolt, Perplexity Pro, Notion, Superhuman, Linear, Granola и других сервисов. Подпишитесь сейчас.

Colin Matthews имеет уникальное достижение: не один, а два поста в моём топ-10 самых популярных публикаций всех времён. Сегодня он возвращается с постом, который, подозреваю, станет третьим в этом списке.

Мне нравятся материалы Colin, потому что они всегда основаны на реальных проблемах, с которыми создатели продуктов сталкиваются при работе с AI-инструментами — и он формулирует решения настолько просто и практично. Я рад продолжать сотрудничество с ним, чтобы помочь всем нам научиться переходить от хайпа к реальности. Давайте начнём.

Больше материалов от Colin: его бесплатное 45-минутное онлайн-занятие, которое пройдёт 8 июля, и его курс AI Prototyping for Product Managers (стартует 30 июня; используйте код LENNYSLIST, чтобы получить скидку $100). Вы также можете заказать у Colin однодневный воркшоп для вашей команды.

С тех пор как я впервые опубликовал руководство по AI-прототипированию для продакт-менеджеров в январе, инструменты AI-прототипирования стали невероятно популярными. Сейчас уже скорее норма, чем исключение, когда продуктовые команды используют v0, Bolt, Replit или Lovable, чтобы быстро собрать прототип, поделиться идеями и получить обратную связь.

Обучив более 500 продакт-менеджеров за последние пять месяцев тому, как извлечь максимум из этих инструментов (плюс ещё 10 000 на многочисленных бесплатных онлайн-уроках), я заметил два вопроса, которые возникают чаще всего, когда люди пытаются использовать эти инструменты в реальной работе:

Как сделать прототипы достаточно качественными, чтобы показывать их клиентам или топ-менеджерам?Как успешно внедрить эти инструменты на уровне команды, а не множества людей, работающих в изоляции?

Именно эти распространённые вопросы являются причиной, по которой продуктовые, дизайнерские и инженерные команды с трудом выстраивают командные рабочие процессы для AI-инструментов. Без чётких инструкций по передаче работы и качественных прототипов AI-прототипирование остаётся на уровне экспериментов и исследований, которые сложно операционализировать и масштабировать.

В этом посте я расскажу о трёх способах создания библиотек компонентов, которые стабильно дают отличные макеты; о командных рабочих процессах для сокращения переделок; и дам пошаговое руководство по использованию прототипов. Также поделюсь множеством приёмов, экономящих время, токены и нервы, для самых популярных инструментов AI-прототипирования. В этом посте я буду использовать v0, Bolt, Cursor и Magic Patterns, но эти техники работают с любым инструментом AI-прототипирования.

Чтобы дать вам краткий пример того, что возможно, вот прототип Airbnb, который я создал одним промптом: «Создай главную страницу и страницу деталей объявления.»

Давайте начнём!

Библиотеки компонентов

Библиотеки компонентов — это первое серьёзное улучшение, которое вы можете привнести в свою команду. Они позволяют сохранять брендинг и единообразие стилей без необходимости вручную дорабатывать каждый прототип, чтобы он выглядел как ваш продукт. Создание библиотеки компонентов потребует первоначальных усилий, но вы также создаёте многоразовые ресурсы, которые значительно повысят качество ваших прототипов в дальнейшем и сэкономят время после начальных вложений.

Существуют три подхода к созданию библиотек компонентов с помощью инструментов AI-прототипирования, с разными преимуществами и компромиссами по трудозатратам и результату:

СкриншотыРасширения для ChromeКод

Давайте разберём каждый и обсудим их компромиссы.

Метод 1: Скриншоты

Скриншоты — самый простой способ начать создание библиотеки компонентов. Вам не нужна техническая экспертиза, и этот подход работает с любым инструментом.

Начните с такого промпта в вашем любимом инструменте AI-прототипирования:

Твоя задача — создать библиотеку компонентов на основе скриншота, используя React и Tailwind CSS.

Все компоненты должны быть сделаны вручную, чтобы максимально соответствовать скриншоту.

Внимательно следуй этим инструкциям:

1. Проанализируй предоставленный скриншот.

2. Определи отдельные UI-компоненты на скриншоте. Это могут быть, помимо прочего: ◦ Кнопки ◦ Поля ввода ◦ Навигационные панели ◦ Карточки ◦ Модальные окна ◦ Элементы типографики

3. Для каждого определённого компонента:

a. Создай функциональный компонент React.

b. Используй классы Tailwind CSS для стилизации компонента, воспроизводя визуальный дизайн со скриншота.

c. Убедись, что компонент адаптивный и доступный.

d. Добавь необходимые props для кастомизации.

e. Добавь краткий комментарий, описывающий назначение компонента.

4. После создания всех отдельных компонентов создай индексную страницу, которая импортирует и отображает каждый компонент с примером использования.

Помни: используй только собственные компоненты и классы Tailwind CSS. Не используй внешние библиотеки или готовые компоненты.

Стремись воспроизвести визуальный дизайн скриншота как можно точнее, сохраняя при этом хорошие практики кодирования и переиспользуемость компонентов.

Давайте попробуем это с v0, воссоздав интерфейс Google Calendar. Не забудьте приложить скриншот!

Вот наш первоначальный результат:

Небольшое замечание: вы можете получить воспроизведение скриншота вместо списка компонентов. Эти AI-инструменты очень хорошо настроены на воспроизведение скриншотов, поэтому вам может понадобиться дополнительный промпт, например: «Вместо страницы, воспроизводящей UI, индексная страница должна быть списком компонентов из библиотеки компонентов.» Далее вы можете продолжать добавлять компоненты, вставляя дополнительные скриншоты с промптом «Добавь также эти компоненты.» Если хотите доработать компоненты, рекомендую начать с такого промпта:

«Перечисли различия между скриншотом и твоей реализацией. Как ты можешь точнее воспроизвести дизайн? Не пиши код.»

Эта техника (называемая рефлексией) позволяет легко использовать AI для быстрого улучшения UX.

Когда ваша библиотека компонентов готова, остановитесь! Вам нужно создать форк проекта и начать использовать компоненты в новом проекте. Форк автоматически будет переиспользовать ваши компоненты для сборки дизайна, как из Lego. Опять же, эта техника работает в любом из ваших любимых инструментов AI-прототипирования. (Вот как создать форк в каждом инструменте: Bolt, v0, Lovable, Replit, Magic Patterns.)

Например, мы можем прототипировать AI-агента в Google Calendar, который блокирует слоты для глубокой работы, простым промптом вроде «Создай основной вид Google Calendar с AI-ассистентом для планирования, который рекомендует блоки для глубокой работы.»

Вот результат:

Вложение времени в улучшение компонентов окупается. Каждый прототип, созданный на их основе, имеет лучшее визуальное качество, меньше отвлекает стейкхолдеров и позволяет сосредоточить обсуждение на конкретных элементах, которые тестируются.

Метод 2: Расширения для Chrome

Следующий вариант создания библиотек компонентов — использование расширений для Chrome. На сегодняшний день Magic Patterns — единственный инструмент, поддерживающий извлечение компонентов непосредственно с веб-страницы.

Использовать расширение просто: выберите UI-элемент, извлеките его стили и превратите в переиспользуемый компонент.

Мне нравится запускать несколько таких извлечений одновременно, чтобы создать как можно больше компонентов за короткое время. Как только они попадают в Magic Patterns, вы можете продолжать дорабатывать их с помощью промптов.

Настоящая магия начинается при использовании этих компонентов. Давайте попробуем промпт «Создай мне вид канала YouTube.»

Вот результат одного промпта:

Метод 3: Код

Последний способ создания библиотеки компонентов — с помощью кода, используя ваши реальные компоненты. Этот подход требует наибольших усилий, но даст вам прототипы, неотличимые от реального продукта. Вам потребуется помощь инженерной команды, а общие трудозатраты и сложность будут зависеть от вашей кодовой базы и размера компании. Этот вариант наиболее реалистичен в небольших компаниях или там, где дизайнеры и продакт-менеджеры более технически подкованы.

Для начала вашей инженерной команде нужно настроить репозиторий так, чтобы вы могли запускать фронтенд-приложение локально без подключения к бэкенд-сервисам или базам данных. Этого можно добиться, создав новую точку входа для клиентского приложения, которая мокирует ответы API. Когда локальное окружение заработает, вы сможете использовать AI-редактор кода вроде Cursor или Windsurf для прототипирования.

Вот пример приложения, над которым я работаю. Вся информация, которую вы видите, мокирована на стороне клиента — без серверов и баз данных.

Этот подход лучше всего работает, если вы знакомы с GitHub, ветками и базовыми командами терминала.

Ещё один способ использовать код для получения более точных компонентов — новый MCP-сервер Figma (который запустился буквально на прошлой неделе!). Если вы не знакомы с MCP — это протокол, позволяющий AI-агентам получать информацию или выполнять действия в другом приложении. В данном случае мы можем использовать агент Cursor для обращения к MCP-серверу Figma, чтобы получить детальную информацию о стилях и затем преобразовать её в компоненты.

В настоящее время Figma поддерживает четыре MCP-действия:

Get CodeGet Variable DefinitionsGet ImageGet Code Connect

Фактически это даёт Cursor возможность автономно делать скриншоты, извлекать дизайн-токены и получать CSS из Dev Mode Figma.

Вот быстрое сравнение дизайн-библиотеки Figma и тех же компонентов, воспроизведённых в коде.

Figma:

Код:

Вот шаги для создания компонентов с помощью Figma MCP:

Включите MCP-сервер Figma для дизайна, с которым хотите работать (Preferences, затем Enable Dev Mode Server). Это даст вам URL для подключения.В Cursor перейдите в Settings, MCP Tools и нажмите «Add a new MCP server». Вставьте URL, предоставленный Figma.Скопируйте URL компонента из Figma, кликнув правой кнопкой и выбрав «Copy as URL».Попросите Cursor сгенерировать это как компонент и сделать индексную страницу списком компонентов.

Пока что, по моим наблюдениям, это лучше всего работает, если у вас есть существующие компоненты, которые Cursor может воспроизвести, или если вы даёте чёткие инструкции по форматированию кода.

Этот вариант совсем новый, но очень перспективный для дизайн-команд, которые хотят использовать свои существующие библиотеки компонентов с инструментами AI-прототипирования.

Подводя итог: библиотеки компонентов дают вашей команде набор общих артефактов, которые позволяют любому легко создавать реалистичные прототипы с помощью AI. Библиотеку можно распространить на всю команду, что упрощает онбординг новых участников и поддержание высокого визуального качества для тестирования непосредственно с клиентами или на встречах с топ-менеджерами.

Командные рабочие процессы

Теперь, когда у вас есть компоненты для мгновенного создания реалистичных прототипов, давайте поговорим о командных рабочих процессах. Я хочу рассмотреть два рабочих процесса:

Базовые версии и форкиЖизненный цикл разработки продукта

Рабочий процесс 1: Базовые версии и форки

Базовые версии и форки — это расширение стратегии библиотек компонентов. С компонентами вы даёте участникам команды фору, предоставляя строительные блоки, которые легко собрать в красивые прототипы. «Базовые версии» идут на шаг дальше, давая вам качественное воспроизведение текущего пользовательского опыта, что позволяет участникам команды легче экспериментировать с новыми идеями с помощью простых промптов. Форки развивают эту идею дальше, позволяя дублировать проект со всем содержимым без использования токенов и защищая базовую версию от случайных изменений.

Лучше всего объяснить это на примере.

Допустим, я продакт-менеджер в Airbnb, работающий над новым продуктом Experiences. Это продукт, демонстрирующий самые уникальные и интересные впечатления по всему миру. Используя базовые версии и форки, я начну с воспроизведения текущей страницы, а затем исследую несколько новых идей.

Создание начальной страницы с моей библиотекой компонентов заняло около 20 минут — в основном на доводку мелких деталей, чтобы прототип действительно выглядел как Airbnb (см. моё предыдущее руководство с советами по тонкой настройке прототипов). Вот как это выглядит:

Кстати, вот реальный сайт:

Теперь, когда у меня есть эта страница, я буду считать её своей «базовой версией». Я больше не буду вносить изменения, а вместо этого создам форк.

На форке я введу один промпт: «Измени эту страницу так, чтобы перед показом впечатлений она проводила опрос для определения предпочтений пользователя. Сохрани брендинг Airbnb.» Вот результат:

Теперь давайте протестируем другую идею: использование истории путешествий клиента для предложения релевантных впечатлений.

Снова создаю форк от базовой версии. В новой копии ввожу промпт: «Измени эту страницу так, чтобы она показывала впечатления, которые мне понравятся, на основе моей истории путешествий с Airbnb. Для каждой рекомендации добавь UI-элемент с текстом «на основе вашей поездки в...»»

Вот результат:

Базовые версии и форки лучше всего подходят, когда вы хотите исследовать несколько разных идей, не перестраивая стартовую страницу каждый раз. Они дают вашей команде дополнительное преимущество для быстрого получения качественных результатов при использовании инструментов AI-прототипирования.

Рабочий процесс 2: Жизненный цикл разработки продукта

Если вы реализуете всё, что мы рассмотрели до сих пор, вы будете значительно впереди среднестатистического новичка в AI-прототипировании. Но вполне возможно, что ваши продакт-менеджеры или дизайнеры всё ещё будут прототипировать в изоляции. Создание общего понимания в команде о том, когда использовать AI-прототипы, так же важно, как и умение получать хорошие результаты.

Прежде чем перейти к жизненному циклу разработки продукта, я хочу кратко затронуть тему детализации. Долгое время у нас были низкодетализированные наброски интерфейсов и высокодетализированные макеты для финального продукта. AI-прототипирование вводит среднюю детализацию — лучше, чем рисунок на салфетке, но ещё не уровень финальных макетов в Figma.

Вот пример макета средней детализации для Reddit. На первый взгляд выглядит правильно, но вы заметите множество несовершенств: две кнопки для голосования вверх, слишком большие отступы в левой навигации, а элементы навигации в правом верхнем углу слишком сильно сдвинуты от правого края.

Вы, безусловно, можете создавать и высокодетализированные макеты с помощью инструментов AI-прототипирования — ключевой вопрос в том, сколько времени и усилий вы на это потратите.

Критически важно выбирать подходящий уровень детализации прототипа в зависимости от контекста и затем чётко устанавливать ожидания с членами команды относительно этого уровня. Например, если вы объясняете взаимодействие инженеру, средняя детализация вполне подойдёт, и нет смысла тратить время на большее. Тогда как если вы убеждаете CEO выделить финансирование для новой команды, требующей миллионных инвестиций, функциональный высокодетализированный макет, вероятно, стоит потраченного времени.

Ниже я описал шесть основных этапов жизненного цикла разработки продукта и то, как на каждом из них можно использовать прототипы, какой уровень детализации выбрать и кто отвечает за прототип. Рекомендую воспринимать это как общее руководство и применять то, что имеет смысл в вашей компании.

Давайте разберём пример полного жизненного цикла разработки новой функции Reddit под названием Reddit Answers. Это будет функция на основе генеративного AI, которая позволяет пользователям задавать вопросы и получать быстрые ответы на основе прошлых постов и комментариев Reddit.

Шаг 1: Исследование

Начиная с этапа исследования, вы можете использовать инструмент AI-прототипирования для быстрого выражения идеи со средним уровнем детализации. Обычно это используется только внутри компании и может ограничиваться обсуждением между продуктом, дизайном и ведущим инженером. Мы можем начать с чего-то подобного, что займёт около 20 минут:

Этот пост доступен только платным подписчикам