Индивидуальный план развития для Middle+ UX-дизайнера

В недавнем tg-посте я уже рассказал, что такое ИПР в принципе, зачем он дизайнеру, бизнесу, и дизайн-лиду.

Удобный и полезный инструмент — дока/табличка с планом роста до ближайшего повышения ЗП :) Ускоряет рост дизайнера и делает его полезней для бизнеса.

Помогает ответить на вопрос «что мне надо сделать-прокачать-нарисовать-наладить, чтобы стать синьором».

Чаще применяется в корпорациях, но я покажу, как применяю в стартапе.

Теперь — к конкретному кейсу. Как я составлял ИПР для конкретного дизайнера, почему именно такой, и как его используем.

Хотим получить крепкого миддла

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

Дизайнер сказал, что он middle+ и хочет в синьоры. Не очень любит созвоны (есть затруднения с речью и слухом). Быстро и довольно хорошо рисует UI. Умеет в UI-киты/дизайн-системы.

Если дизайнер — миддл, то что?

То у него есть необходимая база, он довольно много может-умеет. Прототипирует, рисует UI, пользуется компонентами и пр. Может собирать более-менее объемные фичи. Как-то при этом договаривается с бизнесом и разработчиками. Может стабильно перформить на дистанции.

Что отличает миддла от синьора:

1. Каша из знаний (местами или везде). Инфы много, системности мало
2. Нехватка гибкости (синьор лучше миддла способен перестраиваться)
3. Нехватка способности выходить за свои пределы (синьор лучше решает непривычные и оверсложные для него задачи)
4. Излишний фокус на себе и артефактах (вместо фокуса на результате, опыте пользователя/бизнеса/разработчика — как у синьора)
5. Мало умеет в процессы (не умеет замечать повторяющиеся проблемы, не может найти повторяющийся ритуал/шаблон и высвободить мозги себе и команде, решает каждый раз кастомно)
6. Если к нему приставить пару джунов — легко может не уследить за ними

Важно! Обычно у нас все-таки не сферический миддл в вакууме. В реальности какие-то скиллы обгоняют, какие-то отстают.

Что надо давать миддлу, чтобы он хорошо работал?

В среднем, через полгода-год миддл сваливает на новое место, или начинает лениться :) Как продлить этот срок и получить больше результатов?

Перформящий миддл = деньги+рост+среда

Нормальному миддлу важна среда, в которой он сможет расти. Если смочь дать такую среду — он вложится на полную.

Сначала — диагностика отстающих/обгоняющих скиллов
Потом — ИПР

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

Вот по-быстрому накиданный «сферический скиллсет синьора в вакууме». Такой, чтобы неплохо подошел и в корпорацию, и в стартапы. И сложные финтехи пилить, и в гроусхакингах помогать:

В нашем случае — пришел миддл с хорошим UI и соображалкой, высокой скоростью.

Что вообще проверяем, помимо UI?

1. Cофт-скиллы (работа с ожиданиями и пр)
2. Процессы (взаимодействие, созвоны-встречи)
3. Бизнес-мышление (думать КОНЕЧНЫМ результатом/людьми)
4. Рисование схем и прочего не-пиксельного

Как — оплачиваемый тестовый спринт (2 недели)

Я позвал дизайнера проработать с нами пробные две недели с реальной оплатой и боевыми задачами. Дизайнер согласился и выделил нам по 6 часов в день.

Стараюсь везде, где можно — давать не тестовые задания, а «оплачиваемые тестовые две недели».

Получаем настоящую работу вместо «тестовых суррогатов»

Тестовое часто врет, затягивается. А у нас стартап и правильные первые сотрудники очень важны. Поэтому платим и получаем:

1. Реальное вложение рабочего времени и сил
2. Настоящие задачки, без скидок и натяжек
3. Успеваем плотно покоммуницировать
4. Вообще всё по-настоящему

Что в результате?

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

Как мне помочь дизайнеру на испытательном сроке?

1. Настроить управление ожиданиями
2. Открыть «бензобак» дизайнера
3. Дать бизнесу отрисованные картинки в количестве
4. Настроить взаимодействие дизайна и разработки (норм передача, дизайн контролирует качество верстки и в целом прода)
5. Чтобы после испытательного и бизнесу и дизайнеру все нравилось, дизайнер получил повышение и они счастливо бежали дальше

Тогда и продукт будет расти, и меня-лида все будут любить и ценить :)

Какой-то месяц работы — и ИПР готов 😂

После пробных двух недель мы позвали дизайнера работать. Я за ним еще понаблюдал и дописал ИПР (то есть его лучше не за один подход превозмогать-рожать, а просто смотреть и фиксировать наблюдения).

Что получилось?

ИПР = цели с большой внутрянкой + таймлайн

Я завел отдельную страничку в Notion (мы ведем в нем всё по проекту). Подробно описал все цели на испытательный и предложил, что и в какой срок должно быть сделано.

Это НЕ самая первая вариация (первую я не успел заскриншотить), а уже после нескольких изменений «по пути».

• В заголовке указан срок (чтобы каждый раз не вспоминать «а когда заканчивается испытательный?»)
• Целей — три (больше 3-4 целей лучше не делать, тяжело удерживать фокус), но довольно большие. Нарисовать несколько продуктов, наладить передачу в разработку и управление ожиданиями. Все цели положены в сворачивающиеся заголовки. Удобно читать, удобно погружаться.
• Под целями — диаграмма Ганта, чтобы легко было поиграться со сроками. В первый месяц — управление ожиданиями и один отрисованный продукт. Ближе к середине — начало передачи в разработку. Следующие полтора месяца — еще один продукт. А потом, две три недели — последний, поменьше.

ИПР может меняться

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

Например, сейчас ИПР выглядит уже вот так (и это я еще забыл заскринить самую первую версию, там и график отрисовки продуктов был другой)

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

Всего три цели до роста зп 🙂

1. Управлять ожиданиями (бизнеса, разработки и пр). Большая отдельная тема, очень облегчает жизнь. Нашел пару приемлемых буржуйски статей по теме, вот первая и вторая. Без этого скилла дизайнер обещает слишком много / не то, фокусируется не на том и пр. В итоге — нарисовано много, но тобой недовольны.
2. Настроить передачу в разработку У нас «всё сложно» — несколько больших продуктов делается с нуля. Дизайнер нарисовал целый продукт, закинул ссылку в чатик, и «если у ребят будут вопросы — напишут». В итоге разработчики смотрят все в последний момент, охреневают от объемов, начинают реализовывать и возникает куча вопросов. Сроки едут, фаундер недоволен. И это только один кусочек проблемы. Надо наладить.
3. Задизайнить несколько продуктов (и убедиться, что на проде выкатили ровно то, что он задизайнил) Почти каждый пункт списка — отдельный продукт с несколькими эпиками.

За целями нужно будет постоянно следить — ситуация меняется, возникают риски, нужно помогать дизайнеру их достигать.

Как цели устроены внутри?

Внутри каждой — артефакты, условия, ритуалы…

Прописали:

• Ритуалы (созвоны-встречи и пр.) по каждой цели. На цели охотно забивают, про них надо вспоминать, встречать-говорить-синхронизироваться, чекать прогресс и пр.
• И критерии приемки: как мы поймем, зачет или незачет по каждой цели и когда должны добежать до нее.

Цель 1 — управление ожиданиями

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

Например, наш миддл просто рисовал те фичи, о которых попросили «вот прям сейчас».

Если не синкаться о том, а что у нас вообще запланировано, что и когда ждут, «что такое хорошо и что такое плохо», когда какие макеты надо отгрузить разработке…

То можно не попасть в ожидания бизнеса (которые тот далеко не всегда проговаривает и даже осознает в моменте).

Причем «на берегу» можно сильно повлиять на эти самые ожидания. Объяснить, сколько и каких макетов ты можешь сделать за неделю/месяц и пр. Договориться, как и что должно работать и пр.

Чиним — фолоуапами, майлстоунами, ожиданиями в макетах, таймлайном

1. Фолоуапы после встреч — с кем встретились, что важного обсудили, про что договорились, кто и что дальше делает? Нудно, но полезно.
2. Майлстоуны — маленькие промежуточные шаги внутри спринта. В нашем случае оказалось избыточно — дизайнер очень много делает и очень ответственный. Неплохо делит задачи на шаги со сроками. С менее осознанными и мощными ребятами — очень полезно.
3. Ожидания — в макеты. В нашем случае тоже оказалось избыточно (фаундер глубоко вовлечен и довольно последователен). Бывает полезно обложиться и ТЗ, и рефами и ожиданиями заказчика, чтобы все было под рукой в макетах и легко было напомнить, как мы ставили задачу.
4. Таймлайн и спринты. Мы часто с ним сверялись, очень помогает помнить, до каких сроков мы договорились и вовремя ускоряться/держать темп

Вот на что обратить внимание

Я расписал Acceptance Criteria. То есть как померить, что по цели всё ок. В данном случае:

1. Предсказуемость «когда-где-что будет и куда смотреть». Дизайнер с этим отлично справился. Показывал много промежуточных результатов в чатике (и картинки и GIF и скринкасты). Плюс я поставил регулярные встречи для синка/акцепты с фаундером.
2. Не больше одного серьезного продолба — где мы как-то критично не учли ожидания или сильно уехали по срокам.
3. Легкость постановки задачи — бизнесу не требуется повторять одно и то же помногу, плюс в целом объяснить задачу — не пытка.

И вот не забудь закинуть в календарь

В цели полезно накидывать примерный список созвонов, грумингов, синков, каких-нибудь ревью, 1на1 и пр.

Чтобы в календаре были события, которые подталкивают нас двигаться по ИПР. Про это можно почитать в системе GTD (она в принципе хороша на тему продуктивности)

1. 1на1 по запросу дизайнера — особо не требуются
2. дизайн-синки с фаундером — делаем штуки по 2-3 на двухнедельный спринт
3. груминги с фаундером — делаем по 1-3 штуки на спринт

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

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

Цель 2 — передача в разработку

У миддла ответственность за дизайн часто заканчивается на «я нарисовал вовремя, бизнес принял». А как что поймут разработчики — уже неважно. Синьор идет дальше.

• Синьор знает, когда что будут разрабатывать, и приносит макетики заранее
• Он не верит, что с первого показа разработчики поймут сложную фичу и тут же зададут все вопросы
• Он не верит «да, все понятно» и понимает, что скорее всего где-то подвох :)

Вот какими артефактами это чинится

• В нашем случае я сначала организовал несколько созвонов, и попросил дизайнера на них презентовать макеты девелоперам. Посмотрел, как все идет. У
• видел, сколько вопросов возникает у разработки, как потом идет реализация. И составил доку про handoff process. Объемная история, про нее скорее всего будет отдельная статья

Вот на что обратить внимание

Главное — научиться переносить фокус с артефактов на результат.

• Неправильно с «я сделал все нужные картинки и документики»
• Правильно «вот теперь разработчики всё поняли, спланировали свою работу и воплощают мои наработки в жизнь, и я знаю когда и как проверить результат»

Что еще:

• Итеративность. Когда вгружаешь в разработку что-то сложное — может потребоваться несколько заходов
• Не только дизайн. У нас вместе с макетами передаются userflow, данные, интеграции, тексты ошибок.
• Улучшения/изменения. Скорее всего нормальная передача сложных штук получится не с первой фичи. Пробовать-рефлексировать-менять. Спринт на 3-4 будет уже лучше

И вот не забудь закинуть в календарь/спринты

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

Я закинул это в таймлайн с примерными датами и посоветовал ребятам добавить в свои задачи на будущие спринты.

Цель 3 — дизайн ключевых штук

Понятно, что макетики — ядро. Если их нет в нужном количестве-качестве, то это всё испортит 🙂 Про них тут особо и объяснять нечего.

Как идем по ИПР

[ ] Все доформулировать, добавить ценность, сократить, картинки приложить и пр

В первые недели я:

• Добавлял и устаканивал нужные созвоны. Чтобы получать дизайн, устраивающий бизнес и двигаться в графике. Учились собирать ожидания, изучать проблему, а не бежать сразу в решение.
• Делал продуктовые описания инициатив (инициатива = даже не эпик, а релиз целого продукта).
• Немного каментил дизайн, помогал договориться и пр

Потом (месяца полтора):

• Я смотрел что и как рисуется, как быстро решаются текущие вопросы между бизнесом и дизайнером и пр. Двигал график, пересобирали беклог дизайна.
• Дизайнер прям круто фигачил картинки и быстро много вопросов решал с фаундером в. переписке. Это у него прям отработано, это чувствуется
• Я не мешал ребятам слегка воткнуться в проблему с разработкой (эта проблема такого рода, что пока дизайнер и бизнес ее не начнут ощущать — мои предложения будут приниматься без энтузиазма)

Сейчас

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

А что в итоге?

• Дизайнер хорошо вписался и растет, все получилось очень бесшовно.
• Бизнес доволен и ценит мою работу.
• Я в парт-тайм режиме успеваю принести ценность и не упахаться.

Хочется помощи со своими задачами?

Участвую в продуктах как дизайн-лид и продакт

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

В общем — пиши, обсудим :)