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

Для решения этой проблемы была создана команда дизайн-системы Mollie , но вместо подхода, основанного на проектах, мы решили работать как продуктовая команда. Поэтому мы сформулировали задачу с помощью вопроса «Как мы можем?»:

«Как мы можем обеспечить быстрое исследование и внедрение высококачественных пользовательских интерфейсов?»

Этот вопрос помог нам думать по-другому. Самым большим осознанием было то, что мы могли бы создавать более качественные компоненты, если бы сосредоточились на пользовательском контексте, а не на изолированных платформах (веб, iOS и Android). Этот подход заставил нас думать о наилучшем возможном опыте в зависимости от размера экрана и методов ввода. Поэтому мы определили объем наших компонентов на основе этих свойств, поэтому все компоненты должны будут предоставлять поддержку и функции на основе следующего:

• Размер экрана: Большой или Маленький.
• Метод ввода: мышь, клавиатура или сенсорный ввод.

Одна библиотека для всех контекстов

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

1. Большой и маленький экран
2. Большой экран или Маленький экран
3. Только большой экран
4. Только маленький экран

1. Большой и маленький экран

Это самый распространенный тип компонента, который у нас есть. Размер, отступы и стили остаются одинаковыми для разных размеров экрана и методов ввода. Кнопки, вкладки, значки и многие другие подпадают под эту категорию.

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

2. Большой экран или маленький экран

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

3. Только большой экран

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

4. Только маленький экран

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

Возвращаясь к первоначальному вопросу «как мы можем?», я могу с уверенностью сказать, что этот подход был решающим для решения нашей проблемы. Наиболее значительное влияние оказала возможность принимать масштабируемые проектные решения. Где решение, которое мы принимаем, например, для небольших размеров экрана, может быть использовано в наших приложениях на разных платформах. У нас все еще есть молодая дизайн-система, но она быстро превращается в зрелый продукт.

Бонус: наша метрика для строительных компонентов

Принятие не является нашей основной метрикой, по крайней мере, на данный момент. Поскольку мы только что провели редизайн, 100% платформы построено с использованием нашей системы дизайна. Вместо этого мы ориентируемся на доступность компонентов и токенов. По мере того, как мы находим способы улучшить эти элементы, мы помечаем элементы как «Известная проблема» при определении возможности/ошибки. Что затем становится задачей для нашей команды дизайн-системы.

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

Кайо Манзотти (Caio Manzotti ) — старший дизайнер продуктов для систем проектирования компании Mollie , базирующейся в Амстердаме.