ООО Органайзер ЛидерТаск 
Тендеры и лиды
Информация
Макет находится в Figma, замечания приходят в чат, на почту и в голосовых сообщениях, комментарии оставляют сразу несколько сотрудников клиента. Пока дизайнер вносит изменения, оказывается, что обсуждается уже другая версия, а решение о том, какой вариант утвержден, нигде не зафиксировано. В результате согласование дизайна с клиентом затягивается, количество правок растет, а запуск проекта откладывается.
Избежать этого помогает не новый канал общения, а понятный процесс. Трекер задач по дизайну позволяет собрать в одном месте задачу, ответственного, срок, ссылку на актуальный макет и историю решений. Когда все этапы согласования проходят в единой системе, команде не приходится искать комментарии по разным перепискам, а дизайнер всегда понимает, с какой версией работает.
Правки становятся бесконечными, когда у проекта нет зафиксированной цели, критериев готовности, одного согласующего и понятных этапов. Сам по себе трекер не исправит процесс, если команда заранее не договорилась о правилах работы.
Задача понимается по-разному
Проблема часто возникает еще до первой версии макета. Дизайнер получает неполный бриф, часть требований появляется уже в процессе, а клиент оценивает результат по принципу «нравится — не нравится», а не по согласованным критериям.
Несколько человек — несколько мнений
Когда замечания приходят сразу от нескольких сотрудников, появляются противоречия. Один просит изменить заголовок, другой — вернуть прежний вариант, третий добавляет новые требования. При этом никто не фиксирует, какое решение уже принято, а новая работа постепенно превращается в очередную «правку».
Нет правил согласования
Если у клиента нет срока ответа, макет может несколько дней ждать проверки, а затем комментарии приходят частями. Дизайнер снова возвращается к уже выполненной работе, и количество итераций постоянно растет.
Чтобы этого избежать, сначала нужно определить цель задачи, роли участников, критерии готовности и порядок согласования. Только после этого процесс стоит переносить в трекер задач, где будут зафиксированы ответственные, этапы работы и принятые решения.
Чат сохраняет переписку, но не связывает замечание с конкретной задачей, версией макета и этапом работы. Поэтому итоговые решения нужно фиксировать в карточке дизайн-задачи рядом с актуальной ссылкой и статусом согласования.
Обычно информация распределяется между разными каналами:
бриф хранится в документе;
макет — в Figma;
комментарии — в чате;
уточнения — в голосовых сообщениях;
сроки — в календаре менеджера;
решение об утверждении — в личной переписке или нигде.
Например, клиент оставляет точечные замечания в Figma, затем присылает дополнительные правки в мессенджере, а один из согласующих отправляет новую версию текста по почте. Дизайнеру приходится самостоятельно определять, какие комментарии актуальны и с какой версией нужно работать.
У каждого инструмента своя задача. Figma и другие визуальные сервисы подходят для комментариев к конкретным элементам макета, чат — для быстрых уточнений. Трекер нужен для управления согласованием макетов: в нем фиксируют задачу, ответственного, срок, этап, актуальную ссылку и итоговое решение.
До старта нужно зафиксировать цель, аудиторию, формат, обязательные элементы, ограничения и критерии оценки. Пока этих данных нет, задачу нельзя считать готовой к работе.
Минимальный набор входных данных:
бизнес-цель и целевая аудитория;
тип материала, формат и размеры;
основное сообщение и обязательные тексты;
логотип, изображения и другие элементы;
требования брендбука и технические ограничения;
референсы и антиреференсы;
срок, ответственный за согласование;
критерии готовности;
исходные файлы и необходимые доступы.
Формулировка «сделать красивый современный баннер» не помогает дизайнеру принять решение и не задает проверяемого результата. Полезнее указать, для кого создается баннер, какое действие должен совершить пользователь, какие элементы обязательны и по каким признакам команда примет работу.
Например, вместо общего пожелания можно поставить задачу так: подготовить баннер 1200 × 628 px для руководителей небольших команд, показать интерфейс продукта, использовать утвержденный заголовок и сделать кнопку заметной на мобильном экране.
Дизайнер должен получать один согласованный список замечаний, даже если макет оценивают несколько человек. Для этого заранее распределяют роли и назначают финального согласующего, который объединяет комментарии и подтверждает решение. Такой порядок особенно важен, когда со стороны клиента участвуют бренд-менеджер, юрист, маркетолог и руководитель.
Менеджер отвечает за движение задачи между участниками:
проверяет полноту брифа и исходных материалов;
устанавливает и контролирует сроки;
собирает обратную связь;
уточняет противоречивые замечания;
фиксирует итоговое решение.
Дизайнер работает по согласованной задаче, а не по отдельным сообщениям участников:
задает вопросы до начала работы;
указывает актуальную версию макета;
объясняет принятые решения;
вносит только подтвержденные изменения.
До отправки клиенту макет проходит внутреннюю проверку. Арт-директор оценивает соответствие брифу, замечает визуальные и технические ошибки и не допускает, чтобы сырой результат стал первой версией для заказчика.
Эксперты со стороны клиента дают комментарии в пределах своей компетенции: юрист проверяет формулировки, бренд-менеджер — соответствие брендбуку, маркетолог — рекламное сообщение. Но они не должны передавать дизайнеру отдельные, несогласованные списки.
Финальный согласующий:
объединяет замечания участников;
устраняет противоречия;
определяет приоритет изменений;
подтверждает итоговую версию.
Например, если маркетолог просит сделать кнопку заметнее, а бренд-менеджер запрещает использовать более яркий цвет, дизайнер не должен самостоятельно выбирать сторону. Сначала участники согласуют единое решение, после чего менеджер передает его исполнителю.
Процесс согласования дизайна должен повторять реальный путь макета: от проверки исходных данных до утверждения и передачи результата. Чем точнее определены этапы и условия перехода между ними, тем меньше риск вернуться к уже принятым решениям.
Базовый workflow выглядит так:
Поступает заявка.
Менеджер проверяет бриф, материалы и доступы.
Дизайнер берет задачу в работу.
Макет проходит внутреннюю проверку.
Актуальную версию отправляют клиенту.
Представители клиента собирают комментарии.
Финальный согласующий объединяет замечания.
Команда отделяет исправления от новых требований.
Дизайнер вносит подтвержденные изменения.
Обновленный вариант проверяют повторно.
Клиент утверждает результат.
Финальный файл передают в публикацию, разработку или производство, а задачу закрывают.
Согласовывать только финальный дизайн рискованно. Если клиент впервые видит работу после полной детализации, изменение направления потребует переделать уже готовые элементы. Поэтому в крупных проектах результат принимают постепенно:
задачу и референсы;
концепцию;
структуру;
визуальное направление;
финальную детализацию.
Например, при подготовке лендинга сначала утверждают структуру блоков, затем стилистику первого экрана и только после этого — дизайн всей страницы. Если пропустить промежуточные этапы, замечание к структуре может потребовать переделать уже сверстанные экраны.
Количество шагов зависит от масштаба работы. Для одного рекламного баннера достаточно проверки брифа, внутреннего контроля, клиентского согласования и финального утверждения. Для фирменного стиля или сайта нужны отдельные точки принятия решений.
Статусы должны отражать реальные состояния макета, а не отдельные действия дизайнера. Для большинства команд достаточно восьми-девяти колонок, которые показывают, где находится задача, кто за нее отвечает и почему она может задерживаться.
Оптимальная доска выглядит так:
Новая заявка — задача поступила, но менеджер еще не проверил бриф и материалы.
Не хватает данных — отсутствуют текст, размеры, доступы или другая обязательная информация. Пока данные не собраны, задача не должна переходить в работу.
В работе — дизайнер создает новую версию или дорабатывает макет.
Внутренняя проверка — менеджер или арт-директор проверяет соответствие брифу, брендбуку и техническим требованиям.
На согласовании — актуальная версия отправлена клиенту, команда ожидает консолидированную обратную связь.
Правки — получен подтвержденный список изменений, дизайнер вносит согласованные исправления.
Утверждено — клиент принял итоговую версию, решение зафиксировано.
Передано / опубликовано — макет отправлен в разработку, публикацию, печать или следующий этап работы.
Архив — задача полностью завершена и остается в истории проекта.
Например, если карточка несколько дней находится в статусе «На согласовании», команда сразу понимает, что работа остановилась на стороне клиента, а не дизайнера. Это помогает быстрее находить причины задержек и не искать их в переписках.
Для каждого статуса стоит заранее определить четыре правила:
кто отвечает за следующий шаг;
что должно произойти на этом этапе;
при каком условии задача переходит дальше;
где может возникнуть ожидание.
При необходимости процесс можно упростить и объединить несколько статусов, но создавать отдельную колонку для каждого мелкого действия не стоит. Доска должна показывать состояние задачи, а не каждое действие участников.
Карточка должна отвечать на пять вопросов: что делаем, зачем, к какому сроку, по каким критериям принимаем и где находится актуальный макет. Если хотя бы одного ответа нет, дизайнеру приходится уточнять детали уже в процессе, а риск лишней итерации растет.
Готовый шаблон может выглядеть так.
Название
Баннер для запуска осенней рекламной кампании — 1200 × 628 px.
Бизнес-цель
Привлечь пользователей на страницу новой функции.
Аудитория
Руководители небольших команд.
Основное сообщение
Все задачи команды видны в одном рабочем пространстве.
Обязательные элементы
логотип;
заголовок;
изображение продукта;
CTA;
фирменные цвета.
Материалы
бриф;
брендбук;
утвержденные тексты;
референсы;
ссылка на папку с исходниками.
Организационная информация
дизайнер;
менеджер;
согласующий;
срок;
приоритет;
текущий статус;
номер версии.
Критерии готовности
макет соответствует размеру 1200 × 628 px;
использованы утвержденные тексты;
соблюдены требования брендбука;
элементы читаются на мобильном экране;
результат прошел внутреннюю проверку.
Такую карточку удобно использовать как единый источник информации: дизайнер видит задачу и материалы, менеджер — срок и статус, а согласующий — критерии, по которым нужно оценивать результат.
Перед согласованием макет должен пройти внутреннюю проверку по единому чек-листу. Это помогает заметить технические ошибки, расхождения с брифом и слабые места еще до первой внешней итерации.
Что проверить перед отправкой:
соответствует ли макет цели задачи;
соблюдены ли размеры и формат;
используется ли актуальная версия текста;
учтены ли требования брендбука;
добавлены ли логотип и обязательные элементы;
достаточно ли качественные изображения;
правильно ли подписаны кнопки и ссылки;
нет ли орфографических ошибок;
проверены ли контраст и читаемость;
подготовлены ли нужные адаптивные версии;
соблюдены ли технические параметры;
ведет ли ссылка на актуальный вариант;
может ли менеджер объяснить логику решения.
Например, баннер может выглядеть готовым, но при проверке выяснится, что на мобильном экране теряется CTA, используется устаревший заголовок или ссылка ведет на предыдущую версию. Если такие ошибки замечает клиент, обсуждение начинается не с оценки идеи, а с исправления недочетов.
Кто проводит проверку
В дизайн-команде эту роль обычно берет арт-директор, во внутреннем отделе — дизайн-лид. В небольшой студии макет может проверять менеджер, а фрилансер проводит самопроверку по заранее подготовленному чек-листу.
В карточке дизайн-задачи должна быть одна явно обозначенная актуальная ссылка или файл, а предыдущие варианты — оставаться в истории. Для контроля версий макетов лучше использовать единое правило именования, понятное и дизайнеру, и менеджеру, и клиенту.
Например:
project_asset_v01_2026-08-05
project_asset_v02_2026-08-07
project_asset_approved_2026-08-08
Для внутренней работы подойдет и более простой вариант:
Баннер_осенняя-кампания_v01
Баннер_осенняя-кампания_v02
Баннер_осенняя-кампания_утверждено
Названия вроде final, final_new или final_final быстро перестают что-либо объяснять. Уже после двух-трех итераций участники не понимают, какой файл отправляли клиенту и к какой версии относятся замечания.
Чтобы этого избежать:
храните в карточке только одну актуальную ссылку;
при отправке указывайте номер версии;
привязывайте комментарии к конкретному варианту;
не удаляйте предыдущие файлы до завершения проекта;
после утверждения фиксируйте статус и дату;
не меняйте принятый макет без новой задачи или повторного согласования.
Например, если клиент прислал замечания к v02, дизайнер не должен незаметно заменить файл по той же ссылке и отправить его как прежнюю версию. Лучше создать v03, отметить внесенные изменения и явно указать, что именно отправлено на проверку.
В таск-менеджере можно сохранить актуальную Figma-ссылку, номер версии и итоговое решение в карточке задачи. При этом сама работа с макетом остается в Figma, а трекер помогает видеть, какой вариант сейчас согласовывается и что уже было утверждено.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13691 тендер
проведено за восемь лет работы нашего сайта.
Понятная правка указывает, что именно нужно изменить, как изменить и зачем это требуется. Субъективное замечание вроде «не нравится» или «нужно современнее» следует переводить в конкретное действие, которое можно выполнить и проверить.
Вот как можно переформулировать частые комментарии:
Формула понятной обратной связи выглядит так:
Объект → изменение → причина → приоритет.
Например:
Увеличьте заголовок примерно на 15%, потому что при просмотре с телефона он теряется на фоне изображения. Приоритет высокий.
Не менее важно соблюдать правило одного окна. Если макет оценивают несколько представителей клиента, они сначала обсуждают замечания между собой. Затем финальный согласующий или менеджер передает дизайнеру единый список без противоречий.
Дизайнер не должен начинать работу по отдельным сообщениям, пока итоговая обратная связь не подтверждена. Спорные комментарии сначала решаются на стороне клиента, иначе исполнитель вынужден самостоятельно выбирать между взаимоисключающими требованиями.
Если макет не соответствует согласованному ТЗ, это исправление в рамках текущей задачи. Если клиент меняет уже принятые условия или просит дополнительный результат, объем работ увеличивается — его нужно оценить отдельно.
Проще всего сверять каждый комментарий с тем, что было зафиксировано до начала работы.
Исправление: в утвержденном тексте допущена опечатка.
Исправление: макет подготовлен не в указанном размере.
Исправление: дизайнер использовал цвет, которого нет в брендбуке.
Исправление: в макете указана неверная ссылка.
Новая задача: после утверждения клиент просит адаптировать баннер для другой площадки.
Новая задача: вместо одного баннера понадобилось пять форматов.
Изменение объема: после согласования концепции клиент меняет целевую аудиторию.
Изменение объема: в макет нужно добавить новый обязательный блок.
Например, если в ТЗ указан баннер 1200 × 628 px, а дизайнер подготовил другой размер, это ошибка исполнителя. Но если после согласования клиенту понадобилась вертикальная версия для сторис, речь уже идет о новом результате, которого не было в исходной задаче.
Чтобы определить тип изменения:
Проверьте согласованное ТЗ.
Уточните, было ли требование зафиксировано до начала работы.
Оцените влияние на срок и объем.
При расширении работ создайте отдельную задачу или подзадачу.
Зафиксируйте новые условия до начала доработки.
Это управленческий подход, а не юридическое правило. Порядок оплаты дополнительных работ и официального согласования изменений определяется договором и внутренними правилами компании.
Ограничивать нужно не возможность клиента давать обратную связь, а количество согласованных итераций и порядок их проведения. Число раундов, сроки ответа и правила сбора комментариев лучше определить до начала работы.
Чтобы процесс согласования не растягивался, договоритесь о нескольких правилах:
заранее укажите, сколько итераций входит в работу;
объясните, что считается одним раундом правок;
собирайте все замечания участников одновременно;
установите срок ответа со стороны клиента;
не начинайте доработку по частичному списку;
не возвращайтесь к утвержденным этапам без пересмотра срока;
новый объем оформляйте отдельной задачей;
фиксируйте результат каждого раунда.
Например, одной итерацией можно считать один подтвержденный список комментариев к конкретной версии макета. Если замечания приходят частями в течение нескольких дней, это не должно превращаться в несколько незапланированных возвратов к работе.
Менеджеру важно обозначать границы спокойно, без давления. Подойдут нейтральные формулировки:
Соберите, пожалуйста, все замечания участников в один список. После его подтверждения мы начнем следующий раунд доработки.
Комментарий меняет ранее согласованную концепцию, поэтому сначала оценим, как он повлияет на срок и объем работ.
Чтобы не работать с противоречивыми версиями, дождемся итогового решения ответственного согласующего.
Начните с одного типа дизайн-задач и одной общей доски. Не переносите в систему сразу все процессы: сначала настройте этапы, шаблон карточки, роли и правила перехода между статусами.
Такой процесс можно реализовать практически в любом современном таск-менеджере. Ниже покажем его на примере LeaderTask.
Для начала достаточно автоматизировать один повторяющийся процесс — например, согласование баннеров или обложек статей. Это поможет проверить, насколько удобно выстроены этапы и шаблон карточки.
Порядок настройки может быть таким:
Создайте проект или общую доску для дизайн-задач.
Настройте колонки по этапам работы команды.
Подготовьте шаблон карточки с обязательными полями и чек-листом.
Назначьте исполнителя, менеджера и срок.
Прикрепите материалы или актуальную ссылку на Figma.
Проведите внутреннюю проверку.
Зафиксируйте итоговый список комментариев.
Перемещайте карточку между этапами.
После утверждения сохраните финальную версию и закройте задачу.
Например, карточка баннера сначала попадает в колонку «Новая заявка». Если не хватает материалов, она переходит в «Не хватает данных», затем — в «В работе», после чего проходит внутреннюю проверку, согласование и правки до утверждения.
В любом современном трекере задач этот процесс строится вокруг проектов, канбан-досок, задач, ответственных, сроков, чек-листов, файлов, ссылок и комментариев.
Главное — не усложнять систему. Она должна помогать быстро понять, на каком этапе находится задача, кто отвечает за следующий шаг и что нужно сделать для перехода дальше.
Доступ полезен, если клиент готов работать в системе и понимает, какие действия от него ожидаются. В остальных случаях менеджер может оставаться единым окном: собирать обратную связь, переносить итоговые решения в карточку и фиксировать утверждение.
Сценарий 1. Клиент работает через менеджера
Такой вариант подходит, если согласования происходят редко, заказчик не хочет осваивать новый таск-менеджер или внутренняя доска содержит лишнюю для него информацию.
Менеджер:
отправляет актуальную версию макета;
обозначает срок ответа;
собирает замечания участников;
переносит подтвержденный список в карточку;
фиксирует итоговое решение.
Например, клиент может оставить комментарии в привычном мессенджере или Figma, а менеджер объединит их и передаст дизайнеру без противоречий.
Сценарий 2. Клиент участвует в задаче или проекте
Прямой доступ удобен для долгосрочной работы, большого количества макетов и регулярных согласований. Клиент видит доступные ему задачи, материалы, сроки и текущие этапы, а также может участвовать в обсуждении.
В таск-трекере участника можно подключить к нужной задаче или проекту в пределах выданных прав. При этом не стоит обещать публичную гостевую ссылку без регистрации или функции специального proofing-сервиса: доступ используется для просмотра материалов, статусов и обсуждения процесса.
Выбирать сценарий стоит по простому принципу: клиенту нужен не полный обзор внутренней работы команды, а понятный способ увидеть актуальный результат и передать итоговое решение.
Оценивайте не количество сообщений в чате, а время согласования, число итераций, ожидание ответа клиента и возвраты после внутренней проверки. Сравнивать показатели лучше на нескольких однотипных задачах до и после изменения процесса.
Для начала достаточно отслеживать 6–8 метрик:
Среднее время согласования — сколько проходит от отправки первой версии до утверждения.
Число итераций — сколько раундов доработки требуется для одной задачи.
Время ожидания клиента — как долго макет находится на согласовании без ответа.
Возвраты после внутренней проверки — сколько задач снова отправляют дизайнеру из-за ошибок, которые команда могла заметить сама.
Просроченные задачи — соблюдают ли сроки исполнители и согласующие.
Доля новых требований среди правок — насколько точно команда фиксирует первоначальный объем работ.
Повторные замечания — сохраняются ли принятые решения и учитывается ли история обсуждения.
Задачи без актуальной версии — соблюдаются ли правила хранения макетов.
Например, до изменения процесса баннер согласовывали в среднем за семь дней и возвращали на доработку четыре раза. После внедрения единого брифа, внутренней проверки и консолидированных комментариев срок сократился до четырех дней, а число итераций — до двух. Именно такое сравнение показывает результат, а не субъективное ощущение, что работать стало удобнее.
Необязательно измерять все сразу. Выберите несколько показателей, которые отражают главные проблемы команды, и анализируйте их на одинаковых типах задач: баннерах, обложках или страницах сайта.
Трекер не помогает, если команда продолжает ставить задачи в чатах, не обновляет статусы и хранит несколько актуальных версий одного макета. Система работает только при единых правилах и закрепленной ответственности.
Обычно проблемы возникают на трех уровнях.
Задачи оформляют непоследовательно
не все дизайн-задачи попадают в трекер;
карточки создают без цели и критериев готовности;
новые требования добавляют в старую задачу;
работу закрывают без фиксации утвержденной версии.
Информация остается разрозненной
комментарии продолжают собираться в чатах, письмах и личных сообщениях;
несколько людей одновременно дают поручения дизайнеру;
в карточке хранится несколько «актуальных» ссылок;
макет отправляют клиенту до внутренней проверки.
За процессом никто не следит
статусы не обновляются;
на доске слишком много колонок;
никто не отвечает за соблюдение правил;
команда не разбирает причины задержек.
Например, дизайнер получает задачу в трекере, уточнение — в чате, новую версию текста — по почте, а комментарии клиента — в Figma. Формально карточка существует, но полной картины в ней нет, поэтому таск-менеджер становится еще одним каналом, который приходится проверять.
Чтобы этого не произошло, достаточно контролировать шесть правил:
один канал постановки задач;
один ответственный за следующий шаг;
одна актуальная версия;
один консолидированный список замечаний;
понятный текущий статус;
зафиксированный результат.
Эти правила можно закрепить через общую доску, ответственных, статусы и карточки задач. Но порядок создает не сам планировщик, а договоренность команды использовать его как основное рабочее пространство, а не как дополнение к перепискам.
Разберем одну задачу: рекламный баннер проходит проверку входных данных, работу дизайнера, внутренний контроль, один раунд клиентских правок и финальное утверждение. Такой пример показывает, как отдельные правила складываются в единый процесс.
Шаг 1. Заявка
Менеджер создает карточку «Баннер для осенней рекламной кампании — 1200 × 628 px» и добавляет цель, аудиторию, утвержденный текст, брендбук, срок и финального согласующего.
Шаг 2. Проверка входных данных
Выясняется, что текст кнопки еще не утвержден. Карточка остается в колонке «Не хватает данных»: дизайнер не начинает работу по неполному брифу.
Шаг 3. Работа дизайнера
После получения текста задача переходит в статус «В работе». Дизайнер готовит первую версию — v01 — и добавляет актуальную ссылку в карточку.
Шаг 4. Внутренняя проверка
Арт-директор замечает слабый контраст кнопки и отступы, которые не соответствуют брендбуку. Дизайнер исправляет недочеты до того, как макет увидит клиент.
Шаг 5. Согласование
Менеджер отправляет заказчику ссылку на v02, обозначает срок ответа и просит собрать замечания всех участников в один список.
Шаг 6. Правки
Клиент просит увеличить изображение продукта и сократить подзаголовок. Менеджер проверяет, что комментарии не противоречат друг другу, и фиксирует их одним сообщением или чек-листом.
Шаг 7. Доработка
Дизайнер вносит согласованные изменения и создает v03. Менеджер сверяет результат со списком правок перед повторной отправкой.
Шаг 8. Утверждение
Финальный согласующий подтверждает вариант. В карточке указывают утвержденную версию, дату и итоговый статус, чтобы команда не вернулась к старому макету.
Шаг 9. Передача
Файл передают специалисту, который запускает рекламную кампанию, а задачу перемещают в «Передано / опубликовано». Вся история — от заявки до финального решения — остается в одной карточке.
Figma удобна для обсуждения самого макета и точечных комментариев. Но сроки, ответственного, статус задачи, итоговый список правок и принятое решение лучше фиксировать в трекере задач.
Для большинства команд достаточно семи–девяти статусов. Важно не количество колонок, а то, чтобы каждая из них отражала реальный этап работы и показывала, кто должен выполнить следующее действие.
Нет. Если клиенту неудобно работать в системе, менеджер может собирать обратную связь, объединять комментарии и фиксировать итоговые решения в карточке задачи.
Предыдущие версии можно оставлять в Figma, файловом хранилище или истории вложений. В карточке задачи при этом должна быть только одна актуальная ссылка или файл.
Сначала проверьте, исправляют ли они несоответствие согласованному ТЗ или меняют уже принятое решение. Во втором случае изменения лучше оформить как новую задачу или новый этап работ и пересмотреть сроки.
Возьмите один текущий дизайн-процесс и перенесите его в трекер задач. Через неделю оцените, где возникают задержки, сколько требуется итераций и какие правила стоит уточнить.
Начать можно с простого алгоритма:
Выберите один тип макетов.
Назначьте ответственного за процесс.
Зафиксируйте требования к входным данным.
Создайте основные статусы.
Подготовьте шаблон карточки.
Добавьте чек-лист внутренней проверки.
Установите правило одной актуальной версии.
Определите порядок сбора правок.
Проведите через систему несколько задач.
Оцените сроки, количество итераций и причины возвратов.
После нескольких задач станет понятно, каких правил не хватает именно вашей команде. Только после этого имеет смысл масштабировать процесс на остальные дизайн-задачи.
Создайте в таск-менеджере, например, в LeaderTask, первую доску для согласования дизайна, проведите через нее ближайший макет и проверьте, как изменится процесс уже после нескольких задач.
