Компоненты,
которые работают
как система.
Как мы проектировали гибкие компоненты до появления нативных возможностей Figma — и готовили их к использованию в server-driven интерфейсах.
Настоящие примеры компонента и его документации. Нажми на изображение, чтобы рассмотреть детали в исходном разрешении.
Один компонент.
Разные сценарии.
В дизайн-системе компонент должен быть не просто удобным для дизайнера. Он должен сохранять поведение в разных макетах, быть понятным разработке и масштабироваться на продукты нескольких команд.
Сохранить пропорции
без Aspect Ratio.
На тот момент в Figma ещё не было нативного параметра aspect ratio. При этом дизайнерам требовалось переключать соотношение сторон изображения и свободно менять размеры экземпляра, не ломая пропорции.
16 : 9
Геометрия вместо ручных ограничений
Внутри варианта компонента размещалась вспомогательная прямоугольная распорка с заданными пропорциями. Она удерживала нужное соотношение сторон при изменении размеров контейнера. Для каждого формата — своя геометрия.
Так выбор пропорции становился свойством компонента, а не задачей, которую каждый дизайнер решает вручную.
Варианты, состояния и поведение.
В документации ImageView V2 показаны параметры AspectRatio, Scale (Fit / Fill) и выбор ресурса Image / Icon. Компонент оставался предсказуемым для дизайнера и понятным при переносе в SDUI.
Фрагмент оригинальной документации компонента · нажми для увеличения
Компонент — это ещё
и правила использования.
До публикации мы проверяли документацию вместе с дизайнерами и разработчиками: достаточно ли понятны свойства, состояния, ограничения и сценарии применения. Обратная связь помогала устранять неоднозначности до того, как компонент попадал в работу продуктовых команд.
Поведение
Какие параметры можно менять и что остаётся неизменным.
Примеры
Как использовать компонент в реальных интерфейсных сценариях.
Проверка
Ревью с дизайнерами и разработчиками перед публикацией.
Size · Paddings · Appearance · Event — реальные материалы документации
От компонента в Figma
до схемы для продукта.
Каждый компонент готовился к работе в архитектуре Server-Driven UI. Для него создавалось JSON-описание через внутренний плагин Альфа-Банка. Это связывало свойства компонента в дизайне с параметрами, которые могли использовать продуктовые команды.
Figma
плагин
описание
интерфейс
Схема иллюстрирует рабочий процесс; внутренние JSON-файлы и технические спецификации не публикуются.
Гибкость для нескольких
продуктовых команд.
Второй компонент был проще по устройству, но важен с точки зрения масштабирования: его использовали разные команды и сценарии. Поддержка SDUI позволяла изменять состав и наполнение блоков на страницах без отдельного релиза клиентского приложения — в рамках возможностей серверной конфигурации.
Визуальная схема обобщена: название и точный вид второго компонента можно уточнить после получения макета.
Дизайн-система —
это инфраструктура.
Эта работа была не только про интерфейсные элементы. Она объединила инженерное решение внутри Figma, понятные правила использования и возможность управлять интерфейсом через SDUI. Такой подход снижает ручную работу и помогает командам развивать продукт согласованно.
← Вернуться ко всем кейсам