Файл може містити правильний текст, але все одно виглядати неправильно
Уявіть собі скрипт, який замінює назву товару на двадцяти етикетках. Кожен файл містить правильну назву, але деякі назви перекривають зображення а інші занадто малі, щоб їх можна було прочитати.
Скрипт виконав своє завдання. Макет все ще потребує виправлення.
Автоматизація створення макетів вимагає чітких інструкцій щодо дизайну, а також надійного програмного забезпечення. Особа, яка пише скрипт, повинна знати що можна переміщати, що має залишатися на місці та коли файл потребує перевірки.
Дизайнери знаються на візуальних рішеннях. Розробники знають, як перетворити повторювані кроки на робоче програмне забезпечення. Оператори бачать, що відбувається, коли ця схема використовується в реальному завданні.
Кожна людина може помітити проблеми, які інші можуть пропустити.
Опишіть, що саме має захищати дизайн
Дизайнер може побачити очевидну причину для відступу, розміру тексту або порядку шарів. Скрипт може виконувати лише ті інструкції, які йому надано.
Поясніть важливі елементи макету:
- Логотип має залишатися у погодженому місці.
- Назва продукту має бути легко читабельною.
- Попередження має супроводжувати саме ту інформацію, яку воно описує.
- Значок повинен з’являтися лише для відповідних продуктів.
- Текст не повинен перекривати зображення або необхідні символи.
Наведіть приклад хорошого та поганого результату. Якщо заголовок занадто малий, вкажіть найменший прийнятний розмір. Якщо важливий інтервал, покажіть який проміжок має залишитися незмінним.
Ці приклади допомагають особі, яка готує скрипт, зрозуміти причину існування правила, а не лише розташування текстового поля.
Перетворіть візуальний запит на чітку інструкцію
«Підігнати заголовок» звучить просто, але залишає кілька питань без відповіді.
Чи може заголовок бути у три рядки? Чи може блок збільшитися? Чи можуть елементи під ним переміститися? Чи допустимо зменшити розмір шрифту?
Більш корисною інструкцією може бути:
Заголовок може займати до двох рядків. Дотримуйтесь узгодженого розміру тексту. Якщо заголовок стає вищим, перемістіть панель деталей нижче. Надсилайте довші випадки назад до дизайнера для перегляду.
Тепер команда може перевіряти однакову поведінку. Дизайнер перевіряє, чи все виглядає правильно, розробник — чи працюють інструкції, а оператор знає, коли слід звернутися за допомогою.
Design Script на сайті Paqira містить інструкції щодо створення або оновлення макетів у Adobe Illustrator. Підготовка скрипту вимагає певних зусиль, проте кваліфікований оператор може використовувати готові налаштування, не пишучи ці інструкції для кожного завдання.
Під час планування налаштування використовуйте реальні файли
Обговоріть завдання, відкривши документ Illustrator.
Зверніть увагу на шари, текстові поля, вставлені зображення та шрифти. Перевірте, які елементи команда використовує повторно та які назви є незрозумілими. Група під назвою «Група 47» може бути складнішою для ідентифікації, ніж група під назвою «Деталі продукту».
Спробуйте використати реальний текст продукту. Зразковий приклад може приховати проблеми, пов’язані з довгою назвою або відсутнім зображенням.
Корисні запитання:
- У яке текстове поле вводиться назва товару?
- Що станеться, якщо опціональне значення буде порожнім?
- Які зображення та шрифти повинні бути доступними?
- Як слід називати збережені файли?
- Які частини потребують візуальної перевірки після кожного запуску?
Перед тим, як використовувати шаблон для багатьох продуктів, приведіть його до ладу там, де це потрібно. Мета — створити файл, який буде зрозумілий людям, що над ним працюють.
Запитайте оператора, на якому етапі завдання стає складним
Особа, яка керує виробництвом, часто знає, які етапи призводять до помилок.
Можливо, два робочі процеси мають схожі назви. Можливо, оператору доведеться шукати правильний перелік товарів. Відсутність шрифту може бути очевидною Це зрозуміло для дизайнера, але може заплутати того, хто читає повідомлення про невдале виконання завдання.
Врахуйте ці зауваження під час налаштування.
Робочий процес — це збережена послідовність кроків, що використовується для отримання результату. Визначте для нього чітку мету та поясніть, який контент він очікує.
Домовтеся, що оператор повинен перевірити перед початком роботи, як виглядає успішне тестування та яку інформацію слід передати, якщо запуск завершився невдало. Назва процесу, журнал та приклад файлу можуть допомогти розробнику відтворити проблему.
Чіткі робочі інструкції економлять час усіх, хто бере участь у виконанні завдання.
Перевірте прості та складні приклади
Почніть з кількох випадків, які команда розуміє:
- Типовий продукт з усім очікуваним контентом.
- Довга назва товару.
- Версія без додаткового тексту або значка.
- Довша мовна версія.
- Список із більшою кількістю пунктів, ніж зазвичай.
Разом перегляньте згенеровані графічні матеріали. Перевірте контент, макет та кроки, яких мав дотримуватися оператор.
Якщо одна й та сама проблема виникає кілька разів, вдоскональте загальне правило. Якщо для однієї версії потрібен інший дизайн, чітко позначте її та повідомте дизайнер займеться цим випадком.
Збережіть ці приклади як тестовий набір. Коли скрипт або шаблон пізніше зміниться, команда зможе запустити їх знову.
Залишайте творчі рішення за тими, хто їх приймає
Деякі завдання добре підходять для застосування правил: розмістити назву товару, вибрати правильне зображення, повторити рядок або зберегти файл із узгодженою назвою.
Інші завдання потребують свіжого погляду. Новий стиль кампанії, незвичайна форма упаковки або суттєва зміна обсягу тексту можуть вимагати втручання дизайнера рішення.
Погодьтеся щодо цих меж під час підготовки завдання. Не залишайте оператору право вирішувати під тиском термінів, чи вважати пошкоджений макет є прийнятним.
Завдання розробника — зробити помилки зрозумілими. Завдання дизайнера — описати візуальні обмеження. Оператор допомагає Переконайтеся, що ці рішення є практичними у повсякденному використанні.
Зробіть налаштування корисним не лише під час першого запуску
Paqira Система об’єднує збережений контент, файли Design Script, файли Illustrator та виробничі робочі процеси. Ці компоненти працюють найефективніше, коли команда спільно використовує чіткі приклади та інструкції.
Під час передачі підготовленого завдання додайте шаблон, очікуваний контент, тестові випадки та контактну особу для кожної частини. Дайте іншому колезі можливість спробувати виконати ці кроки.
Якщо вони можуть створювати та перевіряти результат без здогадок, таку конфігурацію легше використовувати повторно. Дизайнер витрачає менше часу на виправлення повторюваних редагувань, розробник отримує чіткіші звіти про проблеми, а оператор має завдання, яке може виконувати з упевненістю.