#промышление Введение

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

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

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

И вот тут переходим к моей идее и философии.
Что если большую часть компонентов ДС будут делать продуктовые дизайнеры? 🤔

Концентрировать всё знание и власть о ДС удобно на ранних стадиях её развития. Но с ростом количества продуктовых команд, брендов и платформ начинает вставать вопрос масштабирования.

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

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

Но что если дать дизайнерам простой и понятный инструмент создания компонентов? Окей, с простым я, наверное, загнул — совсем просто вряд ли получится..😬

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

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

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

- -

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

Уже в эту пятницу стартуют Дизайн-выходные в Казани!

30 мая в 14:00, зал №11 — расскажу про своё видение одной из важнейших функций дизайн-системы — влияния на мышление дизайнеров.

Поговорим о философии и подходах, с помощью которых дизайн-система может формировать нужный майндсет, поощрять правильные решения и направлять ход мыслей дизайнера в нужное русло.

Увидимся на Д-в!


- -

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

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

Философия и подходы, с помощью которых дизайн-система может формировать определённый майндсет, поощрять и направлять ход мыслей дизайнера в нужную сторону.


📱 Смотреть на YouTube

📱 Смотреть в VK

- -
#дизайнвыходные #казань #выступление

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

Вопросы из зала после выступления можно посмотреть пока тут

- -

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

Ладно, сдаюсь, выложил ответы зрителей тоже на ютьюб 😁

📱 Смотреть тут

Чем отличается дизайн для 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