Ваня Серебренников

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

2025-11-06T15:35:58.286Z

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прописали:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что еще:

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

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

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

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

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

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

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

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

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

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

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

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

Сейчас

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

А что в итоге?

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

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

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

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

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

Сложные и размытые задачки — фреймворки, ч.1

2025-03-26T05:39:58.727Z

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

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

Но сходу упираемся в первую мысль

Фреймворки — не главное

Бег за фреймворками и инструментами без понимания смысла = карго-культ. В портфолио и на собеседовании это быстро выявляется. Дизайнер не может ответить, зачем он рисовал, например, userflow; почему именно такой, почему именно на этом этапе проекта, почему именно для всей фичи. И легко опознаётся как джун (максимум миддл).

А как правильно? Правильно — понимать несколько главных вопросов, стоящих за всеми фреймворками. До них мы еще доберемся :)

AI нам подскажет, что к UX/UI/продукту относятся, помогают в работе над ним, или могут быть притянуты за уши:

Design Thinking
Double Diamond
Atomic Design
HCD
JTBD
Lean UX
Service Blueprint
Gestalt Principles
User Story Mapping
HEART Framework
Mental Models
User Story Mapping
Kano Model
Fogg Behavior Model
The Hook Model

Более, того, я сам изобрел один фреймворк, скрестив AARRR-воронку (она же «пиратские метрики») и CJM и выкинув лишнее. Я обучил этому фремворку как минимум несколько сотен людей, но до сих пор не придумал название :)

Без понимания «зачем и в каких случаях», фреймворки работают плохо

Если не понимать сути и смысла фреймворков, их ограничений, их применимости — в них просто теряешься.

У миддлов «в запущенной стадии» или у «фрагментарных синьоров» часто бывает переизбыток знаний и техник и недостаток их систематизации. Знаешь много, умеешь вроде бы тоже, но каша в голове нарастает и работать ты начинаешь все медленнее и с бОльшим скрипом.

Что делать?

Главное — императивы

Все фреймворки отвечают на несколько «простых» вопросов: Зачем, Кто, Что, Как, Когда. Они же императивы менеджмента.

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

И если у тебя покрыты все эти императивы (макетами, схемами, ответами в голове и пр.) — то задача решена.

Если захочется углубиться в тему — читаем Адизеса (он пишет про менеджмент в целом).

То есть, каждый дизайнерско-продуктово-исследовательский фреймворк отвечает на один или несколько этих императивов. Причем есть нюансы.

Например, Mental Models отвечает на «Кто наши пользователи?». Но не отвечает на «Кто наши стейкхолдеры и как мне с ними работать» — для этого уже нужна Stakeholders map.

В рабочих задачах императивы можно покрывать в плюс-минус любом порядке. В среднем, лучше всего начинать с «Зачем». Но, я часто начинаю с «Кто» (надо же понимать, у кого спрашивать «Зачем»). А еще в начале может прилететь какое-нибудь ТЗ (и это будет уже информация про «Что»).

Погрузимся же в эти Зачем, Кто, Что, Как/Когда — и потом наложим на них продуктоводизайнерско-исследовательские фреймворки.

Рассмотрим каждый императив

1. Зачем. Фильтр для всего, что мы делаем. OKR, цели спринта, метрики и пр.

Этот вопрос/императив помогает понять, куда сейчас бежим, какова ближайшая цель — так легче «прицеливаться» и убирать лишнее.

Вот пример. В моем текущем проекте есть такая задача:

Задача большая, точно нужная и дает много ценности продукту. Ее очень любит наш CEO:) Но! Она относится далеко не к первому шагу воронки. А мы сейчас прорабатываем как раз первый шаг пути пользователя (иначе у нас тупо не будет продаж и команда сдуется через несколько месяцев. Значит, привлечение, первый платеж и первый месяц использования — на первом месте.

И как только это выяснилось (спасибо схемам! Так удалось это донести и аргументировать) — мы перестали говорить об этой задаче, пересобрали состав релиза и гораздо лучше сфокусировались.

А на уровне дизайна — можно пока не прорабатывать много сценариев, в навигации достаточно базово прикинуть, где в будущем будет встроен коммуникатор, и пр.

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

2. Что. Производство

Этот вопрос/императив — про готовый самокат/самолет, который мы вытачиваем в гараже/на заводе и отдаем пользователю.

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

Но если подетальней, то:

Описания фичей,
userflow,
макеты,
интерфейсные тексты,
код и пр.

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

Например, та же автоматизация регистрации юрлиц:

3. Кто. Пользователи, стейкхолдеры, команда и пр.

Этот вопрос/императив помогает понять — чьи мнения/боли/хотелки нам надо учитывать при работе. И как именно.

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

99% ценности от любого фреймворка — это внедрение. Твоя способность дожать до принятия командой, успешного применения и получения ценности. Поэтому очень важно не просто понимать «кто», но и «какие они». Чтобы адптировать подачу.

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

Для системной работы над «кто есть кто внутри нашей команды» имеется отличный инструмент — карта стейкхолдеров. Она показывает, на какие четыре группы стоих разделить всех игроков в проекте, и как с ними работать. Соответственно — лепим карточки с ФИО+должностью, либо сегментом. И действуем соответственно :)

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

Кто заказчики/бизнес/стейкхолдеры?
Кто предметные эксперты?
Кто «соседи»?
Кто будет внедрять у себя результаты нашей работы?
Кто что хочет и кому что нужно?
У кого можно получить какую инфу?
Кто какими ресурсами располагает и какие решения принимает?

Это уже не влезет в карту стейкхолдеров и такое удобней просто в майндмепе.

А про пользователей можно рисовать Empathy map, мандмепы с джобами и прочие штуки.

4. Как/когда. Процессы, подходы, ритуалы, церемонии

Мы ведь в статье говорим про расплывчатые и сложные задачи? Они часто не решаются в лоб. И появляется вопрос/императив про то:

Как ты выполняешь задачу
Как собираешь требования по задаче
Как создаешь для команды прозрачность о том, что у тебя происходит
Какие этапы выделяешь в работе над задачей
И все остальные «как»

Вот например, Scrum и Agile — это очень сильно про «Как». Дейлики, спринты, канбаны-родмапы, шаблоны продуктового описания задач и пр.

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

Но есть нюансы:

Впрыскивать пошагово. «Как» — про системность, про «бюрократию в хорошем смысле». И команда, и бизнес часто ей сопротивляется. Поэтому внедрять надо маленькими, но ежедневными/еженедельными шажочками. На текущем месте я сначала внедрил дейлики (их не было), потом у нас появились релизы, потом начали появляться спринты и пр.
Учитывай особенности команды/ситуацию. Для каких-то изменений и практик ситуация может быть просто не назрела. К примеру, сейчас седьмой месяц моей работы над текущим продуктом. И только сейчас все дозрело, чтобы мы начали внедрять метрики. Раньше и пользователей в нужном объеме не было, и проблемы надо было решать — другие.
Продавай через решение конкретных проблем. Частая болезнь «сферического правильного продуктового дизайнера в вакууме» — продавать подходы и методы под соусом «ну так же правильно». Очень часто это не работает. А вот если начать с проблемы, которая болит и у команды и у бизнеса, и сначала договориться, что ты поищешь решение этой проблемы... То потом придти и рассказать про какой-нибудь Double Diamond — сработает гораздо лучше.
Lege, Meditare, Disputi (повторяй, проверяй, спорь). Это старая греко-римская поговорка про освоение философии, или какого-нибудь ремесла. Подходит и для фреймворков :)

В ней предлагается сначала «взять как есть» и затестить максимально близко к описанному.
И посмотреть как работает, получить первый опыт не в воображении, а в реальности.
Желательно — в тепличных условиях, без дедлайнов и жестких требований к результату (иначе трудно учиться, самонаблюдать и делать выводы).
Потом — честное практическое применение так, чтобы максимально освоить и научиться применять в разных условиях, со стабильным хорошим результатом.
Потом — видоизменять, переделывать под себя, опровергать, декомпозировать и скрещивать с другими подходами. В общем — отталкиваться от и творить новое :)

Ок, и как сюда приложить фреймворки?

Ок, допустим, с императивами понятно. Нам нужно собрать-выполнить «Зачем-Кто-Что-Как-Когда» и задачка решится. Куда бежать? Что делать?

С этим я вернусь позже. Итак которую неделю посвящаю завтраки этой статье, пора выпускаться :)

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

Из синьора в лиды — цель, задачи, планирование

2022-05-26T16:38:10.930Z

Привет-привет! У меня в менторинге есть ребята от мидлов до лидов. И один ученик как раз сейчас хочет:

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

Расскажу, как мы это делаем:)

Текущий уровень ученика и его окружение

Поймем отправную точку. Ученик — крепкий синьор, с опытом менеджмента 2-3 дизайнеров (но больше в разрезе "помочь работать круче", чем в разрезе "за полгода вырастить из них мидлов").

Он уже в большой продуктовой команде, и команда планирует расти. Роль лида — есть и ее можно получить.

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

Чего хочется и в чем проблема

Хочется в лиды, но как туда попасть, кто такой "крутой лид" и пр. — непонятно.

Что делать?

Выявить ВКУСНУЮ цель на полгода — которая именно тянет и зажигает. Зачем лидом, почему лидом, что значит лидом, что в этом хорошего? Про эту цель надо будет вспоминать, когда будет хотеться все бросить.
Описать месяц — в измеримых и вкусных результатах.
Сформулировать артефакты, которые помогут работать над целями месяца. Например:

В каком беклоге хранить задачки по превращению в дизайн лида?
Куда записывать кандидатов в будущую команду, которым пока можно просто предлагать какие-то совместные активности в духе "давайте замутим вот такой митап?" или "давай вместе сделаем вот такую штуку для дизайн-системы?"
Где описывать "досье" на стейкхолдеров?
И пр.

Выделить простые десятиминутные первые шаги.
Сделать их :)
Фигачить дальше :)

1. Выявляем цель и описываем полгода.

"Хочу стать лидом в команде чтобы решать глобальные задачи. Набрать какую-то команду, обучить. Проявить себя как лидера, взять небольшой кусок ответсвенности и горизонтально расширять."

Мы продолжили детализировать цель и у нас нарисовалась вот такая схема:

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

Итого, за полгода ученик хочет:

Повышение зп.
Получить свою продуктовую команду (от 3 до 5 дизайнеров).
Нанять как минимум одного дизайнера, который будет в чем-то сильно круче моего ученика.
Вырастить дизайнера из джуна в мидла.
Создать и внедрить полезные ритуалы, так-то улучшить процессы и пр.

Как это получить?

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

Подумали с учеником, и стало понятно, что для "работы с головами" есть куча инструментов:

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

Замечательно, но конкретно делать то что? :)

2. Описываем месяц — активности и пр.

Подружиться с Head of Design, узнать как он видит лида.

У компании уже есть какое-то описание лида, его обязанностей и скиллов и какой-то процессроста до этого самого лида :) Это стоит изучить и применить.

Хороший план на месяц — расспросить, узнать требования к лиду и возможности/процесс роста до него. И договориться, что ты будешь:

"грести" в ту сторону
рассказывать Head of Design о том, что получается
просить помощи и задавать вопросы

Ну и — сделать 1-3 вброса про твои достижения

Плюс — рассказаное Head of Design может наложить коррективы на все последующие пункты :)

Поговорить с текущими дизайн-лидами, понять, как с ними дружить

Кто-то из них может стать советчиком и наставником, с кого-то просто можно "снять модель", кто-то сможет в будущем похвалить тебя перед Head of Design, а от кого-то надо скрывать твои планы :)

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

Познакомиться с технической командой и менеджментом.

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

Хороший план на месяц — заработать 3-5 "спасибо, ты очень помог, хорошо что ты с нами".

Провести столько-то мелких экспериментов с "низковисящими фруктами".

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

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

Хороший план на месяц — найти и закрыть 5-6 таких болей.

Начать вести за собой людей.

Ты собираешься стать лидом и тебя уже окружают какие-то люди. Необязательно ждать момента, когда тебе скажут "Вот корона, командуй" :)

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

Хороший план на месяц — сделать десяток вбросов:

сессия парного дизайна
коллективные нерабочие встречи
онлайн-митап по аналитике
совместные просмотры лекций / конференций
коллективный спорт
и пр.

И дальше посмотреть какой был отклик. Что люди сделали в ответ на твой призыв? С кем у тебя лучше всего получилось договориться, кто дал самый большой результат? С кем не получилось? Почему? Как починить?

3. Формулируем артефакты

Хорошо, если все ключевые активности "приземляются" на какие-нибудь доки, таблички, схемы, фреймворки, еще что-то.

Это поможет "собрать мозги в кучу", когда цель будет теряться (а такое происходит с любой большой целью)

В нашем случае это:

Бэклог с:

Болями и проблемами команды и низковисящими фруктами.
Экспериментами "побежали вместе туда-то?".

"Досье" на важных людей в команде.
Матрица компетенций лида.
CJM - понять архитектуру продукта, как устроена экосистема.

4. Десятиминутные ближайшие шаги

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

В нашем конкретном случае ученик выбрал пойти общаться с Head of design, продактами и пр. Но это — уже в следующей статье :)

Как ученик оценил наш созвон:

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

Хотите в лиды — идите в менторинг

Хочется стать классным лидом классного продукта? Можно придти ко мне в индивидуальный менторинг

Мой телеграм (написать в личку)

Или можно почитать мой телеграм-канал и посмотреть Youtube

Собеседование джуниор UX/UI-дизайнера. Как проводить и как проходить :)

2022-04-20T17:08:53.595Z

В совместном с Product University курсе по UX/UI Мы с Глебом Долговым (Design Lead в Altium) подробно поговорили о том, как устроено собеседование джуна в UX/UI продуктовом дизайне.

На прошлом месте работы Глеб вырастил отдел дизайнеров с 9 до 25 человек. Он нанимает на все позиции, от джунов до синьоров.

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

Кто предпочитает читать — держите саммари :)

Что нужно понять про кандидата:

Насколько он будет гореть той задачей, на которую пришел (интерес к задаче и компании)
Батарейка — как долго он может пахать и преодолевать себя;
Готов ли начинать с низов и делать рутинные задачи;
Обучаемость и гибкость (пластилин);
Химия (если с человеком неприятно общаться — работа не сложится);
Умеет ли взаимодействовать с командой (общительность);
Как он хочет развиваться дальше (чем больше наши задачи совпадают с тем, что драйвит и штырит кандидата — тем больше сил он вложит в работу);
Баланс самостоятельности и вопросов;
Хард-скиллы;
Портфолио.

1. Интерес человека к задаче и компании

Важно видеть, что дизайнер понимает куда он пришел. Глеб работает над сложным веб-сервисом и будет странно, если кандидат скажет “хочу у вас делать мобильные приложения”.

Можно спросить “а ты смотрел чем мы занимаемся?”. Если человек зашел на сайт и посмотрел все про них, это идеальный вариант.

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

2. Батарейка

Легко понять после тестового. Если человек сделал даже больше чем нужно и готов сделать еще, это всегда супер (для джуна!).

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

Классно если в портфолио у джуна есть работы, показывающие рутину (пак иконок, лендинги и экраны).

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

Что делать кандидату: качать батарейку (сон, спорт, еда, эмоциональный интеллект и пр.), применять как написано выше, рассказывать на собеседованиях, в CV, в портфолио :)

3. Рутина и низы

Нужно понять готов ли человек долго делать рутину. Но не все по факту тащат. Поэтому важно спрашивать что именно делал человек руками, как долго.

Что делать кандидату: вспомни кейсы, где тобой было "заборото" очень много рутины (даже если это было не в дизайне). Напиши в CV "умею справлятся с большим объемом рутинных задач, например вовремя работы на заводе сделал тысячу шаблонных договорв".

4. Пластилин и обучаемость

Расспрашивать какие курсы проходил, что это дало, какую проблему хотел решить. Как добывал информацию, какие статьи читает.

Самое главное, что он обучаемый и готов перестраиваться, его можно направлять.

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

И после посмотреть, будет ли он исправлять или забьет — насколько он слышит критику, принимает ее, просит ли сам обратную связь.

Что делать кандидату: почитать "No rools rule" и другие книги про работу с фидбеком. Получить и хорошо обработать десять фидбеков. Рассказать об этом в резюме. Попросить фидбек на тестовое. Обработать его и показать / рассказать про результат.

5. Химия с человеком

Насколько кандидат кофморетен в общении. Если лиду или команде, будет неприятно общаться (или кандидату — с лидом и командой), то ничего не получится.

Химию не так легко создать (и про это есть отдельные книги), но легко испортить — прийти пьяным, невыспавшимся, на нервах и т.п.

Например, у Глеба кандидат на собесе начал курить вейп.

6. Общительность

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

На одном интервью Глеба кандидат начал петь. “А давайте спою часть песни, которая будет описывать баннер”.

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

7. Как хочет развиваться дальше

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

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

8. Баланс самостоятельности и вопросов

Плохо, когда джун мгновенно прибегает с вопросами, ответы на которые легко нагуглить (или придумать).

Плохо, когда джун заходит в тупик и не приходит с вопросами.

Нужен баланс :)

9. Хард-скиллы

Фигма (UI, стили-компоненты и пр.), общее понимание того, что происходит в цифровых продуктах.А дальше — зависит от компании. Где-то нужно уметь в гипотезы, где-то — рисовать фирстиль.

10. Портфолио

Как UX-дизайнеру НЕ рисовать CJM

2021-08-02T07:52:42.913Z

Привет-привет! В вакансиях продуктовых дизайнеров часто есть требование "уметь рисовать CJM". Соответственно, меня часто просят научить его рисовать :)

Как показывает практика, для UX/UI-дизайна CJM скорее поглотитель времени, чем хороший инструмент. Да, для маркетинга, для управления продуктом он отлично работает. Для UX/UI-дизайна — не очень.

В этой статье разберемся, почему так, а в следующей — поймем как получить "CJM здорового человека"

Чем не хорош классический CJM

Да всем хорош:) В тех задачах, для которых он предназначен

Для чего нужен классический CJM?

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

И вот тут возникают вопросы:

Насколько это близко к обычной работе дизайнера, который не дизайн-директор, не продакт и не со/основатель?
Работает ли такой CJM, если его строить из головы?

Итого — дизайнеру-то CJM зачем?

Классический CJM — обжора

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

Actions — поговорить с кем-то, кто хорошо знает продукт. Скорее всего — собрать количественные данные, чтобы померить, что пользователи делают, а что нет
Moods — скорее всего, много интервью, и с пользователями, и с саппортом/сейлзами, и пр.
Touchpoints — для первого приближения достаточно просто поговорить с тем, кто хорошо знает продукт. Для глубокого понимания (звонят по телефону — а сколько раз? Как дозваниваются? И пр.) — снова много говорить с людьми и собирать данные
Pain points — количественные данные (где пользователи отваливаются и бросают наш продукт, где совершают ошибки), возможно юзтесты (почему это происходит, что конкретно неудобно и непонятно пользователям), возможно интервью (что это значит для жизни пользователя)

Серьезно? Мне дали нарисовать фичу и я пойду все это собирать?

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

Да, исключения бывают

Вот хороший кейс от Risiandi Jiang (из которого я как раз взял скриншот CJM) http://workonux.com/project/perx-loyalty-reward-app

Там применяется как раз классический CJM и ребята сделали хорошую работу. Но на один такой хороший случай я знаю очень много плохих, где классический CJM просто запутал дизайнера и команду:)

Зачем тогда CJM пишут в вакансиях?

Чаще всего я видел вот такие причины:

Просто копипаста, "все пишут и мы напишем".
Хотят, чтобы дизайнер понимал бизнес, мог как-то изобразить жизненный цикл пользователя и его проблемные места. И считают, что CJM — показатель наличия этого скилла.
CJM действительно "умеют готовить" и работа над ним правда встроена в процесс (редкий случай)

Что с этим делать? Для первого случая достаточно рисовать CJM из головы (то есть не проводя исследований), но точно по шаблону. Скорее всего, использовать его по-настоящему не потребуется.

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

вместо "каких придется шагов" можно использовать AARRR-воронку или что-то подобное
вместо слоев с настроением и эмоциями пользователя, барьерами (которые не так просто выяснить) и пр — поставить например бизнес-задачи и сценарии/экраны/фичи. Будет намного проще и полезней

А в третьем случае можно вообще не уметь работать с CJM. Для данного работодателя это может быть даже плюс:) (иногда легче научить с нуля, чем переучивать)

И что мне с этим делать?

Допустим, мы договорились, что рисовать барьеры-эмоции-пейнпоинты в CJM из головы — зло. Но делать-то с этим что? Как учиться CJM? Какие схемы и когда предлагать вместо CJM?

В принципе, мы уже разобрали несколько вариантов выше. Докину еще.

Если хочется просто соответствовать копипаста-вакансиям (не вижу в этом ничего плохого кстати) — гуглим CJM в яндекс-картинках и рисуем по найденным шаблонам для первых попавшихся 10-15 продуктов. Ты на "стороне зла, но зато есть галочка в резюме"
Если хочется по-честному в CJM — сначала выполняем п. 1, потом учимся UX Research, и собираем нужные данные. Плюс беремся за задачи, в которым мы хотим по настоящему что-то улучшить в бизнесе, дать ему и пользователям ценность. 2-3 проваленных задачи, 1-2 успешных — и ты уже выше "копипаста-вакансий"
Если нужно больше показать продукт, чем пользовательский опыт — учимся рисовать Service Blueprint, он подойдет больше, чем CJM
Если речь не о целом продукте, а об отдельных фичах — учимся рисовать userflow/taskflow/screenflow
Если речь о сложном взаимодействии пользователя с какой-то системой, где много развесистых сценариев — диаграмма юзкейсов и описание этих самых юзкейсов (про написание юзкейсов есть хорошая книга, А.Коберн "Современные методы описания функциональных требований к системам")
Если нужно показать разработчикам, что есть в системе — screenflow плюс карта сущностей. Юзкейсам они тоже будут рады
Если надо самому разобраться в сложной предметной области и другим объяснить — concept map

Хочется освоить схемы?

Я веду индивидуальный менторинг, партнерюсь с интересными продуктами, и с удовольствием отвечаю на вопросы.

Мой телеграм (написать в личку)

И мой телеграм-канал

И Youtube

Интервью с Замесиным

2021-07-30T06:42:59.348Z

Привет-привет! 16 июля мы пообщались с Ваней Замесиным (известный предприниматель и продакт, автор https://t.me/zamesin) про его вакансию продуктового лид-дизайнера.

Разговор вышел супер-интересным, но с хреновой записью :)

Запись можно посмотреть здесь (плохой звук и только 15 минут)

Что мы смогли вытащить:

... тут не было записи :(

Кто-то:
на какой период ориентируетесь по привлечению следующего раунда инвестиций или получения продаж?

Замесин:
Денег хватит до следующего апреля. Планируем что к этому времени набрать 150-200 постоянных пользователей.

Кто-то: сколько средний чек?

Замесин:
20 или 30$ по подписке. Задача найти сегмент, где важна высокочастотная работа с разными часовыми поясами.

Немаленькие деньги, но SuperHuman показал, что люди готовы платить такие деньги. Сам пользуюсь и счастлив.

Ваня:
Перейдем к вакансии. Кого и с какими суперсилами ты ищешь?

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

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

По всему миру около 150-300 млн человек пользуются календарем постоянно и тратят время неэффективно, особенно в больших компаниях.

Челлендж в том, чтобы не просто перерисовать календарь, а найти новое решение примерно для 200 сценариев и соединить их в одно решение.

Ваня:
В рамках своей работы ты встречал людей, которые решают подобные задачи?

Замесин:
Таких дизайнеров я встречал довольно мало. Почему я говорил про психов - нужно дотошное внимание и хороший уровень скиллов.

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

Ваня:
Так как это довольной редкий дизайнер, может искать их через хакатоны, большие воронки найма?

Замесин:
Не думаю что это должен быть прям супервысокий уровень. Супервысокий — это человек, который уже нашел себя, скорее всего он уже сооснователь в каком-то продукте, у него все хорошо. Таких сложно схантить.

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

Ваня:
С кем он будет решать эту задачу, взаимодействовать?

Замесин:
Со мной, я продуктовая голова, вместе мы будем решать что именно делать.

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

И так как мы выходим на рынок, где есть большие игроки, человек должен принимать инженерные решения типа “как я могу решить задачу человека или не увеличивая complexity или увеличивая на минимальную величину”

Ваня:
Можешь привести такой пример?

Замесин:

Если дизайнер приходит и говорит “а давайте поставим сюда выбор эмодзи”. Значит, должен быть каталог эмодзи, он может пополняться, у нас есть macOS, Android, Web, IOS, на каждой платформе свои эмодзи в разных состояниях. Добавление эмодзи увеличило complexity в два раза. И двадцать билдов будут ломаться, потому что в эмодзи что-то сломалось и мы их пересобираем.

Ваня:
Ага, понятно. А как человек будет взаимодействовать с тобой?

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

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

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

Делаем 1-4 итерации юзтестов, делаем прототип в билде, даем тестерам, дальше “ой фак, забыли про 5 сценариев”, параллельно пишется код и уже делаем чистовую версию

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

Давай о перспективах? Например, продукт закрыли, что останется у дизайнера? И что будет, если продукт выстрелит?

Замесин:
Если не выстрелит... Даже если коммерческий стартап умирает, то ты получаешь опыт создания супер крутого инженерного продукта.

Мы ведь хотим сделать "автомат Калашникова" — инструмент, который перевернет парадигму взаимодействия с календарем (кстати автомат Калашникова — отличный пример дизайна и инженерии).

Если выстрелит — масштабируются задачи, выход на международный рынок, отсутствие проблем с востребованностью на рынке лет на 10-15, и, конечно, деньги выше рынка и опцион

Что еще я запомнил и на что обратил внимание:

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

Главные ошибки в продукте — это ошибки со стратегией. После них идут ошибки хайринга
Давать большое тестовое — чтобы брать только ребят со очень высоким уровнем мотивации
Очень важен уровень энергии кандидата. Проверяется очень просто:) Если ты "подзарядился" после собеседования — все круто. Если же кандидат тебя вымотал — с энергией фигово и лучше отказывать даже если скиллы ок.
Обязательно тестовый день и тестовая неделя. В них можно увидеть кучу стоп-факторов (или наоборот, плюсов), которые не увидишь ни в каком собесе.

Про тестовый день — дается задача, заведомо больше, чем кандидат успеет сделать. Если кандидат просто не сделает — надо прощаться. Если кандидат придет договариваться о том, как пофлексить задачу и сделает это хорошо — act прекрасно, результат отличный. Если сам пофлексит и объяснит почему — троечка/троечка с плюсом.

Аналогичным образом строится тестовая неделя.

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

Перечислю принципы и скажу мысли по каждому:

Start with «Why?»: ты знаешь зачем ты принимаешь каждое решение. Ты знаешь цели компании и как то, что ты делаешь помогает компании достичь эти цели. Ты не согласен(на) делать что-то потому что тебе сказали сделать это.
Что я об этом думаю: офигенный принцип, пользуюсь, учу ему и свои команды и учеников UX Boost. Сначала всегда задаем вопрос "нафига". Он может кардинально поменять ответ на вопрос "как" :)

Customer obsession: ты знаешь потребности клиентов, для которых ты делаешь продукт. И в своих решениях ты исходишь из того, чтобы дать ценность клиентам.
Что я об этом думаю: когда так действительно работает — круто. Но ооочень сложно делать в одиночку, если бизнес от тебя требует просто фичи
Deliver results: ты постоянно ищешь способы быстрее доставить клиенту ценность. Ты не опускаешь руки и не принимаешь загятивающиеся сроки как должное — ты ищешь способ поменять подход, посмотреть на задачу под другим углом, чтобы всё-таки доставить ценность клиенту быстрее.
Что я об этом думаю: тяжело совмещать с высокими стандартами качества. Чтобы то и то одновременно работало, надо или "переключаться между режимами" перфекциониста и жадины во время работы над фичей, или нужно чтобы команда помогала поглядеть под разными углами.
Invent and simplify: ты ищешь новые, неожиданные, хитрые решения для задач, над которыми ты работаешь. При этом, ты ищешь способы сделать решение проще и для клиента и в реализации.
Что я об этом думаю: прикольно, причем не супер сложно. Главное — озадачиться вопросом "а как это можно решить неожиданно и хитро, чтобы стало проще и круче?". Только лично у меня это работает в-основном, когда есть уже какие-то наброски, какое то уже придуманное решение.
Tame and eliminate complexity: ты знаком(а) с концепцией «сложности» [complexity] и ищешь способы снижать сложность или растить сложность на минимально возможные величины при принятии решений.
Что я об этом думаю: даа, клево. Мы хорошо проговорили про эту штуку с Замесиным, я проникся и стал ее осознанно использовать и насаждать в команде. У нее есть интересный эффект — чем дольше ты борешься с complexity — тем больше в продукте мест, где она максимально снижена, и тем легче с новыми фичами.
Insist on the highest standards: ты принимаешь решения из своих внутренних высоких стандартов качества. Ты предъявляешь высокие требования к решениям и действиям своих коллег.
Что я об этом думаю: утомительная штука, не всегда уместная (но для данного продукта в данный конкретный момент — реально необходимая).
Start-to-finish ownership: ты действуешь так, чтобы результат твоей работы как можно быстрее превратился в ценность для клиента, даже если ты отвечал(а) за небольшие части в процессе, завязанном на других людей.
Что я об этом думаю: если этот принцип внедрен в команду — это сильно увеличивает шансы стартапа выжить и не превратиться в "да мы тоже думали это сделать, еще раньше чем Apple/Google" (но почему-то не сделали и закрылись)
Frugality [бережливость]: ты понимаешь, что ресурсов всегда меньше чем задач и ты достигаешь большего с меньшими ресурсами. Ты специально накладываешь ограничения при принятии решений и ищешь хитрые и неочевидные способы достичь желаемого результата за меньшее время.
Что я об этом думаю: очевидная на словах вещь. Как раз внедряю сейчас в своей команде и вижу, что научить людей (и придерживаться этого самому) — непросто. И еще труднее сделать, чтобы и ресурсы экономились, и "делалось хорошо". Хотя если подумать как следует... убираем и не делаем лишнее = остается больше ресурсов, чтобы сделать реально нужное — хорошо.

Хочется внедрить эти принципы у себя?

Могу помочь:) Я веду индивидуальный менторинг, партнерюсь с интересными продуктами, и с удовольствием отвечаю на вопросы.

Мой телеграм (написать в личку)

И мой телеграм-канал

И Youtube

Качаем UI во время standup

2021-07-02T07:07:44.360Z

"Делал вот это, буду делать вон то, не заблокирован" — утренняя мантра IT-команд. Обычно ей все и заканчивается на стендапах. Можно ли использовать это время лучше?

У меня был интересный опыт на эту тему с моей дизайн-командой в Connect club.

Делать, не только говорить

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

У нас была грязь в макетах, хотелось:

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

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

Что делать? Нужны упражнения.

Зарядка для правильных привычек

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

Что делать? Наработать нужные привычки и сразу автоматом делать так, чтобы не переделывать.

Звучит хорошо, но лень и некогда. Что делать?

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

Встречайте — standup-workout

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

Нарисовать фрейм со скруглением углов и автолейаутом,
вставить в него надпись, по центру, выставив паддинги.
Задать ферйму заливку из дизайн-системы.
Задать тексту заливку и стиль из дизайн-системы.

Повторить 15 раз.

И всё. Простые и тупые упражнения хорошо работают.

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

Хотите использовать фреймы вместо групп — создайте 50-60 фреймов, чтобы пальцы привыкли.

Хотите перестать думать о кнопках — научите руки нажимать кнопки правильно.

Как это выглядело

День первый:

Мы придумали четкий алгоритм, по которому надо было идти
Каждый дизайнер сделал по нему 5 "кнопок"

День второй:

Каждый придумал более клевый, простой и быстрый алгоритм, мы попробовали их все

День третий-пятый и далее:

Мы дошлифовали алгоритм, обучили руки, стали делать фреймы очень быстро и на автомате

Что дал нам этот воркаут

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

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

Мы пошли дальше улучшать наш стендап. И для начала — сделали всю "отчетную часть" письменной.

Утром перед стендапом каждый пишет:

Какие есть вопросы (если есть)
Какие макеты хочет показать (если хочет)
Что делалось (надо бы писать что СДЕЛАНО, но пока это не внедрили)
Что будет делаться

Вот скриншотик с примером:

Что нам это дало:

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

Подписываемся и лайкаем :)

Я веду индивидуальный менторинг, партнерюсь с интересными продуктами, и с удовольствием отвечаю на вопросы.

Мой телеграм (написать в личку)

И мой телеграм-канал

И Youtube

Привет, Железяка! Управление хардварным продуктом

2021-06-29T07:35:58.467Z

Гостевой пост от Саши Кузовлева, моего давнего знакомого

Саша Руководил в качестве PM, CTO, BA/SA в нескольких хардварных стартапах, связанных с разработкой сложных систем и продуктов с уклоном в В2В. Ведет телеграм-канал “На шаг впереди”

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

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

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

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

Да, это те самые предметы, которыми мы пользуемся в ежедневно или время от времени: кофемашины, смартфоны и ноутбуки, роботы-пылесосы и разные другие полезные гаджеты.

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

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

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

Окунаемся в предметную область. Что в ней особенного?

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

Человеку со стороны не всегда понятно...

чем электроника отличается от микроэлектроники?
Откуда тут берутся куча разных сложных аббревиатур и что они обозначают?
Что это за всякие разные региональные, международные стандарты и что за ними на самом деле стоит?
Какие есть глобальные и региональные регуляторы и что они регулируют?

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

Совсем другое дело, столкнуться с серьезными вызовами, которые могут завести план, казалось бы, идеального продуктового развития в тупик.

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

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

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

Другое непонимание может возникнуть от незнания всей длиннющей цепочки технологических процессов для производства продукта.

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

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

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

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

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

Долгосрочный Roadmap и стратегия продукта

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

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

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

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

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

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

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

Подходы к прототипированию продукта

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

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

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

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

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

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

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

В некоторых случаях вполне реально сделать MVP с помощью отладочных комплектов и напечатанного корпуса за месяц-другой. Только так можно дать пощупать прототипы потенциальных пользователям. Однако циклы реального серийного производства сократились совсем не так существенно.

Продуктовая аналитика. Как собирать фидбэк и данные о UX?

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

Однако не все продукты являются умными кофеварками. Ещё очень много продуктов ограничиваются просто локальными логами внутри себя.

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

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

Особенности Unit-экономики

Юнит экономика очень сильно зависит от серийности выпуска любых железяк. Чем больше товара будет произведено, тем эффективней можно оптимизировать производство, и тем ниже выйдет себестоимость. Зависимость же при этом крайне нелинейная. Кроме того, она еще имеет и ступеньки при смене одних технологий или даже производств на другие.

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

Соответственно, всегда имеем проблемы с прогнозами. Ошибки могут привести к потерям. Просто на складе будет лежать невостребованная продукция. Или, наоборот, в какой-то момент пойдут продажи и бизнес потребует резко нарастить мощности.

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

Из-за длительных циклов продуктовую экономику часто приходится считать не в месячном масштабе, а в квартальном или даже годовом. Приходится учитывать внутреннюю норму доходности, да и про дисконтирование денежных потоков при больших задержках между вложениями в RnD и периодом максимальных продаж забывать не стоит. Стоимость денег у нас не нулевая.

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

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

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

Обычно на рынке при этом совсем немного вендоров, которые друг друга хорошо знают и работают в узких нишах. Это придает специфики Unit-экономике таких продуктов.

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

Часто продукт может быть комплексным и иметь целую систему дополняющих продуктов или даже экосистему. К такой модели стремятся многие вендоры в настоящий момент.

Работа с заинтересованными сторонами

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

Вместе с тем доля B2B и B2G продуктов в общей массе пока превалирует. И по всей видимости это соотношение пока сохранится.

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

Мало того, в решении о закупке задействованы ещё и различные лица влияющие на решение (ЛВР). Это могут быть менеджеры из экономического блока, отвечающего за закупки, или технические руководители, если подразумевается высокоуровневая интеграция, или отвечающие за эксплуатацию.

И всех участников желательно выявить еще на ранних этапах и иметь хотя бы приблизительное представление об их существовании. Стоит учесть их требования и понять какие решения и на основании каких критериев они будут делать.

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

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

Модели рисков

Что нужно знать продакту, чтобы эффективно управлять рисками? Жизненный цикл продукта, включающий железяки, увязан с процессами производства. Поэтому общий перечень рисков часто можно позаимствовать из проектного управления.Там можно найти, например, такие артефакты как цепочки поставок.

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

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

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

Еще одна проблема состоит в особенностях передачи железяки в продакшн. Аппаратная часть ведь поставляется физически. Что если в каком-нибудь блоке управления легковым автомобилем закрадется существенная ошибка ПО? Машина как правило не подключена к «облаку» для устранения проблем удаленно.

Такие случаи реально происходили и не раз. Чтобы «выкатить релиз в продакшн» приходилось отзывать сотни тысяч машин в сервисные центры для обновления ПО техником вручную. Степень влияния таких рисков может быть очень велика не только на отдельный продукт, но и на бренд компании.

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

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

Подытожим. Скилы продакта и откуда такие продакты берутся

Продакт менеджер в продуктах на стыке железа и программного обеспечения чаще всего является ориентированными в сторону Technical Product Manager (TPM) и Product Owner (PO).

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

Поскольку невозможно ожидать закрытия всех видов активностей одним человеком, маркетинговые и бизнес-активности часто передаются из его зоны ответственности другим специалистам: маркетологам, Business Development Manager (BDM) и другим.

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

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

В отечественных реалиях продакту вероятно придется уметь работать по всем трем типам взаимодействия бизнеса: B2C, B2B и B2G. Это в свою очередь подразумевает хорошую прокачку софт скилов.

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

Гостевой пост от Саши Кузовлева.

Саша Руководил в качестве PM, CTO, BA/SA в нескольких хардварных стартапах, связанных с разработкой сложных систем и продуктов с уклоном в В2В. Ведет телеграм-канал “На шаг впереди”

CV на лид-дизайнера/продакта

2021-06-15T15:30:16.375Z

Привет-привет! Продолжение прошлой статьи про мое трудоустройство. Сегодня разберем CV, которое я использовал

Что есть в моем CV:

Введение. Кто я, чего ищу, контакты
Ключевые достижения как продакта
Суперсилы и ресурсы
Кейсы продактовские (включая немного фейлов)
Кейсы дизайнерские (включая немного фейлов)
Call to action

Почему CV именно такое?

Оно достаточно длинное, написано живым языком. Я специально не делал формальное перечисление мест-достижений.

Оно хорошо отфильтровывает тех, кто мне не подходит. Человек со слишком формальным мышлением увидит что "CV не по ГОСТ" и уйдет.

Как вписывается в мое общение с работодателями?

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

Итого — читают, хорошо общаются, переключаются на прикольный для меня стиль взаимодействия.

Кого и зачем отталкивает мое CV?

Почему мне вообще нужно кого-то отфильтровывать? Почему не лучше, когда пишут все?

Я не хочу работать там, где смотрят исключительно на "proven track records". Есть довольно четкое понимание, куда не хочется и куда хочется.

При этом, чтобы попасть куда хочется — на senior-lead уровне надо хорошо поднапрячься (если ты ищешь действительно челлендж и рост, а не идешь в команду, которая "младше" тебя). Трудно каждый раз "хорошо поднапрягаться", если у тебя 30 собеседований и 15 тестовых. Я буду выжигать себя на много пустых разговоров, будет мало сил.

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

Итого — поймите свою специализацию и особенности — и отталкивайте тех, кто вам не подходит. И привлекайте, тех, кто офигенно подходит.

Копирайтинг и инфостиль

Короткие предложения, текст "отжат" от лишних слов и сложных формлировок

Маркированные списки разнообразят текст и облегчают чтение

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

Цифры, конкретика, инфостиль

Картиночки разообразят текст

Кейсы подобраны разные, покрывают все мои ключевые суперсилы

Не переключайтесь :)

В следующих статьях расскажу про общение с несколькими компаниями:

Miro — еще весной 2020 мне написали и предложили пообщаться. Поговорили хорошо, но тогда я был с головой в бизнесе и не было ресурса даже на тестовое. В конце 202 мы попробовали снова и то было интересно.
Продукты из EDTech — несколько топ-школ для digital-профессий. Собеседовался на менеджерские позиции (руководитель направления, комдир и пр.). Где-то не потянул, где-то слишком долгий цикл найма.
Social Ventures — дейтинговое мобильное приложение. Собеседовался на дизайн-лида. Было очень интересно делать тестовое, отлично размялся и убедился, что все еще могу в UI. Но в общении не сложилась "химия".
Продуктовый ритейл (компанию назвать не могу) — продакт двух мобильных приложений и веб-витрины. Интересно, но не договорились по деньгам.
Ecommerce-гигант — дизайн-директор 42 дизайнеров. Очень растянутый процесс найма, но общаться было интересно. Затягивалось, и я пошел в другое место.
Mercaux — софт для онлайн-розницы и оффлайновых магазинов. Планшет, развитая дизайн-система. 400. Очень понравились, выбирал из них и следующих. Но до сих пор дружим и помог им найти дизайнера.
Connect club — стартап, мобильное приложение, клуб интересных людей. Собеседовался на дизайн-лида, по факту стал еще много кем. Сюда пошел работать и влюбился и в продукт и в команду

Подписываемся и лайкаем :)

Я веду индивидуальный менторинг, партнерюсь с интересными продуктами, и с удовольствием отвечаю на вопросы.

Мой телеграм (написать в личку)

И мой телеграм-канал

И Youtube

Как попасть на зарубежный remote с требованием 5 лет опыта, если у тебя стаж 1-2 года?

2021-06-10T16:56:09.522Z

У меня уже зреет обещанное продолжение прошлой статьи. Надеюсь скоро выпустить, а пока — давайте про вакансии на зарубежном рынке.

Я подсобрал с десяток удаленных вакансий в продуктовом дизайне, с зп от $100-120K/year.

Давайте возьмем любую и посмотрим, что там хотят от дизайнеров и как это изучить?

Итак, пять лет опыта, а у тебя полтора-два, или даже год

Также требуется остальной джентльменский набор:

Навыки коммуникации (письменной и устной)
Пилить концепты
UCD и прочая база
Эмпатия
Базовое знание разработки
UX Research
Брендинг и маркетинг

На каких-то вакансиях будет больше перекоса в метрики и a/b тесты, в других — опыт с мобилками, где-то — основы системного анализа и опыт работы со сложными развесистыми сценариями.

Если ты совсем новичок и только входишь в профессию — на такие вакансии действительно рановато.

Но вот если уже есть год-два опыта... (пусть даже в веб-дизайне чего-то сложного, не лендингов), и ты базово умеешь рисовать интерфейсы — то сможешь примерно за год добежать до и может даже устроиться.

Но этот год будет действительно трудным:)

Какой у нас план?

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

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

Часов 10 в неделю с головой хватит, при условии (!), что:

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

Что конкретно делать?

Как "правильно готовить" свой дополнительный слот:

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

Гуглишь, ищешь кейс-стади и примеры таких навыков, на английском (будет доп практика)
Находишь ментора, который ими владеет и может хорошо проконсультировать, показать примеры и пр. Добиваешься, чтобы у тебя было хороший документ с описанием конкретных примеров применения каждого навыка, включая софт
В идеальном мире — с ментором проделываешь все на английском

Делаешь первый кейс, пет-продукт, где увязываешь в единый процесс все недостающие навыки. Вкладываешь в него 3-4 месяца (пример от учеников раз, пример два, три).
Можно сходить с этим к нам в индивидуальный менторинг :)
Дальше делаешь по кейсу каждый месяц-полтора. Сфокусированных на 1-2 недостающем навыке
То есть не все пихаешь в один кейс, а выбираешь:

"так, в этот раз я покачаю UX Research и высокоуровневое проектирование.
На каких активностях это сделать? Можно провести 5 глубинных интеревью, стркутурировать результаты и сделать storymap с ключевыми участками клиентского опыта.
И сделать userflow самого сключевого сценария".

Все кейсы упаковываешь в кейс-стади (вот наша лекция, как это делать). Тут есть лайфхак — начинай писать дневник про свои обучающие активности. На основе таких материалов выйдет отличный кейс (см примеры выше)

Подробно описываешь что делаешь
Какие вопросы перед тобой встают
Какие трудности
Как ты их преодолеваешь
Какой у тебя план действий
Почему такой
Что у тебя получается
Что от этого получает воображаемый бизнес

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

вариться в английском
рефлексировать и улучшать то, как ты это делаешь

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

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

Правильно заюзать основную работу

В прошлом разделе мы осваивали дополнительный слот. Который вне работы. Создай еще один такой слот внутри работы. Сделай его часов 5-8 в неделю.

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

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

И дальше:

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

Что мне даст такой подход?

Допустим, у тебя получилось отпахать так целый год. Что будет?

Уже 2 года рабочего опыта на основном месте
Несколько хороших свершений на работе
7-8 неплохо описанных кейсов, направленных на все недостающие навыки в вакансии — и которые будут весить как года полтора-два. Итого — вместо двух ты будешь выглядеть на четыре :)
Хорошо подросший английский
Много новых знакомств с HR, лидами, просто зарубежными дизайнерами.
Выросший навык завязывать связи с нужными тебе людьми
Навык "бега на длинные дистанции" — способность сесть и планомерно за год зафигачить очень большой объем дел.
Скорее всего — новая работа 🐶💰🥳

Подписываемся и лайкаем :)

Я веду индивидуальный менторинг, партнерюсь с интересными продуктами, и с удовольствием отвечаю на вопросы.

Мой телеграм (написать в личку)

И мой телеграм-канал

И Youtube

Ваня Серебренников

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А что в итоге?

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

Сложные и размытые задачки — фреймворки, ч.1

Фреймворки — не главное

Без понимания «зачем и в каких случаях», фреймворки работают плохо

Главное — императивы

Рассмотрим каждый императив

1. Зачем. Фильтр для всего, что мы делаем. OKR, цели спринта, метрики и пр.

2. Что. Производство

3. Кто. Пользователи, стейкхолдеры, команда и пр.

4. Как/когда. Процессы, подходы, ритуалы, церемонии

Ок, и как сюда приложить фреймворки?

Из синьора в лиды — цель, задачи, планирование

Текущий уровень ученика и его окружение

Чего хочется и в чем проблема

Что делать?

1. Выявляем цель и описываем полгода.

2. Описываем месяц — активности и пр.

3. Формулируем артефакты

4. Десятиминутные ближайшие шаги

Как ученик оценил наш созвон:

Хотите в лиды — идите в менторинг

Собеседование джуниор UX/UI-дизайнера. Как проводить и как проходить :)

Что нужно понять про кандидата:

1. Интерес человека к задаче и компании

2. Батарейка

3. Рутина и низы

4. Пластилин и обучаемость

5. Химия с человеком

6. Общительность

7. Как хочет развиваться дальше

8. Баланс самостоятельности и вопросов

9. Хард-скиллы

10. Портфолио

Как UX-дизайнеру НЕ рисовать CJM

Чем не хорош классический CJM

Для чего нужен классический CJM?

Классический CJM — обжора

Да, исключения бывают

Зачем тогда CJM пишут в вакансиях?

И что мне с этим делать?

Хочется освоить схемы?

Интервью с Замесиным

Что мы смогли вытащить:

Что еще я запомнил и на что обратил внимание:

Хочется внедрить эти принципы у себя?

Качаем UI во время standup

Делать, не только говорить

Зарядка для правильных привычек

Встречайте — standup-workout

Как это выглядело

Что дал нам этот воркаут

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

Подписываемся и лайкаем :)

Привет, Железяка! Управление хардварным продуктом

Окунаемся в предметную область. Что в ней особенного?

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