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

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

Самая частая ошибка на защите: студент открывает 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, в доступном генераторе или вообще провести отдельный ИИ-протокол вручную в паре. Агентская инфраструктура удобна, когда нужно связать файлы, код, браузер и проверку, но её наличие у студента не считается компетенцией само по себе.Оценивается воспроизводимый след: какой материал вошёл, какую операцию выполнил инструмент, что получилось, как результат проверили и кто принял решение. Название сервиса быстро устаревает; способ удерживать полномочия и доказательства остаётся.

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

4. Финальный интерфейс. Прототип в Figma. Экраны, состояния, переходы, микрокопирайтинг. Это видимый результат — но он имеет смысл только в контексте первых трёх слоёв.

Для каждого подключения ИИ назовите не только операцию, но и право:

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

Документировать ИИ нужно затем, чтобы ответить на вопрос, который теперь звучит при каждой защите, — без покаяния и без хвастовства:«Что в этом проекте сделали именно вы?»Ответ «я всё сделал сам» — враньё или наивность. Ответ «всё сделала нейросеть» — капитуляция. Правильный ответ устроен иначе:Я поставил задачу. Я сформулировал критерии. Я сравнил варианты. Я отсёк неработающее. Я собрал процесс. Я принял финальное решение. Я отвечаю за результат.Это и есть авторство в эпоху ИИ: суждение, отсечение, выбор критерия и сборка процесса — а вовсе не романтическое «я создал из ничего», и уж тем более не «всего лишь отбор»; отбор с критерием — это мышление.Артефакт занятия: карта пайплайна; карта полномочий; три существенных отсечения; короткая зона авторской ответственности; один машинный вывод, который вы перепроверили и изменили.

Формат: индивидуально, 8 минут.Задание: вспомните три момента в вашем проекте, когда вы выбирали между вариантами. Для каждого заполните:

Ключевое: столбец «Что потеряли» — самый важный. Любой выбор — это отсечение. Если вы не можете сказать, что потеряли, — вы не делали выбор, а просто брали первое, что попалось.👁 Для исследовательского трека: добавьте четвёртую строку — момент, когда вы приняли решение вопреки рекомендации ИИ. Что послужило основанием?

На втором занятии модуля мы говорили: прототип — не результат, а инструмент. Единица успеха — проверенная гипотеза через прототип и тестирование. Теперь — конкретика: как устроено тестирование и как оформить выводы.

Проба — это процедура, в которой ваш прототип сталкивается с реальностью. На втором курсе это не релиз, не A/B-тест с тысячей пользователей и не формальный usability-аудит. Это малая, но честная проверка: вы даёте реальному человеку пройти сценарий и фиксируете, что происходит.Важно: тестирование — не формальность «для галочки». Это момент, когда вы узнаёте то, чего не могли узнать из Figma. Прототип, с которым никто не взаимодействовал, — это догадка. Прототип, прошедший тестирование, — это знание.

Вы выбираете формат, адекватный вашей гипотезе. Вот основные:Пользовательский тест. Человек проходит ключевой путь в вашем прототипе. Вы наблюдаете и фиксируете: где он понял сценарий, где споткнулся, где удивился, где потерял интерес. Подходит для прикладных проектов и для проверки навигационной логики.Think-aloud-сессия. Тот же проход, но человек проговаривает вслух всё, что видит, думает, ожидает. Вы записываете (аудио, заметки). Самый информативный формат — но требует от участника готовности думать вслух.Короткое интервью до и после. Перед взаимодействием с прототипом — «как вы обычно решаете эту задачу? что вас раздражает?». После — «что изменилось? что запомнилось? что показалось странным?». Разница между «до» и «после» — и есть ваш результат.Дневник наблюдений. Человек взаимодействует с прототипом (или его имитацией) в контексте — на прогулке, в очереди, дома — и записывает, что замечает. Подходит для исследовательских проектов, где эффект разворачивается во времени, а не в одном клике.Сравнение версий. Вы показываете два варианта сценария — либо сценарий и его отсутствие — и фиксируете различие в реакции. Полезно, когда гипотеза связана с изменением поведения или восприятия.Контекстный тест. Вы воспроизводите ситуацию использования (или максимально близкую к ней) и наблюдаете, как прототип работает «в поле», а не за столом. Например: приложение для навигации тестируется на улице, а не в аудитории.

Для учебного проекта 3–5 человек — достаточно. Нильсен показал, что пять пользователей выявляют до 85% проблем юзабилити. У вас задача ещё скромнее: не аудит интерфейса, а проверка одной гипотезы. Три человека, прошедшие сценарий внимательно, — уже серьёзный результат.

Фиксируйте не мнения, а события:— Где человек остановился или замешкался (и как долго). — Что он сказал или сделал не так, как вы ожидали. — Какие вопросы задал (каждый вопрос — симптом неясности в сценарии). — Что описал своими словами иначе, чем вы формулировали. — Какой момент назвал полезным, странным, лишним, непонятным.Для исследовательских проектов дополнительно:— Изменилось ли описание опыта до и после взаимодействия. — Заметил ли человек то, чего раньше не замечал. — Возникла ли новая категория, метафора, наблюдение.

Выводы — не пересказ того, что сказали участники. Это ваша интерпретация, структурированная вокруг гипотезы:1. Что подтвердилось. Какой элемент гипотезы сработал? Конкретно: «4 из 5 участников прошли ключевой путь без помощи» или «3 из 4 участников описали свой маршрут иначе после использования прототипа».2. Что не подтвердилось. Где гипотеза не сработала? Это не провал — это результат: «участники не поняли ценностное предложение на первом экране» или «механика микро-отклонений вызвала раздражение, а не интерес».3. Что удивило. Неожиданные наблюдения, которые не были частью гипотезы, но оказались важными: «двое участников начали использовать приложение не по сценарию и обнаружили функцию, которую мы считали второстепенной».4. Что вы бы изменили. Конкретные решения, которые нужно пересобрать по итогам тестирования. Это показывает, что тестирование было не ритуалом, а рабочим инструментом.Объём: полстраницы–страница. Не эссе, а протокол с выводами.

Для прикладного акцента тестирование отвечает на вопрос: работает ли сервисный сценарий? Понял ли пользователь ценность? Прошёл ли ключевой путь? Где споткнулся? Захотел ли вернуться?Для исследовательского акцента тестирование отвечает на другой вопрос: переорганизовал ли интерфейс восприятие? Заметил ли человек то, чего раньше не замечал? Описывает ли опыт иначе? Возникло ли новое различение?Если ваш проект совмещает оба полюса — формулируйте оба вопроса и проверяйте оба.

Формат: индивидуально, 10 минут.Задание: составьте черновой протокол тестирования для вашего проекта.

Ключевое: последняя строка. Если у вас нет критерия провала — у вас нет тестирования, а есть ритуал подтверждения. Вспомните лекцию о гипотезе: слабая гипотеза знает, при каком условии она рухнет.Что я проверю: есть ли у вас конкретный формат (а не «мы потестим»), конкретные участники (а не «попросим кого-нибудь») и конкретный критерий провала (а не «посмотрим, что получится»).

Теперь соберём всё в единую структуру показа. Презентацию лучше строить не от набора экранов, а от связки: контекст → проблема → решение → детальный показ через сценарии → техническая реализация → бренд → метрики → выводы.

Перед тем как собирать слайды, назовите действие, которое должно случиться в голове аудитории. Формулировка «рассказать о приложении» слишком рыхлая. Рабочая цель звучит так: слушатель понимает, какую задачу решает сервис; видит, почему приложение уместнее сайта, бота или таблицы; может пересказать вашу гипотезу одним предложением; верит, что вы проверяли, а не украшали.Цель-действие должна быть конкретной. Если после показа человек может сказать только «ну, у них там приложение», презентация не сработала. Если он может сказать «они проверяют, можно ли через такой мобильный сценарий изменить вот это поведение», значит проект стал видимым.

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

1. Проблема и контекст. Одно предложение: какую задачу решает ваш сервис и для кого. Не «моё приложение помогает людям», а конкретная ситуация, конкретная боль, конкретный контекст использования.2. Гипотеза. Ваше утверждение о том, что мобильное приложение — адекватная форма для этой задачи. Почему именно приложение, а не сайт, бот, рассылка, человек?3. Пользователь и его мир. Не абстрактная ЦА («женщины 25–35»), а ситуация использования: где он, что делает, что прерывает, что чувствует, какое у него время.4. Сценарий (ААРРР). Путь от незнания к пользе. Аудитория → Азарт → Регулярность → Распространение → Рубли. Это позвоночник презентации: вы показываете не экраны, а историю.5. Ключевые экраны и интерфейсная логика. Здесь — Figma. Но не как каталог, а как иллюстрация к сценарию. Каждый экран отвечает на вопрос: что здесь происходит в истории пользователя?6. Особые случаи. Первый запуск (empty state), ошибка, офлайн, edge case. Покажите, что ваш сценарий не висит в пустоте.7. Визуальный язык и бренд. Brand Fingerprint из прошлого занятия: шрифт, цвет, иконки, движение, голос. Почему этот сервис выглядит именно так?8. ИИ-пайплайн. Один слайд: какие инструменты использовались, что сделал ИИ, что сделали вы, какие варианты отброшены. Открытость здесь — честность, а не повод для стыда.9. Проба и результаты. Как вы проверяли гипотезу? Кто участвовал, в каком контексте, что зафиксировали? Покажите не «мы потестили и всем понравилось», а конкретные наблюдения: что подтвердилось, что нет, что удивило. Этот блок превращает вашу презентацию из рассказа о намерении в рассказ о проверке.10. Вывод. Что доказывает ваш проект? Что вы узнали? Что бы вы сделали иначе? Куда проект может пойти дальше?

Структура одна, но акценты различаются.Прикладной проект усиливает блоки 1–4 и 6: проблема реальна, сценарий проверен, edge cases продуманы. Вывод звучит как: «этот сервис решает задачу X лучше, чем существующие альтернативы, потому что…»Исследовательский проект усиливает блоки 2, 3, 8 и 9: гипотеза нетривиальна, контекст исследован, процесс задокументирован, вывод содержит знание, а не только продукт. Вывод звучит как: «мы проверили, может ли интерфейс X изменить отношение пользователя к Y, и выяснили, что…»Обе версии обязаны ответить на одни и те же вопросы: почему это приложение, какой у него контекст, кто пользователь, как устроен сценарий, что проверяется, как это выражено в интерфейсе. Различается не набор вопросов, а тип ответа.

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

Структура задаёт маршрут изменения зрителя. В начале он знает меньше, чем в конце; в начале проект может казаться очередным приложением, в конце становится проверяемой гипотезой с собственной логикой.Для прикладного проекта удобно держать схему: боль → решение → доказательство → действие. Для исследовательского проекта: проблема → гипотеза → проверка → результат. Для смешанного проекта: ситуация → осложнение → разрешение. Считайте их траекториями внимания; механическая сборка быстро делает проект плоским. Вы выбираете ту, где ваш проект раскрывается с наименьшим шумом и наибольшей силой.

Формат: в парах, 15 минут (5 минут — показ, 2 минуты — обратная связь, потом меняемся).Задание: покажите свой проект партнёру, используя структуру 10 блоков. Не открывайте Figma — рассказывайте устно, используя максимум 3 экрана как иллюстрации.Правило для слушающего: после показа ответьте на три вопроса:1. Я понял (а), зачем этот сервис существует? (да/нет/частично)
2. Я понял (а), как человек в него попадает и что получает? (да/нет/частично)
3. Я запомнил (а) одну деталь, которая отличает этот проект от других? (если да — какую)Если на все три вопроса «нет» — презентацию нужно пересобрать. Это нормально. Для этого мы здесь.👁 Для исследовательского трека: вместо вопроса 3 слушающий отвечает: «Я узнал (а) что-то новое об X благодаря этому проекту?» Если нет — гипотеза не работает как знание.

У зрителя мало энергии, мало времени и много способов перестать понимать. Мозгу проще узнавать уже знакомое, чем собирать новую модель; проще схватить форму, чем разбирать вязкую кучу деталей. Поэтому презентация сложного продукта должна быть визуально чище самого продукта: сложность остаётся в логике сценария, а показ даёт траекторию, по которой можно пройти без застревания.Отсюда практическая дисциплина: каждый слайд ведёт один поворот мысли; экран, график или результат теста появляются только тогда, когда из них сразу следует вывод. Когда на слайде десять равноправных объектов, аудитория начинает экономить себя и отключаться.

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

Хайдеггер возвращается к греческому слову ἀλήθεια, алетейя, переводя его как несокрытость. В «Бытии и времени» и позднем эссе «О сущности истины» истина перестаёт быть только правильностью высказывания: прежде чем сравнивать фразу с фактом, мир должен каким-то образом открыться. При этом несокрытость не выдаёт вещь «как она есть целиком». Всякое раскрытие удерживает остаток в тени, а привычный способ показа способен превратиться в новое сокрытие.Что это значит для презентации?Презентация разворачивается как акт несокрытия: она выбирает, в каком свете проект сможет явиться комиссии. Глянцевый мокап раскрывает визуальный язык и легко скрывает отсутствие сценария; карта экранов показывает объём и скрывает качество переходов; эффектный ролик прячет нечитаемый error state скоростью монтажа. Нейтральной подачи нет — каждый слайд проводит границу между свидетельством и кулисой.

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

Различие карты (carte) и кальки (calque) появляется во введении к «Тысяче плато», где Делёз и Гваттари описывают принципы ризомы. Калька воспроизводит уже организованные оси и структуры; карта открыта, соединяема, изменяема, допускает множество входов и может быть разорвана, а затем собрана в другой конфигурации. Авторы предупреждают и о более сложном обороте: кальку следует возвращать на карту, потому что чистое противопоставление быстро само становится калькой.

Что это значит для вашего проекта?Студенческий проект легко становится калькой: ещё один трекер воспроизводит знакомую навигацию, прогресс-кольцо и ритуал серии дней, хотя исходная гипотеза говорила о совсем другом опыте времени. Генеративная модель ускоряет это возвращение узнаваемого. По запросу она способна собрать десятки правдоподобных экранов, поскольку обучена продолжать существующие паттерны; количество вариантов не гарантирует выхода из проторенной колеи. В AI-фотографии похожая опасность создаёт бесконечную ленту эффектных одиночных кадров без режиссуры серии.Проект-карта строит новые связи между наблюдением, действием и средой. Он может использовать привычный таб-бар — отказ от всякой конвенции сам по себе ничего не изобретает, — но в одном критическом месте перестраивает территорию задачи. Карта допускает белое пятно и показывает маршрут, которым его собираются исследовать. Авторство здесь проявляется в отборе, постановке опыта и ответственности за отклонение, а не в требовании создать форму, никогда прежде не виденную человечеством.Практический вывод: спросите себя честно — мой проект — карта или калька? Если калька — что нужно изменить, чтобы в нём появился хотя бы один жест эксперимента? Одна зона, где вы не скопировали, а изобрели.Вопрос к проекту: где вы воспроизвели знакомое приложение так точно, что гипотеза перестала быть видна?Вмешательство: замените одну кальку экспериментальной веткой и покажите, какое наблюдение или теоретическая линза оправдывает отклонение.

В алхимических текстах nigredo обозначает почернение, разложение и putrefactio вещества. Единой обязательной последовательности стадий для всей алхимической традиции не существовало: лабораторные рецепты, религиозные аллегории и позднейшая психологическая символика расходятся. Поэтому фраза «первая стадия всякого алхимического процесса» была бы слишком уверенной. В нашем курсе нигредо работает как авторская палеонимия — старое имя для производственного режима, где проект разрешает проверке разложить собственную цельность.На защите это означает право показать незавершённость, прошедшую через опыт и оставившую свидетельства. Недомакетированный экран без исследования остаётся недоделкой; удалённая функция после наблюдаемого провала становится знанием о системе. Чернота не выдаёт автоматическую индульгенцию. Она ценна, когда можно восстановить реакцию: что именно разложилось, каким реагентом, какое решение стало возможным после распада.

Что это значит для защиты?Сильная презентация показывает след мышления: здесь модель предложила убедительную банальность, здесь тест разрушил исходный сценарий, здесь команда отрезала красивый фрагмент, здесь сохранила ограничение вместо ложного обещания. Формула «я не успел, но понимаю» сама по себе ничего не доказывает; к ней нужен следующий шаг, критерий и след уже сделанной проверки.Помните: за каждым экраном стоит некоторая картина мира. Наша задача — научиться эту картину видеть, критиковать и проектировать сознательно. Даже если на экране пока только чернота — это чернота, через которую рождается форма.Вопрос к проекту: что умерло после проверки — любимая функция, исходная гипотеза, визуальный приём — и почему вы всё ещё скрываете труп?Вмешательство: покажите одну связку «было → свидетельство → решение → стало». Этот след разложения доказывает, что проект действительно прошёл через опыт.

Формат: индивидуально, 12 минут. Это последний чекпойнт курса.Задание: заполните итоговую карточку проекта — она станет основой для вашей финальной презентации.

Тест: покажите карточку соседу. Если за 60 секунд он понимает, о чём проект, — вы готовы к презентации.👁 Для исследовательского трека: замените строку «Ключевой экран» на «Ключевой опыт» — какой момент взаимодействия с интерфейсом лучше всего демонстрирует вашу гипотезу?

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

Перед тем как считать презентацию готовой, проверьте, как она работает; красота без этого превращается в косметику:⚫️ Есть ли ясная цель-действие: что должно измениться у слушателя после показа?
⚫️ Есть ли один тезис, который можно повторить без слайдов?
⚫️ Видна ли структура: зритель понимает, куда вы его ведёте?
⚫️ Каждый визуальный материал помогает мысли или просто заполняет пустоту?
⚫️ Дизайн слайдов соответствует содержанию проекта, а не живёт отдельной маленькой карьерой?
⚫️ Есть ли место, где вы показываете проверку, слабое место или отсечение?

Финальный пакет проекта.Это итоговая сдача модуля — и итоговая сдача курса. Пакет состоит из пяти частей, последняя опциональна.Часть 1. Презентация (10–15 слайдов)Структура: 10 блоков, описанных выше. Формат: Keynote, Google Slides или Figma.Обязательные слайды: ● Проблема и контекст (1 слайд) ● Гипотеза (1 слайд) ● Пользователь и ситуация (1 слайд) ● Путь ААРРР (2–3 слайда со сценарием) ● Ключевые экраны (3–4 слайда) ● Особые случаи: первый запуск, ошибка (1 слайд) ● Визуальный язык и бренд (1 слайд) ● ИИ-пайплайн (1 слайд) ● Вывод (1 слайд)Часть 2. Прототип (Figma)Интерактивный прототип ключевого сценария. Минимум 8–12 экранов, связанных переходами. Обязательно: первый запуск (empty state), основной сценарий, хотя бы один edge case.Часть 3. Результаты тестирования (полстраницы–страница)Протокол проверки гипотезы: формат тестирования, участники, контекст, ключевые наблюдения, выводы (что подтвердилось, что нет, что удивило, что бы вы изменили). Формат: Google Doc, FigJam или слайды.Часть 4. ИИ-пайплайн (1 страница)Карта инструментов + карта полномочий + журнал отсечений (минимум 3 задокументированных решения). Формат: FigJam, Google Doc или слайд.Часть 5. Видеосценарий (опционально, но рекомендуется)Запись прохождения прототипа с голосовым комментарием (1–3 минуты). Показывает путь пользователя, а не набор экранов.👁 Для исследовательского трека (дополнительно):Добавьте Research Brief (300–500 слов): исследовательский вопрос, теоретическая рамка, гипотеза, что проверялось интерфейсом, что обнаружено. Это документ, который превращает ваш проект из «приложения» в исследование.Формат сдачи: Figma (прототип) + Keynote/Google Slides/Figma (презентация) + Google Doc/FigJam (результаты тестирования) + FigJam/Google Doc (ИИ-пайплайн).

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

Это не бюрократия, а часть проектного мышления. Документация показывает не «использовали ли вы ИИ», а как вы думали.

1. Карта пайплайна

2. Лог отбора и отсечения

3. Зона авторской ответственности

Например: «Инструмент собрал базовую структуру экранов по моему контракту, но навигационную модель и иерархию я изменил после проверки сценария. Модель помогла сгруппировать Job Stories, однако две группы я распустил: в исходных наблюдениях для них не было достаточных свидетельств».

⚫️ Использовать ИИ на любом этапе проекта.
⚫️ Использовать несколько ИИ-инструментов одновременно.
⚫️ Взять из ИИ-результата значительную часть визуала, если это задокументировано и объяснено.

⚫️ Скрытое использование: выдать полностью сгенерированный результат за самостоятельную работу.
⚫️ Фальсификация процесса: приложить чужие промпты или придуманный лог.
⚫️ Отсутствие документации при очевидном использовании ИИ.

Это место, где мы останавливаемся и смотрим назад. На весь курс, а не только на этот модуль.

Четыре модуля. Лонгриды, лендинги, концептуальные интернет-магазины, мобильные сервисы. Десятки экранов, сценариев, гипотез, разборов. Философия, которую вы, возможно, не просили, но которая — я надеюсь — изменила то, как вы смотрите на экран.

В начале курса мы обещали:Мы не будем учить вас поклоняться инструментам, которые устареют через полгода.Мы не будем делать вид, что достаточно выучить набор кнопок и после этого профессия будет вам что-то гарантировать.Мы не будем выдавать теорию за необязательный декоративный слой.Но мы будем требовать мыслительной работы. И будем помогать вам переводить эту работу в проектные решения.Я надеюсь, это обещание было выполнено. По крайней мере, мы старались.

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

Набор скиллов по Figma устареет, список философов забудется — а вот кое-что более устойчивое:Гипотеза важнее производства. Прежде чем рисовать экран — ответьте на вопрос «зачем». Если ответ «потому что задание» — вы ещё не начали.Теория — инструмент, а не украшение. Если идея никак не меняет ваш интерфейс, вы её пока не применили.ИИ — среда, а не фетиш: документировать, сравнивать, решать самому — вместо поклонения или страха.Странность без хаоса, ясность без банальности. Хороший проект — форма, в которой есть след мысли, а не только след насмотренности.Авторство сводится к суждению: «я поставил задачу, выбрал критерий, отсёк лишнее и отвечаю за результат» — а не «я создал из ничего».

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