🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤🔤

Я уже писал о своём отношении к менторству и курсам, и оно не изменилось. Но в последнее время ко мне начали поступать настойчивые запросы на консультации — в том числе корпоративные. Судя по отзывам, удалось причинить ощутимую пользу. Поэтому теперь я официально консультирую. 😅

ЧЕМ МОГУ ПОМОЧЬ?

✅ Аудит процессов дизайна в отделе/компании: поиск узких мест, варианты решения.

✅ Аудит проекта: качество реализации, стандарты, технологические процессы.

✅ Разбор проблемы, брейншторм по вариантам решения (дизайн-менеджмент, продуктовый и UI-дизайн, проектирование дизайн-систем и т. д.).

✅ Формат «вопрос-ответ»: обсуждение накопившихся вопросов, в том числе с вашей командой.

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

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

ПОЧЕМУ Я?
На моём сайте есть подробное описание опыта (а также кейсы и публикации):
руководство командами разного масштаба, налаживание процессов, проектирование интерфейсов, дизайн-систем (включая кроссплатформенные, мультибрендовые и даже под SDUI-принцип).

По всем вопросам пишите мне в личные сообщения.

- - - -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Про поиск работы, пет-проекты и отдых

Раньше я не понимал, как люди увольняются «в никуда» — без оффера, да ещё и берут перерыв на отдохнуть от работы. А теперь сам в такой ситуации.

Казалось бы, без работы можно наконец спать до обеда и заниматься чем попало. Но привычки берут своё: в 9 утра я уже за рабочим местом. И дел всегда хватает — общение с потенциальными работодателями, созвоны… В общем, как будто мало что поменялось.

Поиск новой работы — это всегда приключение. Только привыкаешь к одному процессу, например, будучи сеньором, как всё снова меняется: теперь ты уже лидер. Есть мысль подробно описать этот опыт — как выглядит поиск работы на позициях выше тимлида. Но сначала надо её найти. 😬 Хотя одной интересной деталью точно поделюсь в ближайшее время, не переключайтесь. 😉

Кроме поиска работы я бросил силы на пет-проекты. Некоторые пока секретные (расскажу, когда будет что показать), а часть — это неожиданно стрельнувшие консультации. Сразу несколько заявок прилетело в день поста — даже не ожидал. Теперь стабильно несколько созвонов в неделю по этому направлению.

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

- - - -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Как-то в компании пришло время нанимать дизайнеров. И вот впервые мне выдали доступ в HR-CRM, кажется, это был Huntflow. Отказывая кандидату, я увидел выпадающее меню «Причина отказа» и нашёл там пункт «Переизбыток опыта».

"WTF?" — подумал я. Как вообще может быть слишком много опыта? Нет, теоретически понятно: если я прямо сейчас откликнусь на позицию джуна, все покрутят пальцем у виска — "сдурел?" — и нажмут "overqualified". Но мне казалось, что это редчайший кейс.

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


А мораль этой басни в чём?

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

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

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

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

- - - -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Сколько арт-директоров нужно, чтобы сделать проект по окружающему миру в 4 классе?

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

Вот, например, в 3 классе задали провести интервью на тему «Кто нас защищает». В итоге пришлось привлечь трёх взрослых: один помог подготовить вопросы, второй дал интервью, третий оформил проект.

Но теперь я вообще в шоке. По теме славянской письменности задали сделать отрывок любого текста в старославянском стиле… на состаренной бумаге (!!!) 🤯

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

- - - -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Про портфолио продуктовых дизайнеров

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


ВАШИ КЛИЕНТЫ

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

Основные "клиенты" вашего портфолио (если вы не фрилансер):

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

1–2 картинки + кратко:
- Какую задачу решали?
- Что делали?
- Какой результат получили?

💡 Совет: Экономьте время HR'а, и он это оценит.

🔺Руководитель НЕ дизайнер (чаще всего продакт-менеджер) — им важно понять механизм принятия решений. Достаточно пары ярких картинок, чтобы убедить, что вы умеете в UI, а дальше — раскрыть процесс:

- Как вы работали с данными?
- Как измеряли успех?
- Как принимали решения?

🔺Руководитель-дизайнер — сам опытный дизайнер, поэтому будет копаться в деталях. Он будет смотреть на качество реализации, сборку макета, и на сколько вы технически подкованы. Тут важно:
- Показать разные состояния интерфейса, логику работы, динамику и анимации.
- Добавить ссылку на Фигму, чтобы пощупать макет изнутри (но Фигма должна быть чистой и понятной, а не свалкой из неподписанных макетов).


ПРО ФОРМУ

Исходя из выше написанного, оптимальная структура кейса:

Первая страница\экран — краткая выжимка для HR + картинка.
Скролл вниз или кнопка «Подробнее» → развёрнутое описание.
Ссылки на макеты в Фигме, прототипы для дизайн-лидов.

Сайт, Dribbble/Behance или Notion — вот в чём вопрос.

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

Лучший вариант — персонализированный сайт (даже на конструкторе). Он помогает выделиться, даёт больше контроля и возможностей, при этом не намного сложнее в реализации, чем Notion.

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


КАК НЕ НАДО

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

Из моей практики самые жёсткие антипримеры:
- Архив на Яндекс.Диске, в котором два .doc-файла с ссылками на Behance 🙈
- Логин и пароль от Behance вместо ссылки на портфолио 🤯

Ещё один момент: мокапы. Дизайн не должен мешать получению смысла. Главное - это ваши макеты, а не в какой макбук или айфон вы их вставили. И, я вас заклинаю, не поворачивайте макеты в мокапе ни в какую сторону. Вот прям фронтально показывайте с углом поворота 0°, разглядывать "креативные" мокапы в изометрии болит шея к концу дня.


ТОЛЬКО ЦЕННОЕ

Финальный совет — пишите о реальном опыте и вызовах.

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

✅ Опишите, какие инсайты вы получили и как они повлияли на результат.

Если вам кажется, что опыт не релевантный — напишите, чему научились. Опыта мало — вытащите всё полезное и важное из тех кейсов, что есть.

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

- -
#портфолио

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Внедрение дизайн-системы сложнее чем реализация

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

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

Но что, если у вас сотни разработчиков, миллионы пользователей, а дизайн-системы нет вовсе? Более того, нет даже базового UI Kit’а, от которого можно было бы оттолкнуться? В таких условиях всё усложняется. Конкретные решения уже не так важны, на первый план выходят процессы, политика и поиск союзников.

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

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

- -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Функции дизайн-системы

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

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

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

Поэтому меня искренне удивило, что именно этого ждали от дизайнера ДС. Более того, с предыдущим кандидатом, как оказалось, попрощались именно из-за того, что он не определял сценарии применения компонентов. Ну и совсем меня убило: рекрутер сделал вывод, что раз я не описал правила использования, значит, сам их не знаю. 🤯

Мне повезло: во всех компаниях, где я строил ДС, я параллельно либо лидил продуктовых дизайнеров, либо возглавлял всё дизайн-направление. Это позволяло настраивать процессы так, что за качество пользовательского опыта всегда отвечали именно продуктовые дизайнеры. Ведь если дизайнер ДС берёт на себя ещё и проработку всех сценариев, то либо их (дизайнеров ДС) рано или поздно станет практически столько же, сколько продуктовых дизайнеров, либо система превращается в ограничивающий инструмент. В итоге — узкие горлышки, нехватка компонентов, невозможность сделать хорошо, а только «как позволяет система».

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

А как у вас? Кто в вашей дизайн-системе описывает применение и решает, какой компонент использовать?

- -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Наткнулся на статью: в Salesforce Lightning — тех самых, для которых Jina Anne ещё в 2014 придумала концепцию дизайн-токенов — решили отказаться от самого термина. Сконцентрировались на CSS-переменных и считают, что грядущая спецификация W3C слишком сложная и движется не в ту сторону.

Это мне напомнило, как во времена хайпа вокруг performance review один из авторов метода позже сам признал его неэффективным.

Как бы там ни было, забавно наблюдать, как все бегают с токенами как с торбой, и ждут что W3C спасет мир от хаоса, а потом читаешь вот такое 😁

- -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru

Тестовое... Опять...

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

Но реальность такова, что с тестовыми всё равно сталкиваешься. И тут закономерный вопрос:
Как понять, каким должен быть результат, чтобы вот точно пройти?
Ответ: никак. 🤷🏻‍♂️

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

Недавний пример — тестовое на позицию лида дизайн-системы.
Сначала вопрос: «Команда хочет какой-то неведомый компонент. Как будете собирать и обрабатывать требования?»
Следом: «Сделайте этот компонент в Figma».
Но, Карл, ты же сам только что сказал, требований пока даже нет... Что тогда я должен сделать-то? 😔


Как быть?

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

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

Если никакой информации нет — делайте так, как вы бы делали это в реальной работе. Максимально естественно и честно. В худшем случае просто не совпадёте ожиданиями нанимателя — это нормально.

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

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

- -

🛫 Канал: UXFLOW • Сергей Мухин
Сайт: uxflow.ru