Статья Как заводить задачи на дизайн
[Все доки](https://hackmd.io/UbcEkPsoSXiok4QZx_TnIQ)

# Как заводить задачи на дизайн

## Куда заводим

[На дизайнерскую доску в гитлабе.](https://gitlab.sima-land.ru/dev-dep/design/sima-land-site/-/boards/200)
Доступ к ней есть только у членов команд дизайна и планирования.

## Целеполагание и обоснование задачи

**Задача ставится исходя из гипотезы, которую мы хотим проверить**. При постановке задачи необходимо обозначить:

- Что мы хотим изменить?
- Какая метрика должна измениться в результате? (конверсия, retention, LTV, MAU, DAU и т.д.)
- На сколько она изменится?
- Как и на ком будем проверять решение? (А/Б-тест, пользовательское исследование, опрос и т. д.)

**Пример:**
“По результатам аналитики пользователи не добавляют товар в корзину из каруселей рекомендаций. Чтобы добавить товар в корзину, пользователю придётся проваливаться сначала в карточку товара и оттуда уже класть товар.
Мы думаем, что если выводить кнопку “в корзину” у товаров в карусели сразу, это увеличит конверсию в покладку.
Гипотеза подтвердится, если конверсия в покладку из каруселей рекомендаций увеличится на 20% в течение двух недель.
Проверять будем через А/Б-тест”

## Заголовок

- В заголовке задачи коротко сформулирована основная её суть. Заголовок начинается с глагола конкретного действия (Нарисовать/ Написать / Доработать / Переделать), а не с размытого (Подумать / Посмотреть / Поразмышлять).
- В заголовке указано, для каких платформ требуется дизайн, если это важно.

**Лучше использовать формулу:** Что (сделать) + Где (раздел) + На какой платформе (Декстоп / Моб версия / Моб приложение)

**Пример хорошего заголовка:** “Нарисовать интерфейс экрана смены пароля в личном кабинете (Десктоп)”

**Пример нехорошего заголовка:** “Не очень понятно как и куда внедрить фичу в поле комментария, надо подумать”

## Описание задачи

- Если задача подкреплена аналитикой и результатами исследований, они приложены к задаче.
**Пример:** *“По результатам исследования (в задаче #ххх) выяснили, что пользователям не хватает механизма частичного выбора товаров в корзине, чтобы удалить несколько товаров (Ссылка на исследование)...”*

- Прикреплены ссылки на макеты, с которыми связана задача.
- Описан кейс (неуспешный), который обьясняет суть задачи.
**Пример:** *"Вася заходит на экран корзины, но по причине особой степени дальтонизма не видит синюю кнопку “оформить заказ”, потому что она сливается с экраном..."*

- В задаче описаны функциональные требования к макету, а не продиктовано конкретное дизайнерское решение
**Плохой пример:** *"Нужно вставить красную кнопку с текстом "купи" прямо под шапку в карточке товара. Место обведено на скриншоте."*
**Хороший пример:** *"Добавить функционал покладки товара в корзину из карточки товара"*

- Если есть связанные задачи по дизайну, то они прилинкованы к текущей.

- Если планируется запуск крупной фичи, то приложен фич-лист — перечисление необходимого функционала, который должен быть отрисован в макете.
**Пример фич-листа:** 

## Лейблы
- После создания задачи на дизайн ей нужно присвоить лейбл “**To do**”.
- Чтобы задачу взяли в план, то до пятницы нужно установить у нее лейбл “**FutureSprint**”
- Лиды команд планирования и дизайна выбирают и распределяют задачи из “**FutureSprint**” в “**ActiveSprint**”. Обычно это происходит в пятницу.
- Также при распределеннии задаче присваивается один из трёх лейблов приоритета ("**Minor**", "**Major**", "**Critical**") и лейбл "**Мобильное приложение**, если задача касается только приложения. Если необходимые лейблы не указаны, задача не попадёт в план на выполнение.
- Когда дизайнер берет задачу в работу он ставит лейбл “**Doing**”
- После того, как задача с лейблом “**Review**” окончательно согласована, нужно отписать итог в комментах к задаче: обычно это ссылка на задачу на разработку в гитлаб. После этого задачу можно отправлять в "done", присвоив ей соответствующий лейбл.
- Если дизайнер ждет ответа больше суток, то он ставит лейбл - Когда дизайнер берет задачу в работу он ставит лейбл “**Agreement**” и указывает причину ожидания