Регламент работы с заявками на иконки

Статус документа: действующий регламент Область применения: Astra Design System — процесс работы с иконками Источник истины: Figma

1. Общие положения

Настоящий регламент определяет единый порядок создания, рассмотрения, доработки, отклонения, публикации и архивирования заявок на иконки в Astra Design System.

Figma является основным источником информации по заявке. Все решения, замечания, уточнения и причины отклонения должны быть зафиксированы в секции соответствующей заявки.

Регламент применяется для новых иконок, возврата иконок из DEPRECATED, замены или исправления существующих иконок, а также добавления недостающих вариантов.

2. Участники процесса и ответственность

2.1. Дизайнер

  • Проверяет наличие подходящей иконки в актуальном пакете.

  • Создаёт заявку в секции ВХОДЯЩИЕ / INBOX.

  • Заполняет обязательные поля и прикладывает все доступные материалы.

  • Отвечает на комментарии ревьюера и дополняет заявку недостающей информацией.

  • Задаёт вопросы по замечаниям или причине отклонения в комментариях секции заявки.

2.2. Ревьюер

  • Проверяет полноту заявки, наличие дублей и подходящих аналогов.

  • Оценивает соответствие визуала принципам иконографики Astra Design System.

  • При нехватке данных оставляет комментарий непосредственно в секции заявки, перечисляет, что необходимо добавить, и отмечает автора.

  • При передаче заявки иллюстратору оставляет в секции понятные пометки: что нужно сделать, какие варианты подготовить, какие ограничения учитывать и на что обратить внимание.

  • При переводе заявки в ГОТОВЫ / DONE при необходимости оставляет пояснения для Core-команды.

  • При переводе заявки в ОТКЛОНЕНЫ / REJECTED указывает причину отказа и, если существует подходящий аналог, прикладывает ссылку на него.

  • Отвечает на вопросы автора по отклонённой заявке в комментариях секции.

  • После решения вопроса или устранения замечания закрывает соответствующий комментарий.

2.3. Иллюстратор

  • Изучает заявку и комментарии ревьюера.

  • Задаёт уточняющие вопросы в комментариях секции.

  • Подготавливает иконку и необходимые варианты.

  • Исправляет замечания после ревью и отмечает ревьюера после внесения изменений.

2.4. Core-команда

  • Забирает принятый визуал из секции ГОТОВЫ / DONE.

  • Проверяет структуру принятого результата.

  • Собирает компонент или component set в актуальном паке.

  • Публикует компонент в библиотеке.

  • Только после публикации переносит заявку в В РАЗРАБОТКУ / TO DEV и передаёт иконку разработчикам.

  • После полного завершения процесса перемещает заявку в АРХИВ / ARCHIVE.

3. Карточка заявки

Для всех типов задач используется единая карточка заявки.

Обязательные поля: название иконки; ссылка на макет или сценарий в Figma; описание задачи и контекста; материалы или референс; имя и фамилия автора; Telegram-ник; дата создания заявки.

В описании необходимо указать, что требуется сделать, где будет использоваться иконка, какой смысл она должна передавать и почему текущих иконок недостаточно.

В материалах можно приложить внешний референс, готовый визуал, скриншот из продукта, старую иконку, ссылку на DEPRECATED или локальный файл.

Наличие всех необходимых вариантов в референсе и короткого комментария для ревьюера может существенно ускорить рассмотрение заявки и сократить количество уточнений.

4. Официальные статусы

ВХОДЯЩИЕ / INBOXНовая заявка ожидает проверки
В РАБОТЕ / IN PROGRESSЗаявка находится на ревью, уточнении или в работе у иллюстратора
ГОТОВЫ / DONEВизуал принят ревьюером и ожидает действий Core-команды
В РАЗРАБОТКУ / TO DEVИконка подготовлена Core-командой и передана в разработку
АРХИВ / ARCHIVEРабота полностью завершена
ОТКЛОНЕНЫ / REJECTEDЗаявка отклонена с указанием причины

5. Порядок прохождения заявки

1ДизайнерСоздаёт и заполняет заявкуВХОДЯЩИЕ / INBOX
2РевьюерПроверяет заявку и при необходимости запрашивает данныеВХОДЯЩИЕ / INBOX или В РАБОТЕ / IN PROGRESS
3Иллюстратор / дизайнерГотовит или дорабатывает визуалВ РАБОТЕ / IN PROGRESS
4РевьюерПринимает результат и закрывает рабочие комментарииГОТОВЫ / DONE
5Core-командаЗабирает визуал из ГОТОВЫ / DONE, собирает и публикует компонент в паке, затем передаёт его в разработкуВ РАЗРАБОТКУ / TO DEV
6Core-командаЗавершает процессАРХИВ / ARCHIVE

5.1. Создание и первичная проверка

Дизайнер создаёт заявку в секции ВХОДЯЩИЕ / INBOX.

Ревьюер проверяет полноту заявки, наличие дублей, подходящих аналогов и соответствие задаче дизайн-системы.

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

5.2. Работа над визуалом

Если готовый визуал принят без доработок, ревьюер переводит заявку в ГОТОВЫ / DONE.

Если требуется новая иконка или доработка, заявка переводится в В РАБОТЕ / IN PROGRESS, а ревьюер оставляет пометки для иллюстратора.

После выполнения работы иллюстратор отмечает ревьюера. Ревьюер проверяет результат и либо принимает его, либо оставляет замечания.

После устранения всех замечаний ревьюер переводит заявку в ГОТОВЫ / DONE.

5.3. Публикация и передача в разработку

Core-команда забирает принятый визуал из секции ГОТОВЫ / DONE, собирает на его основе компонент или component set в актуальном паке и публикует его в библиотеке.

Только после публикации компонента Core-команда переводит заявку в В РАЗРАБОТКУ / TO DEV и передаёт иконку разработчикам.

После полного завершения процесса заявка перемещается в АРХИВ / ARCHIVE.

5.4. Отклонение заявки

Заявка может быть отклонена, если иконка уже существует, есть подходящий аналог, заявка заполнена не полностью, визуал не является UI-иконкой, решение относится только к локальному сценарию или не соответствует принципам дизайн-системы.

При отклонении ревьюер переводит заявку в ОТКЛОНЕНЫ / REJECTED, указывает конкретную причину отказа и при наличии прикладывает ссылку на аналог.

Ревьюер обязан отвечать на вопросы автора по отклонению до тех пор, пока вопрос не будет закрыт.

6. Правила работы с комментариями

Все рабочие обсуждения по заявке ведутся в комментариях соответствующей секции Figma.

Комментарии должны содержать конкретный вопрос, замечание или действие, ожидаемое от участника процесса.

После решения вопроса, предоставления данных или внесения изменений ревьюер закрывает соответствующий комментарий.

Перед переводом заявки в ГОТОВЫ / DONE, ОТКЛОНЕНЫ / REJECTED или В РАЗРАБОТКУ / TO DEV все комментарии, требующие действий, должны быть закрыты.

Открытыми могут оставаться только информационные комментарии, которые не блокируют процесс и не требуют ответа или изменений.

Личные сообщения и чаты могут использоваться для оперативного общения, но итоговое решение обязательно фиксируется в комментариях секции заявки.

7. Спорные ситуации

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

Если после обсуждения остаются разногласия, к рассмотрению заявки могут быть привлечены лиды команды.

Финальное решение фиксируется в комментариях заявки и является итоговым для дальнейшей работы.

8. Требования к результату иллюстратора

Подготовленные варианты должны располагаться в порядке Base → Variable → Solid.

Такой порядок обязателен, поскольку позволяет Core-команде быстро проверить результат и собрать единый component set.

Если требуется только один вариант, допускается одиночный компонент. Причина отсутствия остальных вариантов должна быть понятна из заявки или комментария ревьюера.

9. Критерии готовности

Перед переводом заявки в ГОТОВЫ / DONE ревьюер проверяет отсутствие дублей, корректность метафоры, читаемость в целевом размере, оптический баланс, толщину линий, скругления, отступы, выравнивание по сетке, наличие необходимых вариантов и порядок Base → Variable → Solid.

Статус ГОТОВЫ / DONE означает, что визуал принят ревьюером, но иконка ещё может быть не опубликована в библиотеке или коде.

10. Автоматизация уведомлений

Уведомления отправляются при переходе заявки в ГОТОВЫ / DONE, В РАЗРАБОТКУ / TO DEV и ОТКЛОНЕНЫ / REJECTED.

Уведомления не отправляются для ВХОДЯЩИЕ / INBOX, В РАБОТЕ / IN PROGRESS и АРХИВ / ARCHIVE.

Сообщение может содержать название иконки, ссылку на заявку в Figma, автора, Telegram-ник, статус, причину отказа и ссылку на опубликованный компонент.

Автоматизация должна хранить историю отправленных статусов и не публиковать одно и то же обновление повторно.

11. Контроль соблюдения регламента

Ответственность за корректность заявки несёт её автор.

Ответственность за полноту ревью, фиксацию решений и закрытие комментариев несёт ревьюер.

Ответственность за соответствие результата замечаниям ревьюера несёт иллюстратор.

Ответственность за финальную сборку компонента в паке, его публикацию, перенос заявки в В РАЗРАБОТКУ / TO DEV и последующее архивирование несёт Core-команда.

Заявка не должна переходить в следующий статус, если обязательные действия текущего этапа не выполнены.

Краткая схема

ВХОДЯЩИЕ / INBOX
    ↓
В РАБОТЕ / IN PROGRESS
    ↓
ГОТОВЫ / DONE
    ↓
В РАЗРАБОТКУ / TO DEV
    ↓
АРХИВ / ARCHIVE

Альтернативный путь:
ВХОДЯЩИЕ / INBOX → ОТКЛОНЕНЫ / REJECTED