Чем джун отличается от мидла

Введение

Грейд — это не просто надпись в резюме и не ощущение “я уже давно рисую, значит пора выше”. В продуктовой работе разница между джуниор и мидл дизайнерами чаще видна не по красоте экранов, а по тому, как дизайнер ведёт задачу: какие вопросы задаёт, сколько контекста может разобрать сам, как работает с ограничениями и что отдаёт команде на выходе

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

Это не значит, что джуны слабые или “не настоящие дизайнеры”. Это значит, что у него пока меньше самостоятельности, меньше опыта с реальными ограничениями и меньше доказательств, что ему можно доверить неопределённость

Быстрое сравнение

Где джуг чаще проседает

Самая частая проблема не в том, что джуниор дизайнер “плохо рисует”. Часто экран визуально нормальный, но вокруг него нет рабочей логики. Непонятно, что пользователь делал до этого, что произойдёт после клика, что будет при ошибке, какие данные могут быть пустыми, как макет поведёт себя на длинном тексте и что должен собрать разработчик

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

Как понять, что ты уже растёшь

Хороший сигнал — ты перестаёшь спрашивать только “как это должно выглядеть” и начинаешь спрашивать “какую проблему решаем”, “что пользователь должен сделать”, “что будет при ошибке”, “какие ограничения у разработки”, “как поймём, что стало лучше”

Другой сигнал — твои макеты требуют меньше расшифровки. Разработчику не нужно гадать, где hover, где error, что делать с пустой таблицей, как работает форма и какой статус появляется после сохранения. Команда видит не просто картинку, а понятную сборку решения

Мини-чеклист перехода в middle

Отметь пункты, которые уже можешь делать без постоянной помощи:

•  разобрать задачу, даже если бриф неполный
• задать уточняющие вопросы до старта макета
• собрать user flow перед финальным UI 
• показать основной сценарий, ошибки, пустые и загрузочные состояния 
• объяснить решение без фразы “так красивее”
• подготовить макет к разработке с комментариями
• принять фидбек без личной драмы
• предложить улучшение, которое помогает задаче, а не просто добавляет шум 
• показать результат через сценарий, качество решения или влияние на команду

Что делать дальше 

Выбери одну слабую зону и прокачай её на ближайших задачах. Не “стать middle за месяц”, а конкретнее: в каждом новом макете показывать состояния, писать комментарии для разработки, собирать flow до UI или заранее формулировать проблему задачи