Дизайн-инженерия — это подход к проектированию

Что такое дизайн-инженерия

В сложном продукте недостаточно нарисовать набор экранов. Нужно понимать, какие сущности участвуют в системе, какие состояния возникают, какие компоненты должны быть переиспользуемыми, где проходит граница между UI и runtime-логикой, как интерфейс будет проверяться и как решение попадёт в разработку.

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

Это не означает, что дизайнер должен заменить frontend-разработчика. Смысл в другом: интерфейсные решения становятся точнее, когда уже на этапе дизайна понятны component boundaries, состояния, props-like thinking, data dependencies и будущая логика сборки страницы.

Такой подход особенно важен для сложных B2B, B2C и B2E-продуктов, где экран редко существует сам по себе. За ним стоят роли пользователей, права доступа, фильтры, каталоги, статусы, транзакции, документы, карты, таблицы, пустые состояния, responsive-поведение и handoff в разработку.

Почему одной Figma недостаточно

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

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

• что происходит, если у карточки нет изображения;
• как компонент ведёт себя с длинным названием;
• как фильтр меняет выдачу и бейджи;
• как карта и список синхронизируются;
• как mobile bottom sheet связан с активным pin;
• где хранится selected offer;
• как один detail layout работает для разных типов сущностей;
• что является состоянием приложения, а что локальной композицией страницы;
• где должен быть отдельный компонент, а где достаточно adapter logic.

На статичном экране эти вопросы легко скрыть. В runtime они становятся видимыми. Поэтому Live Demo, reference surfaces и компонентная сборка используются как продолжение проектирования, а не как отдельный этап “после дизайна”.

От страниц к screen families

Один из основных принципов — не проектировать продукт как набор изолированных страниц.

Вместо этого интерфейс раскладывается на screen families: группы экранов, которые имеют общую логику, но меняют активные блоки в зависимости от данных и сценария.

Например, detail page может быть не одной страницей, а семейством. Для маршрута она показывает itinerary, stop cards и карту. Для коммерческого объекта — offer groups, BookingWidget, policies и reviews. Для географической локации — карту, связанные места и рекомендации. При этом базовая структура, навигация, сетка и responsive-поведение остаются узнаваемыми.

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

Слои продуктовой дизайн-системы

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

Я разделяю систему на несколько уровней.

Foundations

Токены, цвета, типографика, spacing, radius, shadows, surface rules и базовые visual principles.

Product UI Kit

Базовые элементы интерфейса: buttons, inputs, badges, chips, selects, overlays, menus, tabs, feedback states, navigation primitives. Это нижний слой, который не должен знать бизнес-логику продукта.

Product Components

Компоненты, которые уже несут продуктовый смысл: карточки, offer rows, reservation rows, notification rows, payment method rows, filter units, account tiles.

Product Component Blocks

Крупные переиспользуемые секции: search toolbar, filter panel, hero media header, detail support blocks, BookingWidget, account sections, recommendation rails.

Product Page Layouts

Правила сборки страниц: порядок секций, grid, responsive behavior, sticky zones, mobile stacking, sidebar behavior и условия появления блоков.

Runtime adapters / View-model layer

Слой, который готовит данные и состояние для UI: routes, filters, selected offer, map/list state, booking draft, source-backed labels, callbacks. Он помогает не смешивать visual anatomy с бизнес-логикой.

Reference surfaces

Отдельные поверхности для проверки компонентов, состояний и layout families вне пользовательского маршрута. Они показывают систему отдельно от “красивого финального экрана”.

Компонентные границы

Компонент должен иметь понятную роль и границу ответственности.

Кнопка не должна знать бизнес-логику. Карточка не должна сама решать routing и состояние приложения. Detail block не должен владеть source data. Page layout не должен превращаться в случайный набор локальных div. Runtime adapter не должен становиться дизайн-системой.

Когда эти границы не определены, продукт быстро начинает распадаться: появляются одноразовые компоненты, page-local стили, повторяющиеся состояния и скрытая логика внутри визуальных элементов.

Когда границы описаны, дизайн и разработка начинают говорить на одном языке: что является primitive, что является product component, где начинается block, где lives layout logic, а где находится runtime state.

Пример компонентной дисциплины: Divider

Хороший пример — даже маленький divider.

В слабой системе он часто остаётся случайным border-top внутри конкретного экрана. Через некоторое время появляются разные оттенки, разные отступы, разные толщины и разные правила поведения на mobile.

В зрелой системе даже такой элемент имеет место:

• в Figma anatomy;
• в токенах или visual rules;
• в Product UI Kit как primitive / wrapper;
• в коде как компонент с понятным API;
• в reference surface;
• в документации;
• в правилах использования внутри карточек, detail pages и layout blocks.

Это не усложнение ради усложнения. Это способ не позволить маленьким локальным решениям накапливаться в системный долг.

Runtime-first проверка

Runtime-first подход не означает “сразу писать production-код”. В контексте портфолио и дизайн-системы это может быть Live Demo, showcase app, reference surface или локальная сборка компонентов.

Задача такого слоя — проверить, как интерфейс ведёт себя за пределами идеального макета:

• как карточки работают с разной плотностью данных;
• как sections включаются и выключаются;
• как detail page адаптируется на desktop и mobile;
• как map/list sync связан с карточками;
• как selected offer попадает в BookingWidget;
• как empty, no-photo и no-results states выглядят без ручной доработки;
• где нужна component boundary, а где достаточно data adapter.

Такая проверка помогает принимать решения не только на уровне “выглядит хорошо”, но и на уровне “это можно поддерживать”.

Frontend-aware workflow

Frontend-aware подход помогает проектировать интерфейс не в отрыве от реализации.

В моей практике React, TypeScript, Next.js и Vite используются как рабочая среда для проверки продуктовой системы: portfolio site, Live Demo, showcase surfaces, component layers и runtime adapters.

Это не позиционирование как full-stack engineer. Это способ лучше понимать, как интерфейс будет жить в продукте:

• какие props нужны компоненту;
• какие states должны быть first-class;
• какие variants стоит описать заранее;
• где проходит граница между layout и data;
• какие responsive rules нужно проверить;
• где Figma и код могут разойтись;
• что нужно передать команде разработки.

Reference surfaces и inspection layer

Reference surfaces — это не пользовательские страницы. Это surfaces для проверки системы.

Они помогают увидеть:

• все варианты карточек;
• состояния компонентов;
• filters;
• offer cards;
• booking components;
• account components;
• page layouts;
• responsive frames;
• fallback states.

Такой inspection layer позволяет оценивать систему не по одному красивому экрану, а по тому, насколько она выдерживает разные данные, states и варианты использования.

Handoff

Handoff в дизайн-инженерном подходе — это не просто ссылка на макет.

Хороший handoff должен объяснять:

• screen family;
• component map;
• variants and states;
• data dependencies;
• runtime boundaries;
• responsive behavior;
• known limitations;
• validation notes;
• visual QA expectations.

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

Что даёт такой подход

Дизайн-инженерия помогает превратить интерфейс в систему, которую можно объяснить, проверить, собрать и передать дальше.

Она снижает риск того, что:

• одинаковые паттерны будут решены по-разному;
• Figma и код разойдутся;
• компоненты начнут владеть чужой логикой;
• временное решение станет постоянным;
• page layout превратится в локальную композицию;
• edge cases появятся только после разработки;
• handoff будет требовать постоянных догадок.

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