Последнее занятие модуля: от дизайн-системы — к показу. Презентация проекта — не экскурсия по Figma, а аргумент: тезис, доказательство, материал. Лекция объясняет ААРРР как сценарную партитуру защиты, показывает, как ИИ-пайплайн ускоряет прототипирование, и вводит «журнал отсечений» — документ честности о том, чего дизайнер решил не делать.
На прошлом занятии мы собрали визуальный язык: дизайн-систему, платформенную грамматику, брендинговый голос. У вас есть инструмент. Сегодня — последнее занятие модуля. И последнее занятие всего курса. Поэтому мы сделаем две вещи: научимся показывать проект так, чтобы он был понятен как замысел, а не как набор экранов. И подведём итог: что именно мы здесь делали весь год и зачем.
Проект — не набор экранов, а аргумент
Самая частая ошибка на защите: студент открывает Figma, листает экраны и говорит: «Вот здесь у нас главная. Вот здесь каталог. Вот здесь карточка товара. Вот здесь корзина». Листает и листает. Комиссия смотрит, кивает, скучает. Через три минуты засыпает: один экран похож на другой, один проект похож на все остальные.
Это склад фич. А склад — не аргумент.
Хороший проект — это аргумент. У него есть тезис (гипотеза), доказательство (сценарий) и материал (интерфейс). Когда вы показываете проект, вы не демонстрируете красивые макеты — вы доказываете, что ваш сервис имеет право на существование. Что он решает задачу, которую стоит решать. Что он решает её способом, который стоит попробовать. Что человек, для которого он предназначен, действительно пройдёт от незнания к пользе, от первого входа к возвращению.
Вывод, с которого мы начинаем: презентация проекта — это не экскурсия по Figma. Это рассказ о необходимости — и демонстрация того, что вы эту необходимость не выдумали, а проверили.
ААРРР: драматургия показа
Для того чтобы показать проект как путь, а не как витрину, нам нужна драматургическая рамка. Одна из самых удобных — ААРРР (Аудитория · Азарт · Регулярность · Распространение · Рубли; в оригинале у Дейва МакКлюра — Acquisition, Activation, Retention, Referral, Revenue), предложенная для стартапов, но в нашем случае работающая как сценарная партитура показа.
Это не бухгалтерия. Это не культ «роста». Для диплома ААРРР полезен прежде всего как ответ на вопрос: что происходит с человеком, когда он встречает ваш продукт?
Пять актов драмы
Акт 1. А — Аудитория: откуда человек вообще узнаёт о вас.
Пользователь сначала должен где-то увидеть, что существует нечто, способное решить его задачу. Это может быть поиск в App Store, пост друга, QR-код на плакате, ссылка в мессенджере, баннер в соцсети. Не обязательно просчитывать медиаплан — но обязательно показать, откуда человек вообще попадает в ваш сценарий.
Если ваша презентация начинается с «пользователь открывает приложение» — вы уже пропустили полмира. Откуда он его взял?
Акт 2. А — Азарт: первый реальный смысл.
Это не регистрация. Это момент, когда человек понимает: «это то, что мне нужно». Ага-момент. Для одного приложения — первый найденный маршрут. Для другого — первый сохранённый рецепт. Для третьего — первое сообщение, на которое ответили.
Большинство студенческих сценариев перескакивают через пустые состояния, онбординг, первый вход и первое полезное действие. Именно здесь видно, умеете ли вы проектировать начало опыта, а не только красивый интерфейс на заполненных экранах.
Акт 3. Р — Регулярность: возвращаемость, а не удержание.
Хорошая формулировка: не «как удержать пользователя», а «почему он захочет вернуться». Не из-за push-уведомлений и streak-ов. А потому что получил пользу, что-то сохранил, что-то настроил, что-то присвоил. Вещь становится твоей после первого пользования — и ты к ней возвращаешься, как к своему стакану.
Акт 4. Р — Распространение: почему довольный пользователь станет советовать.
Не потому что «есть кнопка поделиться». А потому что опыт оказался стоящим разговора. Покажите в презентации: что именно человек скажет другу? «Попробуй, там…» — что?
Акт 5. Р — Рубли: в какой момент ценность переходит в оплату.
Где именно возникает достаточная ценность, чтобы человек заплатил, подписался, оформил покупку, выбрал премиум? Это не обязательно деньги — это может быть инвестиция внимания, времени, данных, доверия. Но она должна быть обоснована.
Главное: ААРРР в презентации нужен не затем, чтобы изображать из себя пирата, а затем, чтобы показать живую логику проекта. Хороший сценарий отвечает не только на вопрос «что умеет интерфейс», но и на вопросы: как человек узнаёт, почему остаётся, почему возвращается, почему советует и в какой момент готов заплатить.
Интерактив 1. ААРРР-маршрут вашего проекта
Формат: индивидуально, 10 минут.
Задание: заполните ААРРР-карту для вашего мобильного сервиса:
● Аудитория. Откуда человек узнаёт о вашем приложении? Конкретный канал.
● Азарт. Какое первое действие приносит ему реальный смысл? (Не регистрация!)
● Регулярность. Почему он вернётся завтра? Что он «присвоил»?
● Распространение.Что именно он скажет другу? Одна фраза.
● Рубли. В какой момент он готов заплатить? Чем и за что?
Тест для самопроверки: если хотя бы одна ячейка пуста — ваш проект пока показан как набор деталей, а не как решение.
👁 Для исследовательского трека: замените Рубли на Инсайт — в какой момент пользователь (или вы сами) узнаёте что-то новое благодаря взаимодействию с интерфейсом? Исследовательский проект продаёт не сервис, а знание.
ИИ-пайплайн: что сделали вы, а что — инструмент
В начале курса мы договорились: ИИ в этом курсе не запрещён, но и не является волшебным заместителем мышления. Настало время предъявить результат этого договора.
Четыре слоя проекта
Студент сдаёт не просто набор экранов, а проект, состоящий из четырёх слоёв:
1. Концептуальная рамка. Гипотеза, контекст, пользователь, задача, теоретическая оптика. Это то, что определяет зачем проект существует. Ни одна нейросеть не может за вас решить, какую проблему стоит решать.
2. Карта пайплайна. Какие инструменты вы использовали и для чего. Figma для прототипирования. ChatGPT для генерации вариантов user stories. Midjourney для поиска визуального направления. Claude для анализа конкурентов. Suno для звуковых экспериментов. Что угодно — но задокументированное. Не как исповедь, а как карта процесса.
3. Журнал отсечений. Самый важный и самый недооценённый слой. Это документация того, что вы отбросили и почему. Нейросеть предложила 20 вариантов — вы выбрали один. Почему именно этот? Что было не так с остальными? Какой критерий вы применили?
4. Финальный интерфейс. Прототип в Figma. Экраны, состояния, переходы, микрокопирайтинг. Это видимый результат — но он имеет смысл только в контексте первых трёх слоёв.
Зачем документировать ИИ
Не для того чтобы покаяться. И не для того чтобы похвастаться. А для того чтобы ответить на вопрос, который теперь звучит при каждой защите:
«Что в этом проекте сделали именно вы?»
Ответ «я всё сделал сам» — враньё или наивность. Ответ «всё сделала нейросеть» — капитуляция. Правильный ответ устроен иначе:
Я поставил задачу. Я сформулировал критерии. Я сравнил варианты. Я отсёк неработающее. Я собрал процесс. Я принял финальное решение. Я отвечаю за результат.
Это и есть авторство в эпоху ИИ: не романтическое «я создал из ничего», а суждение, отсечение, выбор критерия и сборка процесса. Но это не «всего лишь отбор». Это и есть важная часть мышления.
Интерактив 2. Три отсечения
Формат: индивидуально, 8 минут.
Задание: вспомните три момента в вашем проекте, когда вы выбирали между вариантами. Для каждого заполните:
● Момент решения ● Варианты (откуда: ИИ / свой / референс) ● Что выбрали ● Почему ● Что потеряли
Ключевое: поле «Что потеряли» — самое важное. Любой выбор — это отсечение. Если вы не можете сказать, что потеряли, — вы не делали выбор, а просто брали первое, что попалось.
👁 Для исследовательского трека: добавьте шестое поле — момент, когда вы приняли решение вопреки рекомендации ИИ. Что послужило основанием?
Пользовательское тестирование: как проверить гипотезу через прототип
На втором занятии модуля мы говорили: прототип — не результат, а инструмент. Единица успеха — проверенная гипотеза через прототип и тестирование. Теперь — конкретика: как устроено тестирование и как оформить выводы.
Что такое тестирование
Проба — это процедура, в которой ваш прототип сталкивается с реальностью. На втором курсе это не релиз, не A/B-тест с тысячей пользователей и не формальный usability-аудит. Это малая, но честная проверка: вы даёте реальному человеку пройти сценарий и фиксируете, что происходит.
Важно: тестирование — не формальность «для галочки». Это момент, когда вы узнаёте то, чего не могли узнать из Figma. Прототип, с которым никто не взаимодействовал, — это догадка. Прототип, прошедший тестирование, — это знание.
Форматы тестирования
Вы выбираете формат, адекватный вашей гипотезе. Вот основные:
Пользовательский тест. Человек проходит ключевой путь в вашем прототипе. Вы наблюдаете и фиксируете: где он понял сценарий, где споткнулся, где удивился, где потерял интерес. Подходит для прикладных проектов и для проверки навигационной логики.
Think-aloud-сессия. Тот же проход, но человек проговаривает вслух всё, что видит, думает, ожидает. Вы записываете (аудио, заметки). Самый информативный формат — но требует от участника готовности думать вслух.
Короткое интервью до и после. Перед взаимодействием с прототипом — «как вы обычно решаете эту задачу? что вас раздражает?». После — «что изменилось? что запомнилось? что показалось странным?». Разница между «до» и «после» — и есть ваш результат.
Дневник наблюдений. Человек взаимодействует с прототипом (или его имитацией) в контексте — на прогулке, в очереди, дома — и записывает, что замечает. Подходит для исследовательских проектов, где эффект разворачивается во времени, а не в одном клике.
Сравнение версий. Вы показываете два варианта сценария (или сценарий vs. отсутствие сценария) и фиксируете, где различие в реакции. Полезно, когда гипотеза про изменение поведения или восприятия.
Контекстный тест. Вы воспроизводите ситуацию использования (или максимально близкую к ней) и наблюдаете, как прототип работает «в поле», а не за столом. Например: приложение для навигации тестируется на улице, а не в аудитории.
Сколько участников
Для учебного проекта 3–5 человек — достаточно. Нильсен показал, что пять пользователей выявляют до 85% проблем юзабилити. У вас задача ещё скромнее: не аудит интерфейса, а проверка одной гипотезы. Три человека, прошедшие сценарий внимательно, — уже серьёзный результат.
Что фиксировать
Фиксируйте не мнения, а события:
— Где человек остановился или замешкался (и как долго). — Что он сказал или сделал не так, как вы ожидали. — Какие вопросы задал (каждый вопрос — симптом неясности в сценарии). — Что описал своими словами иначе, чем вы формулировали. — Какой момент назвал полезным, странным, лишним, непонятным.
Для исследовательских проектов дополнительно:
— Изменилось ли описание опыта до и после взаимодействия. — Заметил ли человек то, чего раньше не замечал. — Возникла ли новая категория, метафора, наблюдение.
Как оформить выводы
Выводы — не пересказ того, что сказали участники. Это ваша интерпретация, структурированная вокруг гипотезы:
Что подтвердилось. Какой элемент гипотезы сработал? Конкретно: «4 из 5 участников прошли ключевой путь без помощи» или «3 из 4 участников описали свой маршрут иначе после использования прототипа».
Что не подтвердилось. Где гипотеза не сработала? Это не провал — это результат: «участники не поняли ценностное предложение на первом экране» или «механика микро-отклонений вызвала раздражение, а не интерес».
Что удивило. Неожиданные наблюдения, которые не были частью гипотезы, но оказались важными: «двое участников начали использовать приложение не по сценарию и обнаружили функцию, которую мы считали второстепенной».
Что вы бы изменили. Конкретные решения, которые нужно пересобрать по итогам тестирования. Это показывает, что тестирование было не ритуалом, а рабочим инструментом.
Объём: полстраницы–страница. Не эссе, а протокол с выводами.
Проба для двух полюсов проекта
Для прикладного акцента тестирование отвечает на вопрос: работает ли сервисный сценарий? Понял ли пользователь ценность? Прошёл ли ключевой путь? Где споткнулся? Захотел ли вернуться?
Для исследовательского акцента тестирование отвечает на другой вопрос: переорганизовал ли интерфейс восприятие? Заметил ли человек то, чего раньше не замечал? Описывает ли опыт иначе? Возникло ли новое различение?
Если ваш проект совмещает оба полюса — формулируйте оба вопроса и проверяйте оба.
Структура презентации: от проблемы к выводу
Теперь соберём всё в единую структуру показа. Презентацию лучше строить не от набора экранов, а от связки: контекст → проблема → решение → детальный показ через сценарии → техническая реализация → бренд → метрики → выводы.
Девять блоков защиты
1. Проблема и контекст. Одно предложение: какую задачу решает ваш сервис и для кого. Не «моё приложение помогает людям», а конкретная ситуация, конкретная боль, конкретный контекст использования.
2. Гипотеза. Ваше утверждение о том, что мобильное приложение — адекватная форма для этой задачи. Почему именно приложение, а не сайт, бот, рассылка, человек?
3. Пользователь и его мир. Не абстрактная ЦА («женщины 25–35»), а ситуация использования: где он, что делает, что прерывает, что чувствует, какое у него время.
4. Сценарий (ААРРР). Путь от незнания к пользе. Аудитория → Азарт → Регулярность → Распространение → Рубли. Это позвоночник презентации: вы показываете не экраны, а историю.
5. Ключевые экраны и интерфейсная логика. Здесь — Figma. Но не как каталог, а как иллюстрация к сценарию. Каждый экран отвечает на вопрос: что здесь происходит в истории пользователя?
6. Особые случаи. Первый запуск (empty state), ошибка, офлайн, edge case. Покажите, что ваш сценарий не висит в пустоте.
7. Визуальный язык и бренд. Brand Fingerprint из прошлого занятия: шрифт, цвет, иконки, движение, голос. Почему этот сервис выглядит именно так?
8. ИИ-пайплайн. Один слайд: какие инструменты использовались, что сделал ИИ, что сделали вы, какие варианты отброшены. Это не стыдно — это честно.
9. Вывод. Что доказывает ваш проект? Что вы узнали? Что бы вы сделали иначе?
Как показывать два типа проектов
Структура одна, но акценты различаются.
Прикладной проект усиливает блоки 1–4 и 6: проблема реальна, сценарий проверен, edge cases продуманы. Вывод звучит как: «этот сервис решает задачу X лучше, чем существующие альтернативы, потому что…»
Исследовательский проект усиливает блоки 2, 3, 8 и 9: гипотеза нетривиальна, контекст исследован, процесс задокументирован, вывод содержит знание, а не только продукт. Вывод звучит как: «мы проверили, может ли интерфейс X изменить отношение пользователя к Y, и выяснили, что…»
Обе версии обязаны ответить на одни и те же вопросы: почему это приложение, какой у него контекст, кто пользователь, как устроен сценарий, что проверяется, как это выражено в интерфейсе. Различается не набор вопросов, а тип ответа.
Интерактив 3. Черновой прогон
Формат: в парах, 15 минут (5 минут — показ, 2 минуты — обратная связь, потом меняемся).
Задание: покажите свой проект партнёру, используя структуру 9 блоков. Не открывайте Figma — рассказывайте устно, используя максимум 3 экрана как иллюстрации.
Правило для слушающего: после показа ответьте на три вопроса:
- Я понял (а), зачем этот сервис существует? (да/нет/частично)
- Я понял (а), как человек в него попадает и что получает? (да/нет/частично)
- Я запомнил (а) одну деталь, которая отличает этот проект от других? (если да — какую)
Если на все три вопроса «нет» — презентацию нужно пересобрать. Это нормально. Для этого мы здесь.
👁 Для исследовательского трека: вместо вопроса 3 слушающий отвечает: «Я узнал (а) что-то новое об X благодаря этому проекту?» Если нет — гипотеза не работает как знание.
Три линзы напоследок
Это последние три линзы в курсе. Они ничего не говорят о конкретной технике показа, но показывают, как вообще мыслить о том, что вы делаете, когда проектируете и показываете цифровой продукт.
Линза 1. Алетейя: презентация как несокрытие
У Хайдеггера истина — это ἀλήθεια, алетейя, буквально «несокрытость»: момент, когда вещь выходит из тени и показывается как она есть. Противоположность алетейе — не «ложь», а забвение, укрытие, неразличённость.
Что это значит для презентации?
Презентация — это не продажа, не маркетинговый питч, не попытка убедить комиссию, что ваш проект идеален. Презентуя проект, вы совершаете акт несокрытия: вы показываете вещь такой, какая она есть — с её гипотезой, сценарием, решениями, отсечениями, слабыми местами и выводами.
Проект, который прячет свои слабости, — не сильный. Он сокрытый. Проект, который честно говорит «вот здесь я выбирал между A и B, вот почему выбрал A, вот что потерял» — не-сокрыт. И именно поэтому ему доверяешь.
Практический вывод: не прячьте ИИ-пайплайн. Не прячьте edge cases. Не прячьте сомнения. Покажите их — и проект станет сильнее, а не слабее.
Линза 2. Карта и калька: ваш проект — эксперимент или копия?
Делёз и Гваттари различают карту (carte) и кальку (calque). Калька — это копия: она воспроизводит существующее, фиксирует, повторяет. Карта — это эксперимент: она создаёт территорию, а не отражает её. Калька — закрыта. Карта — открыта, множественна, модифицируема, «она имеет множество входов».
«Ризома не сводится ни к Единому, ни ко Множественному. <…> Она не состоит из единиц, а только из измерений».
Что это значит для вашего проекта?
Большинство студенческих проектов — кальки. Они воспроизводят существующие приложения с минимальными вариациями: ещё один трекер, ещё один маркетплейс, ещё один планировщик. Нейросеть может произвести кальку за 20 минут — 40 экранов на уровне хорошей студенческой работы. Мы знаем: это уже случилось. То же самое происходит в AI-фотографии: нейросеть производит «красивые» кадры бесконечно — но без визуального языка, режиссуры и серии они остаются кладбищем красивостей. Карта требует автора. Калька — нет.
Хороший проект — карта. Он не воспроизводит территорию, а создаёт новую: новый способ решить задачу, новый контекст использования, новую связь между человеком и средой. Карта может быть несовершенна. Она может содержать белые пятна. Но она живая — потому что в ней есть эксперимент, а не только репродукция.
Практический вывод: спросите себя честно — мой проект — карта или калька? Если калька — что нужно изменить, чтобы в нём появился хотя бы один жест эксперимента? Одна зона, где вы не скопировали, а изобрели.
Линза 3. Нигредо: право на честную тьму
Нигредо — первая стадия алхимического процесса: разложение, почернение, столкновение с тем, что ещё не оформлено. В алхимии через нигредо обязательно нужно пройти — без него нет трансформации. Нигредо — не провал. Это необходимая тьма.
В контексте этого курса нигредо — это право показать проект как незавершённый, но честный. Не как готовый продукт для App Store, а как гипотезу, которая прошла через проверку и что-то обнаружила — иногда не то, что ожидалось.
Что это значит для защиты?
Идеальная презентация — не та, где всё блестит, а та, где виден след мышления: вот здесь было трудно, вот здесь я ошибся, вот здесь нейросеть предложила банальность, и я от неё отказался, вот здесь я не успел, но понимаю, что нужно доделать. Это не слабость. Это зрелость.
Помните: за каждым экраном стоит некоторая картина мира. Наша задача — научиться эту картину видеть, критиковать и проектировать сознательно. Даже если на экране пока только чернота — это чернота, через которую рождается форма.
Интерактив 4 (финальный). Итоговая карточка проекта
Формат: индивидуально, 12 минут. Это последний чекпойнт курса.
Задание: заполните итоговую карточку проекта — она станет основой для вашей финальной презентации.
● Проблема. Одно предложение: какую задачу решает ваш сервис и для кого.
● Гипотеза. Почему именно мобильное приложение — адекватная форма.
● Пользователь. Ситуация, контекст, состояние — не «ЦА», а человек.
● Путь (ААРРР). 5 ключевых моментов: Аудитория → Азарт → Регулярность → Распространение → Рубли.
● Ключевой экран. Один экран, который лучше всего доказывает вашу гипотезу.
● Отсечение. Одно решение, от которого вы отказались, и почему.
● ИИ. Одно предложение: что ИИ сделал в проекте и что сделали вы.
● Вывод. Что доказывает ваш проект? Что вы узнали?
Тест: покажите карточку соседу. Если за 60 секунд он понимает, о чём проект, — вы готовы к презентации.
👁 Для исследовательского трека: замените строку «Ключевой экран» на «Ключевой опыт» — какой момент взаимодействия с интерфейсом лучше всего демонстрирует вашу гипотезу?
Что вы должны вынести из этой лекции
Не шаблон слайдов и не сценарий защиты, а:
● Понимание того, что презентация — это аргумент, а не экскурсия по Figma.
● ААРРР как драматургию показа: от незнания к пользе, от первого входа к рекомендации.
● Привычку документировать ИИ-пайплайн: что сделала машина, что сделали вы, что отбросили и почему.
● Структуру из 9 блоков — готовый каркас для финальной презентации.
● Честность как стратегию: не прятать слабости, а показывать след мышления.
Домашнее задание
Финальный пакет проекта.
Это итоговая сдача модуля — и итоговая сдача курса. Пакет состоит из четырёх частей.
Часть 1. Презентация (10–15 слайдов)
Структура: 9 блоков, описанных выше. Формат: Keynote, Google Slides или Figma.
Обязательные слайды: ● Проблема и контекст (1 слайд) ● Гипотеза (1 слайд) ● Пользователь и ситуация (1 слайд) ● Путь ААРРР (2–3 слайда со сценарием) ● Ключевые экраны (3–4 слайда) ● Особые случаи: первый запуск, ошибка (1 слайд) ● Визуальный язык и бренд (1 слайд) ● ИИ-пайплайн (1 слайд) ● Вывод (1 слайд)
Часть 2. Прототип (Figma)
Интерактивный прототип ключевого сценария. Минимум 8–12 экранов, связанных переходами. Обязательно: первый запуск (empty state), 2-3 основных сценария, хотя бы один edge case.
Часть 3. ИИ-пайплайн (1 страница)
Карта инструментов + журнал отсечений (минимум 3 задокументированных решения). Формат: FigJam, Google Doc или слайд.
Часть 4. Скринкаст
Запись прохождения прототипа с голосовым комментарием (1–3 минуты). Показывает путь пользователя, а не набор экранов.
👁 Для исследовательского трека (дополнительно):
Добавьте Research Brief (300–500 слов): исследовательский вопрос, теоретическая рамка, гипотеза, что проверялось интерфейсом, что обнаружено. Это документ, который превращает ваш проект из «приложения» в исследование.
Регламент ИИ: финальный чеклист
На первом занятии мы договорились: ИИ разрешён. Сейчас — момент, когда это обещание превращается в конкретный документ. Вот что должно быть в вашей сдаче.
Обязательный пакет ИИ-документации
Документация показывает не «использовали ли вы ИИ», а как вы думали.
1. Карта пайплайна
Схема (FigJam), на которой видно:
— Какие инструменты вы использовали (Pencil, v0, ChatGPT, Claude, Midjourney, другие). — На каком этапе проекта каждый из них подключался. — Что именно он делал: генерировал экраны, помогал с текстом, структурировал исследование, создавал иллюстрации.
Нужна ясная карта: вход → инструмент → выход.
2. Лог отбора и отсечения
Самая важная часть. Покажите:
● Что ИИ предложил (скриншоты, фрагменты, промпты). ● Что вы взяли и почему. ● Что вы не взяли и почему.
Именно «не взяли» — ключевое. Журнал отсечений показывает, что у вас есть критерии, а не просто кнопка «принять». 3–5 примеров достаточно.
3. Зона авторской ответственности
Один абзац, в котором вы отвечаете на вопрос:
● Где проходит граница между тем, что сделал инструмент, и тем, что решили вы?
Например: «Pencil сгенерировал базовую структуру экранов, но все решения по навигационной модели, иерархии информации и визуальному языку — мои. ChatGPT помог сформулировать Job Stories, но я переписал три из пяти, потому что…»
Что оценивается
Уместность. Инструмент подключён там, где он реально ускоряет работу, а не где «модно». Прозрачность. Процесс виден: промпты, варианты, решения. Осмысленность отбора. Есть критерии выбора, а не слепое принятие первого результата. Способность объяснить. Студент может устно ответить «почему так, а не иначе». Авторская ответственность. Понятно, кто принял финальное решение и на каком основании.
Что не является нарушением
● Использовать ИИ на любом этапе проекта. ● Использовать несколько ИИ-инструментов одновременно. ● Взять из ИИ-результата значительную часть визуала, если это задокументировано и объяснено.
Что является нарушением
● Скрытое использование: выдать полностью сгенерированный результат за самостоятельную работу. ● Фальсификация процесса: приложить чужие промпты или придуманный лог. ● Отсутствие документации при очевидном использовании ИИ.
Итоги курса: что мы здесь делали
Это место, где мы останавливаемся и смотрим назад. На весь курс, а не только на этот модуль.
Что было
Четыре модуля. Лонгриды, лендинги, концептуальные интернет-магазины, мобильные сервисы. Десятки экранов, сценариев, гипотез, разборов. Философия, которую вы, возможно, не просили, но которая — я надеюсь — изменила то, как вы смотрите на экран.
Что мы обещали
В начале курса мы обещали:
Мы не будем учить вас поклоняться инструментам, которые устареют через полгода.
Мы не будем делать вид, что достаточно выучить набор кнопок и после этого профессия будет вам что-то гарантировать.
Мы не будем выдавать теорию за необязательный декоративный слой.
Но мы будем требовать мыслительной работы. И будем помогать вам переводить эту работу в проектные решения.
Я надеюсь, это обещание было выполнено. По крайней мере, мы старались.
Три регистра, в которых работал курс
Всё, что мы делали, существовало одновременно в трёх режимах:
Операционный. Вы научились работать в ландшафте, где ИИ — рабочая среда, а не чудо и не угроза. Собирать пайплайн, сравнивать варианты, документировать решения, отвечать за результат. Этот навык не привязан к конкретному инструменту — он будет работать, когда ChatGPT сменится чем-то другим.
Критико-теоретический. Вы узнали, что за интерфейсом стоят культура, аффордансы, аффекты, акторные сети, лиминальность, ритмоанализ, ситуационизм, мереология, ритурнель. Эти слова — не декоративный шум. Это инструменты различения: они позволяют видеть в экране то, что без них невидимо. Формула курса: теория переходит в действие — одна идея, один наблюдаемый след её применения.
Негативный (нигредо-регистр). Вы столкнулись с тем, что часть привычного ремесла автоматизирована. Вместо паники или отрицания мы сделали из этого рабочий материал. Нигредо — не конец. Это начало: стадия, через которую обязательно нужно пройти, чтобы выйти к чему-то новому.
Что вы забираете с собой
Не набор скиллов по Figma (они устареют) и не список философов (они забудутся), а кое-что более устойчивое:
Гипотеза важнее производства. Прежде чем рисовать экран — ответьте на вопрос «зачем». Если ответ «потому что такое дано задание» — вы ещё не начали.
Теория — инструмент, а не украшение. Если идея никак не меняет ваш интерфейс, вы её пока не применили.
ИИ — среда, а не фетиш. Не поклоняться и не бояться. Документировать. Сравнивать. Решать самому.
Странность без хаоса, ясность без банальности. Хороший проект — это форма, в которой есть след мысли, а не только след насмотренности.
Авторство — это суждение. Не «я создал из ничего», а «я поставил задачу, выбрал критерий, отсёк лишнее и отвечаю за результат».
Итоговая формула
Формула модуля:
Мобильный сервис — это не набор экранов. Это аргумент: гипотеза о том, как человек живёт, действует, нуждается и возвращается — воплощённая в интерфейсе и доказанная сценарием.
Формула курса:
Мы учимся проектировать после того, как простое проектирование перестало быть достаточным.
Здесь важен не только интерфейс, но и причина его существования.
За каждым экраном стоит некоторая картина мира. Ваша задача — научиться эту картину видеть, критиковать и проектировать сознательно.
Всё. Спасибо. Удачи на защите.
