Ваша библиотека компонентов в Sketch — это не дизайн-система

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

Перевод Николая Геллара, автора блога о дизайне Sketchapp.me.

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

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

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

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

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

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

Удостоверьтесь, что в вашей команде есть фронтенд-дизайнеры. Если у вас их нет или недостаточно, наймите несколько. Есть множество фронтенд-дизайнеров, стремящихся построить чистый, красивый, модульный, многоразовый код интерфейса.
Установите управляемый шаблонами междисциплинарный рабочий процесс, который подчёркивает необходимость раннего перехода в браузер и итерацию фронтенд-кода. Вместо того чтобы дизайнеры оставались в комфортных стенах своих инструментов статического дизайна, поощряйте совместную работу с разработчиками, чтобы дизайнерское видение пробивалось в фактический код, который будет развёрнут в реальных продуктах.
На ранней стадии создания вашей дизайн-системы обсудите методы, которые вы будете использовать для развёртывания компонентов интерфейса в код продукта, а затем быстро оцените этот рабочий процесс, используя один компонент («Окей, вот компонент кнопки нашей дизайн-системы, как мы используем его на нашей домашней странице?»).
Понять трение между созданием функционирующих компонентов интерфейса, использующих определённые технологии (такие как React, Angular, Twig и другие) и создать систему дизайна, которая будет больше, чем внедрение любой технологии.
Убедитесь, что живые компоненты и код отображаются вместе с любой дизайнерской документацией и скриншотами в руководстве по стилю.

Такие инструменты, как Sketch, InVision Studio, Adobe XD, Figma и другие, наконец, признали важность создания многократно используемых компонентов интерфейса и обмена ими между членами команды.

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

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

Теперь идите и создайте свои тостеры.

#дизайн