AI-редизайн интерфейсов в ВКР: от аудита нейросетью до защищаемых метрик
В апреле 2026 года ZDNet опубликовал кейс: автор скормил ChatGPT Images 2.0 два своих мобильных приложения, нейросеть проанализировала экраны, нашла проблемы юзабилити и выдала готовые мокапы. Формально — красивая демонстрация. По факту — готовый скелет для дипломного проекта, где ИИ выступает не «магической кнопкой», а инструментом внутри воспроизводимого пайплайна аудита и редизайна. Для выпускников направления 09.03.01/09.03.02 это снимает классическую боль: студент не знает, как обосновать решения по интерфейсу, кроме «мне кажется, так удобнее». Генеративный анализ даёт то, чего не хватало — измеримые эвристики, сравнение до/после и воспроизводимую методику.
Семантический каркас темы: что вы реально исследуете
Прежде чем идти к научруку, зафиксируйте терминологию. Комиссия любит, когда студент различает генерацию кода, генерацию изображений и генерацию дизайн-решений — это три разные задачи с разными метриками качества.
| Понятие | Что проверяем в ВКР | Инструмент / стандарт |
|---|---|---|
| Prompt engineering | Воспроизводимость промптов, стабильность результата | Журнал промптов, seed, temperature |
| UX-аудит | Количество выявленных нарушений на экран | 10 эвристик Нильсена, ISO/IEC 25010 (usability) |
| Юзабилити-метрика | Рост SUS-балла после редизайна | System Usability Scale, SUS ≥ 68 |
| Доступность | Соответствие контраста и тач-зон | WCAG 2.2 AA, 4.5:1 |
| Документирование | ТЗ по интерфейсу | ГОСТ 34.602-89, ГОСТ 19.701-90 (схемы) |
Три темы ВКР, которые вырастают из этого кейса
Тема 1. Методика нейросетевого UX-аудита мобильных приложений
Актуальность: статья фиксирует сдвиг — аудит перестаёт быть ручным экспертным процессом и становится конвейером «скриншот → анализ → мокап». Цель: разработать и апробировать методику аудита с участием LLM и верификацией экспертом (human-in-the-loop). Задачи: собрать датасет из 20–30 экранов; сформулировать 15 промптов под эвристики Нильсена; запустить анализ двумя моделями (ChatGPT Images 2.0 и альтернативой) для сравнения; провести SUS-опрос до и после. Структура: Гл.1 — обзор методов UX-аудита и генеративных моделей; Гл.2 — проектирование пайплайна, схема в нотации IDEF0; Гл.3 — эксперимент, статистика, экономика внедрения.
Тема 2. Автоматизация редизайна интерфейсов на основе дизайн-системы
Актуальность: статьи вроде ZDNet показывают интерес разработчиков к «редизайну одним промптом», но промышленные команды упираются в консистентность компонентов. Цель: построить прототип, который генерирует мокапы строго в рамках существующей дизайн-системы (Figma Variables + токены). Задачи: описать токены (цвет, типографика, отступы); подготовить few-shot примеры; разработать правило валидации выхода на соответствие токенам; замерить долю «валидных» генераций. Структура: Гл.1 — дизайн-системы и prompt engineering; Гл.2 — архитектура интеграции Figma API + LLM; Гл.3 — метрики консистентности, тесты.
Тема 3. Оценка влияния AI-редизайна на конверсионные сценарии
Актуальность: кейс описывает «wow-эффект», но не отвечает на вопрос, стало ли лучше с точки зрения бизнеса. Цель: сопоставить косметические улучшения интерфейса с метриками прохождения сценария. Задачи: спроектировать A/B-тест; определить метрики (время до целевого действия, отвал на шаге, error rate); собрать выборку на прототипе (Maze, Useberry); посчитать значимость (t-тест или Манн-Уитни). Структура: Гл.1 — метрики UX и статистическая проверка гипотез; Гл.2 — протокол эксперимента; Гл.3 — результаты и расчёт ROI внедрения.
Аналитическая глава: как обосновать выбор ИИ-инструмента
Не пишите «взяли ChatGPT, потому что популярный». Сравнительная таблица с критериями и весами — вот что защищает аналитическую главу. Возьмите 3–4 решения и оцените по пяти критериям: качество генерации UI (0–5), воспроизводимость результата, стоимость за 100 генераций, соответствие требованиям к обработке данных, наличие API. Веса согласуйте с научруком до начала расчёта — это снимает вопрос «а почему 0.3, а не 0.5».
Отдельным подпунктом зафиксируйте ограничения: генеративные мокапы не несут семантики компонентов, не гарантируют соответствие WCAG 2.2 и не учитывают локаль (кириллица, длинные строки). Это ваши «границы применимости», их отсутствие — главный повод для критики.
Проектная часть: схема пайплайна и артефакты
Минимальный набор диаграмм, без которых защита просядет:
- IDEF0 / BPMN процесса «скриншот → промпт → анализ → мокап → валидация → решение эксперта»;
- UML-диаграмма последовательности для интеграции с API модели (запрос, таймаут, повтор, логирование);
- ER-модель для хранения промптов, результатов и оценок эксперта — потом пригодится для воспроизводимости эксперимента;
- Схема архитектуры по ГОСТ 19.701-90 (или ГОСТ 34.702-89), если вуз требует оформления по ЕСПД.
Технически пайплайн можно собрать без экзотики: Python + FastAPI + PostgreSQL для логов + S3-совместимое хранилище для изображений. Если в дипломе нужна распределённость — оберните в контейнер и разверните в Kubernetes, но не ради Kubernetes, а ради воспроизводимости окружения.
Тестирование и метрики: чем доказывать результат
Это место, где 80% ВКР про интерфейсы проваливают вопрос члена комиссии «а вы уверены, что стало лучше?». Соберите три группы метрик.
| Группа | Конкретные показатели | Способ получения |
|---|---|---|
| Юзабилити | SUS до/после, среднее время задачи, error rate | Опрос 10–15 респондентов, юзабилити-тест на прототипе |
| Доступность | Контраст (WCAG 2.2 AA), размер тач-зон ≥ 44×44 px | Автоматический аудит + ручная проверка |
| Процесс | Время аудита экрана, доля принятых экспертом рекомендаций | Логи пайплайна, оценка двух экспертов |
| Экономика | Стоимость 1 аудита, экономия часов дизайнера | Калькуляция трудозатрат, средняя ставка |
Для логирования запросов к модели и задержек отличная связка — OpenTelemetry SDK: вы получите трейсы «промпт → ответ → сохранение» и честно покажете p95-латентность. Это не «для галочки»: комиссия оценит, что вы умеете смотреть на систему через телеметрию.
Чему вы научитесь, пока пишете эту ВКР
- Формализовать экспертизу: превращать «неудобно» в измеримую эвристику с порогом.
- Проектировать human-in-the-loop процессы и обосновывать роль человека в ИИ-пайплайне.
- Собирать телеметрию LLM-сервиса (латентность, стоимость, качество выхода) и оформлять её в разделе тестирования.
- Готовить техническую документацию по ГОСТ 34.602-89 и ГОСТ 19.701-90 — навык, который прямо конвертируется в оффер.
- «Нейросеть сама придумала дизайн, я только скриншоты приложил». Нет методики — нет исследования. Заведите журнал промптов и критерии валидации выхода.
- «Стало красивее». Красота не метрика. Нужны SUS, время задачи, error rate — хотя бы по 10 респондентам.
- ТЗ и схемы «прикручены» в конце. ГОСТ 34.602-89 требует описать требования до проектирования. Переставляйте главы так, чтобы документы шли в логике жизненного цикла.
FAQ по теме
Насколько сложно это реализовать за семестр?
Средний прототип — 6–8 недель, если не строить своё UI. Стек: Python-скрипт + вызов API модели + SQLite для логов + Figma для ручной сборки мокапов. Самый трудоёмкий блок — не код, а юзабилити-тест и обработка его результатов.
Обязательно ли писать код?
Зависит от вуза. Если в требованиях к ВКР по вашему направлению есть «программная реализация», нужен рабочий прототип. Для гуманитарных и экономических профилей достаточно методики и расчётов. Уточните формулировку в методичке кафедры — это первое, что стоит сделать.
Как оформлять скриншоты «до/после» и диаграммы по ГОСТ?
Скриншоты — рисунки с подрисуночной подписью («Рисунок 3 — Экран авторизации до редизайна»), единая нумерация по главам. Диаграммы — по ГОСТ 19.701-90 (схемы алгоритмов, программ, данных, систем) или ГОСТ 34.702-89 для автоматизированных систем. Не смешивайте нотации в одном разделе: если начали BiPNM — не переключайтесь на UML без обоснования.
Где брать исходные экраны и тестовые данные?
Три законных источника: open-source приложения с разрешительной лицензией, собственные пет-проекты и скриншоты из публичных кейсов (Dribbble, Mobbin — с указанием источника). Не берите закрытые коммерческие приложения без письменного согласия правообладателя — рецензент может спросить.
- Ссылка на оригинальный кейс ZDNet присутствует в списке источников с датой.
- Каждая задача из введения закрыта результатом в заключении (сверка формулировок «один в один»).
- Есть минимум 4 схемы: архитектура, IDEF0/BPMN, UML-последовательность, ER-модель.
- Метрики UX и доступности сведены в таблицу с порогами (SUS ≥ 68, контраст 4.5:1).
- ТЗ оформлено по ГОСТ 34.602-89, схемы — по ГОСТ 19.701-90.
- Промпты к модели вынесены в приложение с указанием модели, версии и параметров (seed, temperature).
- Проверено соответствие требованиям кафедральной методички по объёму и структуре.
Итог: где здесь точка защиты
Статья ZDNet — это не рецепт «нажми кнопку и получи дизайн». Это иллюстрация того, что методология аудита интерфейсов меняется: эксперт больше не единственный источник оценки, но и ИИ — не финальный арбитр. Ваша ВКР выигрывает, если вы покажете границы применимости генерации, измерите эффект и оформите всё так, чтобы работу мог воспроизвести другой студент через год. Именно этого ждёт комиссия. И если нужна помощь с дипломом на этапе от структуры до расчётов — пишите, разберёмся вместе.
Источник: I asked ChatGPT Images 2.0 to redesign my app UIs - and wow (опубликовано 2026-04-30)
```