Чем отличается дизайн для SDUI (он же BDUI)?

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

Для начала важно сделать шаг назад и понять: на что именно влияет технология, и какие вообще бывают варианты реализации SDUI.

Ключевые области, которых касается внедрение безрелизности, — это бизнес-логика, вёрстка и автоматизация.

🌟Начнём с бизнес-логики.
Бизнес-логика в данном случае — это то, что управляет реакцией приложения на действия пользователя.
"Если пользователь нажимает на кнопку — показывается окно выбора..." — вот подобные штуки и есть бизнес-логика.

Она может быть реализована по-разному. Чаще всего встречаются три варианта (которые могут комбинироваться):

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

— Толстый клиент с управлением через actions. Здесь логика описывается в виде процедур или функций, часто — довольно атомарных и гибко настраиваемых. Контракт (обычно это JSON с вёрсткой) уже содержит вызовы этих функций. Например, в случае перехода достаточно указать в контракте саму функцию и её параметры (тип перехода, линк и т. д.).

— Толстый клиент с загружаемыми скриптами. В этом варианте бизнес-логика исполняется на клиенте, но поставляется с сервера в виде загружаемых скриптов — чаще всего на JS.

Как это влияет на работу дизайнера?

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

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

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

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


- -
#sdui #bdui #бизнеслогика

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

Чем отличается дизайн для SDUI (он же BDUI)?
продолжение

Бизнес-логику мы уже рассмотрели — теперь хочется перейти к другим двум ключевым аспектам SDUI: вёрстке и автоматизации.


🌟 Верстка

Здесь главное различие — гранулярность системы. То есть, насколько «мелко» можно управлять интерфейсом через контракт: какие сущности доступны и на каком уровне атомарности.

Возможны разные варианты:
— Виджетная архитектура с хранением вёрстки на клиенте
— Обращение к элементам дизайн-системы, также хранимым на клиенте
— Гибкий отрисовщик, построенный на примитивах, с распределённым хранением вёрстки (часть элементов на клиенте, часть, например компоновка и параметры декоратора, на сервере).

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

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

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

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

А ещё, помимо самой вёрстки, хочется сказать пару слов о верстальщике. Эта роль при переходе на SDUI меняется радикально.

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

А может быть и другой сценарий: часть задач верстальщика уходит к дизайнеру, особенно если в системе уже есть автоматизация (о ней — чуть ниже).


🌟 Автоматизация

Здесь всё проще. Автоматизация бывает и вне SDUI, но именно переход к этой архитектуре обычно стимулирует её активное развитие.

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

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


- -
#sdui #bdui #верстка #автоматизация

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

Завтра у меня первый рабочий день в роли «Эксперт-дизайнер команды дизайн-системы и DesignOps» в Т-Банке.

Буду помогать с внедрением SDUI в систему.

Собственно, это и есть та самая Big News. На самом деле, за этим решением стоит целая эпопея — и даже сложно понять, с чего начать рассказ: хочется поделиться многим.

Когда я начал искать новую работу в январе, был уверен, что благодаря нетворкингу закрою вопрос за два, ну максимум три-четыре месяца. Думал: потом напишу в канал пост на тему «Каково это — искать работу выше сеньора?», где по шагам распишу весь процесс.

А теперь ответ на этот вопрос укладывается в одно слово: ЖОПА.

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

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

Я расширил круг — стал рассматривать не только позиции директоров, экспертов и лидов, но и просто сеньорские, не только продукт, но и студии. Понизил зарплатные ожидания.

Это сработало: получил оффер от студии INET — на позицию директора всего дизайн-департамента.

Честно — я очень благодарен ребятам. Наверное, они тогда просто спасли меня от карьеры курьера. Было непонятно, сколько ещё бы продлился мой поиск, а деньги начинали заканчиваться.
И задачи там были интересные: перестроить департамент, где помимо интерфейсных дизайнеров были графдизайнеры, арт-директора, моушн, брендинг, SMM. Отдельный вызов — погрузиться в студийную специфику, процессы, тендеры.

Но потом случились дизайн-выходные — и сообщение от команды Т-Банка.
Сначала всё выглядело как нетворкинг: «давай познакомимся». Поговорили про SDUI. А потом… последовало предложение, которое невозможно было игнорировать.

Я искренне благодарен студии INET за доверие и возможность. Но снова заняться дизайн-системами, да ещё и фактически продолжить проект внедрения SDUI, — это шанс, от которого сложно отказаться.

И вот, сижу жду курьера со служебным макбуком и предвкушаю много нового контента для канала 😁

- -

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

Пост‑наблюдение

Раньше было сложно найти сильного продуктового дизайнера: в портфолио — «сайтики» или графдизайн, а нужно было — метрики, UX, гипотезы и вот это всё.

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

И вот обратная проблема: сейчас почти у всех в кейсах акцент на проектировании, метриках, аналитике и исследованиях. А сам интерфейс (UI) зачастую базовый — хотя на самом деле запрос в первую очередь на сильный визуал.

Даже работа с дизайн-системами и UI Kit’ами встречается чаще, чем по-настоящему интересный с визуальной точки зрения сайт!

Кстати, студия всё ещё в поиске мастера креативного веб-дизайна.
Если это про вас — 🔎 откликайтесь
Или пишите сразу Максу — @shvahin

- -

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

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

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

Книга уже доступна для предзаказа 🛒

А здесь, в статье, можно найти промокод на скидку в 30%. 🛍

- -

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

Почему я всё ещё работаю «на дядю»
(нерегулярная рубрика "Дед забыл выпить таблетки")

Сейчас модно говорить: «Делай своё, стань фаундером, уволься и забудь про найм», а работа в компании подаётся как временный этап.

Да и меня многие знакомые часто спрашивают: «А почему ты не откроешь свою студию, курсы или продукт (нужное подчеркнуть)?»

А я скажу наоборот: иногда оставаться в найме — это лучший выбор.

И тут я тоже, своего рода, учёный из афоризма:

«Учёный — это человек, который удовлетворяет собственное любопытство за счёт государства».

Только вместо государства — крупная компания, а вместо лаборатории — продукт с десятками команд.

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

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

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

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

- -

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

Не люблю я молекулы

В своих дизайн-системах я стараюсь обходить каноничный нейминг по Фросту с «атомами», «молекулами», «организмами»…
Идея вложенности и иерархии мне нравится, но вот эти названия... 🤦‍♂️

Поэтому у меня чаще встречаются слова вроде: basics, simple items, complex items, widgets.
А слова «организм» и особенно «молекула» я не использую. Более того, когда их произносят другие — у меня слегка дёргается глаз.

Почему? Одно видео, лет 20 назад, навсегда сломало для меня слово «молекула».
Пришлось изрядно покопаться, чтобы найти именно с той самой озвучкой 🤌

Но я его нашёл 😁

⚠️ Осторожно: после просмотра слово «молекула» уже никогда не будет прежним.

- -

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

Дайджест январь-август 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