Московский: Дизайн & Тимлид

Закрутился и забыл рассказать. Короч, недавно был гостем в подкасте Ozon Design. Тема — «Дилемма тимлида: повысили, и что теперь?» Поговорили честно, без «успешного успеха». Лид — это вообще отдельная профессия, а не «дизайнер, которому докинули людей». Тут заново учишься разговаривать, договариваться, разруливать конфликты. И это нормально, что первое время буксуешь. Ну и про «работать руками» — я же про это уже писал. На записи тоже зашёл разговор, так что тема живая и спорная, мое мнение вы знаете) Если вы сейчас в точке «повысили — и что теперь» — гляньте, должно откликнуться 📱 YouTube 📱 VK Видео

Этот месяц богат на подкасты. На самом деле записали новый подкаст про AI еще месяц назад. Но монтаж и работа заставили выпустить только сейчас. Кстати, впервые этот подкаст мы записывали в реальности и втроем с приглашённым гостем Артёмом из Яндекс 360. Мы также записывали видео, но, к сожалению, видео оказалось без звука, поэтому слушайте аудиоверсию. Оставили самые интересные из часового разговора. 🎵 Яндекс Музыка ✨ Звук 💙 VK Музыка

Дилемма тимлида: повысили, и что теперь? 🗓 Среда, 17 июня 19:00 МСК Принято считать, что повышение до лида — это карьерный рост. Но на деле это полноценная смена профессии. Вчера вы отвечали за свою задачу, сегодня — за результат всей команды. При этом никто заранее не объясняет, как теперь работать и управлять людьми. В новом эфире «Дилемма тимлида» разберём этот переход с теми, кто через это прошёл. Гости: 😎 Виталий Мазуревич — Lead Product Manager в Ozon. Направления: оформление заказа, UGC, геймификация, спецпроекты. 🤓 Дмитрий Московский — Lead Product Designer в Яндексе. Продукты: Трекер, Вики, Формы. На встрече обсудим: — Кто такой тимлид: руководитель или сильный специалист, который ещё работает руками — Как заново выстроить отношения с теми, с кем вчера работали на равных — «Играющий тренер»: рабочая модель или способ сэкономить на менеджере — Как быть строгим и не свалиться в токсичность. Где грань — Коллега метил в лиды, а взяли тебя. Как с ним работать дальше — Первые месяцы в роли: с чего начинать и чего точно не делать, чтобы не потерять авторитет у команды Ведущий встречи: 🌟 Глеб Долгов — ex-Lead Designer группы дизайна внутренней разработки Ozon Tech. Встреча проходит в формате диалога, зрители смогут задавать вопросы в прямом эфире ——— 🗓 Среда, 17 июня 19:00 МСК. Чтобы не пропустить встречу, ставьте напоминание

Сегодня был на подкасте у Глеба, общался с Мазуревичем. Интересно пообщались, подняли проблемы тимлидов. Всегда приятно общаться с опытными коллегами. Выпуск полезный. Будет запись, так что, если не были, сможете посмотреть!

Ищу старшего продуктового дизайнера в команду Яндекс.Трекера Нужен дизайнер, которому интересно разбираться в продукте, задавать неудобные вопросы, понимать бизнес и пользователей, спорить аргументированно и отстаивать хорошие решения. Трекер — один из ключевых B2B-продуктов Яндекса. Сервисом пользуются как внутри компании, так и внешние команды: от небольших стартапов до крупных организаций с тысячами сотрудников. И задач там хватает 🙂 Много сложных сценариев, процессов, системности и мест, где дизайн реально влияет на продукт. Что важно: — опыт в больших продуктовых компаниях от 3 лет; — сильные продуктовые кейсы; — умение презентовать и защищать решения; — зрелая коммуникация и хорошие софт-скиллы; — системное мышление и внимание к деталям. Что у нас: — сильная команда; — много пространства для влияния; — возможность глубоко погружаться в продукт, а не просто «двигать пиксели»; — развитие внутри Яндекса; — работа в Москве или Санкт-Петербурге. Откликайтесь по ссылке Буду благодарен за репост или пересылку знакомым сильным дизайнерам ✌️

Раньше час встречи казался нормой, сейчас 30 минут — предел Когда-то давно я работал как вебстудия: ходил на встречи, программировал и делал «дизайн». Как-то босс одного из сайтов сказал, что встречи больше часа неэффективны. Я не сразу его понял, казалось, что мы только разогнались.. Со временем сам пришел к тому, что час — это потолок для обычных встреч, потом внимание падает. Решил покопаться в исследованиях и вот что узнал: - Уже после 30 минут около 52% людей теряют концентрацию и начинают постепенно выпадать из обсуждения. Часто сам вижу, как на встречах начинают проверять почту или отвечать в чатах. - Стэнфордский университет ввел термин: зум-усталость. Суть в том, что онлайн встречи нагружают сильнее обычных. Мы не двигаемся, плюс постоянно видим себя на экране: мозг перегружается. Продуктивность таких встреч снижается еще быстрее. В идеале я стараюсь уложиться на любой встрече в 30 минут: этого хватает, чтобы обсудить главное и сохранить всем время и силы. Если на встречу нужно больше часа — делаю перерыв. Короч, делайте эффективные встречи — лучше на 30 минут.

Про синдром самозванца Во втором выпуске подкаста про синдром самозванца с Ростиславом пришли к интересным мыслям. Хочу зафиксировать. Синдром самозванца — это ощущение, что ты оказался на своём месте случайно и в любой момент тебя могут «разоблачить». В измеримых профессиях, вроде продаж, всё проще: сделал 30 сделок — молодец, не сделал — понятно, куда расти. В дизайне же границы размыты: кому-то решение понравится, другому — «ну такое». Что с этим делать: 📍Не обесценивать свой результат (спасибо кэп) Звучит банально, но попробуйте принимать обратную связь (ОС) и просить ее у коллег. Если вас хвалят, не отмахивайтесь, что ничего особенного не сделали. Примите это. 📍Фиксировать достижения Ростислав сохраняет ОС и это крутой совет, я так не делал: коллекционируй все места, где похвалили тебя или твою работу. В сложные моменты — смотри на эти сохранения, чтобы стать увереннее в своих решениях. 📍Присваивать знания Например, если проходите курс или читаете о чем-то новом, можно фиксировать информацию в заметках или тетради. Мне это помогает почувствовать, что знания остались в голове, а не просто пролетели мимо. 📍Сравнивать себя с собой Если человек в профессии на 5 лет дольше, неудивительно, что многие вещи он делает круче. Лучше смотри на свой прогресс: что ты сам умел год назад и что умеешь сейчас. 📍Нарабатывать опыт Чем больше задач решаешь, тем увереннее себя чувствуешь и тем лучше результат. Иногда для личностного роста даже полезно взять задачи посложнее — главное, чтобы были выполнимыми. Короч, синдром самозванца — норм, это мы сомневаемся и растем. Вопрос не в том, как его убрать, а в том, как научиться идти с ним рядом.

Редизайн Yandex Cloud На прошлой неделе команда Yandex Cloud показала новый визуальный стиль. И у коллег получилась интересная штука. Они взяли идею конструктора: из простых модулей собираются сложные системы. И этот принцип перенесли в визуальный язык — иллюстрации, паттерны, графика. Получается довольно метафоричная цепочка: сервисы как детали конструктора — большой IT-ландшафт, который из них собирается. Люблю такие идеи, которые делают технологии понятнее для пользователя. Посмотрим, как дальше этот стиль будет жить в разных форматах. Если не видели, вот пост ребят с роликом и примерами И подробная статья про редизайн тут Команде — респект. Выглядит свежо 🔥

Фундаментальная ошибка при подборе аудитории Можно сколько угодно проводить исследования и находить новые фичи для улучшения продукта, но если подбирать респондентов без учета эффекта выжившего — новых пользователей это может и не привлечь. В моей практике был такой случай. Но сначала коротко про эффект выжившего. Это когнитивное искажение: мы делаем выводы, смотря на удачные кейсы, игнорируя тех, кто потерпел неудачу. Во времена Второй Мировой инженеры изучали пробоины на самолетах после боевых заданий — усиливали те места, куда попадали пули. Проблема в том, что это были повреждения, которые самолет может пережить. А надо было изучать урон тех самолетов, которые до базы не добрались. Похожее есть и в продуктах. Какое-то время назад мы спрашивали у активных пользователей, чего им не хватает. Добавляли фичи, улучшали сценарии и т.д. А часть людей продолжала отваливаться после первых попыток освоить продукт. Дело в том, что пользователей продукта найти проще, чем тех, кто воспользовался им и ушёл. Но в какой-то момент мы решили найти и опросить тех, кто отвалился на начальных этапах. Вскрылась неприятная вещь. Один из пользователей сказал: «У вас слишком перегруженный интерфейс, хочется скрыть эти панели. Я ушел к конкуренту, потому что у него проще». Мы и сами предполагали такое, но не фокусировались на проблеме, пока нам так хорошо на нее не указали. Стало понятно, что мы смотрели не туда: улучшали продукт для лояльных, но не думали о погружении новых. Короч, опрашивайте не только пользователей вашего продукта, но и тех, кто не стал им пользоваться. Там могут быть очень важные инсайты, которые увеличат прибыль вашего продукта и/или сделают его более конкурентноспособным.

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

Нами пользуется METRO Недавно увидел новость, что METRO перешел на сервисы Яндекс 360. Обычно я пишу здесь про команду, но не могу не поделиться успехами продукта, над которым мы работаем. Приятно слышать, что на Трекер, Вики и Формы перешёл такой крупный клиент. Да еще и магазин, в котором я периодически бываю. Подробнее в посте.

Еще раз про важность демо В период, когда многие подводят итоги работы, не лишним будет сделать демо вашей команды. Я уже писал ранее про свой опыт и советы. Недавно был на демо соседней команды дизайнеров и смотрел на все со стороны. Напомню детали, которые важно не упускать: 📍На самом деле демо начинается еще до первого экрана. Проговорите вначале: — о чём будете говорить; — что покажете; — и почему это важно. Но со вступлением лучше не затягивать — посвятить этому 5-10 минут будет достаточно. 📍Во время выступления сильнее всего работает живая речь. Когда ты не читаешь со слайда, а разговариваешь с людьми: жестикулируешь, улыбаешься, задаешь вопросы. Это хорошо держит внимание, даже если тема сложная или информации много. ——— Недавно видел у Гоши Путилова подробный чек-лист о том, как правильно проводить дизайн-демо для клиентов и команды. Он дает советы, как настраивать собеседников на нужную волну, производить правильное впечатление и сглаживать углы, если сыпется критика или работой не довольны. Удобно, что есть примеры фраз. Всё собрано в один файл, найти его можно в посте у Гоши. Рекомендую глянуть тем, кто презентует свои проекты. Короч, готовьтесь к демо — это не просто отчёт, а возможность показать, как вы думаете и работаете.

Сначала сильный дизайнер, потом тимлид, не наоборот Когда я еще был в другой команде, случалось так, что получал советы тимлида и ловил себя на мысли: «Эмм… а почему так поверхностно?». Такое бывает у тимлидов, которые проскочили стадию «сильного дизайнера» и сразу стали руководителями. Или у тех, кто даже не был дизайнером: например, сильному менеджеру доверили команду дизайнеров. Причина в том, что у человека нет сильной дизайнерской базы. Он не прошёл через сотни решений, не собрал внутреннюю библиотеку интерфейсов. А такая библиотека приходит не с должностью, а с насмотренностью и самостоятельной работой. Отсюда и последствия: — Советы для дизайн команды поверхностные; — Нет насмотренности, трендов, направления; — Появляется риск микроменеджмента, потому что «так спокойнее»; — И самое важное — непонимание тех проблем, через которые проходит дизайнер каждый день. При этом тимлид не из дизайна — абсолютно нормальная история. У такого руководителя много плюсов: — Не тонет в текучке, не уходит делать все своими руками; — Аккуратно выстраивает процессы и работает с людьми; — Держит фокус на документации, систематизации. Но есть одна штука, которую этим плюсам сложно заменить — умение оперативно подхватить задачу. Когда уволился дизайнер или задача горит — от тимлида ждут, что он заменит. Компании выгодно, чтобы у руководителя была дизайнерская база. По моему опыту, самые сильные тимлиды — это те, кто успел «пожить» дизайнерской жизнью. Попробовал, ошибся, разобрался, собрал свою внутреннюю библиотеку интерфейсов. Такой человек может и процессы наладить, и в макет нырнуть, и объяснить, почему так лучше с точки зрения знаний и опыта. Короч, тимлид не из дизайна — это нормально, если надо навести порядок в процессах. Но если важен сильный дизайн, подойдет человек с большим дизайнерским прошлым.

Московский: Дизайн & Тимлид pinned a photo

Записали первый выпуск подкаста про фидбэк Мы с Ростиславом наконец-то записали первый выпуск подкаста «Кофе с тимлидами». Это пилот — слегка волнительно, немного сыро, но, надеюсь, полезно. Общались без лишней воды и по делу. Поговорили про фидбэк: как его давать, не портя отношения, и как самому его принимать без защиты и обид. Делимся личным опытом и реальными ситуациями с работы. Если интересна тема фидбэка, развития команды и непростых рабочих разговоров — советую послушать. Слушать на Яндекс Музыке

Мемы в интерфейсе Недавно мне выскочило такое окошко. Окак. Вроде и смешно, но больше вопросов. Мемы в интерфейсе — неоднозначная штука. В ленте соцсетей они выглядят органично: увидел прикол, улыбнулся, пролистнул и через пару минут забыл. Но интерфейс — это другое. Тут шутки за пару месяцев устаревают и быстро начинают бесить. Как и этот окак. Есть ещё история с аудиторией. Если возраст, опыт и контекст пользователей очень разные — половина просто не поймёт, что это было. Интерфейс всё-таки делается для людей, а не ради того, чтобы команде было смешно. Хотя плюс у такого юмора всё же есть: он вызывает эмоцию. А эмоция лучше, чем полное безразличие. Но только если она не мешает понять, что вообще происходит на экране. Но больше всего меня смутил сам текст окошка: он интуитивно не понятен. Говорится, что появилась темная тема, но ни заголовок, ни первое предложение вообще на это не намекают. Потратил пару секунд, чтобы разобраться, что от меня хотят. И в этот момент мысль была простая: а стоит ли мем того, если из-за него теряется смысл? Мне кажется, что нет. А вы как думаете — юмор в интерфейсе помогает или всё же чаще мешает?

Тимлид должен работать руками Кто-то считает, что тимлид не должен работать руками: он строит процессы, управляет командой, фидбечит макеты других дизайнеров. Я с этим не согласен. Да, тимлид отвечает за процессы, коммуникацию со смежниками, согласования, мотивацию команды. Но быть сильным дизайнером «когда-то в прошлом» недостаточно — нужно работать руками, чтобы не потерять навык. Интерфейсы постоянно меняются, старые паттерны устаревают, появляются новые. В этом нужно постоянно вариться, чтобы не терять навык: приносить свежие идеи, замечать слабые места в макетах и постоянно пополнять базу знаний «интерфейсов». Что помогает держать форму? Следить за трендами, смотреть на конкурентов, обсуждать общие решения на дизайн-синках и, конечно же, работать руками хотя бы 20-30% времени. Это могут быть глобальные задачи, где нужно придумать направление или концепт, а проработку деталей уже передать дизайнерам. Или это могут быть задачи без горящих сроков, но важные. В этом процессе тимлид как шеф-повар на кухне. Он готовит свои фирменные блюда и руководит кухней целиком: от получения заказа до выдачи в зал. Но, если будет нужно, он готов засучить рукава и сделать любое блюдо сам. Короче, тимлид должен чутка работать руками. Это классный способ поддерживать навык дизайнера.

Дизайнер должен уметь писать текст Если дизайнер вместо текста ставит Lorem ipsum и говорит, что кто-то другой допишет его позже — это рэд флаг 🚩 У нас долгое время не было редактора: все тексты дизайнеры писали вместе с продактом. Возможно, не всегда консистентно: например, где-то кнопка называлась «отменить», а где-то «отмена». Но самое главное — доносили смысл дизайна в том числе через текст. Относительно недавно у нас появился UX-редактор — теперь наводим порядок в подсказках, кнопках в меню и вообще везде, где есть буквы. Тексты стали короче и информативнее. Из минусов: работа идет дольше. Нужно погрузить редактора в задачу, объяснить контекст, показать сценарии. Но результат стоит того. Из плюсов — финальные тексты можно примерить в дизайне и посмотреть, как все стало красиво. Да и разработчику проще: до этого правки по тексту могли прилететь уже после выкатки, потому что их в последний момент решили переписать. Считаю, что у дизайнера должны быть базовые навыки письма. Даже если в команде есть редактор, дизайнеру полезно разбираться в текстах, потому что именно он держит в голове весь сценарий. Он знает, какие экраны до и какие после. Не обязательно писать так же круто, как UX редактор — достаточно базовых навыков. Советую прочитать: — «Пиши, сокращай» Максима Ильяхова; — «Этой кнопке нужен текст» Кирилла Егерева. Короч, пишите тексты для интерфейсов: слова важны так же, как и пиксели

Матрица согласований У дизайнера найдется десяток людей, которые «пытаются помочь» ему делать свою работу. И это одна из первых ловушек, в которую попадает начинающий тимлид. Типовая ситуация: дизайнер приносит макет, вокруг собираются разработчики, менеджеры, подруга жены босса и каждый начинает «накидывать». Дизайнер погружает новых людей в задачу и доказывает, что сценарий решается интерфейсом. Бонусом идут редкие сценарии, которые «нужно обязательно учесть». После этого интерфейс превращается в компромисс, пытающийся учесть все и сразу. Оговорюсь — я не против фидбека от команды, но он должен быть в формате рекомендаций, а финальное решение остается за дизайнером. У меня были такие же общие синки: куча мнений и бесконечные согласования. По ощущениям, такие встречи затягивали процесс. Нашел для себя триггер: если команде не хочется идти на эту встречу, потому что «сейчас накидают на вентилятор» — это сигнал, что проблема есть. Решение — поделить участников по категориям: — кто реально принимает решения, — кого просто держим в курсе, — кого стоит исключить из процесса. Это я назвал матрицей согласований. Матрица экономит время на синках и помогает строить отношения внутри команды: так проще понять, хорошая ли связка дизайнер+продакт или нет. А еще матрица увеличивает эффективность и ответственность: отвечать за решения будут конкретные люди, а не вся команда по чуть-чуть. В блоге я оставил пошаговый разбор и ссылку на шаблон, чтобы вы могли использовать матрицу для себя. P.S. Этот пост — начало серии заметок для начинающих тимлидов. Пишите, какие темы еще разобрать.

Пишите сразу по делу Не люблю, когда в рабочих переписках пишут по два абзаца вступлений перед сутью: Здравствуйте! Как у вас дела? Простите, что отвлекаю, есть минутка? Хотелось бы задать вам вопрос. Поможете? Зачем это, если после приветствия можно было сразу перейти к просьбе? Или вот еще в постах любят писать так: Здравствуйте! Простите, что давно не писал, исправляюсь! Извиняться стоит только тогда, когда вы обязались что-то делать регулярно — к примеру, раз в две недели писать пост/отчет. Чаще всего, когда звучит такая фраза, обязанности не было. Я считаю, что длинные вступления перед сутью — полная фигня. Время — ограниченный ресурс, его всегда мало. И для меня короткое сообщение, написанное четко и по делу — это уважение к человеку, который его читает. Только я говорю про деловую переписку. Другое дело в жизни: там уместен смолток. Я спрошу как у человека дела, хорошо ли он долетел, как прошла конференция. И не потому что «это надо спросить», а потому что интересно. В рабочих переписках это выглядит странно. Ну ответят тебе «хорошо», и смолток закончится. Зачем он нужен был-то? Для приличия достаточно простого «привет» в начале предложения. Только не пишите его отдельным сообщением, когда специально не пишешь вопрос, пока с тобой не поздороваются в ответ 😄 Короч, пишите сразу по делу и экономьте время тем, кто вас читает.