Зоны ответственности junior, middle, senior дизайнеров
Я продакт дизайн лид в компании Instories. В нашей команде дизайнеры с разными грейдами и передо мной встал вопрос о том, как наладить работу с каждым в отдельности, чтобы не заниматься микроменеджментом, но при этом быть уверенной в качестве выпускаемых фичей. Мы с HR начали прописывать зоны ответственности для каждого грейда и точки контроля. Именно из этого процесса и получилась статья.
Для начала скажу, что все зоны ответственности должны быть таковыми по моему субъективному мнению. Я знаю минимум десяток примеров, когда джуны принимали важные решения по развитию проектов; и такой же десяток, когда сеньеры не принимали вообще никаких решений. Но я не считаю это правильным. Если вы в процессе чтений найдёте себя не в том грейде по зоне ответственности, не переживайте. У вас свой путь.
Что такое зона ответственности
Это участок проекта или процесса. Внутри зоны ответственности есть задачи, за выполнение которых отвечает сотрудник.
Почему важно понимать зону ответственности?
Кажется, что чем больше зона ответственности, тем лучше: можно влиять на бизнес, принимать решения по развитию продукта, управлять ресурсами и тд.. На практике, если ты не готов к ответственности, её увеличение может фрустировать; заставлять чувствовать себя некомпетентым; принимать решения, для которых не хватает навыков. Если ответственность слишком большая, то её рано или поздно захочется скинуть.
Давайте представим дизайнера, который устроился в первую компанию на позицию джуна. В компании он единственный дизайнер и может сложиться ощущение, что он ответственный за весь дизайн в компании. Что делает наш дизайнер? Начинает пытаться строить процессы, внедрять практики, делать редизайны и много чего ещё. Но что-то всё не получается: его никто не слушает, задачи падают сверху без особых обсуждений, практики не внедряются, редизайн не идёт. Это то, как видит ситуацию дизайнер.
Руководство видит начинающего специалиста, которого взяли на рост, но пока он не в состоянии принимать никаких важных решений. Его инициативы ничем не подкреплены. Но с сотрудником эти моменты не проговорили.
Дизайнер не понимает, что для влияния на бизнес недостаточно отсутствия других возможных кандидатов. Нужно обладать навыками, стратегическим мышлением, опытом, уметь выстроить коммуникацию и тд. Наш дизайнер чувствует ответственность, которой на самом деле нет. Дизайнер через 2-3 года устаёт от такой обстановки и уходит в компанию, где есть команда дизайнеров и арт-директор и с радостью отдаёт всю ответственность, пока не подкачает хардовые и софтовые мышцы.
Второй кейс, когда дизайнер приходит в компанию джуном или мидлом. У него есть четко очерченная зона ответственности и руководитель. За время работы дизайнер изучает всю внутреннюю кухню, понимает процессы смежных команд, начинает оказывать саппорт в сложных вопросах смежникам. У него есть поддержка и понятные точки контроля. Зона ответственности плавно меняется от точечной, в ответственность за проект или направление. Он имеет представление, как курировать младших дизайнеров на основе собственного опыта и команда ценит его вклад.
Два разных опыта складывается из, казалось бы, маленькой детали.
Дизайн-процесс
Теперь перейдем к зонам ответственности по грейдам. Я составила их на основе матрицы компетенции и с учётом дизайн-процесса в компании. Этот дизайн-процесс лег в основу точек контроля.
Дискавери
- исследование;
- проектирование ux;
Деливери
- проектирование ui;
- исследование;
- работа с дизайн-системой;
- дизайн-ревью.
Процессы
Внутрикомандные и межкомандные.
Junior
Выполняет небольшие понятные задачи по заданному фреймворку. Нужен контроль на каждом этапе разработки задачи.
Проектирование (UI UX)
- Задачи ставит руководитель, старший дизайнер, менеджер.
- Дизайнер демонстрирует каждый этап выполнения фичи (ресеч, сбор референсов, ux, ui), получает комментарии и следует им.
- На командные встречи приходит с вопросами и вариантами дизайна.
- Продуктовые спецификации требуют валидации старшего дизайнера.
Исследование пользователя
- Отсматривает проведенные интервью с пользователями. Может присутствовать на интервью.
- Учится замечать инсайты.
- Много слушает.
Дизайн-система
- Добавление и описание каждого атома валидируется старшим дизайнером или лидом.
Дизайн-ревью
- Дизайн-ревью проводит только вместе со старшим дизайнером.
- Не может самостоятельно принять результат у смежников.
- Не принимает решение по запуску или раскатке фичи.
Звучит жёстко. Но на деле это обоснованное решение. Джуниор может не до конца понимать процессы, метрики, правила консистентности и тд. Но важно, чтобы был прогресс в изучении важных направлений. Особенностью джуниор позиции, как мне кажется, является нестабильная выдача качественного результата: то хорошо, то плохо. То учёл все вводные, то нет. Поэтому нужен контроль.
Что касается процессов, то на этом этапе важно изучить процессы команд и не спотыкаться по ходу дела. Если что-то не так, то идти к руководителю.
Но при систематическом качественном выполнении задач, пониманию всех существующих фреймворков в компании джун становится мидлом и зона ответственности расширяется.
Middle
Выполняет понятные задачи с предсказуемым результатом. Контроль нужен на основных этапах.
Проектирование (UI UX)
- Задачи ставит руководитель, менеджер.
- Ресечи может провести самостоятельно, презентовав выводы и ход мыслей.
- Финальное решение по ux и ui принимает старший дизайнер или лид.
- Самостоятельно создает продуктовые спецификации, валидирует с разработкой и тестированием. Собирает обратную связь о каждом этапе своей работы.
- Может презентовать концепции стейкхолдерам и команде.
Исследование пользователя
- Первые несколько исследований проводит под руководством лида или старшего дизайнера. Далее может проводить исследование самостоятельно или с менеджером.
- Формирует гипотезы совместно со старшим дизайнером. Опирается на метрики.
Дизайн-система
- Добавляет атомы ДС под руководством лида или старшего дизайнера.
Дизайн-ревью
- Дизайн-ревью несколько раз проводит со старшим дизайнером, пока не начинает выдавать стабильно хороший результат.
- Принимает результат от смежников вместе с лидом. Учится корректировать смежников.
Процессы
- Может придумывать свои фреймворки решения, но валидирует их с лидом.
- Начинает оказывать консалтинг смежным командам, если это касается общих процессов.
- Если есть сложности с процессами, может предложить решение команде или лиду. Может попробовать внедрить процесс под саппортом руководителя.
Мидл — это хороший предсказуемый сотрудник. Есть мем на тему (не помню как звучит, но смысл следующий). Весь айти мид держится на мидлах. Джуны ещё не могут (ничего не понимают), сеньеры уже не могут (очень заняты поиском топового оффера). Работать некому, кроме мидлов.
Важно с мидлом уделять внимание анализу выпущенных фичей, работать с пониманием бизнес процессов, помочь ему наладить работу со смежниками (особенно смежными дизайнерами). Это поможет ему понимать какой результат он должен всегда выдавать, к чему стоит стремиться, где решение он может принять самостоятельно.
При этом мидлам ещё важен саппорт руководителя. Не все дизайн-решения могут быть элегантны. Мидла ещё можно "прогнуть" и этим могу пользоваться менеджеры (не в обиду им). Мидл может не понять, что в команде сломан процесс и делать лишнюю работу. В общем, вы поняли.
Senior
Выполняет задачи, которые никто не знает как решать. Контроль на первой и последней точке.
Проектирование (UI UX)
- Ставится задача лидом, пути к решению сеньор придумывает сам.
- В сложных кейсах занимает ресечем. Может прийти за консультацией к лиду.
- Все общения со смежниками инициирует сам.
- Приносит на обсуждения осмысленные решения, все вопросы решаются до того.
- Может провалидировать решение младших дизайнеров и дать обратную связь.
- Итоговое решение принимает вместе с лидом.
- Презентует и защищает финальное решение (стейкхолдеры и команда).
Исследование пользователя
- Дизайнер самостоятельно проводит интервью с пользователями. Пользуется всеми возможными инструментами для исследований. Описывает инсайты.
- Передаёт знания о пользователе команде и смежникам.
- Формирует гипотезы (с учетом основных метрик) для беклога команды → Участвует в оценке гипотез.
Дизайн-система
- Понимает стратегию формирования ДС.
- Самостоятельно качественно добавляет атомы ДС. Валидирует собранные компоненты младшими дизайнерами.
Дизайн-ревью
- Создает подробные спецификации проекта со всеми артефактами, валидирует с командой и тестировщиком.
- Проводит самостоятельно ДР.
- Может провалидировать сборки всех команд.
- Может оценить качество выдаваемых решений от смежников (контент дизайнеров).
Процессы
- Может придумывать свои фреймворки решения, но валидирует их с лидом.
Запуск продуктов
- Понимает бизнес цели и стратегию компании, в рамках которой реализуем задачу.
- Понимает цели дизайн-команды и ожидания к качеству продукта (ux, ui).
- Если дизайнер понимает перед релизом, что продукт почему-то получился плохим (эксперимент точно не сыргает, “не верим в такую реализацию идеи”, негативно повлияет на пользователя), то подсветит это менеджеру и лиду и поставит под вопрос релиз.
Сеньер стоит дорого и должен уметь справиться с любой задачей: запуск нового продукта, смена стрима, изучение пользователей, изменение процессов. Так же должен приносить деньги в компанию и уметь пережить любые колебания. Позиция позволяет принимать решения на всем пути самостоятельно, но всегда есть "НО".
Сеньеры это уже сформировавшиеся личности, с отличительным бекграундом и собственными правилами дизайна. Им иногда хочется делать "своё". Вот тут важна стратегическая синхронизация и прозрачный план "куда идём". Поэтому точки контроля тоже должны быть.
Вывод
Зоны ответственности нужны для того, чтобы сотрудник учился принимать решения и понимал чего от него ожидают. А руководитель (особенно тревожный, как я), учился не залезать в каждый микропроцесс.
Если у вас другое видение зон ответственности, пишите в комментах, будет очень интересно обсудить.
И подписывайтесь на телеграм-канал Дизайн тащит . Там публикую посты о жизни и рутине в продуктовой команде, а также море мемов на тему дизайна.
Классная статья, спасибо!
В применении к нам (занимаемся мобильной разработкой), функционал джуна очень схож, за мелкими исключениями типа таких: джун не просто может присутствовать на интервью, но в позиции младшего полноценно участвует в них, включается в диалог и продает свои решения, получая обратную связь от клиента напрямую. Это важно - как можно раньше переставать нянчить джуна, который сначала получает задачи и обратную связь только внутри, от мидла и/или прожекта, и запускать его во внешний мир, в реальные процессы с клиентом.
А функционал мидла и сеньора у нас смешан. Точнее, часть самых ответственных функций сеньора выполняют руководители. Надеюсь, что «пока выполняют руководители, а потом - будут сеньоры», тут есть куда расти )
Спасибо за ответ!)
Есть разные джуны: некоторых сразу можно в поля брать, некоторым можно сначала на коллегах поучиться. Но я согласна, чем раньше поймут весь скоп работы и попробуют, тем быстрее вольются и совершат первые ошибки)
Спасибо за статью, интересно узнать как у других распределяются зоны)
Судя по нашим зонам, я мидло-синьер. Есть ответственность за продукт и право принимать решения, но я не всегда могу найти верное решение для любой задачи
Мне тоже интересно на сколько эффективно у других команд и что на это влияет) почитаем если накинут варианты
Да, я тоже по этому описанию мидло-синьор. Особенно про взаимодействие со смежниками и улучшение процессов. Надо пойти лиду намекнуть 😅
Спасибо за интересную статью! Было бы супер узнать примерные вилки по рынку на таких ролях🙃
Приходи в канал, обсудим)