4.8. ИИ-пайплайн и презентация мобильного продукта

На прошлом занятии мы собрали визуальный язык: дизайн-систему, платформенную грамматику, брендинговый голос. У вас есть инструмент. Сегодня — последнее занятие модуля. И последнее занятие всего курса. Поэтому мы сделаем две вещи: научимся показывать проект так, чтобы он был понятен как замысел, а не как набор экранов. И подведём итог: что именно мы здесь делали весь год и зачем.Финальный предмет показа — небольшой запускаемый мобильный сервис: человек открывает его на телефоне, выполняет основное действие и получает заявленный результат. Допустимо мобильное веб-приложение и любая доступная среда сборки, включая вайбкодинг. Figma помогает объяснить решения; работоспособность подтверждается исполнением. Полный стартап, сложный сервер, настоящая оплата и публикация в магазинах приложений не требуются. Резервный прототип допустим в заранее согласованном объёме, с явными пределами доказательства.

Самая частая ошибка на защите: студент открывает Figma, листает экраны слева направо и говорит: «Вот здесь у нас главная. Вот здесь каталог. Вот здесь карточка товара. Вот здесь корзина». Листает и листает. Комиссия смотрит, кивает, скучает. Через три минуты всё сливается: одни экраны похожи на другие, один проект похож на другой.Перед нами склад фич — а склад аргументом не становится.Хороший проект выстраивается как аргумент — с тезисом (гипотезой), доказательством (сценарием) и материалом (интерфейсом). Когда вы показываете проект, вы не демонстрируете красивые макеты — вы доказываете, что ваш сервис имеет право на существование. Что он решает задачу, которую стоит решать. Что он решает её способом, который стоит попробовать. Что человек, для которого он предназначен, действительно пройдёт от незнания к пользе, от первого входа к возвращению.

Вывод, с которого мы начинаем: презентация проекта разворачивается как рассказ о необходимости — демонстрация того, что вы эту необходимость не выдумали, а проверили; Figma здесь лишь иллюстрация, а не маршрут показа.

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

Для того чтобы показать проект как путь, а не как витрину, нам нужна драматургическая рамка. Одна из самых удобных — ААРРР (Аудитория · Азарт · Регулярность · Распространение · Рубли; в оригинале у Дейва МакКлюра — Acquisition, Activation, Retention, Referral, Revenue), предложенная для стартапов, но в нашем случае работающая как сценарная партитура показа.Для модульного проекта ААРРР полезен как набор вопросов о встрече человека с продуктом. Это адаптируемая рамка показа, без обязанности придумывать монетизацию и удержание там, где сервис рассчитан на бесплатный или однократный опыт.

Акт 1. А — Аудитория: откуда человек вообще узнаёт о вас.Пользователь сначала должен где-то увидеть, что существует нечто, способное решить его задачу. Это может быть поиск в App Store, пост друга, QR-код на плакате, ссылка в мессенджере, баннер в соцсети. Не обязательно просчитывать медиаплан — но обязательно показать, откуда человек вообще попадает в ваш сценарий.Если ваша презентация начинается с «пользователь открывает приложение» — вы уже пропустили полмира. Откуда он его взял?Акт 2. А — Азарт: первый реальный смысл.Не регистрация — а момент, когда человек понимает: «это то, что мне нужно». Ага-момент. Для одного приложения — первый найденный маршрут. Для другого — первый сохранённый рецепт. Для третьего — первое сообщение, на которое ответили.Большинство студенческих сценариев перескакивают через пустые состояния, онбординг, первый вход и первое полезное действие. Именно здесь видно, умеете ли вы проектировать начало опыта, а не только красивый интерфейс на заполненных экранах.

Акт 3. Р — Регулярность: возвращаемость, а не удержание.Хорошая формулировка: не «как удержать пользователя», а «почему он захочет вернуться». Не из-за push-уведомлений и streak-ов. А потому что получил пользу, что-то сохранил, что-то настроил, что-то присвоил. Вещь становится твоей после первого пользования — и ты к ней возвращаешься, как к своему стакану.Акт 4. Р — Распространение: почему довольный пользователь станет советовать.Не потому что «есть кнопка поделиться». А потому что опыт оказался стоящим разговора. Покажите в презентации: что именно человек скажет другу? «Попробуй, там…» — что?Акт 5. Р — Рубли: в какой момент ценность переходит в оплату.Если у проекта есть модель оплаты, объясните, что именно приобретается. Выручка означает деньги; внимание, время и доверие — другие виды участия, их не нужно переименовывать в рубли. Для бесплатного проекта честно обозначьте отсутствие оплаты и условия получения результата. Завершённый исследовательский опыт также может оставаться бесплатным.

Главное: ААРРР в презентации нужен не затем, чтобы изображать из себя пирата. А затем, чтобы показать живую логику проекта. Хороший сценарий отвечает не только на вопрос «что умеет интерфейс», но и на вопросы: как человек узнаёт, почему остаётся, почему возвращается, почему советует и в какой момент готов заплатить.

Формат: индивидуально, 10 минут.Задание: заполните ААРРР-карту для вашего мобильного сервиса.

Тест: у применимых этапов есть основание в сценарии. Для неприменимого этапа напишите почему: отсутствие оплаты или повторного использования может быть осмысленным свойством продукта. Гипотезы распространения не выдавайте за уже измеренный спрос.👁 Для исследовательского трека: можно заменить вопрос о рублях вопросом о новом различении: что человек или автор исследования обнаруживает благодаря взаимодействию? Это адаптация рамки, без заявления, что знание уже продано.

В начале курса мы договорились: ИИ в этом курсе не запрещён, но и не является волшебным заместителем мышления. Настало время предъявить результат этого договора.

Платная подписка на ChatGPT, Claude, Adobe или другой западный сервис для курса не требуется. Можно работать в Qwen, Kimi, DeepSeek, с локальной моделью, через общий стенд AI-Lab, в доступном генераторе или вообще провести отдельный ИИ-протокол вручную в паре. Агентская инфраструктура удобна, когда нужно связать файлы, код, браузер и проверку, но её наличие у студента не считается компетенцией само по себе.Оценивается воспроизводимый след: какой материал вошёл, какую операцию выполнил инструмент, что получилось, как результат проверили и кто принял решение. Название сервиса быстро устаревает; способ удерживать полномочия и доказательства остаётся.Школьные лимиты, модели и режимы работы используем только после подтверждения доступа. Чат с LLM не гарантирует кодинг-агента, постоянный контекст и skills. Контекст проекта хранится переносимыми файлами; при отсутствии нужной функции заранее согласуется другой способ работы. Обязательный объём не должен требовать личных расходов сверх фактически предоставленного ресурса.

Проект складывается из четырёх слоёв:1. Концептуальная рамка. Гипотеза, контекст, пользователь, задача, теоретическая оптика. Это то, что определяет зачем проект существует. Модель может предложить проблему и убедительно её описать, но не может отвечать за то, что проблема реальна и стоит вмешательства.2. Карта пайплайна. Какие инструменты вы использовали и для чего. Figma или Penpot — для прототипирования; Qwen, Kimi, DeepSeek, ChatGPT, Claude или локальная модель — для текстовых и аналитических операций; доступный генератор — для визуального или звукового материала. Что угодно — но задокументированное. Не как исповедь, а как карта процесса.3. Журнал решений. Сохраняет существенные принятия, правки и отсечения вместе с критериями. Почему оставлена именно эта версия? Что показала проверка? Если модель сразу предложила подходящее решение, его не нужно портить или переписывать вручную ради доказательства труда.

4. Финальный интерфейс. Запускаемая версия с проверенным основным путём, состояниями и фактическим результатом. К ней прилагаются исходники и инструкция запуска. Макет в Figma может объяснять решение или служить согласованным резервным форматом; он не подтверждает невыполненные операции.