UXPUB 🇺🇦 Дизайн-спільнота

Cover image for Почему дизайн-системы терпят неудачу и как заставить их работать в 2020 году
Редакція
Редакція

Опубліковано

Почему дизайн-системы терпят неудачу и как заставить их работать в 2020 году

После отказа от нашей первой дизайн-системы в конце 2018 года мы создали новую и улучшенную дизайн-систему с нуля.

Еще в 2018 году, когда я начал работать в WebNL, меня попросили улучшить взаимодействие между дизайном и разработкой в нашей компании. Я создал систему, которая автоматически извлекала дизайн-токены из проектов Sketch и переводила их в переменные SCSS. Это была наша первая дизайн-система.

По многим причинам она потерпела неудачу. Вы можете прочитать о принципах ее работы и причинах неудачи, в моей предыдущей статье.

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

Переход на Figma

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

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

Figma стала нашим новым инструментом дизайна. Она отлично подходит для построения дизайн-системы благодаря функции библиотеки компонентов. Компоненты могут совместно использоваться в библиотеке между файлами дизайна, и их можно вставлять и извлекать, как код в системе управления версиями. Для нас это было намного лучше, чем то, что предлагал Sketch в то время, даже в сочетании с Invision Design System Manager.

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

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

Это убедило меня перейти от использования Sketch в качестве основного инструмента проектирования к Figma. Но решить это для себя было недостаточно. Я должен был убедить всю свою команду.

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

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

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

Хотя переход на новый инструмент, на самом деле, на этом не закончился. Сначала было много жалоб на такие мелочи, как перенос изображений внутри фреймов или создание масок. В Figma и Sketch это работало немного по-разному, что требовало от дизайнеров привыкания к таким вещам.

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

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

Исследование потребностей пользователя

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

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

Примерно в то же время я пошел на митап в другое агентство под названием Angi Studio. Они специализируются на создании дизайн-систем для своих клиентов. Они также разработали инструмент под названием Design System Checklist. Он берет начало из упражнения, созданного Натаном Кертисом.

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

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

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

Создание стартового набора

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

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

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

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

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

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

У интернет-магазинов существует много паттернов, к которым пользователи уже привыкли. Они ожидают такого поведения от интернет-магазина, и при создании MVP отклоняться от этого не рекомендуется. Благодаря этому я смог сделать эти шаблоны довольно подробными. Лучшие практики, такие как соблюдение Общего регламента по защите данных (GDPR), могут быть заранее учтены.

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

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

Документация в Zeroheight

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

К сожалению, тогда Design System Manager не предлагал поддержку Figma. Но это не помешало нам перейти на Figma. Я верил, что поддержка Figma появится в ближайшее время, и, если нет, то какой-нибудь другой инструмент заполнит этот пробел. И я был прав. Через несколько месяцев мы обнаружили, что Zeroheight предлагает те же функции, что и Invision Design System Manager, но для Figma.

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

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

Поскольку мы перестраиваем нашу кодовую базу, наши компоненты создаются с использованием Vue, Laravel и BEM. Это означает, что мы используем отдельные файлы HTML, SCSS и Javascript, в основном из-за SEO. Поэтому я также должен показать это отдельно в нашей документации.

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

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

Принятие дизайн-системы дизайнерами и разработчиками

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

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

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

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

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

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

Следующий год: команда дизайн-системы и процесс

Чтобы увидеть, как система проектирования оценивается по зрелости, John Gully и Marcel Somers из PatternPack создали модель зрелости дизайн-систем. Эта модель варьируется от непоследовательной стадии, когда дизайн-система отсутствует, до управляемой, когда процесс библиотеки паттернов встроен в организацию.

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

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

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

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

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

Вывод

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

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

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

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

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


Перевод статьи uxdesign.cc

Найстарші коментарі (0)