Как я впервые стала арт-директором и выстроила пайплайн с нуля в инди-команде
Это мой первый опыт арт-дирекшена — и у меня не было ни одного гайда, который объяснял бы, что делать. В интернете, конечно, было много статей о том, кто такой арт-директор — но ни одна из них не давала мне алгоритма действий и инструкций. В свое время тред с личным опытом облегчил бы старт в новой компетенции — но столкнуться с этим не удалось — я не понимала, что искать. В итоге, я собрала весь процесс с нуля — в команде из трёх человек, с минимальными ресурсами и без готовой документации — мы разбирались и писали ее в процессе. В этой статье — как именно я это сделала: с ошибками, инструментами и решениями, которые сработали.
Команда: 3 человека на все роли — как мы покрыли весь арт-пайплайн в инди-разработке
Наша команда была маленькой — всего три человека в арт-отделе. Это типичная ситуация для инди-разработки, когда каждый берёт на себя сразу несколько ролей. При этом задачи были плотно распределены, чтобы избежать провисаний.
Кто за что отвечал:
Я выполняла одновременно функции арт-директора и художницы по персонажам, от концепта до анимаций, занималась VFX, UI/UX, а также ревью, документацией и настройкой арт-пайплайна.
Художница по окружению занималась левел-артом, моделингом, текстурированием, а также концепт-артами для окружения.
Левел-дизайнер совмещала создание оружия и рук, а также занималась их анимациями и звуком — от концепта до имплементации. Я помогала ей с ригом.
Все участницы команды так или иначе работали над концептами. Но при этом каждый этап — от референсов до финального ассета — проходил моё ревью. Это было нужно, чтобы выдерживать целостность визуального стиля и синхронизировать визуал с геймдизайном.
Я старалась давать максимально понятный фидбек: по структуре, композиции, читаемости. И всегда — в контексте задачи.
Как мы выстроили коммуникацию
Мы использовали общий чат в Телеграме с подтемами, как рабочую площадку. Художник мог запросить фидбек в любой момент — просто отправив WIP или вопрос. Это сильно ускоряло процесс и снижало количество итераций. Все правки и обсуждения были открытыми, чтобы команда была в курсе контекста.
После завершения задачи художник переводил её в колонку «Тестирование», и я делала финальное ревью. Мы работали циклически: задача → правки → повтор → финал.
Как я выстроила пайплайн разработки игрового арта в Miro
У меня не было ни одной готовой инструкции. Всё, что я собрала — это результат личного опыта, попыток и ошибок. Я хотела, чтобы команда могла работать автономно, и всё было доступно в одном месте.
Почему именно Miro
Мы пробовали и Google Docs, но Miro оказался единственным инструментом, который позволял:
- Собрать визуальное арт-пространство, а не просто таск-трекер
- Связать всё — от референсов до финальных ассетов — в одну доску
- Сделать доступ к любому элементу визуальным и прямым
Структура доски в Miro
Вот как выглядело наше рабочее пространство. Всё расположено по этапам, по которым движется ассет — от идеи до финала:
1. Зона референсов
Собраны и отсортированы примеры, подходящие под задачу. Обязательно с пометками: почему этот референс важен и чем он полезен для конкретного ассета.
2. Зона концептов
Первичные наброски и идеи, которые затем переходят в ТЗ. Уже здесь может начаться фидбек.
3. Зона технических заданий (ТЗ)
Сюда входят:
- Ключевые референсы
- Обоснование визуальных решений
- Технические ограничения и метрики (топология, полигоны, анимация, размер)
- Контекст в геймдизайне или краткая выжимка из ГДД самого важного
4. Зона разработки
Визуальный трекер статусов: WIP, на проверке, готово. На каждом этапе — скриншоты и комменты.
5. Зона правок
Фидбек, схемы, выделения, правки поверх. Отдельный блок, куда попадали ассеты, прямо напротив непосредственно ассетов.
6. Общий гайдлайн
Висит сверху всей доски. Обновляется по мере эволюции визуального языка и проектных решений.
Я выстроила структуру как user-flow: от референса до финального ассета. Это позволило команде работать без моего постоянного участия — не потому что я контролировала, а потому что структура была понятной и самодостаточной.
Как работала связность
Я дублировала важные элементы в разных зонах. Например:
- В ТЗ клались копии концептов и референсов
- В правках — скриншоты финальных ассетов
- Зоны имели прямые ссылки на соседние этапы
Это исключало фрустрацию от «где искать» и снижало входной порог даже для других людей.
Что дал такой подход
- Команда быстро освоилась, потому что доска была интуитивно понятной.
- Всё хранилось в одном пространстве — не нужно было переключаться между Notion, Figma, Docs.
- Можно было отслеживать прогресс, пересматривать старые решения, и не терять контекст.
Какие выводы я сделала, выстраивая арт-процессы сама:
- Думать как UX-дизайнер, а не как менеджер
- Организация арт-пространства — это не второстепенное: это часть самого процесса
- Важно сократить количество внешних инструментов — всё, что можно, должно быть в одном месте
Постановка задач: как я училась писать ТЗ, чтобы не терять недели на переделки
Когда ты арт-директор впервые, кажется, что «ТЗ — это просто текст с референсами». Но на деле именно плохо написанное ТЗ съедает часы, энергию и мотивацию всей команды. Я это поняла на собственном опыте, после одной задачи, которую мы переделывали четыре раза с нуля.
Я думала, что даю хорошие ТЗ. Но если художник не может понять, чего от него хотят — значит, задача была поставлена плохо...
Пример провального ТЗ из практики
Контекст: нужно было сделать ресурсы. Я выдала много референсов — красивые, но разрозненные. И самое главное — не объяснила, что это проджектайлы, не рассказала про конструкцию, геймдизайн или ограничения. Художник сделал честно, но получилось не то: скучно, топорно, нечитабельно. Мы всё переделали. И потом — ещё раз.
Как я переписала ТЗ, чтобы оно сработало
- Сократила число референсов до 2–3, объяснив: этот — форма, этот — материал, этот — функция.
- Добавила контекст: как этот объект работает в геймплее, где он появляется, какие задачи выполняет.
- Если надо было — моделила пример сама, чтобы было видно, что и зачем я имею в виду.
Что я включаю в хорошее ТЗ сейчас
- Несколько ключевых референсов с вариацией, а не просто пачку картинок с Pinterest
- Подписи к каждому референсу: «только форма», «только поверхность», «цвет»
- Функциональное описание: это интерактив? элемент окружения? что должно быть читаемо с 10 метров?
- Технические ограничения
- Опять же, то самое геймдизайн-оп
Фидбек и итерации: как давать правки, не разрушая мотивацию
Когда ты впервые становишься арт-директором, особенно в маленькой команде, тебе хочется, чтобы всё выглядело «как надо». Но очень быстро становится понятно: если ты даёшь правки просто «по вкусу» или без системы — художники теряются, фрустрируют и начинают делать работу вслепую.
Мне потребовалось несколько итераций, чтобы найти способ давать обратную связь, которая не выжигала людей и реально улучшала результат.
Я не говорила “это плохо” — я объясняла, что и почему не работает. Обратная связь — это не столько про мнение, сколько про развитие функции.
Моя структура фидбека
Я старалась всегда отвечать по трём пунктам:
- Что не работает — и где именно
- Почему не работает — с опорой на геймдизайн, стиль, читаемость
- Как это можно поправить — с примерами, схемами, визуальными аналогами
Иногда я рисовала по скрину прямо в Miro, иногда — делала наложения поверх. Если нужно — показывала примеры из других игр, делала сборки из референсов или объясняла через геймплейную механику.
Все было хорошо, но что-то пошло не так...
Поначалу мне казалось, что фидбек — это однонаправленная вещь. Я давала правки, художники кивали — и задача «готова». Но через время я поняла, что я не понимала, как фидбек воспринимается с той стороны.
— Усвоил ли человек суть?
— Понял ли он, что именно нужно поменять?
— Не фрустрирован ли?
— Не чувствует ли он, что его «правят» бесконечно?
Фидбек без фидбека на фидбек — это просто монолог. А я хотела, чтобы это был диалог, в котором можно было что-то улучшать, а не ломать. Да и, в общем-то, мне самой было очень трудно без обратной связи на свой труд — а работала я много, ведь была на связи 24/7. Это фрустрировало и меня, как работника.
Как я изменила процесс
- Добавила опрос после фидбека: «всё ли понятно, хочешь ли обсудить решение или может быть предложить свое?»
- Стала выделять критичность правок — что обязательно исправить, а что рекомендую
- Начала давать право выбора, особенно в зонах, где есть художественная свобода
- Перевела большую часть фидбека в визуальную форму — меньше текста, больше схем и стрелок в Miro
Это снизило количество непонимания, ускорило итерации и убрало ненужный стресс. Хотя, справедливости ради, опрос не возымел сильного эффекта, потому что это ощущалось несколько душно. Тем не менее, обсуждать ТЗ мы стали немного чаще.
Перераспределение задач и выгорание: как мы не развалились в кранче (или все же развалились, но поменьше)
Когда ты арт-директор в маленькой команде, особенно если это твой первый опыт, ты быстро сталкиваешься с перегрузом. Причём не только у себя — у всей команды. Количество задач растёт быстрее, чем вы успеваете их передавать друг другу. А правки копятся, даже если ты стараешься быть бережной.
Я довольно быстро увидела, что часть команды начинает выгорать, хотя мы все были предельно замотивированы. Кто-то не хотел делиться задачами, потому что «это нужно в портфолио». Кто-то тянул слишком много просто потому, что альтернатив не было.
Мне пришлось прямо считать задачи. Условно: у тебя 10 тасков по 10 часов — ты просто физически не вытянешь. Но художник это не ощущал — а я не могла на глаз всё держать.
Как я организовала перераспределение нагрузки
Я сделала таблицу в Google Sheets, в которую мы вносили:
- Название ассета
- Человека, который за него отвечает
- Оценку по времени (по данным из трекера). Причем, данные из трекера не всегда объективны, поэтому оценка времени складывалась из минимального времени по трекеру и фактического — которое наблюдала в работе на ассетом я.
- Автоматический подсчёт общего времени по каждому участнику
Когда у кого-то выходило часов больше, чем можно позволить выделить на создание ассетов — мы перераспределяли. Без споров, обсуждая компромисс. Это сделало планирование объективным — цифры не спорят.
А еще это помогло немного повлиять на геймдизайн — система не переусложнилась, и работа над сущностями началась более качественная, чем количественная.
Как мы пережили кранч
В один момент задач стало так много, что я поняла: если не сменю режим — команда не выдержит.
Что я сделала:
- Правки только по критичным вопросам. Всё, что «можно лучше» — уходит в бэклог или не правится вообще.
- Коворкинги в Discord. Работали вместе, онлайн, чтобы быстрее проверять и обсуждать.
- Сама брала задачи. Это не только помогало разгрузить других, но и давало мне ощущение, что я не просто наблюдаю, а участвую.
Когда я чувствовала, что перегреваюсь — я уходила в моделинг, анимации, эффекты или интерфейс. Это был способ остаться в команде, а не “над” командой.
Что реально сработало против выгорания
- Прозрачность нагрузки. Если видно, кто сколько тащит — проще договариваться.
- Ограничение количества итераций. Если задача близка к финалу — не «перфектничать».
- Гибкость в сроках. Иногда проще сдвинуть задачу, чем потерять человека.
- Контакт. В кранч важно быть не «менеджером», а участником процесса.
Что я поняла за первый опыт в арт-дирекшене: выводы и советы себе
Это был мой первый арт-дирекшен. Я училась «в бою»: параллельно строила пайплайн, решала конфликты, писала ТЗ, ревьювила концепты и пыталась не выгореть. В процессе многое пришлось менять — и в процессе, и в себе.
Я не знала, как быть арт-директором. И никто не мог объяснить — хотя я искренне пыталась спрашивать. Пришлось строить свою систему — из логики, наблюдений и откатов назад.
Если бы я говорила с собой тогда
- Ты не узнаешь, как делать идеально с первого раза. И не обязана.
- Если у тебя что-то работает, даже на минималках — это уже результат.
- Системность важнее таланта.
- Плохой фидбек — хуже его отсутствия. Учись говорить не «что не так», а «как улучшить».
- Не пытайся тащить всё одна. У тебя команда — и это не ресурс, а живые люди.
- Будь проще с документацией. Лучше понятный черновик сейчас, чем идеальный гайд через месяц.
- Никто не умрёт от того, что референс не совпал на 10 %. А вот от эмоционального выгорания — да.
И еще один забавный лайф-хак: мы работали по принципу «итеративной импровизации» — и это развязывало руки. Можно было сказать себе и художникам: «да ладно, сейчас мы возьмем, как есть, чтобы у нас был результат, а потом, если что, переделаем».
Спойлер: мы почти ничего не меняли — зато как просто двигались дальше! :)
Что бы я посоветовала другим начинающим арт-директорам
Делайте систему под свою команду, а не под идеал
Я адаптировала стиль под людей, а не под “эталонный вижен”. Это позволило всем работать без чувства давления и разочарования.
Не бойтесь визуализировать всё
- Стрелочки, схемы, скрины, подписанные фреймы — всё помогает.
- Даже если кажется «глупо» — это экономит часы.
Ведите таблицы — особенно времени и нагрузки
- Это защищает не только от выгорания, но и от конфликтов.
- Люди лучше реагируют на цифры, чем на ощущения.
Перестаньте бояться слова «дирекция»
- Арт-дирекшен — не про контроль. Это про связность, объяснение и поддержку.
- Ваша задача — не знать всё, а сделать так, чтобы люди могли работать вместе.
В завершение
Я написала эту статью потому, что когда я только начинала, ничего подобного не было. Вернее, может быть, и было — но сейчас это уже не важно, а опыт лишним не бывает.
Если у вас тоже нет инструкции — ничего страшного. Всегда можно выстроить свою. И, возможно, она окажется лучше, чем чужие шаблоны, которые может повезти все-таки найти.