Чем больше у команды проектов – тем сложнее сохранять контекст в работе над ними. В каждом из проектов своя архитектура, внутренняя логика, разная скорость. Детали неизбежно теряются.

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

Шрифты и потеря контекста

У нас в отделе больше 20 дизайнеров, мы находимся в совершенно разных географических локациях, и мы аутсорс. Работа разбита на множество проектов (на одного дизайнера может выпадать несколько). И это совершенно разные продукты: образовательный сервис, услуги такси, финтех, медицинский сервис или приложение по подбору питания. И тут, при организации работы, важно учитывать тот самый пресловутый «человеческий фактор». Кто-то внимательный к деталям и помнит все до каждой мелочи, кто-то – совсем наоборот. Но даже в ситуациях, когда у дизайнера феноменальная память, какая-то деталь все равно может выскочить: что-то стало обыденным, что-то доведено до автоматизма, что-то обязательно потеряется из-за когнитивных перегрузок.

У меня был случай, когда я забыла передать файлы по шрифтам. Причем, была уверена, что они есть у всех, но нет, это было ошибкой.

Важно помнить: у многих дизайнеров контекст существует только в голове. Шанс помнить все, каждый нюанс и деталь, гипотетически существует, но, на самом деле, он небольшой. Информации слишком много: если процентов 70 контента ты еще можешь держать в уме, то оставшиеся 30 – это непредвиденные ситуации и форс-мажоры, которые не учитываешь. Если в работе у команды несколько проектов вы можете потерять контекст.

Как это было у меня

Мы договорились с разработчиком, что отступы в проекте между элементами баннеров будут 16 пикселей. Когда я отдала дизайн экрана, то забыла про это. Это не критичная ошибка, ее исправление не требует большого количества времени, но, как минимум, чувство неловкости из-за того, что что-то забыл, возникает.

Что включает этот самый контекст:

понимание проекта
ведение макетов
специфика работы, процессы
ограничения
договоренности с разработкой
важные артефакты

Карт-бланш для всех

Чтобы избежать хаоса, подробно ведите макеты и структурируйте дизайн-проекты. Это залог скорости и качества реализации проекта. Сначала к вам придут аналитики, потом разработчики, в конце за них возьмутся тестировщики. Дизайн - это один из источников правды, инструмент верификации проекта. Если хотя бы на одном из этапов возникнут вопросы, то с ними придут к дизайнеру. Если у вас не прописан функционал, анимации, как ведет себя продукт в различных ситуация, то этих вопросов будет больше.

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

Четко прописанный дизайн-проект снижает количество ошибок. Если учтены шрифты, колористика, состояние кнопок, то шансов, что в продакшен уйдет «кривой» продукт с изломами, будет гораздо меньше.

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

Важность онбординга

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

В 2025 году у нас был набор дизайнеров. Как тимлид, я видела, что новички «плывут» из-за отсутствия прописанных правил. Поначалу им сложно погружаться в контекст, приходится задавать дополнительные вопросы, а это в перспективе создает дополнительную нагрузку на команду.

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

Что должен включать онбординг

Общая информация о проекте (задачи, цели, целевая аудитория, этап реализации)
Контактная информация и функционал (кто у вас за что отвечает, инструменты коммуникации)
Доступ к рабочим инструментам (Slack, Jira, Figma и так далее, как получить доступ, структура рабочих папок)
Процессы и правила (дедлайны, чаты, оформления, дизайн-гайды)
Шрифты (да, снова они). Перед отпуском я забыла передать информацию, в результате дизайнер не мог нормально вступить в работу над проектом.
Общее понимание продукта. В зависимости от аудитории, его дизайн может очень сильно различаться (для детской аудитории - один, для взрослой - другой).
Какие инструменты используем конкретно мы. Если это нейросети, то какие промты используются.

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

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

Клаб коллективного опыта

Еще один инструмент, чтобы не потерять контекст - это клабы. Мы проводим их примерно 1 раз в две недели. Мы проводим здесь что-то вроде «смотрин» наших проектов. Есть еще тувиклики - неформальные посиделки отдела: здесь мы также можем обсудить, кто над чем работает и понять, что происходит.

Неформальные встречи – это своеобразная форма обмена опытом. Слушаем, кто над чем работает, кому-то можем предложить потом выступить в формате клаба. В любом случае, перенимаем опыт. Какие-то идеи можно попытаться адаптировать на других проектах.

Клабы и другие встречи возвращают в контекст: у них нет жесткого формата, как у рабочих митингов. Фактически, это функция мягкой синхронизации внутри всего отдела.

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

Последний месяц мы проводим встречи в режиме, когда каждый рассказывает о своих текущих задачах. Это не требует больших ресурсов на подготовку: ты просто «шаришь» рабочий экран ноутбука и показываешь, что делаешь. Это помогает понять, кто и как решает проблемы в режиме реального времени.

Внедрение подобных практик - формирует принцип преемственности. Если возникнет задача поменять дизайнера (заболел, уволился, «перегорел»), мы сделаем это быстрее, а проект не будет виснуть.

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

В результате этих изменений уровень ошибок и провалов заметно снизился. Команда стала работать более слаженно, а проекты — продвигаться эффективнее и стабильнее.

Вспомнить все: как онбординг и подробные макеты позволяют дизайнерам не впасть в хаос