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

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

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

Выступление на Д-в всё-таки состоится, так что продолжение темы будет уже там. Пока не знаю, будет ли трансляция и запись от организаторов, как в прошлый раз. Но хотя бы какую-то запись — пусть своими силами — в любом случае постараюсь сделать и выложить на канале. Ну и в ближайшее время выложу анонс со всеми подробностями: когда, во сколько и в каком зале. *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

Я уже писал о своём отношении к менторству и курсам, и оно не изменилось. Но в последнее время ко мне начали поступать настойчивые запросы на консультации — в том числе корпоративные. Судя по отзывам, удалось причинить ощутимую пользу. Поэтому теперь я официально консультирую. 😅 ЧЕМ МОГУ ПОМОЧЬ? ✅ Аудит процессов дизайна в отделе/компании: поиск узких мест, варианты решения. ✅ Аудит проекта: качество реализации, стандарты, технологические процессы. ✅ Разбор проблемы, брейншторм по вариантам решения (дизайн-менеджмент, продуктовый и UI-дизайн, проектирование дизайн-систем и т. д.). ✅ Формат «вопрос-ответ»: обсуждение накопившихся вопросов, в том числе с вашей командой. ✅ Дизайн-системы: можно обсудить процессы, конкретные решения или уже сформировавшуюся боль, поискать оптимальный вариант. Также можно обсудить и другие форматы, например сопровождение проекта, помощь при запуске или другой формат. ПОЧЕМУ Я? На моём сайте есть подробное описание опыта (а также кейсы и публикации): руководство командами разного масштаба, налаживание процессов, проектирование интерфейсов, дизайн-систем (включая кроссплатформенные, мультибрендовые и даже под SDUI-принцип). По всем вопросам пишите мне в личные сообщения. - - - - 🛫 Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

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

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

В последние дни я снова вернулся к работе над Китом в Figma. Ранее я показывал, как можно управлять свойствами через variables, даже после отвязки от библиотеки, и применял это в рецептах компонентов. А сейчас я пошёл дальше — вынес часть параметров из вариантов в modes и variables. Поймал себя на мысли, что теперь хочу Enterprise-тариф с почти бесконечным количеством модов, чтобы вынести в управление через переменные практически всё, что раньше было в вариантах. В теории это должно быть невероятно удобно: все параметры компонента видны в табличке, сразу понятна их связь с токенами. Блин, в такой системе я начинаю понимать, чем полезны токены компонента 😁. Конечно, такой душный подход подходит не всем. Но для меня, с моим складом мышления, табличное отображение параметров гораздо удобнее, чем визуальное управление через варианты частными пересечениями свойств компонента. Главное, чтобы не было ограничений на количество модов, а переменные можно было привязать ко всему. - - - - #дизайн #дизайнсистемы #figma #переменные 🛫Канал: UXFLOW • Сергей Мухин | Сайт: uxflow.ru