Модель оценки продуктового дизайнера

Полная версия страницы доступна после авторизации.

В Контуре два раза в год, зимой и летом, проходит полугодовое ревью. Руководители и сотрудники общаются и дают друг другу обратную связь.

Этапы ревью

Дизайнеров оценивают с двух сторон. Непосредственный руководитель смотрит на работу в команде, скорость решения задач, эффективность и экологичность коммуникаций. Функциональный руководитель оценивает качество решений, визуальную составляющую, дает советы по профессиональному росту.

Детальный процесс отличается в разных подразделениях и дизайн-группах, но есть общие моменты:

  • дизайнер пишет селф-ревью;
  • руководители встречаются с дизайнером, а потом синхронизируют свою оценку.

Селф-ревью

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

Чтобы написать хорошее селф-ревью, запланируйте на него два-три часа в календаре. Нужно собраться с мыслями, вспомнить важное. Селф-ревью не должно быть очень длинным или коротким, оптимальный размер полторы-две страницы А4.

План селф-ревью:

  • Цели с прошлого периода. Коротко про каждую: выполнена — результаты, не выполнена — причины.
  • Самые интересные и показательные задачи в продукте: нужно выбрать такие, по которым можно будет составить впечатление об объеме и сложности проделанной работы. По каждой задаче: ссылка на Фигму, суть задачи и все, что захотите рассказать: новое, подводные камни и другие приключения в ходе решения, оценка результата.
  • Другие активности в продукте и вне его: выступил в роли наставника, помогал менять процессы, фичелидил задачу, продал задачу команде, организовывал митап дизайнеров, писал гайд и др.
  • Собственная оценка прошедших шести месяцев. Что было хорошо, что не получилось, что делал впервые, чему научился, что принесло положительные эмоции, что расстраивало.
  • Цели на следующий период, которые хочется перед собой поставить. Коротко о мотивации: зачем хочется достичь эту цель? Пример: сходить на стажировку к дизайн-лиду другой группы, чтобы научиться скиллу Х. Если ничего не придумывается, лучше оставить блок пустым.

Модель оценки

Модель — это инструмент оценки продуктового дизайнера в команде, а не план его развития.

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

Супер-скиллы

Супер-скиллы — это навыки и свойства дизайнера, которые не являются обязательными для грейда. Они полезны для продукта и компании, поэтому тоже влияют на зарплату.

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

  • Наставничество — любит учить других дизайнеров, регулярно берет стажеров и джунов.
  • Рисует красивые иконки — может нарисовать набор иконок, не уступающих работе иллюстратора.
  • Метрики — может написать запросы и получить статистику либо сходить в Метрику или Гугл.Аналитику.
  • Исследования — проверка своего решения и проведение исследования.
  • Выступления и полезные активности — периодически выступает на конфах, пишет статьи или организует профессиональные мероприятия.
  • Пишет гайды — регулярно пишет новые гайды, участвует в их обсуждении, улучшает сайт с гайдами.
  • Супер-производительность — берет реально много задач и делает их быстро и качественно.
  • Супер-владение инструментом — идеально знает Фигму или другой инструмент, виртуозно им владеет, делится знанием с другими ребятами.
  • Супер-эрудированность в дизайне — много читает, слушает, смотрит, в курсе трендов и повестки, делится инфой с другими, создает вокруг себя заряженное информационное поле.
  • Супер-знание предметки, умение погружаться в аналитику — особенно глубоко погрузился в сложную предметку, может сделать проводку в бухгалтерской программе или ответить на звонок в техподдержку.
  • Супер-знание архитектуры продукта — знает все сущности и зависимости в продукте, использует эти знания при проектировании, отвечает на вопросы коллег.
  • Выстраивает и развивает процессы в команде — активно формирует процессы в команде, помогает их внедрять, модернизировать.
  • Фичелидство — фичелидит задачи в команде и умеет делать это хорошо.
  • Супер-красивые макеты — делает красивые, гармоничные, визуально привлекательные макеты: внимателен к мелочам, грамотно работает с графикой, использует интересные акценты и незаезженные ходы.
  • Пишет супер-тексты — может написать средний/большой текст, который не просто донесет информацию, а будет интересно подан, его хочется дочитать.
  • Супер-продуктовость — принимает активное участие в проработке стратегии развития продукта, формулирует гипотезы, думает о монетизации и привлечении/удержании аудитории.

Базовые скиллы и грейды

В базовые скиллы попало только пять навыков, которые отвечают следующим критериям:

  • являются неотъемлемыми для грейда,
  • растут с каждым грейдом.

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

Джун

Мидл

Сеньор

Лид

Портрет

👶‍ Ваня

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

👩 Лена

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

👨‍ Женя

Успел поработать в нескольких командах и продуктах. Справляется с большими задачами, но может ошибаться по срокам, зайти на второй/третий круг, просесть по качеству

‍👸 Катя

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

Делает большие задачи с высокой степенью неопределенности. И делает их стабильно хорошо

Сложность задачи,
с которой может справиться

Небольшие задачи, определенные, хорошо описанные.

Необходимо много встреч для обсуждений промежуточных этапов. В одиночку может закопаться.

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

Задачи среднего или большого размера, определенные, но, возможно, с пробелами в аналитике.

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

Пример: новый раздел, новый сценарий

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

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

Пример 1: стабильно делает новый раздел, шаблонный продукт.

Пример 2: может спотыкаться, если попадется нешаблонный продукт, сложный сценарий, где нет четкой логики или много ограничений от разработки

Большие задачи с высокой степенью неопределенности: нет или мало аналогов решения, никто не знает, как делать эту задачу, аналитика туманна.

Может решать задачи, сформулированные менеджером, без аналитики. Поможет выстроить процесс решения задачи.

Умеет планировать свою работу и сроки по сложным задачам.

Пример: новый сложный сервис, сложная, запутанная логика

Систематизация и порядок

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

Учится использовать компоненты и стили, но создает компоненты редко.

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

Может забывать описывать состояния, валидации

Решая задачу, всегда думает, как она соотносится с другими интерфейсами системы.

Файлы в проекте понятно названы, есть обложки, пейджи понятно названы, черновые макеты явно отделены от чистовых, фреймы названы, рядом с фреймами есть комментарии и дополнения.

Библиотеку компонентов проекта поддерживает нестабильно или ее может не быть совсем

Ко всем решениям подходит системно, не только в плане интерфейса, но и с точки зрения пользовательского опыта в целом.

Стабильно пользуется компонентами, автолейаутами, стилями. Поддерживает библиотеку проектных компонентов и паттернов. Состояния элементов описывает на вариантах

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

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

Общается с фронтендером на одном языке, стремится синхронизировать библиотеку дизайна и верстки.

Кроме макетов, стремится упорядочить знания о пользователях, сценариях, целях продукта и команды.

Может организовать работу нескольких дизайнеров внутри продукта

Веб-технологии

Может не знать, как устроена html-верстка, что можно сделать, что нельзя.

‍Не умеет оценивать сложность своих решений и «спорить» с фротендером.

‍Пример: рисует интерфейсы, которые после комментариев фронта регулярно приходится переделывать

Накапливает знания, старается их структурировать и применять в работе:

‍Фронтендер: «Как это работает?» Дизайнер: «А как можно?»

‍Понимает, как работает адаптивная верстка, брейкпоинты.

‍Пример: помнит про адаптивность, рисует ее, ховеры, разные состояния интерфейса. Рисует макет, который хорошо смотрится на самых популярных разрешениях пользователей, нет белых пятен и пр.

Про многие вещи уже знает заранее, что можно, что нельзя, что дорого, что просто. Но все еще остаются большие белые пятна.

‍Структурирует макет в Фигме близко к верстке.

‍Пример: может открыть инспектор, что-то подправить, передать фронту четкую инструкцию, как надо переделать

‍Понимает, как устроена верстка, блочная модель, DOM, HTML, CSS, Javascript, одностраничные приложения, CSS-анимации. Знает основные теги, их атрибуты, свойства CSS.

‍Понимает взаимодействие фронтенда и бэкенда.

‍Говорит с фронтом на одном языке.

‍Пример 1: может спроектировать анимацию в кодепене и передать прототип фронту.

‍Пример 2: Яков

Визуальное решение

Изучает правила дизайна, накапливает палитру инструментов, учится делать аккуратно.

‍Учится использовать стиль Контура, но пока может нарушать гайды неосознанно.

‍Макеты: даже с зумом 50% видны шероховатости и слабые места

Овладел основами UI-дизайна. Типовые экраны получаются аккуратными, но суховатыми.

‍Не хватает стабильности, может ошибаться особенно в сложных нетиповых случаях. Пробует сделать поинтереснее, но получается неуверенно.

‍Может осознанно, но неоправданно нарушать правила дизайна и дизайн-системы: когда и стандартное решение работает хорошо.

‍Макеты: простые лейауты аккуратные, но при близком рассмотрении могут появляться вопросы

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

‍Умеет хорошо выстроить композицию, соблюсти иерархию объектов, пропорцию белого и заполненности. Но пока боится или не умеет делать смело.

‍Редко ошибается, в типовых случаях почти никогда.

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

‍Может красиво сверстать сложный экран, где много элементов разных по структуре: виджеты, таблицы, списки.

‍Может делать смело, при этом осмыслено, и в ретроспективе такой дизайн оказывается правильным: решения нетиповые, которые никто не проверял, но в данном случае они могут быть особенно удачными. Смелая типографика, структура экрана, композиция.

‍Хорошо делает на автомате.

‍Макеты: чем дольше смотришь, тем больше нравится

Коммуникация

Презентация решения, встречи, восприятие критики

Сидит в себе

‍Сам не инициирует презентации. Недостаточная подготовка к презентации. Отсутствие структуры и плана.

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

‍Может рассказывать про отдельные места дизайна вместо сценария.

‍После презы требуется длительное восстановление 🤕

Выходит к команде

‍Может принести небольшие задачи в команду, продать ее в планировании, иногда у него это получается.

‍Готовится и проходит презентация хорошо, но без подготовки начинает теряться. Очень старается продать свое решение, может перегибать палку.

‍Понимает, когда какой формат презентации подходит, но может полениться и отправить ссылку

Привлекает команду

‍Сам принимает решение, но пока не лезет в политику.

‍Может не готовиться к презе, но она пройдет хорошо.

‍Неудачи не выбивают из колеи.

‍К презентации уже все показал, :) cюрпризов не будет.

‍Уместно использует других как инструмент для поиска решения

Выходит за пределы команды, меняет процессы команды

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

‍Может договориться с командой и менеджментом об определенной квоте задач от дизайнеров.

‍Умеет в политику: понимает, кто и как принимает решения, не требует нереальных вещей, но реальные и нужные настойчиво продает.

‍Влияет на развитие продукта