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

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

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

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

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

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

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

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

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

— понимание проекта

— ведение макетов

— специфика работы, процессы

— ограничения

— договоренности с разработкой

— важные артефакты

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

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

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

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

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

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

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

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

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

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

— Общая информация о проекте (задачи, цели, целевая аудитория, этап реализации)

— Контактная информация и функционал (кто у вас за что отвечает, инструменты коммуникации)

— Доступ к рабочим инструментам (Slack, Jira, Figma и так далее, как получить доступ, структура рабочих папок)

— Процессы и правила (дедлайны, чаты, оформления, дизайн-гайды)

— Шрифты (да, снова они). Перед отпуском я забыла передать информацию, в результате дизайнер не мог нормально вступить в работу над проектом. 

— Общее понимание продукта. В зависимости от аудитории, его дизайн может очень сильно различаться (для детской аудитории — один, для взрослой — другой).  

— Какие инструменты используем конкретно мы. Если это нейросети, то какие промты используются. 

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

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

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

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

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

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

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

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

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

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

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