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

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

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

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

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

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

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

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

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

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

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

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

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

• -

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

В этом посте были ссылки, но мы их удалили по правилам Сетки