Фреймворк оценки задач для дизайн-команд

Уверен, вам знакомо чувство, когда ваш PM просит вас оценить некую задачу вы сталкиваетесь со следующей дилеммой: если дать слишком сжатый дедлайн — можно не уложиться; если поставить слишком долгий — может сложиться впечатление, что вы некомпетентны. Так как же дизайнерам оценивать задачи так, чтобы это было удобно обеим сторонам — и PM’ам, и дизайнерам?

Фреймворк оценки задач для дизайн-команд

Чтобы лучше согласовывать ожидания, избегать перегрузок, повышать предсказуемость загрузки дизайнеров и избавиться от сложных временных формул, мы используем систему XS–XL для оценки дизайн-задач.

Смысл данного подхода в том, чтобы уйти от жёсткого планирования по времени. Иначе можно было бы просто использовать оценки в часах. У каждого дизайнера разная скорость — поэтому я не привязываю размеры XS–XL к часам или дням. Обычно нужно несколько спринтов, прежде чем PM’ы научатся переводить размеры задач во время для разных дизайнеров или команд.

Также важен и психологический комфорт дизайнеров: я не хочу ситуаций, когда дизайнеры боятся «не выполнить» фиксированное количество задач за спринт только потому, что это «должно» вписаться в некую формулу.

Для удобства оценки задач я рекомендую использовать три критерия: сложность, объём и коммуникации, — чтобы каждый дизайнер мог оценивать задачу так, как ему привычно и комфортно. Эти три критерия — лишь ориентир и вы можете выработать свои, если хотите.

Размеры задач

🟢 XS — крошечная задача («С закрытыми глазами»)
Пример: заменить кнопку, обновить текст, изменить цвет токена, обновить иконку в компоненте.

🔵 S — небольшое улучшение («Да, нормально»)
Пример: редизайн карточки, подправить фильтр, добавить состояния ошибки/загрузки для компонента.

🟡 M — стандартная продуктовая задача («Поехали»)
Пример: дизайн флоу авторизации, рефакторинг адаптивной модалки, создание нового компонента.

🟠 L — крупный функционал («Ух ты, серьёзно»)
Пример: новый раздел или флоу в приложении, многоступенчатые процессы.

🔴 XL — проект или инициатива («20-минутное приключение»)
Пример: запуск новой продуктовой категории, редизайн всей навигации, создание дизайн-системы с нуля.

Критерии оценки

Чтобы оценить задачу, учитывайте три критерия (необязательно — можно использовать свои):

1) Сложность, глубина — требует ли задача ресёрча, концептов или кастомных UX-решений?

Вспомогательные вопросы:
- Нужен ли новый подход или глубокая проработка?
- Это типовой UX или что-то, создаваемое с нуля?
- Потребуется ли ресёрч, анализ конкурентов или ветвление UX?
- Это простой UI или требуется концептуальное переосмысление?

2) Объём, ширина — сколько экранов, состояний, крайних кейсов, вариантов или компонентов?

Вспомогательные вопросы:
- Это один экран или несколько флоу?
- Сколько уникальных состояний, экранов, ховеров, брейкпоинтов? (iOS, Android, десктоп, мобайл)
- Нужны ли новые компоненты, токены, иконки или можно переиспользовать уже существующие?

3) Коммуникации — сколько согласований, стейкхолдеров и итераций?

Вспомогательные вопросы:
- Сколько людей участвуют в согласовании и сколько времени это займёт?
- Нужны ли синки с продактом, разработкой, аналитиками или контентом?
- Критично ли согласование со стейкхолдерами или задача может идти сразу в работу?
- Полностью ли задача в моей зоне контроля или нужны внешние вводные/доступы?

В заключение

Как и в любом процессе, здесь есть нюансы. Вот три момента, которые важно учитывать:
Продакт-менеджеры — пользователи продукта «оценка задачи», который создают «исполнители», поэтому стоит начать с понимания их опыта и требований. Исполнители — пользователи продукта «управление проектами». Обе стороны должны проявлять эмпатию к потребностям друг друга.

На вопрос «Как дизайнеры могут оценивать задачи, чтобы это было удобно и PM’ам, и самим дизайнерам?» не может ответить одна из сторон по-отдельности. Поэтому стоит начать с открытого диалога между дизайнером и PM. Возможно, некоторым менеджерам потребуется более простая или наоборот более детализированная система оценки. Контекст имеет значение.

Отказ от жёсткого планирования по времени возможен для исполнителей, но может быть непрактичен для PM. Им всё равно нужно перевести оценку в эквивалент времени и трудозатрат. Психологическая безопасность создаётся, когда разделены зоны ответственности двух «пользователей», а также есть понятные договорённости. Не додумывайте за других — обсуждайте.

Спасибо за внимание:) Не стесняйтесь задавать вопросы, предлагать улучшения данного подхода или просто начните применять его в своей работе. Мой тг