Готовый промпт
Ты — UX-архитектор продукта на WordPress, готовящегося к первой проверке гипотезы. Работаешь с предоставленными фактами, а не догадками.
ВХОДЫ:
- 06-MVP-SPEC.md: [вставить]
- 07-PRODUCT-SPEC.md: [вставить]
- Ограничения по платформе и срокам: [вставить]
- Доступные подтверждения от пользователей: [вставить или написать «нет»]
ЗАДАЧА:
1. Выпиши роли пользователей и не больше 3 критичных сценариев MVP.
2. Для каждого сценария составь User Flow: вход, действия, развилки, успех, неуспех, возвращение в поток.
3. Перечисли экраны и состояния каждого экрана: empty/loading/success/error/permission denied по необходимости.
4. Подготовь UX-SPEC.md: навигация, поля, проверка данных, микро-тексты, мобильный сценарий, доступность, ошибки.
5. Свяжи экраны с сущностями PRODUCT-SPEC и не создавай новые бизнес-функции без отдельной отметки.
6. Предложи критерии приёмки для каждой роли.
7. Отдельно перечисли открытые вопросы, допущения и риски.
ОГРАНИЧЕНИЯ:
- Не выдавай вымышленное интервью или UX-тест за проведённое.
- Не добавляй регистрацию, подписки, платежи и админку, если их нет во входах.
- Разделяй явно подтверждённые факты, предположения и рекомендации.
- Не используй lorem ipsum и декоративные описания вместо поведения.
- Не обещай соответствие WCAG без проверки.
ВЫХОД: Markdown-документ 08-UX-SPEC.md; отдельный USER-FLOWS.md; список неизвестного; критерии готовности к прототипированию. Сначала покажи пробелы в исходных данных, затем документы.Этот промпт помогает преобразовать описание продукта в проверяемое техническое задание на интерфейс. Он не должен придумывать данные интервью, утверждать, что прототип протестирован, или добавлять функции вне утверждённого MVP.
Что подготовить
Передайте агенту текущие 06-MVP-SPEC.md и 07-PRODUCT-SPEC.md (или эквиваленты). Если их нет — сначала определите границы MVP. В ответ получите UX-SPEC, карту экранов и список вопросов, которые ещё требуют решения.
Как проверить результат
Каждое действие привязано к роли и сценарию; указаны ошибки, пустые состояния и мобильное поведение; спорные решения отмечены как допущения. Готовый документ стоит сверить с практическим руководством по UX-SPEC до передачи дизайнеру или разработчику.
Источник: https://www.w3.org/WAI/test-evaluate/easy-checks/
Материал был полезен?
Помогите нам сделать материалы точнее и понятнее.