Мыслью по древу • UXFLOW • Сергей Мухин

продолжение Бизнес-логику мы уже рассмотрели — теперь хочется перейти к другим двум ключевым аспектам SDUI: вёрстке и автоматизации. 🌟 Верстка Здесь главное различие — гранулярность системы. То есть, насколько «мелко» можно управлять интерфейсом через контракт: какие сущности доступны и на каком уровне атомарности. Возможны разные варианты: — Виджетная архитектура с хранением вёрстки на клиенте — Обращение к элементам дизайн-системы, также хранимым на клиенте — Гибкий отрисовщик, построенный на примитивах, с распределённым хранением вёрстки (часть элементов на клиенте, часть, например компоновка и параметры декоратора, на сервере). В первых двух подходах на клиенте хранится конечный (или условно конечный) набор компонентов. А в случае с гибкой системой — платформа позволяет собирать виджеты и даже атомы (например, кнопку) из базовых примитивов. Это напрямую влияет на архитектуру и конфигурацию дизайн-системы. При виджетном подходе сервер может управлять только выбором виджетов, их параметрами и расположением. И для продуктового дизайнера приоритетом становится поиск безрелизного решения: как «выкрутиться» с текущим набором компонентов. Потому что это быстрее и дешевле. Только если нужного виджета или параметра нет, команда решается на доработку — а это уже означает выпуск новой версии и релиз в стор. В более гранулярных системах возможностей для безрелизных изменений больше, но и здесь есть ограничения: не всё можно сделать без обновления клиента. При этом именно такие фичи — с условием «без повышения версии» — часто оказываются самыми приоритетными. Кроме того, в системах любой гранулярности обычно используется многоуровневая система контейнеров со слотами, что тоже влияет на логику проектирования. А ещё, помимо самой вёрстки, хочется сказать пару слов о верстальщике. Эта роль при переходе на SDUI меняется радикально. Теперь макеты у дизайнера будет принимать бэкендер — потому что бизнес-логика теперь на сервере, да и верстка при некоторых подходах тоже. А может быть и другой сценарий: часть задач верстальщика уходит к дизайнеру, особенно если в системе уже есть автоматизация (о ней — чуть ниже). 🌟 Автоматизация Здесь всё проще. Автоматизация бывает и вне SDUI, но именно переход к этой архитектуре обычно стимулирует её активное развитие. От автоматической сборки виджетов и конвертации макетов в вёрстку — до внутренних инструментов, вроде линтера для дизайнеров, который проверяет макет на соответствие правилам. Работа с автоматикой может поначалу усложнить подготовку макетов — но в итоге снимает рутину, снижает количество ошибок и освобождает время для творческих задач. - - #sdui #bdui #верстка #автоматизация 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

Прежде чем SDUI снова ворвётся в мою работу и в контент на канале, хочется разобраться — чем вообще отличается процесс и технология дизайна в таком подходе. Для начала важно сделать шаг назад и понять: на что именно влияет технология, и какие вообще бывают варианты реализации SDUI. Ключевые области, которых касается внедрение безрелизности, — это бизнес-логика, вёрстка и автоматизация. 🌟Начнём с бизнес-логики. Бизнес-логика в данном случае — это то, что управляет реакцией приложения на действия пользователя. "Если пользователь нажимает на кнопку — показывается окно выбора..." — вот подобные штуки и есть бизнес-логика. Она может быть реализована по-разному. Чаще всего встречаются три варианта (которые могут комбинироваться): —Тонкий клиент. Вся бизнес-логика выполняется на сервере, а клиент получает только результат — изменения в контенте и вёрстке. — Толстый клиент с управлением через actions. Здесь логика описывается в виде процедур или функций, часто — довольно атомарных и гибко настраиваемых. Контракт (обычно это JSON с вёрсткой) уже содержит вызовы этих функций. Например, в случае перехода достаточно указать в контракте саму функцию и её параметры (тип перехода, линк и т. д.). — Толстый клиент с загружаемыми скриптами. В этом варианте бизнес-логика исполняется на клиенте, но поставляется с сервера в виде загружаемых скриптов — чаще всего на JS. Как это влияет на работу дизайнера? Во-первых — это влияет на мышление. Реализация через actions требует другого подхода к проектированию: всё начинает дробиться на действия, функции, состояния. Анимации переходов становятся частью логики, что подталкивает к систематизации, стандартизации и визуальному единообразию. Такой способ мышления полезен не только в контексте SDUI — он помогает пересматривать сущности, улучшать сценарии и думать о интерфейсе как о системе. Во-вторых — это вопрос планирования. В модели тонкого клиента отрисовка результата бизнес-логики происходит на фронте, на основе правил и механизмов дизайн-системы или дизайн-платформы. Обновление этих правил требует обновления самого клиента — то есть выкладки новой версии в стор. Поэтому так важно сразу продумать архитектуру, заложить гибкость в ключевые решения и сделать инструмент, который покрывает основные сценарии — без постоянного обновления сборки. - - #sdui #bdui #бизнеслогика 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

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

«Дизайн-система как инструмент формирования мышления продуктового дизайнера» Философия и подходы, с помощью которых дизайн-система может формировать определённый майндсет, поощрять и направлять ход мыслей дизайнера в нужную сторону. 📱 Смотреть на YouTube - - #дизайнвыходные #казань #выступление 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

Ночью доделал презентацию. Надеюсь, что в этот раз не буду снова переделывать всё в отеле за пару часов до выступления… 😁

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

Выступление на Д-в всё-таки состоится, так что продолжение темы будет уже там. Пока не знаю, будет ли трансляция и запись от организаторов, как в прошлый раз. Но хотя бы какую-то запись — пусть своими силами — в любом случае постараюсь сделать и выложить на канале. Ну и в ближайшее время выложу анонс со всеми подробностями: когда, во сколько и в каком зале. *P.S. Рубрику в письменном виде потом всё равно обязательно раскроем, как и планировалось — чтобы всё это можно было прочитать здесь, в канале. Просто сейчас все силы уйдут на написание доклада и подготовку презентации к выступлению 😉

В качестве введения хочу поделиться, с одной стороны, наблюдением о дизайн-системах, а с другой — идеей, к которой я пришёл в последнее время. Начнём с наблюдения. Так получилось, что я уже видел приличное количество дизайн-систем «изнутри». И не только те, что делал сам, но и на консультациях, на собеседованиях, расспрашивая команды, помогая друзьям и знакомым, кто так или иначе с этим связан. И мало где подход действительно можно назвать продуктовым. Несмотря на то, что сейчас модно говорить, мол, ДС — это продукт, на практике очень часто оказывается, что «продуктовость» сводится к тому, что работа над продуктовым инкрементом размазывается на две команды. Сначала продуктовые дизайнеры исследуют гипотезу, понимают, какой UX им нужен, а потом смотрят, можно ли реализовать это в рамках существующей ДС. Если нельзя — что ж, надо идти бить челом в команду дизайн-системы. И уже они решают, вносить ли изменения (или нет) в компоненты, которые нужны для конкретной фичи. П - продуктовость. На практике во многих командах эта история ещё и тоталитарная. Поскольку ДС в первую очередь меряет свой успех через экономию ресурсов, нужно буквально расшибиться в лепёшку, чтобы ради твоей фичи доработали компонент. А в 90+ процентах случаев приходится натягивать своё решение на текущие возможности системы — потому что твоя фича не тянет на достаточный импакт. И вот тут переходим к моей идее и философии. Что если большую часть компонентов ДС будут делать продуктовые дизайнеры? 🤔 Концентрировать всё знание и власть о ДС удобно на ранних стадиях её развития. Но с ростом количества продуктовых команд, брендов и платформ начинает вставать вопрос масштабирования. И дальше есть масса вариантов, но базово всё сводится к двум направлениям: — Делить ответственность и контроль над ДС между несколькими командами. — Наращивать команду ДС хоть до полноценного департамента. И, конечно, можно комбинировать оба пути. Важно вот что: если смотреть с точки зрения болей и потребностей, ни у кого нет боли «хочу дизайн-систему». Все решают свои задачи и хотят инструмент, который помогает их решать. И продуктовые дизайнеры чаще всего вполне не против делать компоненты сами. Главное противоречие здесь — поддержание единообразия, консистентности и снижение костов. Без централизованного механизма управления качество будет разным, появится множество уникальных компонентов, и консистентность поплывёт. Поэтому чаще всего побеждает диктатура. Но что если дать дизайнерам простой и понятный инструмент создания компонентов? Окей, с простым я, наверное, загнул — совсем просто вряд ли получится..😬 Суть подхода в том, чтобы создать правила — своего рода Таблицу Менделеева и законы физики — в рамках которых система будет саморегулироваться. При комбинировании элементов между собой получается компонент, свойства и поведение которого можно спрогнозировать, зная правила. А команда ДС смещает фокус: не делает готовые фичи и компоненты, а создаёт сами правила и элементы, обучает, делится практиками, помогает находить неожиданные, но рабочие решения. Собственно, в следующих постах серии разберём уже практические приёмы: как можно организовать такую систему и каким образом она влияет на мышление дизайнеров и формирует его. - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

В зависимости от набора данных, метки могут раскрываться в полноценные чипсы с текстом. Так пользователь может сразу, не проваливаясь внутрь, понять по списку карточек, что означает каждая из меток. - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

И вот листаю свежий выпуск за март, и вижу: «Сергей Мухин рассказывает…». С момента, как я начал вести канал и писать статьи, это до сих пор остаётся самым удивительным — когда кто-то находит в твоём тексте ценность и делится им без твоего участия. Но когда видишь свою статью в медиа, которое сам читаешь — это уже буквально чувство из серии: «Мам, я в телевизоре!» Кстати саму статью я особо никуда не выкладывал, лежит на сайте среди других кейсов в моём портфолио. Тем удивительнее, что она попала в подборку. Саму статью можно почитать на моём сайте. - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

Или всё-таки сохранилось? Перетряхнул старые ящики электронной почты — и да, нашёл рабочий проект! Это кусочек сайта, который я делал в 2007 году на тему рок-музыки. Треки, конечно, давно не запускаются, но сам плеер жив — всё нажимается, перетаскивается. Местная фишка — летучие мыши 🦇 Помню, сколько с ними возился: чтобы летали свободно, если их не трогать, убегали от курсора, если подводишь, и наоборот — слетались к активности: наведению или клику. Интересно, сколько седых волос я бы сейчас заработал, если попытался бы повторить всё это на JS… В общем, как вам интерфейс почти двадцатилетней давности? Кажется, дизайн состарился гораздо лучше, чем я ожидал 🙈 Да, UI и визуал кое где протухли, но вот особенно плеер всё ещё выглядит вполне. Ещё по современным меркам с контрастом беда — но тогда и мониторы были другие. - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

Я уже делился своим мнением, почему не использую тестовые задания при найме и сам редко делаю. Но реальность такова, что с тестовыми всё равно сталкиваешься. И тут закономерный вопрос: Как понять, каким должен быть результат, чтобы вот точно пройти? Ответ: никак. 🤷🏻‍♂️ Часто даже сами наниматели не до конца понимают, что хотят увидеть. Плюс задания бывают абстрактными, с внутренними противоречиями и размытым фокусом. Недавний пример — тестовое на позицию лида дизайн-системы. Сначала вопрос: «Команда хочет какой-то неведомый компонент. Как будете собирать и обрабатывать требования?» Следом: «Сделайте этот компонент в Figma». Но, Карл, ты же сам только что сказал, требований пока даже нет... Что тогда я должен сделать-то? 😔 Как быть? Если есть возможность — задавайте вопросы. Выясняйте, что от вас ждут, какие критерии успеха, есть ли чеклист. Во ВкусВилле на вайтбордах я, например, всегда проговаривал, что смотрю в первую очередь на мышление и пользовательский путь. А UI — если успеем. В других компаниях может быть наоборот: фокус на крутой UI. Сделаешь идеальный UX, но провалишь визуал — отказ. Если вдруг у вас есть знакомые внутри компании, куда вы проходите тестирование — спросите у них, какие стандарты, на что смотрят, как вообще принято оформлять задачи. Это даст хоть какой-то ориентир. Если никакой информации нет — делайте так, как вы бы делали это в реальной работе. Максимально естественно и честно. В худшем случае просто не совпадёте ожиданиями нанимателя — это нормально. Отдельная история — когда наниматели сами не знают, чего хотят. Я бы даже не тратил время. У меня были коллеги, которые отбирали людей по принципу «огонь/не огонь» и не могли объяснить, почему. Пройти такой отбор — это реально рулетка. Ну и ещё. Я не верю в тестовые с ментором — за исключением стажеров и джунов. На старте ментор может помочь структурировать мысли, дать шаблоны, подтянуть результат. Но если у вас уже приличный опыт, ментор может, наоборот, сбить. Он будет транслировать своё видение, а вы бы, возможно, сделали лучше, если бы опирались только на своё. - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

Канал ведёт дизайн-лид Маша Чубина. Она консультирует дизайнеров, делает разборы резюме и делится практическими материалами о трудоустройстве. Здесь можно узнать, какие навыки ценят в продуктовых командах, как грамотно выстраивать коммуникацию, презентовать себя и проходить испытательный срок. Начни с топа полезных постов 🥴 Зоны ответственности junior, middle, senior дизайнеров. 🥴 У дизайнера руководителем должен быть дизайнер. 🥴 Как создать актуальное рынку резюме. 🥴 Как нанимающий менеджер оценивает портфолио дизайнера. 🥴Как пройти собеседования дизайнеру. Если тебе интересно карьерное развитие, то этот блог для тебя ;) ⛓ Подписаться

Хочется продолжить брюзжание на тему дизайн-систем. Обычно я делюсь мыслями, исходя из реального рабочего процесса, но сейчас, будучи безработным, возьму материал из собеседований. 😁 Недавно, рассказывая о своих дизайн-системах, столкнулся с удивлённой реакцией: у меня в документации подробно описаны свойства и поведение компонентов, но нет чёткого указания, когда и как их использовать. Например, чем чекбокс отличается от свитчера? Или насколько «зелёную» кнопку должен выбрать дизайнер? Как же дизайнер поймёт, что ему делать? Причина простая — такой потребности просто не возникало. Дизайн-система для меня — это инструмент, а не диктатура. Я никогда не стремился бить дизайнеров по рукам, навязывая им, как именно им делать свою работу. Ответственность за пользовательский опыт и принятие решений лежит на продуктовых дизайнерах. Ну и общее правило, которое я подрезал у знакомого разработчика, и постоянно цитирую: «Миром правит любовь, в её отсутствие — здравый смысл». Поэтому меня искренне удивило, что именно этого ждали от дизайнера ДС. Более того, с предыдущим кандидатом, как оказалось, попрощались именно из-за того, что он не определял сценарии применения компонентов. Ну и совсем меня убило: рекрутер сделал вывод, что раз я не описал правила использования, значит, сам их не знаю. 🤯 Мне повезло: во всех компаниях, где я строил ДС, я параллельно либо лидил продуктовых дизайнеров, либо возглавлял весь дизайн-направление. Это позволяло настраивать процессы так, что за качество пользовательского опыта всегда отвечали именно продуктовые дизайнеры. Ведь если дизайнер ДС берёт на себя ещё и проработку всех сценариев, то либо их (дизайнеров ДС) рано или поздно станет практически столько же, сколько продуктовых дизайнеров, либо система превращается в ограничивающий инструмент. В итоге — узкие горлышки, нехватка компонентов, невозможность сделать хорошо, а только «как позволяет система». При этом я вовсе не против best practices и гайдов по использованию прямо в документации ДС. Особенно если продуктовым дизайнерам удобно получать информацию там. Но источник этих знаний должен быть в продуктовых командах, а не исключительно в голове дизайнера ДС. А как у вас? Кто в вашей дизайн-системе описывает применение и решает, какой компонент использовать? - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

Часто в чатиках и дизайнерских комьюнити вижу истории о том, как небольшая команда на молодом проекте берётся за дизайн-систему. Один-два дизайнера, десяток разработчиков, быстрые договорённости с фронтами — и вот, ресурсы выбиты, процесс пошёл. Завидую… Когда дизайнеры начинают работать над дизайн-системой, их главный фокус — сама реализация: какие компоненты нужны, как их организовать, какие механизмы использовать. И это действительно важно. Если команда маленькая, а проект свежий, достаточно просто начать — остальное наладится в процессе. Но что, если у вас сотни разработчиков, миллионы пользователей, а дизайн-системы нет вовсе? Более того, нет даже базового UI Kit’а, от которого можно было бы оттолкнуться? В таких условиях всё усложняется. Конкретные решения уже не так важны, на первый план выходят процессы, политика и поиск союзников. Нужно договариваться, продвигать ценность дизайн-системы, убеждать команды, которые привыкли работать по старым схемам. И главное — внедрять систему так, чтобы не спровоцировать саботаж (а такое бывает), когда команды будут стараться работать старыми методами игнорируя новые процессы и всячески тормозить внедрение новой системы. Иначе даже самая идеально спроектированная дизайн-система останется просто очередной папкой в Фигме. Дизайн-система — это не только про кнопки и компоненты. Это про людей, процессы и умение менять культуру работы. Это важно не упускать, и не зацикливаться только на токенах и компонентах. - - 🛫 Канал: 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

Контент выходного дня. Каждый раз поражаюсь школьным домашним заданиям — там проекты один краше другого. Вот, например, в 3 классе задали провести интервью на тему «Кто нас защищает». В итоге пришлось привлечь трёх взрослых: один помог подготовить вопросы, второй дал интервью, третий оформил проект. Но теперь я вообще в шоке. По теме славянской письменности задали сделать отрывок любого текста в старославянском стиле… на состаренной бумаге (!!!) 🤯 Выбрали отрывок из какой-то детской книжки. Не думал я, что в 4 классе буду учить дочь, как рисуется славянская вязь, и чем акцидентный шрифт отличается от текстового. Даже интересно, как выкрутились остальные. - - - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

"WTF?" — подумал я. Как вообще может быть слишком много опыта? Нет, теоретически понятно: если я прямо сейчас откликнусь на позицию джуна, все покрутят пальцем у виска — "сдурел?" — и нажмут "overqualified". Но мне казалось, что это редчайший кейс. Однако со временем я начал сталкиваться с этим всё чаще. Причины у отказов с пометкой overqualified разные: от завышенных зарплатных ожиданий до перспектив дальнейшего роста. Даже если я прохожу по деньгам, но работодатель видит, что у меня слишком много опыта и мои потребности выходят за рамки роли, логично предположить, что вскоре я начну просить больше полномочий, более интересный проект или просто уйду в другую компанию на релевантную позицию. Поэтому на меня изначально не хотят тратить ресурс, считая заведомо рискованным кандидатом. А мораль этой басни в чём? В начале карьеры все страдают от недостатка опыта, потому что работодатели мечтают о 18-летних джунах с 15-летним стажем. И мало кто задумывается, что однажды опыта может стать слишком много. Кажется, что после определённого уровня найм превратится в рай: компании будут сами стучаться в личку, преклоняться перед твоими скиллами и засыпать оферами. Но на деле процесс найма просто меняется. Вакансий становится меньше, многие из них уходят в непубличный сегмент, а попасть на них можно только через прямые контакты с рекрутерами и руководителями. А в откликах всё чаще мелькает "переизбыток опыта". Найм — это всегда сложно, рискованно и непредсказуемо. Неважно, джун вы или дизайн-директор — на каждом этапе есть свои нюансы, и легко не будет никогда. Всё, что могу посоветовать: заранее продумывайте стратегию поиска, развивайте нетворкинг и не расслабляйтесь.😬 - - - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

Раньше я не понимал, как люди увольняются «в никуда» — без оффера, да ещё и берут перерыв на отдохнуть от работы. А теперь сам в такой ситуации. Казалось бы, без работы можно наконец спать до обеда и заниматься чем попало. Но привычки берут своё: в 9 утра я уже за рабочим местом. И дел всегда хватает — общение с потенциальными работодателями, созвоны… В общем, как будто мало что поменялось. Поиск новой работы — это всегда приключение. Только привыкаешь к одному процессу, например, будучи сеньором, как всё снова меняется: теперь ты уже лидер. Есть мысль подробно описать этот опыт — как выглядит поиск работы на позициях выше тимлида. Но сначала надо её найти. 😬 Хотя одной интересной деталью точно поделюсь в ближайшее время, не переключайтесь. 😉 Кроме поиска работы я бросил силы на пет-проекты. Некоторые пока секретные (расскажу, когда будет что показать), а часть — это неожиданно стрельнувшие консультации. Сразу несколько заявок прилетело в день поста — даже не ожидал. Теперь стабильно несколько созвонов в неделю по этому направлению. На фоне всего этого я вдруг понял, что про отдых вообще забыл. Пришлось заставить себя взять паузу на неделю и даже выгнать себя в небольшую поездку. Теперь заряд энергии получен, и можно снова фигачить. 💪 - - - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru