UX FLOW • Сергей Мухин

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

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

Ищем продуктового дизайнера в команду дизайн-системы Т-Банка — с фокусом на дизайн-токены и автоматизацию. Что предстоит делать — Вместе со мной развивать и сопровождать систему дизайн-токенов: расширять, улучшать и модернизировать её. — Участвовать в проектировании процессов синхронизации токенов между дизайном (Figma) и кодом, автоматизировать экспорт и импорт (JSON и др.). — Работать с продуктовыми командами, frontend-разработчиками и менеджерами: помогать находить компромиссы и принимать архитектурные решения. — Готовить и поддерживать документацию, гайды и обучающие материалы, проводить воркшопы и ревью для команд-потребителей. — Обеспечивать качество системы: accessibility, тестирование токенов и контроль обратной совместимости изменений. — Инициировать улучшения: ускорять процессы, развивать CI/CD для токенов и экспериментировать с масштабируемостью и производительностью. Формат: удалёнка, гибрид или офис. Присылайте ваши CV и кейсы по дизайн-системам Ангелине. 🔎 Смотреть вакансию - - 🛫Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

Переменные в Фигме. Боль, JSON и AI. Сейчас делаю концепт новой архитектуры цветов. Одна из фич — гибкое склонение токенов по группам. Например, цвет primary может склоняться по: 🔵оттенку (neutral, positive, brand…), 🔵семантической группе (accent, contrast, inversed), 🔵платформе (web, iOS, Android), 🔵и, финально, теме — день/ночь. Это даёт гибкость, расширяемость и задел на важные механики в будущем. Например, на действительно гибкую темизацию. Но! Фигма так нативно и красиво не умеет. Только через костыль. Во-первых, сразу отказываемся от идеи переключать оттенки модами (neutral, positive, negative… . вот эта штука). Очень хотелось бы, но нет уверенности, что хватит лимита по количеству модов — не хочется загонять себя в ограничения на старте. И даже без этого, чтобы переключать остальные группы через моды, на первом слое нужно объявить всё логическое произведение групп (перемножить их между собой). И получается жесть. Допустим, семантические группы мы выносим в моды. Но все остальные измерения зашиваем в уникальные переменные вида: day\web\primary day\ios\primary day\android\primary night\web\primary night\ios\primary night\android\primary И это ещё нужно продублировать для каждого (!!!) оттенка. И так для каждого токена. Зато в следующих коллекциях можно всё красиво связать с модами, скрыть промежуточные коллекции от публикации и получить аккуратное управление. Но какой ценой? Вручную это обслуживать почти нереально. И тут внезапно на сцену выходят нейросети. Даже обычный ChatGPT уже неплохо редактирует JSON. Достаточно: 1️⃣ экспортировать переменные из Фигмы через любой бесплатный плагин, 2️⃣ скормить JSON в нейронку, 3️⃣ внести правки, 4️⃣ импортировать обратно. Да, бэкапы сохраняем постоянно — это база. А если настроить это аккуратно через специализированные ИИ-инструменты (тот же Codex) и связать всё через что-нибудь вроде Cursor с Фигмой, можно автоматизировать часть рутины, обложить правилами и со временем минимизировать галлюцинации и лишние пояснения. В общем, кажется, это первый в моей личной практике внятный кейс, когда ИИ реально упрощает работу с дизайн-системой. - - 🛫Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

Анимации, продолжение Кто ответил что-то вроде «удаление одного элемента и добавление другого» — оказался прав. Остальные нет😂  Что я в итоге сделал: Разделил анимации появления и исчезновения ещё на две: 1️⃣ собственно появление/исчезновение элемента 2️⃣ уплотнение/расширение списка (когда слот удалённого элемента схлопывается). Все эти штуки я обозначил как «базовые типы» и ввёл принцип последовательности: запрет одновременного воспроизведения двух и более разных базовых типов. То есть если нужно удалить сразу 10 ячеек — это ок, для них можно сыграть одинаковые анимации параллельно. Но любые другие типы изменений должны идти строго последовательно. Такое поведение проще просчитать, легче комбинировать и конфигурировать. А при сложных изменениях благодаря последовательности становится наглядно видно, что вообще происходит. Ну а результат для того же самого сценария «удаление → затем добавление» — смотрите ниже. 👇 - - 🛫Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

Недавно прорабатывал анимации изменений контента в списках для SDUI-контейнера. Решил оттолкнуться от того, что уже используется в нативной ДС. Нашёл достаточно подробный гайд, но вот с анимациями возникли вопросы. При сложных изменениях все триггеры срабатывали одновременно, и в итоге все анимации играли параллельно. Местами они перекрывали друг друга и выглядело это грязновато — особенно когда анимация «уплотнения» списка накладывалась на исчезновение элементов. Плюс, на мой взгляд, это ещё и не выполняет важную функцию анимации — объяснять пользователю, что вообще происходит с контентом. Давайте немного интерактива, а за одно и проверим мою гипотезу: Как вы думаете, что произошло со списком в анимации из превью? А я пока допишу пост о том, что там на самом деле, как я подошёл к задаче и что получилось в итоге. 😉 - - 🛫Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

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

О важности концептуального виденья Сейчас я и команда в основном работаем над созданием движка низкоуровневой вёрстки для SDUI-фреймворка. И недавно я получил неожиданную просьбу от тимлида разработки: сформулировать концептуальное видение проекта😱 Оказалось, всё просто. Сейчас мы двигаемся поэтапно: слой за слоем я описываю группы компонентов и разные механики. Но так как виден только текущий шаг, без возможности посмотреть на общую картину, становится сложно обсуждать отдельные решения. Непонятно, как они связаны с тем, что уже есть, и — что важнее — с тем, что ещё только предстоит описать. Я довольно долго мучился, пытаясь найти форму и нужные формулировки. В итоге остановился на формате манифеста и достаточно абстрактных принципах, не привязанных к реализации. И как только я перестал упираться в детали, всё само сложилось в стройную картину. Команда тепло приняла манифест, и я хочу поделиться с вами некоторыми его положениями — именно теми принципами, которые вы легко сможете примерить на свои системы. 🔺ЦЕЛОСТНОСТЬ (консистентность) Система должна быть единым организмом. Даже если что-то заимствовано, оно проходит переработку — пока не станет элементом нашего языка, а не случайным инородным телом. Целостность — это не про одинаковость визуала. Это про внутреннюю логику, которая чувствуется при работе с системой: «Да, это работает так же, как и всё остальное». 🔺МОДУЛЬНОСТЬ Части системы развиваются независимо. Она должна масштабироваться без разрушения структуры. Добавление нового — это расширение, а не ломка. 🔺НЕ ПЛОДИТЬ СУЩНОСТИ Принцип «расширяй, не создавай заново». Перед добавлением новой сущности — поиск аналогов и попытка обобщить. Перед созданием любой новой сущности — шаг назад: «Это новое? Или это частный случай уже существующего?» Система выигрывает, когда обобщает, а не распыляет. В идеале новая сущность — это выражение закономерности, а не «компонент для конкретного кейса». Новая сущность должна рождаться не из задачи, а из закономерности. Мы ищем то, что повторяется, и поднимаем это на уровень абстракции. Сущность должна отвечать на вопрос: «Это выражение функции или просто костыль?» 🔺ПРОСТОТА ДЛЯ ПОЛЬЗОВАТЕЛЯ Сложность решения внутри системы — ок, если внешнее API остаётся простым и предсказуемым. Простое — это не примитивное. Система может быть сложной, но простой в использовании, т.е. внутренние механизмы могут быть сложными, но внешний язык должен быть лёгким и предсказуемым. 🔺ОБОБЩЕНИЕ Обобщать — значит замечать закономерности и поднимать уровень абстракции. Не «кнопка отдельная, карточка отдельная», а «интерактивный блок со состояниями», который потом проявляется разными способами. Обобщение — источник появления сильных, долговечных сущностей. Мы ищем общее между разными решениями. Мы строим не частные компоненты, а абстракции. Кроссплатформенность — естественное продолжение обобщения. 🔺 УНИВЕРСАЛЬНОСТЬ Язык системы должен быть понятен на любой платформе — разработчикам, дизайнерам и всем пользователям системы. Универсальность — не про одинаковость, а про общность принципов. 🔺КОМБИНИРОВАНИЕ И ВАРИАТИВНОСТЬ Элементы системы должны сочетаться и порождать новое. Настройки должны позволять выражать разные формы в рамках одних и тех же принципов. Сила системы — в том, как она проявляется в комбинациях. Комбинации должны порождать давать новые свойства, недоступные элементам по отдельности. - - 🛫Канал: UXFLOW • Сергей Мухин Сайт: uxflow.ru

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

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