Дизайн-системы в 2020 году: где источник истины?

Иногда системы лишь масштабируют проблему

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

Дизайнеры создают визуальный язык для бренда, руководство по стилю А+ класса с 15 страницами, абстрактный набор из 5 основных элементов (например, Uber) и более 50 конкретных визуальных элементов.

Дизайн-система Slack Engineering глазами дизайнера:

Затем разработчики создают современную библиотеку компонентов с последними функциями React, такими как хуки и Context API. Они делают все возможное, чтобы реализовать компоненты дизайна в компоненты кода, а затем передают эту библиотеку команде разработчиков приложений.

Дизайн-система Polaris от Shopify с точки зрения разработчика:

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

В скором времени нарушается единство дизайна и кода.

Почему это происходит?

Дизайн-система — это:

«Библиотека визуального стиля, компонентов и других аспектов, задокументированных и выпущенных отдельным лицом, командой или сообществом в качестве инструментов разработки кода и дизайна для повышения эффективности и согласованности принятия продуктов».

Суть проблемы заключается в словах «в качестве инструментов разработки кода и дизайна«.

Дизайнеры должны работать вместе с разработчиками над созданием UX/UI. Однако они работают с различными источниками истины и используют разные инструменты.

Так что же является источником истины: дизайн или код?

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

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

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

Обе эти цели передаются пользователям с помощью кода. Пользователи не взаимодействуют с файлами Sketch или ассетами Zeplin, поэтому в идеале дизайнеры и разработчики должны стремиться к общению через код.

Однако разработчикам легче взглянуть на дизайн, чем дизайнерам на код. Посмотрите на этот компонент React Chart:

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

Как дизайнеры могут участвовать в работе над кодом?

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

Чтобы объединить дизайн-систему в один источник истины, необходимо предоставить дизайнерам визуальный интерактивный доступ к коду разработчиков.

Как это работает?

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

Вместо того, чтобы «закапывать» код компонентов в репозитории на GitHub, его можно визуализировать для дизайнеров так, чтобы они могли видеть и отслеживать изменения, обеспечивать обратную связь и принимать активное участие в рабочем процессе.

Со стороны разработчика, такие инструменты, как Bit.dev, позволяют размещать и управлять всеми компонентами кода в общей коллекции в облаке.

Каждый компонент можно просматривать и редактировать визуально. В будущем, интерактивный визуальный интерфейс может предоставить дизайнерам наглядный способ взаимодействия с кодом. Например, простая панель свойств React позволяет редактировать стиль кнопки.

Затем эти компоненты можно интегрировать в такие инструменты, как Sketch или InVision DMS.

Интересной новинкой в этой области являются дизайн-токены — технология, с помощью которой дизайнеры могут изменять низкоуровневые параметры стиля прямо из дизайн-инструментов. Это лишь вопрос времени, когда эта технология появится в таких инструментах, как Sketch и InVision DMS.

С интеграцией Bit.dev-GitHub дизайнер может визуально редактировать стили компонента, сохранять изменения, а фактический компонент кода будет обновляться с новой версией. Каждый репозиторий GitHub мгновенно получит пул-запрос с новой версией компонента, и каждое приложение будет обновлено.

Заключение

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

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