20 уроков · 20 заданий · 20 проверок понимания
Создание продукта с ИИ: от идеи до первых пользователей
20 практических шагов: проверить проблему, собрать MVP с ИИ, протестировать, опубликовать и оценить интерес.
Ваш итоговый проект
Follow-up — небольшой сервис для самостоятельного специалиста: добавить клиента, записать договорённость и увидеть, кому пора ответить. ИИ помогает создавать приложение; встроенная нейросеть в самом продукте не обязательна. Вы можете заменить сюжет своим, сохранив узкий основной сценарий.
Что нужно на старте
Нужны браузер, редактор и готовность запускать проверки. Полезны основы HTML, JavaScript и Git; пробелы можно закрывать по ссылкам в уроках. Выберите доступный вам ИИ-инструмент. При отсутствии подписки выполняйте шаги вручную или с тестовыми ответами. Не загружайте реальные клиентские данные в учебные промпты.
Как проходить
Идите по номерам: прочитайте объяснение, разберите пример, выполните задание в своём проекте и ответьте на вопрос. Каждые пять шагов завершают очередную часть маршрута. Практику вы проверяете по критериям и подтверждаете самостоятельно; код в Loono не исполняется.
Материалы открыты без регистрации. Прогресс публичной карты сохраняется в этом браузере. Для серверного сохранения скачайте карту и импортируйте её в свой аккаунт через кнопку импорта.
Скачать карту для личного импорта (JSON)Авторский материал Loono. Редакция 2026-09-07. Внешние сервисы могут требовать отдельного доступа; это отмечено в заданиях.
Программа и материалы
1. Проблема и первый сценарий
01. Один пользовательВыбрать конкретную ситуацию вместо абстрактной аудитории.
Продукт начинается с повторяющейся трудности. «Сервис для фрилансеров» слишком широко: дизайнер и бухгалтер могут работать совершенно по-разному. Выберите человека в конкретной ситуации — например, дизайнер после созвона забывает вернуться к потенциальному клиенту.
Опишите существующий способ решения: заметки, календарь, таблица. Это ваш первый конкурент. Человеку придётся сменить привычку, поэтому новое решение должно выигрывать в заметном действии. ИИ ускоряет создание интерфейса, но не доказывает, что проблема важна. До выбора фреймворка напишите одно предложение о том, кому и в какой момент станет легче.
Разбор на примере
Гипотеза: «Самостоятельный дизайнер после переговоров за минуту записывает следующий шаг и утром видит, кому ответить». Наблюдаемый результат — договорённость не теряется. «Умная CRM нового поколения» такого результата не задаёт.
Практическое задание
Выберите одну аудиторию и одну повторяющуюся ситуацию. Опишите текущий обходной путь и то, что именно в нём неудобно.
Критерии готовности
- Названа конкретная роль и момент использования.
- Известно, чем человек пользуется сейчас.
- Польза описана действием, а не набором функций.
Проверка понимания
Какое описание помогает спроектировать первую версию?
- Платформа для всех
- Дизайнер фиксирует следующий контакт после созвона
- CRM с максимальным числом функций
Показать ответ и объяснение
Дизайнер фиксирует следующий контакт после созвона
Конкретный контекст задаёт вход, действие и результат продукта.
Источники
02. Разговор о прошломОтделить вежливый интерес от реальной боли.
На вопрос «пользовались бы вы?» легко получить вежливое согласие. Просите рассказать о последнем реальном случае: когда потерялась договорённость, как человек заметил это, что сделал и чем обошлась ошибка. Не подсказывайте проблему в самом вопросе.
Записывайте факты отдельно от интерпретаций. «Дважды за месяц искал письмо по двадцать минут» — наблюдение. «Готов платить за наш продукт» — вывод, которого из этого ещё нет. Небольшое число разговоров помогает уточнить сценарий, но не даёт оценки рынка. Если возможности поговорить нет, явно оставьте гипотезу непроверенной и сократите стоимость разработки.
Разбор на примере
Три вопроса: «Расскажите о последнем клиенте, которому нужно было написать повторно». «Где был записан следующий шаг?» «Что произошло, если вы забыли?» После ответа попросите показать существующую последовательность на вымышленных данных.
Практическое задание
Проведите несколько коротких разговоров с подходящими людьми либо подготовьте сценарий интервью и отметьте его как ещё не проведённый. Не заменяйте интервью ответами ИИ.
Критерии готовности
- Есть история конкретного случая.
- Факты отделены от предположений.
- Согласие попробовать не записано как готовность платить.
Проверка понимания
Что лучше свидетельствует о проблеме?
- Похвала идеи
- Сгенерированный ИИ портрет клиента
- Описание недавнего случая и затрат на обходное решение
Показать ответ и объяснение
Описание недавнего случая и затрат на обходное решение
Реальное поведение надёжнее гипотетического обещания.
Источники
03. Проверяемое обещаниеСформулировать пользу и условие эксперимента.
Сформулируйте обещание, которое можно проверить после короткого использования. Follow-up обещает показать забытые следующие контакты. Он пока не обещает рост дохода, которого вы не измеряли. Хорошая формулировка позволяет показать результат без длинного обучения.
До разработки выберите условие следующего решения: сколько приглашённых попробуют основной сценарий и сколько вернутся к нему в подходящий момент. Числа здесь — ваши критерии эксперимента, а не рыночные нормы. Для редкого рабочего действия ежедневное возвращение не подходит. Запишите ограничение времени и усилий, чтобы эксперимент не превратился в бесконечную разработку.
Разбор на примере
Учебный план: пригласить 8 подходящих знакомых, помочь начать, проверить через неделю, вернулись ли хотя бы 3 к списку следующих контактов. Это пример порога решения, не доказательство спроса и не универсальная конверсия.
Практическое задание
Напишите одно обещание продукта и условие «продолжаем / меняем сценарий». Укажите, какие наблюдения нужны и когда их соберёте.
Критерии готовности
- Обещание относится к текущей функции.
- Критерий записан до получения результатов.
- Период проверки соответствует частоте задачи.
Проверка понимания
Почему заранее задают критерий эксперимента?
- Чтобы гарантировать успех
- Чтобы не менять определение успеха после результата
- Чтобы не разговаривать с людьми
Показать ответ и объяснение
Чтобы не менять определение успеха после результата
Предварительный критерий помогает честно интерпретировать результат.
Источники
04. Границы MVPОставить один рабочий путь до ценности.
Минимальный продукт должен завершать задачу пользователя. Половина формы с красивым дизайном не является рабочим сценарием. Для Follow-up достаточно добавить клиента, записать следующий контакт и увидеть список просроченных действий. Автоматизация почты и командные роли пока не нужны.
Разделите обязательное для сценария и полезное позднее. Сохранение данных обязательно, иначе договорённость исчезнет. Переключение тем оформления не обязательно. Для каждого пункта спросите: без него человек получит обещанный результат? Ограничение функций уменьшает число состояний, которые нужно проверить, и делает запросы к ИИ точнее.
Открыть в полном размере ↗Разбор на примере
Входит: имя клиента, следующий шаг, дата, список «сегодня и просрочено», отметка выполненного. Позже: календарные интеграции, биллинг, генерация писем, командный доступ. Граница сохраняется, даже если ИИ предлагает добавить всё сразу.
Практическое задание
Составьте список первой версии и список отложенного. Нарисуйте путь из трёх экранов или состояний без дополнительных функций.
Критерии готовности
- Основной путь заканчивается результатом.
- Есть сохранение и повторное открытие данных.
- Каждая обязательная функция объяснена обещанием.
Проверка понимания
Что нельзя убрать из MVP Follow-up без потери смысла?
- Три цветовые темы
- Командный чат
- Сохранение следующего контакта
Показать ответ и объяснение
Сохранение следующего контакта
Без сохранения приложение не решает проблему забытых договорённостей.
Источники
05. Прототип до кодаПроверить понятность основного действия.
Сначала набросайте пустой список, заполненный список и форму. Пользователь должен понять, с чего начать и что произойдёт после нажатия. Не просите оценить красоту: дайте задачу «добавьте клиента и запланируйте ответ на завтра» и наблюдайте, где человек остановился.
Для прототипа достаточно бумаги или статичного HTML. Реальные данные не нужны. Добавьте состояния загрузки, ошибки и успешного сохранения: они формируют доверие так же, как основной экран. Кнопка «Сохранено» до ответа сервера создаёт ложное впечатление, даже если выглядит аккуратно.
Разбор на примере
Пустой экран: «Следующих контактов пока нет» и кнопка «Добавить клиента». После сохранения — карточка с датой и следующим действием. При ошибке формы введённый текст остаётся, а рядом появляется понятное объяснение.
Практическое задание
Сделайте прототип трёх состояний. Попросите одного человека пройти сценарий без подсказок либо проведите самостоятельный проход по заранее записанной задаче и отметьте ограничение такого теста.
Критерии готовности
- Основная кнопка понятна без объяснения.
- Предусмотрены ошибка и пустое состояние.
- Отказ сохранения не стирает введённые данные.
Проверка понимания
Как лучше проверить понятность прототипа?
- Спросить, нравится ли цвет
- Дать конкретную задачу и наблюдать
- Попросить ИИ поставить оценку
Показать ответ и объяснение
Дать конкретную задачу и наблюдать
Прохождение задачи показывает реальные затруднения интерфейса.
Источники
2. Сборка с помощью ИИ
06. Задача для ИИДать агенту конкретный проверяемый результат.
ИИ легче помогает, когда знает контекст, границы изменения и критерии готовности. Запрос «сделай CRM» оставляет слишком много решений неявными. Разбейте работу на вертикальные шаги: форма и локальное состояние; затем сохранение; затем доступ пользователей. Каждая задача заканчивается проверкой.
Перед изменением существующего кода попросите инструмент объяснить текущий путь данных и назвать файлы. Укажите, какие соглашения проекта нужно соблюдать. Не отправляйте настоящий .env, клиентскую базу или ключи. Если инструмент не может запустить проверку, он должен явно сообщить это, а не утверждать работоспособность по внешнему виду кода.
Разбор на примере
Пример задания: «Добавь форму клиента: имя, следующий шаг, дата. Сохраняй в существующий API. При 400 покажи ошибку рядом с полем, при 500 сохрани ввод. Готово, когда запись появляется после перезагрузки и двойное нажатие не создаёт дубль. Покажи изменённые файлы и результат проверки».
Практическое задание
Напишите три последовательные задачи для ИИ по своему MVP. Для первой подготовьте точные входные данные и ожидаемый результат проверки.
Критерии готовности
- У задачи одна основная цель.
- Описаны ошибка и успешный путь.
- Проверка имеет наблюдаемый результат.
Проверка понимания
Что полезнее добавить в запрос к ИИ?
- Будь гениальным
- Используй всё самое модное
- Ожидаемое поведение при успешном и неуспешном сохранении
Показать ответ и объяснение
Ожидаемое поведение при успешном и неуспешном сохранении
Конкретные критерии уменьшают число произвольных решений.
Источники
07. Стек и окружениеВыбрать инструменты, которые сможете проверить.
Выберите небольшой привычный стек. Для учебного Follow-up подойдёт обычное веб-приложение с сервером и реляционной базой. React или другой интерфейсный инструмент — выбор реализации, а не источник спроса. Чем больше новых сервисов, тем больше регистраций, конфигурации и мест отказа.
Зафиксируйте версии runtime, команды установки, запуска и проверки. ИИ должен работать в этом окружении, а не каждый раз предлагать новый фреймворк. Локальный запуск не означает готовность публикации: ещё предстоят доступ, конфигурация, хранение и наблюдаемость. Для первого прототипа допустимо локальное хранилище, но его ограничения нужно явно показывать.
Разбор на примере
Карточка стека: «Интерфейс — React; сервер — Node.js; база — PostgreSQL; зависимости фиксируются lockfile; npm run dev запускает локальную разработку; тесты и build выполняются отдельно». Список можно упростить под ваш опыт.
Практическое задание
Запустите пустой проект выбранного стека. Запишите команды и воспроизведите их в чистой копии. Уберите сервисы, не требующиеся основному сценарию.
Критерии готовности
- Проект запускается по README.
- Есть lockfile.
- Каждая внешняя зависимость имеет понятную функцию.
Проверка понимания
Какой стек лучше для первого эксперимента?
- Максимально сложный
- Тот, который позволяет быстро собрать и проверить сценарий
- Тот, который ИИ предложил последним
Показать ответ и объяснение
Тот, который позволяет быстро собрать и проверить сценарий
Проверяемость и стоимость поддержки важнее числа технологий.
Источники
08. Маленькие измененияСохранять работающие состояния проекта.
После каждого завершённого изменения проверяйте diff и создавайте небольшой коммит. Это позволяет сравнить работающую версию с поломанной. ИИ может незаметно поменять соседний сценарий или удалить проверку; просмотр изменений — часть разработки, а не недоверие к инструменту.
Не смешивайте обновление зависимостей, редизайн и авторизацию в одной задаче. Если что-то сломалось, сначала локализуйте изменение. Возвращение отдельного коммита предпочтительнее удаления всей рабочей папки. Незакоммиченные правки тоже могут быть ценными: перед любым откатом проверьте статус и сохраните нужное. Резервная копия репозитория и Git решают разные задачи.
Открыть в полном размере ↗Разбор на примере
Рабочий цикл: git status → небольшая задача → запуск сценария → git diff → коммит. Название «Добавить сохранение следующего контакта» объясняет результат лучше, чем «updates». При ошибке сравните последний рабочий коммит и текущий diff.
Практическое задание
Сделайте две отдельные правки интерфейса с отдельными коммитами. Покажите diff каждой и объясните, как вернуть только вторую, сохранив первую.
Критерии готовности
- Каждый коммит имеет одну объяснимую цель.
- Проверены незакоммиченные изменения перед откатом.
- В истории нет секретов и клиентских данных.
Проверка понимания
Почему опасно просить «откати всё» без просмотра статуса?
- Git перестанет работать
- Можно потерять нужные незакоммиченные изменения
- Коммиты станут длиннее
Показать ответ и объяснение
Можно потерять нужные незакоммиченные изменения
Объём отката нужно понимать до действия.
Источники
09. Рабочая формаСделать ввод понятным и устойчивым к ошибкам.
Каждое поле имеет видимую подпись, понятный формат и сообщение об ошибке. Placeholder не заменяет label: после ввода он исчезает. Форма должна работать с клавиатуры и на узком экране. Для даты объясните смысл: день следующего контакта, а не момент в произвольном часовом поясе.
Во время сохранения предотвращайте случайный повтор, но не считайте отключение кнопки серверной защитой от дублей. При ошибке сохраняйте ввод и дайте повторить. Успех показывайте после подтверждения записи. Если используете оптимистичное обновление, продумайте возврат состояния при ошибке.
Разбор на примере
Состояния кнопки: «Сохранить» → «Сохраняем…» → карточка клиента. При 400 поле получает сообщение «Укажите следующий шаг». При сетевом сбое форма остаётся заполненной и показывает «Не удалось сохранить. Повторить».
Практическое задание
Реализуйте форму и проверьте Tab, Enter, пустые поля, длинное имя, узкий экран и сетевую ошибку.
Критерии готовности
- Поля связаны с label.
- Ошибка не стирает ввод.
- Кнопка доступна и понятна с клавиатуры.
Проверка понимания
Когда безопасно показать «Сохранено»?
- Сразу при нажатии
- После ответа сервера об успешной записи либо с корректной моделью оптимистичного отката
- После запуска анимации
Показать ответ и объяснение
После ответа сервера об успешной записи либо с корректной моделью оптимистичного отката
Интерфейс должен отражать реальный исход операции.
Источники
10. Сохранение данныхДовести сценарий через перезагрузку и перезапуск.
Первый вертикальный срез считается рабочим, когда запись появляется после повторного открытия. Локальный массив исчезает при перезапуске процесса. localStorage живёт в конкретном браузере и не даёт общий аккаунт между устройствами. Серверная база решает другую задачу: постоянное хранение с правилами доступа.
Для Follow-up достаточно таблицы контактов с владельцем, именем, следующим действием, датой и состоянием. Валидацию повторяют на сервере. Если задача привязана к дню, храните дату как дату; превращение её в полночь UTC может сдвинуть отображение. Не добавляйте сложную синхронизацию до проверки обычного сохранения.
Разбор на примере
Контакт: id, owner_id, name, next_action, follow_up_date, status. Пользователь передаёт name, next_action и дату. owner_id задаётся сервером. После POST выполните отдельный GET и перезапустите процесс перед повторным чтением.
Практическое задание
Подключите постоянное хранение. Создайте контакт, перезагрузите страницу и перезапустите сервер. Проверьте дату на границе суток.
Критерии готовности
- Данные сохраняются после обоих перезапусков.
- Владелец не задаётся произвольным полем формы.
- Дата следующего контакта не смещается неожиданно.
Проверка понимания
Что доказывает сохранение только в localStorage?
- Серверная база работает
- Данные доступны на любом устройстве
- Запись хранится в данном браузере при сохранности его хранилища
Показать ответ и объяснение
Запись хранится в данном браузере при сохранности его хранилища
Локальное хранилище не заменяет серверный аккаунт и синхронизацию.
Источники
3. Продукт, которому можно доверять
11. Вход и изоляцияПроверить продукт двумя пользователями.
Регистрация не является целью продукта: она помогает безопасно сохранять личные данные. Не заставляйте человека проходить её до понимания пользы, если сценарий допускает демонстрацию. Но демонстрационные данные должны быть вымышленными, а приватные записи — изолированными.
Для входа используйте поддерживаемое решение, не собственную криптографию. На сервере проверяйте владельца при каждой операции. Кнопки интерфейса не являются защитой: запрос можно отправить напрямую. Временный тестовый вход должен отсутствовать в опубликованном окружении. Два тестовых пользователя позволяют обнаружить типовую ошибку «все вошедшие видят все записи».
Разбор на примере
Аня создаёт контакт. Борис открывает его URL и отправляет прямой запрос чтения, изменения и удаления. Во всех случаях доступа нет. Список Бориса также не содержит запись Ани. Выход делает прежнюю сессию недействительной согласно выбранной схеме.
Практическое задание
Подключите вход и проведите проверку двух аккаунтов. Запишите результаты доступа по прямому ID, а не только видимость кнопок.
Критерии готовности
- Чужие данные не читаются и не изменяются.
- Тестовый вход не активен в опубликованной конфигурации.
- Выход и истечение сессии обработаны.
Проверка понимания
Почему скрытой кнопки удаления недостаточно?
- Её цвет может измениться
- Запрос можно отправить без интерфейса
- Пользователь может забыть пароль
Показать ответ и объяснение
Запрос можно отправить без интерфейса
Реальные ограничения применяются на сервере.
Источники
12. Разобраться в поломкеДать ИИ воспроизводимую ошибку.
Когда приложение сломалось, соберите точный сценарий: исходное состояние, действие, ожидаемый результат, фактический результат. Посмотрите запрос в Network и журнал сервера. Не отправляйте ИИ весь журнал без просмотра: там могут быть токены и приватные данные.
Просите сначала объяснить вероятную причину и предложить минимальную проверку гипотезы. Ошибка интерфейса может оказаться неправильным ответом сервера, а ошибка сервера — конфигурацией. Случайное обновление библиотек редко помогает локализовать причину. После исправления повторите исходный сценарий и соседний рабочий путь. Если ошибка не воспроизводится, сохраните наблюдение, а не объявляйте исправление доказанным.
Разбор на примере
Хорошее описание: «POST /contacts возвращает 201, после reload список пуст. В GET /contacts — 200 и []. Сервер перезапускается между вызовами. Ожидание: созданный контакт остаётся». Это направляет проверку к хранилищу и окружению.
Практическое задание
Намеренно внесите небольшую локальную ошибку сохранения, сформулируйте воспроизведение и исправьте её. Сохраните до/после и проверку повторного чтения.
Критерии готовности
- Описан точный запрос и исход.
- Из журналов убраны секреты.
- Исправление проверено тем же сценарием.
Проверка понимания
Что полезнее передать ИИ при ошибке?
- Всё сломалось
- Весь диск проекта без отбора
- Шаги воспроизведения и обезличенный ответ проблемного запроса
Показать ответ и объяснение
Шаги воспроизведения и обезличенный ответ проблемного запроса
Минимальные точные данные помогают локализовать причину.
Источники
13. Приёмочные сценарииПроверить обещание продукта целиком.
Сборка без ошибок доказывает, что код собрался, но не что человек может решить задачу. Подготовьте несколько сквозных сценариев в браузере: новый пользователь создаёт контакт, меняет дату, видит просроченный контакт и завершает действие. Добавьте отказ сети и попытку чужого доступа.
Автоматизируйте стабильный основной путь, а визуальную понятность проверьте отдельно. Не делайте тест, который лишь подтверждает существование кнопки: нажмите её и проверьте сохранённый результат после перезагрузки. На время теста используйте отдельные данные. Если ИИ пишет тесты вместе с кодом, намеренно нарушьте ключевое правило и убедитесь, что тест способен это обнаружить.
Разбор на примере
Сценарий: заполнить имя и следующий шаг → сохранить → перезагрузить → увидеть ту же запись → сменить дату → перезагрузить → увидеть новую дату. Отдельный сценарий: отказ сервера сохраняет введённый текст.
Практическое задание
Запишите пять приёмочных сценариев. Автоматизируйте хотя бы основной путь и ручным проходом проверьте мобильный экран и клавиатуру.
Критерии готовности
- Проверка включает перезагрузку.
- Есть негативный сценарий.
- Тест действительно падает при нарушении сохранения.
Проверка понимания
Что лучше подтверждает готовность формы?
- Кнопка есть в DOM
- Build завершился
- Запись появилась после сохранения и перезагрузки
Показать ответ и объяснение
Запись появилась после сохранения и перезагрузки
Сквозная проверка подтверждает пользовательский результат.
Источники
14. Первый полезный результатПомочь начать без длинной экскурсии.
Пользователь пришёл решить задачу, а не изучить устройство приложения. Первый экран должен вести к одному действию. Для Follow-up это создание первого следующего контакта. Демонстрационная карточка может объяснить формат, но её нельзя выдавать за реальные данные пользователя.
Сократите обязательные поля до нужных сценарию. Телефон, должность, аватар и отрасль не требуются, чтобы записать следующий шаг. После первого успеха покажите, где найти задачу завтра. Не путайте активацию с регистрацией: аккаунт создан, но ценность может быть ещё не получена. Определите событие, которое соответствует обещанию.
Разбор на примере
Первый экран: «Кому нужно ответить?» Поля: имя, следующий шаг, дата. После сохранения: «Готово. Этот контакт появится в списке на выбранный день». Событие активации — первый сохранённый следующий контакт, а не открытие формы.
Практическое задание
Пройдите приложение как новый пользователь. Уберите одно необязательное препятствие до первой ценности и измерьте число действий в сценарии.
Критерии готовности
- Первое действие понятно без тура.
- Демо-данные явно обозначены.
- Активация связана с сохранённым результатом.
Проверка понимания
Что ближе к активации Follow-up?
- Открытие лендинга
- Первый сохранённый следующий контакт
- Выбор цвета аватара
Показать ответ и объяснение
Первый сохранённый следующий контакт
Активация должна отражать получение основной пользы.
Источники
15. События без шумаИзмерить путь от входа до пользы.
Для первого эксперимента достаточно нескольких событий: открытие продукта, начало основного действия, успешное сохранение, повторное полезное действие. Не отправляйте в аналитику имена клиентов, текст договорённостей, ключи и полные тела запросов. Агрегированных событий обычно достаточно для проверки гипотезы.
Событие успеха отправляется после подтверждённой операции. Повторы и собственные тесты могут искажать числа, поэтому задайте правило исключения технических посещений. Проверяйте инструмент в режиме, соответствующем выбранным настройкам согласия. Отсутствие события не всегда означает отсутствие действия: блокировщик или отказ от аналитики создают неполные данные.
Разбор на примере
События: contact_form_opened, follow_up_created, follow_up_completed. Разрешённые свойства: версия интерфейса и тип входа. Имя клиента и next_action не передаются. Для повторной отправки используйте идентификатор события, если система поддерживает дедупликацию.
Практическое задание
Добавьте три события и проверьте момент отправки. Убедитесь, что неуспешное сохранение не учитывается как активация.
Критерии готовности
- События соответствуют бизнес-результату.
- В свойствах нет пользовательского содержимого.
- Известны ограничения полноты данных и собственные тесты.
Проверка понимания
Когда отправлять follow_up_created?
- При открытии формы
- При каждом нажатии кнопки
- После подтверждённого создания записи
Показать ответ и объяснение
После подтверждённого создания записи
Иначе метрика считает попытки, а не полученную пользу.
Источники
4. Публикация и проверка интереса
16. Первый выпускОпубликовать проверенную версию с возможностью возврата.
Перед публикацией проверьте production-конфигурацию: адрес API, доступ к базе, отсутствие тестового входа, обработку ошибок и HTTPS. Секреты передаются через настройки окружения, а не через frontend bundle. Изучите минимальные требования выбранного хостинга и стоимость, не подключая лишние услуги автоматически.
Сохраните версию артефакта и способ возврата. После выпуска повторите реальный сценарий создания и чтения: локальная проверка не обнаружит ошибку внешнего адреса или cookie. Разделяйте работоспособность приложения и сохранность данных. Для эксперимента достаточно небольшого окружения, но должно быть понятно, что произойдёт при перезапуске и как восстановить учебные данные.
Разбор на примере
Проверка после выпуска: открыть сайт в новой сессии → войти тестовым аккаунтом → создать контакт → перезагрузить → проверить запись → выйти → убедиться в отказе доступа. Удалите только созданные вами тестовые записи по их точным ID.
Практическое задание
Подготовьте конфигурацию публикации и проведите репетицию на отдельном окружении. Если публикация требует оплаты, сначала запишите выбранный тариф и ограничения; оплату выполняйте осознанно.
Критерии готовности
- В клиентском коде нет секретов.
- Известен рабочий предыдущий артефакт.
- Проверен сквозной сценарий в опубликованном окружении либо явно отмечено, что проверен только локальный запуск.
Проверка понимания
Достаточно ли локального build для подтверждения релиза?
- Да
- Нет, нужен запуск и проверка внешнего сценария
- Да, если ИИ сказал, что готово
Показать ответ и объяснение
Нет, нужен запуск и проверка внешнего сценария
Конфигурация и сеть могут отличаться от локального окружения.
Источники
17. Страница с обещаниемПривести человека сразу к понятному действию.
Лендинг объясняет, кому полезен продукт, какую задачу решает и что делать дальше. Заголовок должен соответствовать реальной функции. Покажите короткий пример до/после, одну основную кнопку и ограничения. Не обещайте автоматические письма, если в первой версии есть только список контактов.
Для поиска странице нужны доступный текст, уникальные заголовок и описание, правильный canonical и рабочие ссылки. Индексация не равна трафику, а трафик не равен полезному использованию. Свяжите обещание лендинга с первым экраном: человек, пришедший за списком следующих контактов, не должен сначала разбираться в универсальной CRM.
Разбор на примере
Заголовок: «Не теряйте следующий разговор с клиентом». Подзаголовок: «Запишите договорённость и увидьте, кому пора ответить». Кнопка: «Добавить первый контакт». Пример использует вымышленные имена и показывает дату следующего шага.
Практическое задание
Соберите одну страницу продукта. Сверьте каждое обещание с реализованным сценарием и проверьте путь от кнопки до результата.
Критерии готовности
- Нет обещаний ещё не созданных функций.
- Основной текст доступен без обязательной регистрации.
- Кнопка ведёт в соответствующий сценарий.
Проверка понимания
Что показывает попадание страницы в индекс?
- Продукт точно востребован
- Страница может участвовать в поисковой выдаче
- Пользователи готовы платить
Показать ответ и объяснение
Страница может участвовать в поисковой выдаче
Индексация — технический этап, спрос проверяется дальнейшим поведением.
Источники
18. Первые пользователиНаблюдать использование подходящей аудиторией.
Начните с людей из выбранной ситуации. Массовый случайный трафик может дать много посещений и мало полезных выводов. Приглашение должно честно объяснять раннюю версию, сценарий и ожидаемое время. Попросите человека выполнить настоящую задачу с допустимыми данными, а не просто посмотреть сайт.
Отмечайте, где вы помогли вручную: такое прохождение не равно самостоятельной активации. После использования спросите, что человек сделал бы без сервиса и что мешает вернуться. Не добавляйте каждую пожеланную функцию сразу. Повторяющаяся проблема нескольких подходящих пользователей весит больше единичной идеи о будущем.
Разбор на примере
Приглашение: «Собрал простой список следующих контактов. Хочу проверить, помогает ли он не забывать договорённости после созвонов. Попробуй записать один следующий шаг; мне важно узнать, где неудобно». Это черновик, отправлять его нужно только выбранным вами людям.
Практическое задание
Подготовьте список подходящих участников и приглашение. Проведите несколько проходов; отдельно отметьте самостоятельные и проходы с вашей помощью.
Критерии готовности
- Участники соответствуют исходной аудитории.
- Есть реальные наблюдения, а не только похвала.
- Ручная помощь не скрыта в метриках.
Проверка понимания
Как интерпретировать проход, где вы всё время подсказывали?
- Как полностью самостоятельную активацию
- Как доказательство спроса
- Как проход с помощью, полезный для поиска затруднений
Показать ответ и объяснение
Как проход с помощью, полезный для поиска затруднений
Помощь меняет условия эксперимента и должна учитываться.
Источники
19. Цена и расходыПроверить, что полезный сценарий экономически возможен.
Цена продукта и его себестоимость — разные величины. Посчитайте постоянные расходы и переменные на активного пользователя: хранение, почта, внешние API и ИИ, если он действительно есть в продукте. ИИ-инструмент, которым вы разрабатывали приложение, относится к вашим расходам разработки; это не обязательно расход каждого запроса пользователя.
Для ИИ-функции учитывайте всю цепочку вызовов, повторы и лимиты. Не обещайте безлимитный тариф до понимания распределения использования. Обсудите цену с человеком в контексте полученной пользы, а не задавайте абстрактный вопрос «сколько готовы платить». Для начала можно проверить интерес к платной версии без реализации сложного биллинга, ясно обозначив, что оплата ещё не подключена.
Разбор на примере
Учебная модель: постоянные расходы 1000 условных единиц в месяц; переменные — 20 на активного пользователя; цена — 100. Вклад пользователя до прочих расходов — 80; для покрытия 1000 нужно не меньше 13 таких пользователей. Это пример арифметики, не тариф и не прогноз.
Практическое задание
Составьте таблицу расходов и три сценария использования: низкий, типичный, высокий. Отдельно отметьте расходы разработки и обслуживания пользователей.
Критерии готовности
- Платные вызовы посчитаны на весь сценарий.
- Есть предел расходов при активном пользователе.
- Гипотетический интерес к цене не выдан за оплату.
Проверка понимания
Подписка на ИИ для написания кода автоматически делает каждый запрос пользователя платным?
- Нет, это зависит от архитектуры самого продукта
- Да
- Да, если в названии есть ИИ
Показать ответ и объяснение
Нет, это зависит от архитектуры самого продукта
Разработка с ИИ и встроенный ИИ — разные источники расходов.
Источники
20. Решение по экспериментуВыбрать следующий шаг по наблюдениям.
Сопоставьте результат с критерием, записанным до запуска. Отдельно рассмотрите приход, активацию, повторное полезное действие и готовность платить. Если никто не дошёл до формы, причина может быть в привлечении или обещании. Если форму заполняют, но не возвращаются, проверьте ценность и частоту задачи. Маленькая выборка даёт направление для следующей проверки, а не окончательный приговор рынку.
Выберите одно изменение с понятной гипотезой. Не переписывайте весь продукт после двух отзывов. Если проблема не подтверждается и участники предпочитают привычную таблицу, допустимо остановить эксперимент. Сохраните работающие материалы и выводы, чтобы следующая попытка стоила дешевле.
Разбор на примере
Пример: из 8 приглашённых 5 открыли сервис, 3 создали контакт, 2 вернулись через неделю. Двум потребовалась помощь с датой. Следующая гипотеза — упростить выбор даты и повторить проверку; утверждать доказанный спрос по этим числам рано.
Практическое задание
Запишите фактическую воронку, три наблюдения и одно решение: продолжить текущий сценарий, изменить его или остановить. Для выбранного изменения задайте новую проверку.
Критерии готовности
- Цифры имеют понятные знаменатели и период.
- Технические тесты и помощь отмечены отдельно.
- Следующий шаг связан с наблюдаемой проблемой.
Проверка понимания
Что делать с низкой активацией после нескольких посещений?
- Сразу переписать весь продукт
- Локализовать место потери и проверить одну гипотезу
- Объявить рынок отсутствующим
Показать ответ и объяснение
Локализовать место потери и проверить одну гипотезу
Малая выборка и разные этапы воронки требуют аккуратной локализации причины.