Промпты для дизайнера интерфейсов – тема, которая звучит просто, но на практике разбивается о первый же расплывчатый запрос к нейросети. Получить от ИИ что-то действительно полезное для UX/UI-работы удается далеко не с первого раза, и причина почти всегда одна: неточная формулировка задачи.
В этой статье собраны 29 готовых промптов для дизайнера интерфейсов – от анализа пользовательских сценариев до генерации текстов для пустых состояний экрана. Каждый промпт решает конкретную задачу, которая регулярно встречается в работе.
Статья будет полезна в таких ситуациях:
- Нужно быстро сгенерировать варианты структуры экрана или навигации
- Требуется провести анализ конкурентов или пользовательских сценариев
- Стоит задача написать технические требования или описание компонента
- Нужна помощь с текстами интерфейса: кнопки, подсказки, сообщения об ошибках
- Требуется подготовить обоснование дизайн-решения для команды или клиента
- Нужно сгенерировать варианты пользовательских историй или сценариев тестирования
Все промпты готовы к использованию: достаточно подставить свои данные в переменные и получить результат.
29 промптов для дизайнера интерфейсов: готовые примеры
1. Анализ целевой аудитории и создание персонажей
Проблема: Дизайнер начинает проектировать экраны, не имея четкого понимания, кто будет ими пользоваться. В итоге интерфейс получается “для всех” – то есть ни для кого.
Решение: Промпт генерирует детальные портреты пользователей с поведенческими паттернами, болями и целями – основу для всех дальнейших решений.
Текст промпта:
*****
Ты – опытный UX-исследователь, специализирующийся на создании портретов пользователей для цифровых продуктов.
Создай 3 детальных портрета пользователя для [опишите продукт, например, “мобильное приложение для учета личных финансов”].
Контекст: [опишите рынок и ситуацию, например, “приложение ориентировано на жителей России в возрасте 25–45 лет, которые хотят контролировать расходы без сложных таблиц”].
Для каждого портрета опиши:
– Имя, возраст, профессия, уровень дохода
– Главная цель при использовании продукта
– Ключевые боли и разочарования
– Поведение: как часто заходит, с какого устройства, в какое время суток
– Фраза, которую этот человек мог бы произнести о продукте
Ограничения: не используй клише вроде “молодой специалист Иван”. Портреты должны быть реалистичными, с конкретными деталями жизненной ситуации. Тон – профессиональный, без лишней воды. Объем: 150–200 слов на каждый портрет.
*****
Почему это работает: Структура с конкретными полями не дает нейросети уйти в абстракцию – каждый раздел требует конкретики. Фраза персонажа в конце помогает сразу проверить, насколько портрет живой.
2. Генерация пользовательских сценариев
Проблема: Без прописанных сценариев дизайнер проектирует “счастливый путь” и забывает про все остальное – ошибки, нестандартное поведение, возврат к предыдущему шагу.
Решение: Промпт создает полный набор сценариев, включая негативные и пограничные случаи, которые обычно всплывают уже на тестировании.
Текст промпта:
*****
Ты – ведущий UX-аналитик с опытом проектирования пользовательских сценариев для мобильных и веб-приложений.
Разработай полный набор пользовательских сценариев для функции [опишите функцию, например, “оформление заказа в интернет-магазине”].
Контекст продукта: [опишите продукт и его аудиторию, например, “маркетплейс товаров для дома, пользователи – люди 30–55 лет, часто не очень уверенные в онлайн-покупках”].
Включи:
– Основной сценарий (счастливый путь): шаг за шагом, от входа в функцию до завершения
– 3 альтернативных сценария (нестандартное поведение пользователя)
– 3 негативных сценария (ошибки, сбои, нехватка данных)
– Для каждого сценария: триггер → действия пользователя → ожидаемый результат системы
Ограничения: сценарии должны быть реалистичными, не теоретическими. Избегай формулировок “пользователь нажимает кнопку” – описывай намерение и контекст. Формат: структурированный список с заголовками для каждого сценария.
*****
Почему это работает: Разделение на основной, альтернативный и негативный сценарии заставляет нейросеть охватить все ветки поведения, а не только идеальный путь, который в реальности встречается реже всего.
3. Создание структуры информационной архитектуры
Проблема: Информационная архитектура часто строится интуитивно, без системного анализа – и потом пользователи не могут найти нужный раздел, хотя он “очевидно” находится именно там.
Решение: Промпт генерирует обоснованную структуру навигации с группировкой разделов по логике пользователя, а не по логике разработчика.
Текст промпта:
*****
Ты – специалист по информационной архитектуре с опытом проектирования навигации для сложных цифровых продуктов.
Создай структуру информационной архитектуры для [опишите продукт, например, “корпоративный портал для управления проектами с командами до 50 человек”].
Контекст: [опишите ключевые задачи пользователей, например, “пользователи ежедневно отслеживают задачи, ведут документацию, общаются с командой и формируют отчеты”].
Структура должна включать:
– Главные разделы первого уровня (не более 7)
– Подразделы второго уровня для каждого раздела
– Обоснование группировки: почему именно эти элементы стоят рядом
– Элементы, доступные глобально (из любого раздела)
– Потенциальные конфликты навигации и как их решить
Ограничения: структура должна строиться на логике пользователя, а не на внутренней логике системы. Избегай технических названий разделов. Формат: иерархический список с пояснениями.
*****
Почему это работает: Требование обосновать группировку не дает нейросети просто перечислить разделы – она вынуждена объяснить причинно-следственную связь между структурой и поведением пользователя.
4. Разработка концепции онбординга
Проблема: Онбординг – это первое впечатление, и многие продукты теряют пользователей именно здесь. Либо слишком много информации сразу, либо пользователь вообще не понимает, с чего начать.
Решение: Промпт создает пошаговую концепцию онбординга с учетом типа продукта и уровня подготовки пользователя.
Текст промпта:
*****
Ты – UX-дизайнер с глубокой экспертизой в проектировании пользовательского онбординга для мобильных и веб-приложений.
Разработай концепцию онбординга для [опишите продукт, например, “сервис для автоматизации бухгалтерского учета для малого бизнеса”].
Целевая аудитория: [опишите пользователей, например, “владельцы малого бизнеса без бухгалтерского образования, впервые переходящие с ручного учета на цифровой”].
Концепция должна включать:
– Цель онбординга: что пользователь должен понять и сделать за первые 5 минут
– Количество шагов и обоснование (почему не больше и не меньше)
– Содержание каждого шага: что показываем, что объясняем, какое действие просим совершить
– Механика прогресса: как пользователь понимает, что движется вперед
– Точка выхода: когда и как пользователь попадает в полноценный интерфейс
– Что делать, если пользователь пропустил онбординг
Ограничения: онбординг не должен быть обучающим курсом. Каждый шаг – одна мысль, одно действие. Тон концепции – практический, без маркетинговых клише.
*****
Почему это работает: Ограничение “один шаг – одна мысль” не позволяет нейросети генерировать перегруженные экраны. Вопрос о пропуске онбординга вынуждает продумать реальное поведение, а не идеальное.
5. Написание текстов для пустых состояний экрана
Проблема: Пустые состояния – один из самых недооцененных элементов интерфейса. Большинство команд пишет туда “Данных нет” и считает задачу выполненной. Пользователь при этом не понимает, что делать дальше.
Решение: Промпт генерирует тексты для пустых состояний, которые объясняют ситуацию, снимают тревогу и ведут к действию.
Текст промпта:
*****
Ты – UX-райтер, специализирующийся на написании микротекстов для цифровых интерфейсов.
Напиши тексты для пустых состояний экрана для [опишите раздел или функцию, например, “раздел ‘Мои заказы’ в мобильном приложении интернет-магазина”].
Контекст продукта: [опишите продукт и тон коммуникации, например, “приложение для заказа продуктов, тон – дружелюбный, живой, без официоза”].
Для каждого пустого состояния напиши:
– Заголовок (до 5 слов)
– Подзаголовок или пояснение (1–2 предложения, максимум 20 слов)
– Текст кнопки призыва к действию
Создай варианты для следующих ситуаций:
– Пользователь еще ничего не заказывал (первое посещение)
– Пользователь отменил все заказы
– Поиск не дал результатов
– Ошибка загрузки данных (нет соединения)
Ограничения: никаких технических формулировок. Текст должен снимать тревогу, а не добавлять ее. Каждый вариант – не более 3 элементов (заголовок + пояснение + кнопка).
*****
Почему это работает: Разделение по конкретным ситуациям (первое посещение, ошибка, отмена) дает нейросети четкий контекст для каждого варианта – и результат получается функциональным, а не универсально-бесполезным.
6. Создание текстов сообщений об ошибках
Проблема: Сообщения об ошибках – это момент, когда пользователь уже расстроен. Фраза “Произошла ошибка #404” в этот момент добивает окончательно. Хорошее сообщение об ошибке – это маленький кризисный менеджер.
Решение: Промпт создает набор текстов для типичных ошибок, которые объясняют проблему и предлагают выход.
Текст промпта:
*****
Ты – UX-райтер с опытом написания микротекстов для критических состояний интерфейса: ошибки, предупреждения, системные сообщения.
Напиши тексты сообщений об ошибках для [опишите продукт, например, “веб-приложение для онлайн-банкинга”].
Тон коммуникации: [опишите голос продукта, например, “спокойный, уверенный, без паники – как хороший консультант в банке”].
Создай тексты для следующих ситуаций:
– Неверно введен пароль (первая попытка)
– Неверно введен пароль (третья попытка, аккаунт будет заблокирован)
– Платеж не прошел (недостаточно средств)
– Платеж не прошел (технический сбой на стороне банка)
– Сессия истекла, требуется повторный вход
– Загрузка файла не удалась (неподходящий формат)
Для каждого сообщения:
– Заголовок (до 4 слов)
– Объяснение (1 предложение: что случилось и почему)
– Действие (что пользователь может сделать прямо сейчас)
Ограничения: никаких технических кодов ошибок в тексте. Никакого перекладывания вины на пользователя. Каждое сообщение – не более 30 слов суммарно.
*****
Почему это работает: Трехчастная структура (что случилось → почему → что делать) создает сообщение, которое не просто информирует, но и ведет пользователя к выходу из ситуации. Ограничение в 30 слов исключает многословные оправдания системы.
7. Анализ конкурентных интерфейсов
Проблема: Анализ конкурентов часто превращается в субъективное “этот интерфейс красивый, а этот нет”. Без структуры такой анализ бесполезен для принятия дизайн-решений.
Решение: Промпт создает структурированную систему сравнения конкурентов по параметрам, которые действительно влияют на пользовательский опыт.
Текст промпта:
*****
Ты – старший UX-аналитик с опытом проведения конкурентного анализа цифровых продуктов.
Проведи структурированный анализ конкурентных интерфейсов для [опишите тип продукта, например, “приложения для отслеживания физической активности”].
Конкуренты для анализа: [перечислите продукты, например, “три ведущих российских приложения в категории здоровье и спорт”].
Проанализируй каждый продукт по следующим параметрам:
– Навигационная модель: как организован переход между разделами
– Онбординг: как продукт знакомит нового пользователя
– Главный экран: что показывается в первую очередь и почему
– Работа с данными: как отображается прогресс и статистика
– Обработка ошибок и пограничных состояний
– Персонализация: насколько интерфейс адаптируется под пользователя
– Сильные стороны, которые стоит учесть
– Слабые стороны, которые можно использовать как конкурентное преимущество
Формат: сравнительная таблица + краткое резюме по каждому продукту (3–4 предложения). Тон – аналитический, без оценочных суждений типа “красиво” или “некрасиво”.
*****
Почему это работает: Конкретные параметры анализа переводят субъективные впечатления в измеримые наблюдения. Разделение на сильные и слабые стороны сразу дает практический вывод: что брать, что обходить стороной.
8. Разработка системы дизайн-токенов
Проблема: Без системы дизайн-токенов интерфейс держится на “у нас принято делать такой отступ” – и это знание существует только в голове у одного человека, который в отпуске.
Решение: Промпт помогает сформировать логичную систему переменных для цветов, типографики и отступов с понятной логикой именования.
Текст промпта:
*****
Ты – ведущий дизайнер дизайн-систем с опытом создания токенов для масштабируемых продуктов.
Разработай систему дизайн-токенов для [опишите продукт и его масштаб, например, “веб-платформа для управления складом, используется командой из 200+ человек”].
Контекст: [опишите технологический стек и ограничения, например, “интерфейс строится на компонентах, команда разработки использует одну из популярных российских систем управления кодом”].
Создай систему токенов для:
– Цвета: основные, вспомогательные, семантические (успех, ошибка, предупреждение, информация), нейтральные
– Типографика: размеры, насыщенность, межстрочный интервал, семейства шрифтов
– Отступы: внутренние (padding) и внешние (margin) по шкале
– Скругления: варианты для разных типов элементов
– Тени: уровни для разных слоев интерфейса
Для каждой группы токенов:
– Логика именования (как называть, чтобы было понятно без объяснений)
– Примеры применения в реальных компонентах
– Почему именно такая структура (обоснование)
Ограничения: система должна быть понятна разработчику без дизайн-образования. Избегай сложных иерархий с более чем 3 уровнями вложенности.
*****
Почему это работает: Требование обосновать каждую группу токенов превращает результат из простого списка переменных в документ с логикой, который команда сможет поддерживать без автора.
9. Написание описаний компонентов для дизайн-системы
Проблема: Компонент без описания – это загадка для разработчика и новичка в команде. Когда использовать этот вариант кнопки? Почему здесь такой отступ? Молчание документации – громкий сигнал о проблемах.
Решение: Промпт создает структурированные описания компонентов, которые отвечают на все практические вопросы команды.
Текст промпта:
*****
Ты – дизайнер дизайн-системы с опытом написания технической документации для команд разработки и дизайна.
Напиши полное описание компонента [укажите компонент, например, “кнопка с вариантами: основная, вспомогательная, опасное действие, неактивная”] для дизайн-системы.
Контекст: [опишите продукт и аудиторию документации, например, “корпоративная платформа, документация читается разработчиками и дизайнерами с разным уровнем опыта”].
Описание должно включать:
– Назначение компонента: для каких задач используется
– Варианты и состояния: все визуальные вариации и интерактивные состояния
– Правила применения: когда использовать каждый вариант
– Антипримеры: когда этот компонент использовать нельзя
– Параметры: размеры, отступы, цвета со ссылками на токены
– Поведение при адаптации: как компонент меняется на разных экранах
– Доступность: требования для пользователей с ограниченными возможностями
Ограничения: язык – простой и конкретный. Никаких фраз “используется по усмотрению дизайнера”. Каждое правило должно быть однозначным.
*****
Почему это работает: Раздел с антипримерами – ключевой элемент. Именно он устраняет самые частые ошибки применения компонента, которые возникают, когда правил нет, а интуиция подводит.
10. Формулировка технического задания на экран
Проблема: Техническое задание на экран, написанное дизайнером, часто содержит либо слишком мало деталей (“кнопка должна быть красивой”), либо описывает внешний вид вместо поведения. Разработчик в итоге додумывает сам.
Решение: Промпт создает структурированное техническое описание экрана с поведением, состояниями и логикой – всем, что нужно разработчику.
Текст промпта:
*****
Ты – старший продуктовый дизайнер с опытом написания технической документации для команд разработки.
Составь техническое описание экрана [укажите экран, например, “экран авторизации в мобильном приложении”] для передачи в разработку.
Контекст: [опишите продукт и техническую среду, например, “мобильное приложение для iOS и Android, команда разработки работает по методологии двухнедельных итераций”].
Техническое описание должно включать:
– Цель экрана: какую задачу пользователя решает
– Список всех элементов интерфейса с их типами
– Состояния каждого элемента (по умолчанию, активный, ошибка, недоступен, загрузка)
– Логика поведения: что происходит при каждом действии пользователя
– Валидация полей: правила и сообщения об ошибках
– Переходы: на какие экраны ведут действия пользователя и при каких условиях
– Особые случаи: что показывается при отсутствии соединения, при первом входе, при повторном входе
Формат: нумерованный список с подпунктами. Тон – технический, без дизайн-терминологии. Разработчик должен понять все без уточнений.
*****
Почему это работает: Требование описать особые случаи – то, что обычно забывают. Именно эти ситуации потом приходят в виде вопросов от разработчика в самый неподходящий момент.
11. Генерация вариантов структуры главного экрана
Проблема: Главный экран – это лицо продукта, и именно здесь дизайнеры чаще всего застревают на этапе идей. Первый вариант кажется единственно возможным, хотя на самом деле это просто первый пришедший в голову.
Решение: Промпт генерирует несколько концептуально разных вариантов главного экрана с обоснованием каждого подхода.
Текст промпта:
*****
Ты – креативный директор UX с опытом проектирования главных экранов для мобильных приложений разных категорий.
Предложи 4 концептуально разных варианта структуры главного экрана для [опишите приложение, например, “сервис доставки еды из ресторанов”].
Ключевые задачи пользователя на главном экране: [перечислите, например, “быстро найти нужный ресторан или блюдо, увидеть актуальные акции, проверить статус текущего заказа”].
Для каждого варианта опиши:
– Концепция: основная идея структуры (1–2 предложения)
– Иерархия элементов: что в верхней части, что в середине, что внизу и почему
– Главный акцент: какое действие пользователя этот вариант продвигает в первую очередь
– Для кого подходит лучше всего: какой тип пользователя выиграет от такой структуры
– Риски: что может не сработать в этом варианте
Ограничения: варианты должны отличаться концептуально, а не только визуально. Избегай вариантов, которые отличаются только расположением одного блока. Тон – аналитический.
*****
Почему это работает: Требование описать риски каждого варианта – это встроенная критика, которая экономит время на обсуждение с командой. Вопрос “для кого подходит” сразу привязывает структуру к реальным пользователям.
12. Разработка навигационной модели
Проблема: Выбор между нижней панелью, боковым меню или вкладками часто делается на основе того, что “все так делают” или “так красивее”. Это приводит к навигации, которая противоречит реальным паттернам использования.
Решение: Промпт анализирует задачи пользователей и предлагает обоснованную навигационную модель с аргументами за и против каждого варианта.
Текст промпта:
*****
Ты – UX-архитектор с глубокой экспертизой в проектировании навигационных систем для мобильных и веб-приложений.
Разработай и обоснуй навигационную модель для [опишите приложение, например, “корпоративный мессенджер для команд до 100 человек”].
Контекст использования: [опишите, как и где используется приложение, например, “используется в рабочее время, преимущественно на смартфоне, часто в условиях нехватки времени и многозадачности”].
Основные разделы продукта: [перечислите разделы, например, “чаты, каналы, задачи, файлы, настройки”].
Проанализируй и сравни следующие модели навигации:
– Нижняя панель с иконками
– Боковое выдвижное меню
– Вкладки в верхней части экрана
– Комбинированная модель
Для каждой модели:
– Соответствие паттернам использования (подходит ли для данного контекста)
– Масштабируемость (что будет при добавлении новых разделов)
– Когнитивная нагрузка на пользователя
– Итоговая рекомендация с конкретным обоснованием
Формат: сравнительный анализ + финальная рекомендация с аргументами. Тон – аналитический, без категоричных суждений без обоснования.
*****
Почему это работает: Вопрос о масштабируемости – это то, о чем думают редко на старте и сильно жалеют потом. Анализ четырех моделей вместо одной дает реальный выбор, а не подтверждение уже принятого решения.
13. Создание сценариев юзабилити-тестирования
Проблема: Юзабилити-тестирование часто проводится с вопросами типа “вам нравится этот интерфейс?” – это не тестирование, это опрос об эстетических предпочтениях. Реальное тестирование строится на задачах, а не на мнениях.
Решение: Промпт создает набор задач для тестирования с четкими критериями успеха и вопросами для наблюдения.
Текст промпта:
*****
Ты – специалист по юзабилити-исследованиям с опытом проведения тестирований для цифровых продуктов разных категорий.
Разработай сценарий юзабилити-тестирования для [опишите продукт или конкретную функцию, например, “функция создания нового проекта в системе управления задачами”].
Аудитория тестирования: [опишите участников, например, “менеджеры проектов с опытом работы 2–5 лет, ранее не использовавшие этот продукт”].
Сценарий должен включать:
– Вводный инструктаж для участника (что говорить в начале, как настроить на думание вслух)
– 5–7 задач для тестирования (реалистичные жизненные ситуации, не инструкции)
– Для каждой задачи: формулировка, критерий успешного выполнения, на что обращать внимание наблюдателю
– Вопросы после каждой задачи (3–4 вопроса)
– Итоговые вопросы после всего тестирования (5–6 вопросов)
Ограничения: задачи не должны содержать подсказок о том, где находится нужный элемент. Никаких вопросов “вам понравилось?”. Только поведенческие наблюдения и открытые вопросы о процессе.
*****
Почему это работает: Критерий успешного выполнения для каждой задачи – это то, что превращает наблюдение из субъективного впечатления в измеримый результат. Без этого критерия два наблюдателя посмотрят одно и то же и сделают разные выводы.
14. Написание пользовательских историй
Проблема: Пользовательские истории часто пишутся как технические требования в другом формате: “как пользователь, я хочу нажать кнопку, чтобы открылась страница”. Это не история – это описание клика.
Решение: Промпт создает полноценные пользовательские истории с контекстом, критериями приемки и связанными историями.
Текст промпта:
*****
Ты – продуктовый аналитик с опытом написания пользовательских историй для команд, работающих по гибким методологиям разработки.
Напиши пользовательские истории для [опишите функцию или раздел, например, “функция фильтрации товаров в каталоге интернет-магазина”].
Контекст продукта: [опишите продукт и его пользователей, например, “маркетплейс строительных материалов, покупатели – прорабы и частные застройщики, часто ищут конкретные технические характеристики”].
Для каждой истории напиши:
– Формулировка истории: Как [тип пользователя], я хочу [действие], чтобы [цель/ценность]
– Контекст: в какой жизненной ситуации возникает эта потребность
– Критерии приемки: конкретные условия, при которых история считается реализованной (5–7 пунктов)
– Связанные истории: что нужно реализовать до или после
– Приоритет и обоснование
Напиши 6–8 историй, охватывающих основные сценарии использования функции, включая нестандартные случаи.
Ограничения: каждая история – одна потребность, одна ценность. Никаких технических деталей реализации в формулировке истории. Критерии приемки – измеримые, не субъективные.
*****
Почему это работает: Раздел “связанные истории” создает карту зависимостей, которая помогает команде планировать спринты без сюрпризов в духе “оказывается, для этого нужно было сначала сделать вот это”.
15. Разработка концепции адаптивного дизайна
Проблема: Адаптивность часто понимается как “уменьшить все для мобильного”. В результате мобильный интерфейс – это уменьшенная копия десктопа, которой неудобно пользоваться ни на одном устройстве.
Решение: Промпт создает стратегию адаптации с четкими решениями для каждой контрольной точки и принципами приоритизации контента.
Текст промпта:
*****
Ты – UX-дизайнер с экспертизой в адаптивном проектировании для мультиплатформенных продуктов.
Разработай концепцию адаптивного дизайна для [опишите продукт, например, “образовательная платформа с видеоуроками, тестами и личным кабинетом”].
Контекст использования: [опишите, как пользователи взаимодействуют с продуктом на разных устройствах, например, “на десктопе – в рабочее время, на смартфоне – в дороге и перед сном, на планшете – для просмотра видео”].
Концепция должна включать:
– Принцип подхода: мобильный приоритет или десктопный приоритет и обоснование
– Контрольные точки (breakpoints): какие точки адаптации и почему именно они
– Для каждой точки адаптации:
- Изменения в навигации
- Изменения в сетке и отступах
- Элементы, которые скрываются или трансформируются
- Элементы, которые остаются неизменными
– Приоритизация контента: что показывается в первую очередь на маленьком экране
– Взаимодействие: как меняются интерактивные элементы (размеры зон нажатия, жесты)
Ограничения: адаптация – это не масштабирование. Каждое устройство должно иметь интерфейс, оптимальный для своего контекста использования, а не уменьшенную копию другого.
*****
Почему это работает: Вопрос о контексте использования на каждом устройстве меняет саму постановку задачи – от “как это уместить” до “что нужно пользователю именно здесь и сейчас”. Это фундаментальная разница в подходе.
16. Составление обоснования дизайн-решения
Проблема: Дизайнер принял решение, основанное на глубоком понимании пользователей и данных. Стейкхолдер хочет изменить цвет кнопки, потому что “так красивее”. Без структурированного обоснования этот разговор обречен.
Решение: Промпт создает аргументированное обоснование дизайн-решения, которое говорит на языке бизнеса и пользовательских данных.
Текст промпта:
*****
Ты – старший продуктовый дизайнер с опытом презентации дизайн-решений руководству и стейкхолдерам.
Составь структурированное обоснование дизайн-решения для [опишите решение, например, “отказ от боковой навигации в пользу нижней панели в мобильном приложении”].
Контекст: [опишите ситуацию, например, “решение принято по результатам юзабилити-тестирования, но вызвало сопротивление у руководителя, который привык к боковому меню”].
Аудитория документа: [укажите, кому адресовано, например, “директор по продукту и технический директор”].
Обоснование должно включать:
– Проблема, которую решает это решение (с данными или наблюдениями)
– Рассмотренные альтернативы и почему они не подошли
– Принятое решение: описание и логика
– Влияние на пользователя: какую проблему пользователя это решает
– Влияние на бизнес-метрики: какие показатели должны измениться и в какую сторону
– Риски и как их митигировать
– Следующие шаги для проверки решения
Тон: уверенный, аргументированный, без защитной позиции. Язык – бизнесовый, не дизайнерский. Объем: 300–400 слов.
*****
Почему это работает: Перевод дизайн-языка на бизнес-язык – это навык, который многие дизайнеры недооценивают. Промпт намеренно требует говорить о метриках, а не об эстетике – именно это работает в разговоре со стейкхолдерами.
17. Создание карты пользовательского пути
Проблема: Карты пользовательского пути часто рисуются как линейные схемы “зашел → сделал → вышел”. Реальный пользователь движется нелинейно, возвращается, сомневается и делает все совсем не так, как планировалось.
Решение: Промпт создает детальную карту пути с эмоциями, точками трения и возможностями для улучшения.
Текст промпта:
*****
Ты – UX-исследователь с опытом создания карт пользовательского пути для сложных цифровых продуктов.
Создай карту пользовательского пути для [опишите сценарий, например, “первая покупка в интернет-магазине электроники”].
Персонаж: [опишите пользователя, например, “Андрей, 42 года, инженер, покупает смартфон для жены, не очень уверен в онлайн-покупках, сравнивает цены на нескольких сайтах”].
Карта должна включать следующие этапы: осознание потребности → поиск информации → выбор магазина → выбор товара → оформление заказа → ожидание → получение → оценка опыта.
Для каждого этапа опиши:
– Действия пользователя (что делает)
– Мысли пользователя (что думает)
– Эмоции (с оценкой по шкале от -2 до +2)
– Точки контакта с продуктом (где взаимодействует)
– Точки трения (что мешает, раздражает, вызывает сомнения)
– Возможности для улучшения (конкретные решения для каждой точки трения)
Формат: структурированная таблица по этапам. Эмоции – конкретные, не абстрактные (“раздражение от непонятной доставки”, а не просто “негатив”).
*****
Почему это работает: Шкала эмоций от -2 до +2 – простой инструмент, который визуализирует эмоциональный график пути. Именно падения на этом графике указывают на приоритеты для работы.
18. Генерация вариантов микровзаимодействий
Проблема: Микровзаимодействия – это детали, которые незаметны, когда работают правильно, и очень заметны, когда их нет или они раздражают. Большинство команд добавляет их в последнюю очередь и без системной логики.
Решение: Промпт создает концепции микровзаимодействий для ключевых точек интерфейса с описанием триггера, логики и обратной связи.
Текст промпта:
*****
Ты – дизайнер взаимодействий с глубокой экспертизой в проектировании микроанимаций и обратной связи в интерфейсах.
Разработай концепции микровзаимодействий для [опишите продукт или раздел, например, “приложение для медитации и отслеживания настроения”].
Контекст: [опишите общий тон и атмосферу продукта, например, “продукт должен создавать ощущение спокойствия и заботы, без резких переходов и агрессивных анимаций”].
Разработай микровзаимодействия для следующих точек:
– Добавление записи о настроении
– Завершение сеанса медитации
– Достижение цели (например, 7 дней подряд)
– Напоминание о практике
– Загрузка контента
Для каждого микровзаимодействия опиши:
– Триггер: что запускает взаимодействие
– Логика: что происходит внутри системы
– Обратная связь: что видит и чувствует пользователь
– Длительность анимации (в миллисекундах)
– Эмоциональная цель: какое ощущение должно возникнуть
– Что будет, если этого микровзаимодействия нет (почему оно важно)
Ограничения: никаких анимаций ради анимаций. Каждое взаимодействие должно решать функциональную задачу или усиливать нужную эмоцию.
*****
Почему это работает: Вопрос “что будет, если этого нет” – это тест на необходимость. Если убрать взаимодействие и ничего не изменится – значит, оно было декоративным, а не функциональным.
19. Разработка концепции доступного интерфейса
Проблема: Доступность интерфейса воспринимается как дополнительная задача “для особых случаев”. На самом деле интерфейс, недоступный для пользователей с ограниченными возможностями, часто плохо работает и для всех остальных.
Решение: Промпт создает практический план обеспечения доступности с конкретными требованиями и способами проверки.
Текст промпта:
*****
Ты – специалист по доступности цифровых интерфейсов с опытом аудита и проектирования инклюзивных продуктов.
Разработай концепцию доступного интерфейса для [опишите продукт, например, “портал государственных услуг для подачи заявлений”].
Контекст: [опишите аудиторию и требования, например, “продукт используется людьми всех возрастов, включая пожилых пользователей и людей с нарушениями зрения, слуха и моторики”].
Концепция должна включать:
– Требования к контрасту: минимальные соотношения контраста для текста и интерактивных элементов
– Навигация с клавиатуры: порядок фокуса, видимость фокуса, логика перемещения
– Альтернативные тексты: правила написания для изображений, иконок, кнопок
– Размеры зон нажатия: минимальные размеры для разных типов устройств
– Формы и поля ввода: требования к подписям, подсказкам, сообщениям об ошибках
– Анимации: правила для пользователей с вестибулярными расстройствами
– Способы проверки: какие инструменты и методы использовать для тестирования
Для каждого раздела: конкретные числовые параметры, примеры правильного и неправильного решения. Формат – практическое руководство, а не теоретическая лекция.
*****
Почему это работает: Конкретные числовые параметры (соотношение контраста, размеры зон нажатия) превращают абстрактные требования в измеримые критерии, которые можно проверить без специального образования.
20. Написание гайдлайна по тональности интерфейса
Проблема: Когда над текстами интерфейса работают несколько людей без общего руководства, продукт начинает говорить с пользователем разными голосами. На одном экране – официальный тон, на другом – панибратский. Это разрушает доверие.
Решение: Промпт создает гайдлайн по голосу и тональности с конкретными примерами правильных и неправильных формулировок.
Текст промпта:
*****
Ты – UX-райтер и контент-стратег с опытом создания редакционных руководств для цифровых продуктов.
Создай гайдлайн по голосу и тональности интерфейса для [опишите продукт, например, “финтех-приложение для инвестиций”].
Характер продукта: [опишите, каким должен быть голос продукта, например, “умный и уверенный, но не снисходительный; доступный, но не упрощенный; поддерживающий, но не навязчивый”].
Гайдлайн должен включать:
– Описание голоса продукта: 4–5 прилагательных с развернутым объяснением каждого
– Чем голос НЕ является: 4–5 антиподов с объяснением
– Тональность в разных ситуациях: как меняется тон в зависимости от контекста (успех, ошибка, обучение, срочность)
– Правила написания текстов: конкретные лингвистические принципы
– Примеры: для каждого правила – формулировка “как не надо” и “как надо”
– Список слов и конструкций, которые запрещены
– Список слов и конструкций, которые рекомендуются
Формат: структурированный документ с примерами в каждом разделе. Объем: достаточный для практического применения без дополнительных объяснений.
*****
Почему это работает: Пары “как не надо / как надо” – это самый быстрый способ передать тональность. Читая примеры, человек мгновенно понимает разницу, которую не всегда можно объяснить словами.
21. Создание концепции уведомлений
Проблема: Уведомления – это привилегия, которую пользователь дает продукту. Большинство продуктов используют ее настолько агрессивно, что пользователь отключает все уведомления разом – и теряется важная коммуникация.
Решение: Промпт создает продуманную систему уведомлений с четкой логикой приоритетов и текстами для каждого типа.
Текст промпта:
*****
Ты – продуктовый дизайнер с экспертизой в проектировании систем уведомлений для мобильных приложений.
Разработай концепцию системы уведомлений для [опишите приложение, например, “сервис аренды самокатов”].
Контекст: [опишите ключевые события в жизни пользователя, связанные с продуктом, например, “пользователь ищет самокат, едет, завершает поездку, получает счет, использует приложение нерегулярно”].
Концепция должна включать:
– Типология уведомлений: разделение на категории по важности и срочности
– Для каждого типа: канал доставки (пуш, SMS, внутреннее), приоритет, возможность отключения
– Полный список событий, требующих уведомления, с обоснованием
– Тексты уведомлений для каждого события (заголовок + тело + действие)
– Правила частоты: как часто можно отправлять уведомления без раздражения
– Логика персонализации: как система должна адаптировать уведомления под поведение пользователя
– Что делать, если пользователь отключил уведомления
Ограничения: каждое уведомление должно нести реальную ценность для пользователя. Маркетинговые уведомления – отдельная категория с отдельными правилами. Тексты – конкретные, без клише.
*****
Почему это работает: Разделение на категории по важности и срочности – это фундамент системы. Без этого разделения все уведомления получают одинаковый приоритет, и пользователь быстро перестает их различать.
22. Разработка концепции поиска в интерфейсе
Проблема: Поиск добавляется в продукт как “строка ввода с иконкой лупы” – и на этом работа заканчивается. Как поиск ведет себя при опечатках? Что показывается при отсутствии результатов? Как работают подсказки? Эти вопросы обычно всплывают уже после запуска.
Решение: Промпт создает полную концепцию поиска со всеми состояниями и сценариями поведения.
Текст промпта:
*****
Ты – UX-дизайнер с опытом проектирования поисковых систем для сложных цифровых продуктов.
Разработай концепцию поиска для [опишите продукт, например, “база знаний для технической поддержки компании”].
Контекст: [опишите, что ищут пользователи и как, например, “пользователи ищут инструкции и решения проблем, часто используют непрофессиональные термины, ожидают немедленного результата”].
Концепция должна включать:
– Типы поиска: полнотекстовый, по тегам, по категориям – что нужно и почему
– Поведение строки поиска: когда активируется, как выглядит в фокусе, что происходит при вводе
– Подсказки и автодополнение: логика появления, типы подсказок, ограничения
– Результаты поиска: структура выдачи, ранжирование, выделение совпадений
– Обработка опечаток: как система реагирует на неточный ввод
– Пустые результаты: что показывается и какие действия предлагаются
– Фильтры и уточнение: когда они нужны и как работают
– Сохранение истории поиска: логика и управление
Формат: детальная спецификация поведения для каждого элемента. Тон – технический, точный.
*****
Почему это работает: Обработка опечаток и пустых результатов – это те состояния, которые определяют реальное качество поиска. Именно в этих точках пользователь решает, работает ли поиск вообще.
23. Создание концепции форм и полей ввода
Проблема: Формы – это место, где пользователи сдаются и уходят. Слишком много полей, непонятные подписи, агрессивная валидация “в реальном времени” – все это превращает простую задачу в испытание.
Решение: Промпт создает концепцию формы с продуманной последовательностью полей, логикой валидации и текстами подсказок.
Текст промпта:
*****
Ты – UX-дизайнер, специализирующийся на проектировании форм и сценариев ввода данных.
Разработай концепцию формы [опишите форму, например, “форма регистрации нового пользователя в сервисе телемедицины”].
Контекст: [опишите ситуацию заполнения формы, например, “пользователь заполняет форму впервые, часто на смартфоне, в состоянии беспокойства о здоровье – важно не создавать дополнительный стресс”].
Концепция должна включать:
– Список полей с обоснованием каждого (почему это поле необходимо)
– Порядок полей: логика последовательности
– Типы полей: какой тип ввода оптимален для каждого поля
– Подписи и подсказки: тексты для каждого поля
– Валидация: когда проверять (в реальном времени или после отправки), сообщения об ошибках
– Обязательные и необязательные поля: как обозначать и почему именно так
– Прогресс: нужен ли индикатор прогресса и какой
– Состояние после отправки: что видит пользователь после успешного заполнения
Ограничения: каждое поле должно быть обосновано. Никакой валидации до того, как пользователь завершил ввод в поле. Тексты ошибок – без обвинений.
*****
Почему это работает: Требование обосновать каждое поле – это встроенный фильтр от лишних вопросов. Если поле нельзя обосновать – скорее всего, оно не нужно, и пользователь это тоже чувствует.
24. Разработка концепции дашборда
Проблема: Дашборды часто превращаются в “выставку всех данных, которые у нас есть”. Пользователь смотрит на экран из 20 виджетов и не понимает, что из этого важно и что делать с этой информацией.
Решение: Промпт создает концепцию дашборда, построенного вокруг задач пользователя, а не вокруг доступных данных.
Текст промпта:
*****
Ты – продуктовый дизайнер с опытом проектирования аналитических дашбордов для бизнес-приложений.
Разработай концепцию дашборда для [опишите роль пользователя и контекст, например, “руководитель отдела продаж в компании среднего размера, ежедневно контролирует работу команды из 15 менеджеров”].
Ключевые вопросы, на которые дашборд должен отвечать: [перечислите, например, “как команда выполняет план, кто из менеджеров отстает, какие сделки в зоне риска, что изменилось за последние 24 часа”].
Концепция должна включать:
– Иерархия информации: что показывать в первую очередь и почему
– Ключевые показатели: список метрик с обоснованием выбора
– Визуализации: какой тип графика для каких данных и почему
– Временные периоды: какие периоды сравнения нужны и как переключаться
– Тревожные сигналы: как визуально выделять отклонения от нормы
– Детализация: как пользователь переходит от общей картины к деталям
– Персонализация: что пользователь может настраивать под себя
Ограничения: каждый элемент дашборда должен отвечать на конкретный вопрос или поддерживать конкретное решение. Данные ради данных – не концепция.
*****
Почему это работает: Начало с вопросов, а не с данных – это принципиальный сдвиг в подходе. Дашборд, построенный вокруг вопросов пользователя, всегда будет полезнее дашборда, построенного вокруг доступных метрик.
25. Написание концепции геймификации интерфейса
Проблема: Геймификация часто понимается как “добавить значки и прогресс-бары”. В результате получается поверхностная механика, которая не влияет на реальное поведение пользователя и раздражает тех, кто не воспринимает игровые элементы.
Решение: Промпт создает продуманную концепцию геймификации, основанную на мотивации пользователя, а не на визуальных украшениях.
Текст промпта:
*****
Ты – специалист по поведенческому дизайну с опытом внедрения геймификации в образовательные и продуктивные приложения.
Разработай концепцию геймификации для [опишите продукт, например, “приложение для изучения иностранных языков”].
Целевое поведение: [опишите, что должна поддерживать геймификация, например, “ежедневные короткие сессии занятий, возвращение после перерыва, постепенное усложнение заданий”].
Аудитория: [опишите пользователей, например, “взрослые люди 25–40 лет, учатся в свободное время, мотивация нестабильная, часто бросают через 2–3 недели”].
Концепция должна включать:
– Анализ мотивации: что движет этой аудиторией (внутренняя vs. внешняя мотивация)
– Механики прогресса: как пользователь видит свое развитие
– Система достижений: типы, логика выдачи, визуальное оформление
– Социальные механики: нужны ли и в каком объеме
– Механики возвращения: что возвращает пользователя после перерыва
– Антимеханики: что делать, чтобы геймификация не раздражала
– Метрики успеха: как измерить, что геймификация работает
Ограничения: геймификация не должна быть обязательной для достижения основных целей продукта. Пользователь, игнорирующий игровые элементы, должен получать полноценный опыт.
*****
Почему это работает: Раздел “антимеханики” – это защита от геймификации ради геймификации. Понимание того, что раздражает пользователя, важнее понимания того, что его радует.
26. Создание концепции темной темы
Проблема: Темная тема часто делается как “инвертировать все цвета” – и получается интерфейс, который выглядит как фотонегатив. Настоящая темная тема требует отдельной работы с цветами, контрастом и тенями.
Решение: Промпт создает полноценную концепцию темной темы с принципами адаптации цветовой системы.
Текст промпта:
*****
Ты – дизайнер дизайн-систем с опытом создания темных тем для сложных интерфейсов.
Разработай концепцию темной темы для [опишите продукт, например, “профессиональный редактор кода для разработчиков”].
Контекст: [опишите условия использования, например, “пользователи работают в темных офисах и ночью, темная тема – основная для большинства пользователей, светлая – вторичная”].
Концепция должна включать:
– Принципы адаптации цветов: почему нельзя просто инвертировать
– Фоновые уровни: сколько уровней фона нужно и почему (вместо теней в светлой теме)
– Адаптация основных цветов: как изменяются акцентные и семантические цвета
– Контраст: минимальные соотношения для текста, иконок, интерактивных элементов
– Изображения и иллюстрации: как адаптировать или заменить
– Переключение между темами: логика, скорость перехода, сохранение выбора
– Автоматическое переключение: по системным настройкам и по времени суток
– Элементы, которые не меняются между темами
Ограничения: темная тема – не просто эстетика, а функциональный инструмент снижения нагрузки на зрение. Каждое решение должно быть обосновано с этой точки зрения.
*****
Почему это работает: Принцип фоновых уровней вместо теней – это ключевое отличие профессиональной темной темы от любительской. Промпт направляет нейросеть именно к этому нюансу, который часто упускается.
27. Разработка концепции обработки загрузки данных
Проблема: Состояния загрузки – это время ожидания, которое пользователь проводит в неопределенности. Крутящийся индикатор без контекста – это лучший способ заставить пользователя думать, что приложение зависло.
Решение: Промпт создает систему состояний загрузки, которая управляет ожиданием и снижает тревогу пользователя.
Текст промпта:
*****
Ты – UX-дизайнер с экспертизой в проектировании состояний загрузки и управлении пользовательским ожиданием.
Разработай систему состояний загрузки для [опишите продукт, например, “мобильное приложение для бронирования авиабилетов”].
Контекст: [опишите ключевые операции с длительной загрузкой, например, “поиск рейсов занимает 3–8 секунд, оформление билета – до 15 секунд, оплата – до 10 секунд”].
Система должна включать:
– Типология загрузки: мгновенная (до 1 сек), короткая (1–3 сек), средняя (3–10 сек), длинная (более 10 сек)
– Для каждого типа: рекомендуемый паттерн загрузки и обоснование
– Скелетные экраны: когда использовать вместо индикатора, принципы построения
– Прогресс-индикаторы: когда использовать, как показывать прогресс без точных данных
– Тексты во время ожидания: что говорить пользователю на каждом этапе
– Обработка ошибок загрузки: что показывать при таймауте, как предлагать повторить
– Оптимистичные обновления: когда показывать результат до подтверждения сервера
Ограничения: каждое решение должно снижать воспринимаемое время ожидания, а не просто информировать о факте загрузки. Тексты – конкретные, без “пожалуйста, подождите”.
*****
Почему это работает: Разделение по длительности загрузки – это практический инструмент. Разные временные диапазоны требуют принципиально разных решений, и смешивать их – значит делать плохо для всех сценариев сразу.
28. Создание концепции персонализации интерфейса
Проблема: Персонализация часто реализуется как “показывать рекомендации на основе истории просмотров” – и это все. Настоящая персонализация интерфейса затрагивает структуру, контент и поведение продукта.
Решение: Промпт создает многоуровневую концепцию персонализации с четкими правилами сбора данных и адаптации интерфейса.
Текст промпта:
*****
Ты – продуктовый дизайнер с экспертизой в персонализации цифровых интерфейсов и поведенческом дизайне.
Разработай концепцию персонализации интерфейса для [опишите продукт, например, “новостной агрегатор для профессионалов”].
Аудитория: [опишите пользователей, например, “бизнес-аудитория, руководители и специалисты, интересуются отраслевыми новостями, ценят время и не любят информационный шум”].
Концепция должна включать:
– Уровни персонализации: явная (пользователь настраивает сам) и неявная (система адаптируется автоматически)
– Данные для персонализации: что собираем, как используем, как объясняем пользователю
– Точки адаптации интерфейса: что конкретно меняется под пользователя
– Первый запуск: как собрать первичные предпочтения без раздражения
– Прозрачность: как показывать пользователю, почему показывается именно этот контент
– Управление: как пользователь корректирует персонализацию
– Защита от “пузыря”: как не замкнуть пользователя в его собственных предпочтениях
Ограничения: персонализация не должна ограничивать доступ к контенту за пределами предпочтений. Сбор данных – минимально необходимый, с объяснением цели.
*****
Почему это работает: Раздел “защита от пузыря” – это редкий, но критически важный элемент. Продукт, который замыкает пользователя в его предпочтениях, постепенно теряет ценность, потому что перестает удивлять и расширять горизонт.
29. Разработка концепции офлайн-режима
Проблема: Офлайн-режим добавляется в последнюю очередь или не добавляется вовсе. Пользователь, потерявший соединение, видит белый экран или ошибку – и уходит. А ведь именно в этот момент продукт мог бы показать свою надежность.
Решение: Промпт создает концепцию офлайн-режима, которая обеспечивает непрерывный пользовательский опыт даже без соединения.
Текст промпта:
*****
Ты – UX-дизайнер с опытом проектирования офлайн-функциональности для мобильных приложений.
Разработай концепцию офлайн-режима для [опишите приложение, например, “корпоративное приложение для выездных сотрудников сервисной компании”].
Контекст: [опишите условия использования, например, “сотрудники работают в производственных помещениях и на объектах, где часто нет стабильного соединения; им нужен доступ к заданиям и возможность фиксировать результаты работы”].
Концепция должна включать:
– Функции, доступные офлайн: что обязательно работает без соединения
– Функции, недоступные офлайн: что блокируется и как об этом сообщается
– Синхронизация данных: логика синхронизации при восстановлении соединения
– Конфликты данных: что происходит, если данные изменились на сервере пока пользователь был офлайн
– Индикация состояния: как пользователь понимает, что работает офлайн
– Кэширование: что и как долго хранится на устройстве
– Переход в онлайн: как интерфейс ведет себя при восстановлении соединения
Ограничения: пользователь не должен терять данные, введенные офлайн. Переход между режимами должен быть незаметным там, где это возможно. Тон сообщений об офлайн-режиме – информирующий, не тревожный.
*****
Почему это работает: Раздел об обработке конфликтов данных – это то, о чем не думают до тех пор, пока пользователь не потерял часть работы. Промпт вынуждает решить эту проблему на этапе концепции, а не после первых жалоб.
Типичные ошибки при работе с промптами для проектирования интерфейсов
- Отправлять запрос без описания аудитории и контекста продукта. Нейросеть не знает, для кого проектируется интерфейс, и генерирует универсальный ответ, который подходит всем в равной степени – то есть никому конкретно.
- Просить сразу финальное решение вместо вариантов для выбора. Первый ответ нейросети – это не лучшее решение, это наиболее вероятное. Запрашивать 3–4 концептуально разных варианта всегда продуктивнее, чем принимать первое предложение.
- Не указывать ограничения и антипримеры в запросе. Без ограничений нейросеть стремится к полноте охвата и генерирует перегруженные решения. Фраза “чего делать нельзя” в промпте часто важнее фразы “что нужно сделать”.
- Использовать результат нейросети без критической проверки на конкретный контекст. Сгенерированный промпт для дизайнера интерфейсов дает профессиональную отправную точку, но не финальное решение. Каждый результат требует проверки на соответствие реальным пользователям и бизнес-задачам.
- Описывать желаемый внешний вид вместо задачи пользователя. “Сделай красивый онбординг” – это не запрос, это пожелание. “Разработай онбординг, который за 3 минуты доводит нового пользователя до первого успешного действия” – это задача, с которой нейросеть может работать.
- Игнорировать состояния ошибок и пограничные случаи в запросе. Если в промпте не упомянуть негативные сценарии, нейросеть сфокусируется на счастливом пути. А именно в пограничных случаях и ошибках обычно скрыты главные проблемы пользовательского опыта.
- Задавать слишком широкий запрос без декомпозиции на подзадачи. “Спроектируй мобильное приложение” – это не промпт, это техническое задание на полгода. Разбивка большой задачи на конкретные элементы (навигация, главный экран, состояния загрузки) дает несравнимо более полезный результат.
- Не уточнять формат вывода и структуру ответа. Без указания формата нейросеть выбирает его сама – и это может быть сплошной текст там, где нужна таблица, или список там, где нужно развернутое описание. Конкретный формат в промпте экономит время на переработку результата.
Сравнение слабых и сильных запросов для дизайнера интерфейсов
| Задача | Слабый запрос | Сильный запрос | Почему сильный работает лучше |
| Навигация | Придумай навигацию для приложения | Сравни 3 модели навигации для приложения доставки еды, используемого в спешке на смартфоне. Укажи плюсы, минусы и рекомендацию | Контекст использования (спешка, смартфон) меняет выводы кардинально |
| Онбординг | Напиши онбординг для банковского приложения | Разработай онбординг для банковского приложения: 4 шага максимум, цель – довести до первой операции, аудитория – люди 45+, впервые переходящие в мобильный банк | Ограничение в шагах и конкретная аудитория устраняют половину типичных ошибок онбординга |
| Тексты ошибок | Напиши текст ошибки при неверном пароле | Напиши тексты для 3 ситуаций с паролем: первая ошибка, третья ошибка (предупреждение о блокировке), блокировка. Тон – спокойный, без обвинений, не более 15 слов каждый | Три разных контекста требуют трех разных тональностей, ограничение слов убирает воду |
| Главный экран | Как должен выглядеть главный экран приложения для спорта? | Предложи 3 концептуально разных варианта главного экрана для трекера тренировок. Для каждого: иерархия элементов, главный акцент, для какого типа пользователя подходит лучше | Три варианта вместо одного дают реальный выбор; вопрос о типе пользователя привязывает к реальности |
| Пустые состояния | Что написать, если список задач пустой? | Напиши тексты для 3 пустых состояний списка задач: первый вход, все задачи выполнены, поиск не дал результатов. Тон – мотивирующий, не более 10 слов на каждое состояние | Три разные ситуации требуют разного эмоционального посыла; ограничение слов гарантирует лаконичность |
| Форма регистрации | Помоги сделать форму регистрации удобной | Проверь эту форму регистрации [список полей]: какие поля лишние, в каком порядке расположить, какой тип ввода оптимален для каждого, как формулировать подписи | Конкретный список полей дает конкретные рекомендации вместо общих советов |
| Дашборд | Спроектируй дашборд для руководителя | Разработай структуру дашборда для руководителя отдела продаж: 5 ключевых вопросов, на которые он должен отвечать за 30 секунд, без скроллинга. Укажи тип визуализации для каждой метрики | Ограничение “30 секунд без скроллинга” задает правильный приоритет: что важно, а что нет |
Советы по работе с промптами в дизайне интерфейсов
- Добавляйте в промпт описание эмоционального состояния пользователя в момент взаимодействия. Пользователь, оформляющий страховку после аварии, и пользователь, выбирающий пиццу на вечер, требуют принципиально разного тона и структуры интерфейса – и нейросеть учтет это только если контекст указан явно.
- Просите нейросеть объяснять причины каждого предложения, а не только перечислять решения. Фраза “для каждого решения укажи, почему именно так” в промпте превращает список рекомендаций в аргументированный документ, который можно защитить перед командой.
- Используйте нейросеть для генерации антипримеров – примеров плохих решений с объяснением. Понимание того, что делать нельзя и почему, часто более ценно, чем список правильных подходов: антипримеры запоминаются лучше и предотвращают конкретные ошибки.
- Разбивайте сложные дизайн-задачи на цепочку последовательных промптов. Сначала – анализ аудитории, затем – сценарии, затем – структура экрана. Каждый следующий промпт использует результат предыдущего как контекст: качество финального результата несравнимо выше, чем при попытке решить все одним запросом.
- Просите нейросеть сыграть роль скептичного стейкхолдера и задать вопросы к предложенному решению. Это позволяет выявить слабые места концепции до того, как она попадет на реальное обсуждение – и подготовить ответы заранее.
- Указывайте конкретные метрики успеха в запросе, а не абстрактные цели. “Снизить время выполнения задачи с 3 минут до 1 минуты” дает нейросети конкретный ориентир для оценки решений, в то время как “сделать интерфейс удобнее” не дает ничего измеримого.
- Сохраняйте промпты, которые дали качественный результат, с пометкой о контексте использования. Удачная формулировка для анализа навигации в одном продукте с минимальными правками сработает для следующего – и не придется каждый раз изобретать структуру запроса заново.
