10 мифов о дизайн-системах

Давайте же разберем 10 самых распространенных заблуждений о дизайн-системах и узнаем, как обстоят дела на самом деле.

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

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

Почему дизайн-системы по-прежнему остаются непонятыми

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

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

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

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

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

Давайте же разберем некоторые из них.

1. Дизайн-система — просто набор компонентов в Figma

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

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

Основа качественных компонентов — базовые переменные или токены. 

Есть люди, которые создают систему, поддерживают ее, рассказывают о ней другим и выступают в ее защиту перед заинтересованными сторонами.

Есть выстроенные процессы для добавления компонентов и направления запросов, для получения обратной связи и для совместной работы. А документация соединяет все эти точки воедино.

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

2. Работа над дизайн-системой — это не творческая работа

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

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

3. Дизайн-система ограничивает креативность, не позволяя создавать что-то новое

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

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

4. Создание дизайн-системы требует много денег и времени

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

На мой взгляд, это дороже и отнимает намного больше времени.

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

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

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

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

5. Мне нужно создать дизайн-систему, которая будет работать следующие 5–10 лет

Помните, мы строим не здание. Под устойчивостью дизайн-системы понимается ее масштабируемость, возможность легко вносить изменения и обновления. Технологии стремительно меняются, тренды приходят и уходят, что напрямую отражается на фирменных цветах и типографике брендов. Поэтому не пытайтесь предсказать, каким будет актуальный UI через 5–10 лет.

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

6. Как только дизайн-система готова, работа закончена

Дизайн-система — живой организм. Ее нужно поддерживать, тестировать и дорабатывать, чтобы она оставалась актуальной.

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

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

7. UI-кит = дизайн-система

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

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

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

8. Дизайн-система — это в первую очередь дизайн

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

9. Никто не читает документацию дизайн-системы

Недавно eBay перезапустил сайт своей дизайн-системы, и я готова проводить целые часы, изучая этот ресурс.

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

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

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

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

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

10. «Преодоление разрыва между дизайном и кодом» означает, что дизайнеры должны понимать последний

Вопрос «должны ли дизайнеры изучать код?» неизменно вызывает жаркие споры.

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

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

Аналогичная ситуация возникает, когда вы передаете свои Figma-макеты разработчику — это ваши инструкции относительно того, как должен выглядеть и работать интерфейс. Не вы пишете код, но чем лучше вы сможете донести свои идеи (потому что понимаете, что нужно разработчику), тем лучше будет результат.

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

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

Спасибо за внимание!