Требования к постановке для выполнения работ дизайнером

В данном документе описаны принципы работы 
с документацией проектом в целом. Затрагиваются важные моменты структурирования и актуализации информации. Однако, не описывается сам процесс продуктового подхода. Продуктовый подход можно посмотреть в следующем документе: гайд по дизайну продукта
Авторы
Василина
Усольцева
Лиза 

Сахонь
Никита
Денисенко
Содержание:
Роль пользователей
Проблема, которую решают пользователи
Факторы
Критичность
Импакт
Контактное лицо
Сроки
Время реализации
Развитие
Пожелания бизнеса
Роль пользователей
Описание ролей, которые будут сталкиваться с описанными в задаче кейсами, и их рабочие обязанности влияют на выбор паттерна и расстановку визуальных приоритетов.Если роли уже описаны в проекте, то достаточно только перечислить их
Проблема, которую решают пользователи
Описание проблемы позволяет дизайнерам лучше вникнуть в проблематику, чтобы подобрать наилучший паттерн, задавая меньше вопросов, которые затягивают процесс проработки задачи.
Примеры описания проблемы:
Непонятное описание

Надо добавить виджет на дашборд, там показать график и такие-то параметры.
Понятные описание

Перед пользователем стоит такая-то задача, по такой-то причине. Для решения задачи ему, скорее всего, понадобятся вот такие данные. Нужно подумать, как решить задачу / проблему / Есть предложение по решению данной задачи / проблемы / Есть пожелания по решению данной задачи / проблемы
Если данная функциональность существует в старой системе (либо данная фукциональность — переработка существующей), она должна описываться в формате «Как есть. Как должно быть». Знание такой информации поможет дизайнером сэкономить время на продумывание уже существующего и рабочего решения, и наоборот не создавать решения, которые уже проверены и являются неверными.Перечисляя данные, очень полезно пояснять почему именно они нужны для решения задачи /проблемы, чтобы дизайнер расположил 
их в верном для пользователя месте и порядке.
Факторы
На выбор элементов и паттернов интерфейса сильно влияют следующие факторы:— Тех. ограничения связанные с реализацией задачи В какой момент происходит передача или запрос данных, есть ли сложности при их получении. Большую часть тех. проблемы можно сгладить визуальными приемами, снижая дискомфорт пользователя Атрибуты данных, отображаемых в задаче Кол-во символов в строке или названии, min 
и max. значение, статичность отображаемых данных и другие атрибуты влияют на расположение данных и их размер— Примеры реальных данных Они позволяют сделать макет достоверным, а так же улучшают восприятие сценария, упрощая согласование с другими участниками
Критичность
Вопросы требующие ответа:
1. Насколько критична данная проблема для пользователя? Зная ответ на этот вопрос дизайнеры смогут понять состояние пользователя при прохождении данного кейса, что будет влиять на его поведение 
и способ принятия решений, а значит и расстановку визуальных акцентов и манеру отображения информации.
2. Как часто он с ней сталкивается? Создавая супер-универсальный инструмент очень легко создать непонятного мутанта, поэтому всегда рекомендуется в первую очередь закрыть боли 80% ситуаций, против 20%. Зная, как часто встречается данный кейс, дизайнеры смогут понять, что приоритетнее при его прохождении: время или обдуманность.
3. Насколько важен описанный в задаче кейс для проекта? Т.к. дизайнеры бывают часто ограниченны временными рамками, важно понимать, насколько дотошно нужно подходить к проработке той или ной задаче. Как правило, к значимым для проекта задачам бизнес особенно внимателен, а значит кроме выполнения задачи, можно подумать еще и о представлении ее в лучшем свете (например сделать крутой интерактивный прототип)
Импакт
Понимание, какие части системы могут быть затронуты при решении данной задачи, может помочь сократить время дальнейших доработок и снизить вероятность переработки части интерфейса.

Содержание:
— Роль пользователей

— Проблема, которую решает пользователи

— Факторы 

— Критичность 

— Импакт 

— Контактное лицо 

— Сроки
Время реализации Развитие Пожелания бизнеса
Для этого понимания необходимы ответы на следующие вопросы:
1. Откуда пользователь может попасть на эту страницу и куда может перейти?
2. Есть ли связанные экраны и аналогичные задачи встречающиеся 
в другой части системы?
3. Ссылки на макеты
4. Предполагается ли в будущем разработка связанных экранов 
и аналогичных задач?
5. Скриншоты, наброски или ссылки на описание/макеты
Если данная информация не известна заранее, можно обсудить данный момент на встрече с дизайнерами. Это поможет всем целостнее увидеть разрабатываемый продукт.
Контактное лицо
Человек, готовый оперативно ответить на вопросы дизайнера, возникающие в процессе работы Если контактное лицо — создатель задачи, указывать его в постановке не требуется
Сроки
Зная желаемый срок выполнения задачи, и ее приоритет, дизайнеры смогут лучше спланировать время, оправдывая большее кол-во ожиданий.Нужно понимать, что реальные сроки выполнения задачи могут не совпадать с желаемыми, вне зависимости от приоритета задачи
Время реализации
Ориентировочная дата, когда планируется реализовать функционал согласно решению по данной задачи, поможет команде дизайна верно распланировать время, чтобы своевременно провести ревью реализации, а так же поддержать разработку при выполнении 
их части задачи.
Развитие
Видимые горизонты развития функционала по данной задаче, помогут дизайнерам правильнее собрать компоненты, чтобы в будущем было проще в них что-то добавить.
Пожелания бизнеса
Предложения, которые были высказаны заказчиками, позволяют лучше их понять, а значит больше угодить.
Пример постановки задачи
Описание проблемы
Описание проблематики, то с какими проблемами сталкивается пользователь текущего интерфейса. И какие боли хочет решить бизнес. Учитываем оценку критичности проблемы, частоты ее возникновения 
и оценку важности задачи.
— Оценка критичности проблемы для пользователя позволяет дизайнерам адаптировать расстановку визуальных акцентов 
и отображение информации в соответствии с состоянием и поведением пользователя.

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

— Оценка важности задачи позволяет дизайнерам определить, насколько детально нужно ее проработать, учитывая ограничения по времени. Важные задачи могут быть подвержены большему вниманию бизнеса, поэтому их решение может включать создание дополнительных элементов, например, интерактивных прототипов, для более эффективного представления решения.
Указание роли
Указать роли пользователей, кто будет пользоваться данным функционалом. Описание ролей, их рабочих обязанностей и какие бизнес задачи решает данная роль в этом функционале. От этого зависит выбор паттерна и расстановку визуальных приоритетов.
В рамках какого процесса происходит сценарий для которого нужны макеты
Какую бизнес-задачу необходимо решить. Описание или если есть схемы по процессу для которого нужны макеты, будет полезно приложить к описанию.
Сценарий по которому идет пользователь.
Точка старта сценария, какие шаги проходит пользователь, какие действия совершает.
— Как пользователь может попасть на данную страницу и куда он может перейти?
— Есть ли связанные экраны?

Если задача основывается на гипотезе, то необходимо это указать.
Модель и пример данных
Максимально описать какие сущности будут содержаться в данном функционале (Поля, списки, кнопки). Если есть графическое представление (схемы, макеты), так же можно приложить к описанию.
Для того, чтобы дизайнер мог правильно разместить данные 
в приложении или на сайте, важно не только перечислить их, 
но и объяснить, как они помогут решить определенную 
задачу или проблему.
Ограничения бизнеса
Например проверка на дубликаты, обязательные поля, ограничения 
со стороны бэка на количество вводимых записей.