Шаблон задачи
Документ для дизайнеров и аналитиков, чтобы избежать разночтений и ускорить понимание требований.
Включает: как поставить задачу аналитику, как передать выполненную задачу дизайнеру, чего не должно быть в задаче + пример задач для нового флоу и внесения правок
  • 1. Материалы по задаче
    Приложите только те материалы, которые необходимы для работы: тексты, графику, прототипы
  • 2. Цель и контекст
    Опишите бизнес-цель и проблему, которую необходимо решить. Достаточно 2–3 предложений: что требуется и зачем
  • 3. Функциональные требования
    Укажите, что должно быть реализовано для пользователя. Прикрепите прототип (если он есть) и отметьте возможные ограничения платформы
  • 4. Технические требования (если необходимы)
    Укажите использование API, интеграции, особенности производительности или платформ
  • 5. Сроки и результаты
    Определите сроки выполнения задачи. Укажите, как будет измеряться успешность: метрики, тестирование, дополнительные ресурсы (если необходимы)
  • 6. Документация и файлы (если необходимы)
    Предоставьте все финальные источники: тексты (в приоритете), шрифты, иконки, графику
  • 1. Черновики и лишние материалы
    Дизайнеру нужны только основные материалы, которые помогают понять суть задачи, а не вся информация, которая обсуждалась в любых источниках, кроме задачи
  • 2. Лишняя информация
    Постановка задачи должна быть ясной и честной. Опишите задачу просто и понятно — 3-5 предложений достаточно, при необходимости, можно расширить. Чем меньше текста, тем лучше
  • *Что может быть, но дизайнер может не учитывать
    Неокончательные макеты:
    Вайрфреймы, драфты и другие не готовые макеты можно предоставить, чтобы дизайнер понял задачу, но дизайнер не обязан их использовать

1. Определение задачи и контекста

  • 1. Определите, что именно нужно сделать: новая фича или доработка существующего функционала
    • Новая фича: Подготовьте User flow (оставьте место для прикрепления ссылки на макет)
    • Доработка текущего функционала: Укажите, что это не новая сборка flow, прикрепите ссылки на макеты, где требуется внести изменение

    2. Убедитесь, что User flow согласован с разработкой
    • Если User flow не требуется (например, для небольшой доработки), зафиксируйте это 
    • Возможно привлечение дизайнера

    3. Опишите бизнес-цель и проблему пользователя
    • Должно быть ясно, зачем мы делаем эту задачу и какую проблему решаем
    • Достаточно 2–3 предложений
2. Контент и материалы
  • 1. Проверьте, подготовлен ли реальный контент
    Если контент отсутствует, зафиксируйте план по его подготовке

    2. Определите, нужно ли закладывать время на прототип или варфреймы
    • Да: задача объемная, логика требует предварительного согласования
    • Нет: задача небольшая, глубокая проработка не нужна
3. Функциональные требования
  • 1. Опишите, что должно быть реализовано для пользователя
    2. Укажите все действия и процессы, которые доступны пользователю
    3. Заранее определите ограничения платформы или бизнес-ограничения (если необходимы)
4. Сроки и результат
  • 1. Определите сроки выполнения задачи

    2. Уточните, как будет измеряться успешность задачи (применимо для нового флоу)
    • Метрики (например, конверсия, вовлеченность)
    • Нужно ли проводить тестирование (юзабилити, A/B, интеграционное)
5. Грумминг и согласование макета
  • 1. Грумминг
    Встреча для сбора обратной связи по дизайн макету и согласование с командой (ПО, аналитик, разработка, дизайнер)

    2. Зафиксируйте, может ли макет быть изменен:
    • Согласован, изменения невозможны — дизайнер работает с финальной версией
    • Отправлен на доработку — возможны изменения
1. Как передать задачу заказчику
  • 1. Проверьте, готов ли прототип или варфрейм для задачи (если необходимы, для создания новых сценариев)
    2. Определите, нужно ли создавать дополнительные состояния интерфейса для проверки логики
2. Работа с материалом
  • 1. Используйте только финальные материалы: тексты, графику, иконки, шрифты
    2. Черновики, непроверенные вайрфреймы и драфты могут быть предоставлены для понимания задачи, но их использование необязательно
3. Состояние страницы
  • (Если есть необходимость)
    Проверьте, что отрисованы все ключевые состояния элементов интерфейса:
    1. Ошибки при загрузке данных — пользователь должен видеть корректное сообщение об ошибке
    2. Заблокированные и неактивные состояния компонентов — кнопки, поля и другие элементы, которые нельзя использовать
    3. Состояния отсутствия данных — пустые экраны, сообщения «нет данных» и т.д
    4. Учесть возможные проблемы с контентом:
    • Пользовательский контент может не загрузиться
    • Ошибка на странице, контент не отображается
    • Долгая загрузка контента
    Если какое-то состояние не применимо, зафиксируйте причину
4. Максимальные и минимальные состояния контента
  • (Если есть необходимость)
    1. Проверьте, что все блоки и компоненты отображаются корректно при максимальном и минимальном объеме данных
    2. При необходимости добавьте пояснения для разработчиков о вариативности контента
5. Навигация и структура макетов
  • Убедитесь, что макеты организованы логично:
    1. Страницы подписаны
    2. Блоки и секшены сгруппированы так, чтобы любой член команды мог быстро понять структуру и найти нужный элемент
6. Адаптивность
  • (Если есть необходимость)
    1. Проверьте, что макеты подготовлены для всех необходимых экранов: адаптивная версия для веба, а при необходимости — отдельные версии для Android и iOS
    2. Если это не указано в задаче, уточните у аналитика или продакта, чтобы исключить недопонимания
7. Финализация макета
  • 1. Проверьте макет перед передачей в разработку: все состояния, контент и интерактивные элементы должны быть продуманы
    2. Если макет требует доработки, убедитесь, что команда знает о дополнительных работах. Нужно избежать кейса, что дизайнер вносит правки, а разработка параллельно работает с этим макетом
Небольшая доработка (уже есть макет)
  • Контекст:
    Нужно внести правки в существующий макет страницы оплаты — заменить текст кнопки «Оплатить» на «Перейти к оплате» и добавить уточнение под полем выбора карты. Это не новая сборка flow

    Функциональные требования:
    • Изменить текст кнопки согласно новому копирайту
    • Добавить подсказку под полем: «Поддерживаются карты Visa, MasterCard и Мир»
    • Проверить, чтобы отображение корректно работало на десктопе и мобильных устройствах
Новое flow
  • Контекст:
    Создание нового флоу «Повторная покупка товара» для упрощения повторных заказов. User flow подготовлен и согласован с аналитиком и разработкой (ссылка на макет будет добавлена после первого варфрейма).
    Бизнес-цель — повысить конверсию повторных покупок и сократить путь пользователя до оплаты

    Контент и материалы:
    Нужен прототип для согласования логики шагов (выбор товара → подтверждение адреса → оплата). Тексты и иллюстрации будут добавлены после утверждения UX

    Функциональные требования:
    • Пользователь может выбрать ранее купленный товар из личного кабинета
    • После выбора — перейти к подтверждению адреса и способа оплаты
    • На финальном экране отобразить статус заказа и кнопку «Вернуться в каталог»
    • Учесть бизнес-ограничение: возможность повтора только для товаров в наличии
    Сроки и результат:
    Срок — до конца текущего спринта. Успех оценивается по росту доли повторных покупок (цель: +10%)

    Грумминг:
    • После первого варфрейма провести грумминг с разработкой и аналитикой. Макет может быть изменен после обратной связи