В названии задачи необходимо прописать название проекта (можно краткое), тип носителя (рол-ап / баннер-прога / …) и корректные даты проведения мероприятия.
Крайний срок исполнения задачи
В описании задачи для баннеров, рол-апов, всевозможных оклеек, кулис и тд. пишем следующее:
1.1. Размеры видимой области в формате Ш м / см / мм (ширина) х В м / см / мм (высота) для макетов и в горизонтальной, и в вертикальной ориентации
1.2. Размеры вылетов (Х см / мм – слева, справа, Х см / мм – сверху, снизу; либо Х см / мм со всех сторон; если вылеты не нужны, укажите это в описании)
1.3.  Для оклеек регистраций просьба дополнительно к пунктам выше прописывать количество рабочих мест.
1.4. Для баннеров, содержащих программу / сетку мероприятия, просьба прикладывать драфт в формате Ворд или Эксель.
1.5. Содержание: полное название мероприятия, даты, город проведения, логотипы организаторов (хотя бы текстовый список), QR-коды (желательно векторные). Сгенерить векторный код можно тут: https://generator-qr.com/ru. Если нет возможности сгенерить его самостоятельно, присылайте в задачу ссылку.
1.6. Вся работа над макетами должна вестись в битриксе. Если какие-то правки были даны в TG / WA / лс в битриксе, их следует продублировать в задачу. 
1.7. Для обозначения приоритета в битриксе есть “огонёк”. Его следует ставить на действительно срочные задачи, потому что если в огне всё, то ничего не в огне. 
1.8. PDF-превью макетов не стоит просматривать внутри битрикса или в браузере, тк там они отображаются некорректно. Файл нужно скачать на компьютер. Так макет предстанет перед вами в задуманном дизайнером виде.
1.9. Пожалуйста, не редактируйте комментарии с правками, когда над задачей ведется активная работа! Если что-то из присланного вами ранее стало не актуальным, напишите новое сообщение. 

При наличии специальных требований к макету (тип сжатия, разрешение, формат файла и всё-всё, что кажется непонятным и неважным) просим вас приложить их к описанию задачи на стадии ее формирования. Если требования появляются позже или они меняются, потому что меняется подрядчик, просьба не затягивать до дня икс, когда печатный макет пора отдавать в печать, а информировать дизайнера об изменениях в момент получения новых вводных. Так мы экономим время. И силы тоже.
2.1. Для фигурных макетов, в частности виндеров, прикладывайте к описанию задачи лекало с производства.

Логотипы организаторов, спонсоров и информационных партнёров лучше присылать в векторных форматах: .ai, .eps, .pdf., svg, .cdr. С такими лого у нас точно не будет никаких проблем.
Растровые логотипы (.tif, .png, .jpg), чуть более капризные, но всё ещё ок. Чтобы растр хорошо выглядел на баннере, он должен быть в высоком разрешении (200-300 dpi, проверяем это в свойствах картинки).
Давайте договоримся быть аккуратными с такой вещью как png-логотипы «с сайта». Зачастую они классно выглядят в веб-пространстве, но могут не подходить для размещения на больших носителях из-за низкого разрешения. Если нет возможности запросить другой лого, мы должны быть готовы к тому, что на баннере png-предатель в размере 200 на 200 пикселей будет выглядеть плохо.

Если не известны точные размеры, то нет никакого смысла согласовывать с клиентом превью оформления площадки, параллельно тратя время на создание визуализаций / мокапов / привязок. Это всегда заканчивается повторным согласованием и повезет, если одним. Запоминаем формулу успеха: сначала размеры, затем визуал.

1.1. В названии задачи необходимо прописать название проекта (можно краткое), тип носителя (анкета / сертификат участника / …) и корректные даты проведения мероприятия. 
1.2. Описание задач начинаем с размеров в формате ШхВ, либо пишем формат листа (а6, а5 и тд.). Далее содержание: полное название мероприятия, даты, город проведения, логотипы организаторов (хотя бы текстовый список), QR-коды (желательно векторные). Далее опционально: градация для бейджей, драфт программы, список для навигации, фио на таблоиды и тд. 
1.3. Если носитель задуман не по формуле «размер + дизайн», а требует чего-то специального (тиснение, вырубка, фальцовка и тд.) – прикладывайте, пожалуйста, требования от подрядчика, как только они оказываются у вас на руках. Помним: это экономит время.
1.4. Вся работа над макетами должна вестись в битриксе. Если какие-то правки были даны в TG / WA / лс в битриксе, их следует продублировать в задачу. 
1.5. Для обозначения приоритета в битриксе есть “огонёк”. Его следует ставить на действительно срочные задачи, потому что если в огне всё, то ничего не в огне. 
1.6. PDF-превью макетов не стоит просматривать внутри битрикса или в браузере, тк там они отображаются некорректно. Файл нужно скачать на компьютер. Так макет предстанет перед вами в задуманном дизайнером виде.
1.7. Пожалуйста, не редактируйте комментарии с правками, когда над задачей ведется активная работа! Если что-то из присланного вами ранее стало не актуальным, напишите новое сообщение.

Пожалуйста, прикладывайте образцы с прошедших мероприятий. Также уточняйте формулировку сносок, в частности наименование юр. лица и информацию о нём.

3.1. По мере готовности
Если вы знаете, что программа ещё очень сырая и наверняка будет меняться не один раз, пожалуйста, информируйте нас об этом. Лучше подождать и один раз сверстать приближенный к финальному вариант, чем переверстывать несколько раз с нуля. 
3.2. Одна научная программа – одна задача – один дизайнер
Давайте договоримся, что работа над научной программой, куда бы она в итоге не пошла (на сайт, печататься в другом формате, на заставки в залы и прочее) должна вестись в одной задаче одним дизайнером. Все правки в программу также вносятся одним человеком в одной конкретной задаче, и только после этого исправленный вариант разносится на другие носители. Это очень важный момент, потому что ситуация, когда два дизайнера в соседних задачах работают с одним и тем же текстом научки, недопустима. Во-первых, это напрасно расходует рабочий ресурс как минимум одного человека из этой пары. Во-вторых, мы сильно путаем клиента. Не будем так делать.
3.3. Из печатки в диджитал и обратно
Печатные многостраничные издания верстаются по определенным правилам (их много, вдаваться в детали не будем). Скорректировать такой макет для диджитал среды – дело простое, так как требования для веба чуть мягче, чем для печатки. А вот при переводе макета, который сделан для диджитала, в печатный формат мы можем забуксовать. Поэтому просим вас сразу прописывать, куда макет будет направлен: печататься, на сайт или в обе стороны.
3.4. Переход из А5 в А4
В идеальном мире формат издания известен в первую очередь и не меняется по ходу работы над макетом. Если всё-таки условную брошюру формата а5 надо переверстать в а4, готовимся к тому, что это займёт какое-то время.
3.5. Как давать правки
Ещё в идеальном мире нет правок. Совсем нет. В нашем же мире правки лучше давать одним из этих способов:
как комментарии в пдф, который дизайнер ранее отправил вам на вычитку и согласование.
как комментарий в битриксе, который написан в формате «1. *текст правки* - номер страницы».
Скриншоты и правки, надиктованные по телефону, не принимаются 😊
Друзья, очень важно: даже если вы потрясающе владеете Адоб Акробат, клиент проел вам голову словом “срочно” или вы просто решили помочь, не нужно вносить правки в обход дизайнера. Это чревато тем, что вы отправите клиенту, например, исправленный файл программы, который он согласует, а после запросите у нас печатный макет, в котором всего, что вы внесли самостоятельно, просто не будет. Думаем, не нужно говорить, стрессом какого размера такая ситуация станет для всех участников процесса.
Мы не верстаем издания в Акробате, не копируем текст каждой страницы целиком, а потому не сможем довести файл-исходник до нужного вида, если все изменения, которые необходимо сделать, не будут отмечены вами одним из способов, которые мы привели выше. Даже если речь идёт про одну букву в ФИО, запятую или пробел.
3.6. Вид программы
Предоставлять программу в работу дизайнеру желательно в том виде, который предполагается увидеть в итоге: в виде таблицы или же сплошного текста. Менять вид многостраничной программы в сжатые сроки не представляется возможным!
Если вы делаете файл в виде таблицы, то не увлекайтесь излишним форматированием, так как это создает лишнюю проблему для дизайнера - убирать подложки, тени и прочие украшательства в документе.

4.1. В описании задачи пропишите, во сколько цветов будет напечатан пакет: в один, два и тд. или в полноцвет.
4.2. Если на пакете необходимо разместить логотипы организаторов или спонсоров, а пакет печатается в один / два / три цвета из фир. стиля мероприятия, логотипы нужно предоставить в векторном формате: .ai, .eps, .pdf., svg, .cdr.
4.3. При печати бумажных пакетов просим вас подгружать в описание задачи лекало с производства.

5.1. В описании задачи пропишите, односторонняя или двусторонняя лента нужна.
5.2. Если на ленте необходимо разместить логотипы организаторов или спонсоров, логотипы нужно предоставить в векторном формате: .ai, .eps, .pdf., svg, .cdr.

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

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

Самое-самое важное тут – требования подрядчика. Согласовывать с клиентом, например, дизайн ручки без знаний о том, какие ТТ есть у производства – значит тратить наше общее время и время клиента. Почему так?

Особенность изготовления сувенирной продукции состоит в жестких требованиях производителя. Игнорирование требований чревато тем, что производитель будет возвращать макет на доработку, пока его условия не будут выполнены. Это в свою очередь будет менять вид изделия, а значит процесс согласования макета с клиентом будет запускаться снова. Поэтому чтобы сегодня не объяснять клиенту, почему с ручки вдруг исчез логотип, который еще вчера был на превью, мы дизайним в заданных производством рамках, а после отдаём макет на согласование.

Создавайте подзадачу под каждую страницу сайта, так мы сможем оперативно внести правки.  Если появляются страницы второго уровня, описывайте их в подзадаче через слеш (Медиа/новости, О проекте/архив)
НЕ ДЕЛАЙТЕ подзадачи в соответствии с меню 1 уровня (так как один пункт меню может содержать несколько подпунктов то есть страниц сайта)

Сделайте одну задачу на весь проект.