Дайджест январь-август 2025

Давненько я не делал подборку.
Вот что было интересного за эти пол года.


ПОСТЫ:

🔺Материалы для самопроврки к «Испытанию купоном»

🔺Должен ли уметь рисовать дизайнер интерфейсов?

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

🔺Как не надо делать библиоткеку иконок в фигме

🔺Про тестовые задания

🔺«А вы часто думаете о Римской Империи?» - утерянная технология Flash и её до сих пор не превзойденные уникальные возможности

🔺Редизайн своего же дизайна для сервиса загородного отдыха.

🔺Про обновления дизайна IOS 26 и Material Expressive

🔺Чем отличается дизайн для SDUI
[часть 1 | часть 2]

🔺Почему я работаю в компании а не открываю своё

🔺Концепт: Модификаторы токенов цвета


СТАТЬИ И ВИДЕО:

🔺Большая статья про SDUI платформу, которую я строил во ВкусВилл.

🔺 Пилотный выпуск «Привет, Сергей» - рассмотрели проблему нового компонента с точки зрения дизайна и кода, в конце получили работающее решение.

🔺Выступление на Дизайн-Выходных в Казани - «Дизайн-система как инструмент формирования мышления продуктового дизайнера» и ответы на вопросы из зала

🔺Большая статья «Я не дизайнер!» про моё принятие своего пути, вышла на проекте errarium


Что ещё я сделал за пол года:
🔺Ушёл из ВкусВилл
🔺Открыл консультации
🔺Бухал на вечеринке Авито
🔺Попал в Дайджест продуктового дизайна
🔺Поработал пару месяцев в студии и ушёл в Т-Банк (пост о том как я искал работу)
🔺Редачил книгу про дизайн-системы


- -

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

Вам не нужна дизайн-система если…

В чатах по дизайн-системам постоянно всплывает вопрос:
«Мы маленький стартап. Лучше взять готовую ДС или сразу пилить свою? Опыт — ноль».

Честный ответ: если вы задаёте этот вопрос, значит, дизайн-система вам пока не нужна.

ДС создают не потому, что «у всех есть, и у нас тоже будет». Её делают тогда, когда без неё продукт реально перестаёт развиваться. Когда хаос в интерфейсах и коде уже мешает масштабироваться. Если вы не понимаете, как система будет жить и эволюционировать — лучше отложить.

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

С готовыми open-source вариантами та же история. Плохо собранная чужая система хуже, чем её отсутствие. Особенно, когда через год-два вы попробуете масштабироваться и поймёте, что фундамент у вас чужой и непрочный.

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

Со временем у вас сама собой начнёт появляться дизайн-система. Но она будет состоять только из того, что вам понятно, реально работает и отвечает задачам. Без артефактов гигантских систем и лишних деталей из «космолётов» советчиков из бигтеха.


- -

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

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

Иными словами, это непредсказуемость системы как целого, поскольку её свойства не сводятся к простой сумме свойств её частей.

Хороший пример — человек. У него есть сердце, мозг, лёгкие, руки и ноги. Но ни одна из этих частей не может мыслить, чувствовать или творить. Эти свойства рождаются только в целостной системе, которой является человек.

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

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

- -

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

Неделю ходил в офис. Итоги испытательного срока.

Недавно съездил в московский офис Т-Банка — неделю ходил туда как приличный человек. И внезапно понял, что это мой первый «поход в офис» за последние пять лет, с тех пор как грянул ковид😱.

Т-Банк — первая по-настоящему большая корпорация в моей карьере, прямо тру бигтех 🤌.
И ощущения, конечно, совсем другие.

Тут в офисе тебе и комнаты для медитаций, и кабинки, чтобы поспать (серьёзно), и арома-комната, и фитнес, и бесплатное питание, и даже собственная клиника.
Всё продумано до мелочей: забота, баланс, уют. Но удаленно всё же мне комфортнее, я так продуктивнее, проще контролировать и перераспределять своё рабочее время.

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

За испытательный срок я написал архитектурное решение для SDUI-системы, которую мы сейчас разрабатываем, согласовал его со стейкхолдерами и утвердил. Это и была моя главная задача на входе.

Второй задачей была за время онбординга сделать аудит ДС и предложить улучшения. Такой вот «экспертный» старт 😬

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

- -

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

Костыли — это хорошо

Признайтесь, у кого не было соблазна запретить продуктовым командам всё, кроме компонентов дизайн-системы?
А за нарушение — строго карать.
Ну хотя бы выговором.
В идеале — увольнением 😈

Потому что сколько можно: ходишь по командам, ищешь костыли, стараешься поднять покрытие ДС — а оно всё не растёт.

Но представьте, что вам на завтрак запретили есть всё, кроме гречки.
Круто? 😁

Костыли — не зло. Они — индикаторы.
Без них система была бы негибкой и глухой к изменениям.
Костыль — это сигнал: команда не нашла нужный инструмент в ДС.
Значит, либо его там нет, либо команда о нём не знает.

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

И не забывайте про эксперименты и «снежинки».
Не всё стоит тащить в общий кит, но и игнорировать их нельзя — рано или поздно они всплывут где-нибудь на проде.

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

- -

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

О важности концептуального виденья

Сейчас я и команда в основном работаем над созданием движка низкоуровневой вёрстки для SDUI-фреймворка. И недавно я получил неожиданную просьбу от тимлида разработки: сформулировать концептуальное видение проекта😱

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

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


🔺ЦЕЛОСТНОСТЬ (консистентность)

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

Целостность — это не про одинаковость визуала.
Это про внутреннюю логику, которая чувствуется при работе с системой:
«Да, это работает так же, как и всё остальное».


🔺МОДУЛЬНОСТЬ

Части системы развиваются независимо.
Она должна масштабироваться без разрушения структуры.
Добавление нового — это расширение, а не ломка.


🔺НЕ ПЛОДИТЬ СУЩНОСТИ

Принцип «расширяй, не создавай заново». Перед добавлением новой сущности — поиск аналогов и попытка обобщить.

Перед созданием любой новой сущности — шаг назад:
«Это новое? Или это частный случай уже существующего?»

Система выигрывает, когда обобщает, а не распыляет.
В идеале новая сущность — это выражение закономерности, а не «компонент для конкретного кейса».

Новая сущность должна рождаться не из задачи, а из закономерности.
Мы ищем то, что повторяется, и поднимаем это на уровень абстракции.

Сущность должна отвечать на вопрос:
«Это выражение функции или просто костыль?»


🔺ПРОСТОТА ДЛЯ ПОЛЬЗОВАТЕЛЯ

Сложность решения внутри системы — ок, если внешнее API остаётся простым и предсказуемым.

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


🔺ОБОБЩЕНИЕ

Обобщать — значит замечать закономерности и поднимать уровень абстракции.
Не «кнопка отдельная, карточка отдельная»,
а «интерактивный блок со состояниями», который потом проявляется разными способами.

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


🔺 УНИВЕРСАЛЬНОСТЬ

Язык системы должен быть понятен на любой платформе — разработчикам, дизайнерам и всем пользователям системы.
Универсальность — не про одинаковость, а про общность принципов.


🔺КОМБИНИРОВАНИЕ И ВАРИАТИВНОСТЬ

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


- -

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

Дополнение про виденье

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

Казалось бы, всё довольно очевидно, но я бы не писал манифест, если бы это действительно было так. Например, в противовес такому абстрактному подходу есть мышление «от кейса». И был случай, когда мы чуть не поступили вопреки здравому смыслу. Описывая свойства контейнеров, всерьёз обсуждали поддержку max-height и max-width, но отказ от min-height и min-width в первой итерации — просто потому что «нет кейса». К счастью, здравый смысл победил, и мы поддержали все четыре свойства. А что если бы нет?

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

- -

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

Анимации, продолжение

Кто ответил что-то вроде «удаление одного элемента и добавление другого» — оказался прав. Остальные нет😂 

Что я в итоге сделал:

Разделил анимации появления и исчезновения ещё на две:
1️⃣ собственно появление/исчезновение элемента
2️⃣ уплотнение/расширение списка (когда слот удалённого элемента схлопывается).

Все эти штуки я обозначил как «базовые типы» и ввёл принцип последовательности: запрет одновременного воспроизведения двух и более разных базовых типов.

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

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

Ну а результат для того же самого сценария «удаление → затем добавление» — смотрите ниже. 👇
- -

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

Ищем продуктового дизайнера в команду дизайн-системы Т-Банка — с фокусом на дизайн-токены и автоматизацию.

Что предстоит делать

— Вместе со мной развивать и сопровождать систему дизайн-токенов: расширять, улучшать и модернизировать её.

— Участвовать в проектировании процессов синхронизации токенов между дизайном (Figma) и кодом, автоматизировать экспорт и импорт (JSON и др.).

— Работать с продуктовыми командами, frontend-разработчиками и менеджерами: помогать находить компромиссы и принимать архитектурные решения.

— Готовить и поддерживать документацию, гайды и обучающие материалы, проводить воркшопы и ревью для команд-потребителей.

— Обеспечивать качество системы: accessibility, тестирование токенов и контроль обратной совместимости изменений.

— Инициировать улучшения: ускорять процессы, развивать CI/CD для токенов и экспериментировать с масштабируемостью и производительностью.

Формат: удалёнка, гибрид или офис.

Присылайте ваши CV и кейсы по дизайн-системам Ангелине.

🔎 Смотреть вакансию

- -

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

Вот так теперь выглядит та же анимация удаление+появление


- -

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