Создание дизайн-системы от А до Я: опыт компании qwerty.Software. Часть 1

Привет, меня зовут Витя Житомирский и я главный дизайнер в Qwerty.Software. Этот цикл статей будет посвящен тому, как мы в нашей компании работаем над дизайн-системой. Надеюсь вам будет полезно узнать о подобном опыте с самого начала — зарождения самой идеи. Расскажу о важности дизайн системы для сотрудников компании, о том для чего она им пригодится и как упростит работу. Я не буду рассказывать КАК делать дизайн систему с технической точки зрения (об этом написано достаточно), а расскажу ЧЕМ ее наполнять и ПОЧЕМУ именно этим, для получения максимального эффекта и упрощения работы.

Photo by Kaleidico on Unsplash

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

В этой статье расскажу:

1. Как возникла необходимость в дизайн системе

2. Преимущества дизайн системы

3. Инструмент проектирования

Как возникла необходимость в дизайн системе

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

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

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

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

Guideline — свод правил работы над интерфейсом, описанный в текстовом формате. Такие компании как google с их дизайн системой material design в своих гайдлайнах описывают собственный подход к разработке интерфейсов. Их компонентами может воспользоваться любой желающий, поэтому для таких открытых фреймворков (полностью готовых библиотек компонентов в коде) крайне важно доступным языком описать принципы и правила работы с их компонентами.

Дизайн система — набор компонентов (желательно в коде), объединяющий в себе ui-kit (то есть весь визуал, разобранный на мелкие интерфейсные детали) и guideline, в котором описаны принципы работы интерфейса, а также подход к разработке продукта. Material design от google, описанный выше — это классический и самый популярный пример дизайн-системы.

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

Атомарный дизайн — если очень коротко — это методология (принцип и последовательность действий), по которой строится дизайн система. Описанная Бредом Фростом в 2013 году эта методология делит элементы интерфейса на:

  • атомы: сетка, типографика, цвета, иконки
  • молекулы: кнопки, инпуты, дропдауны и т.д.
  • организмы: навбар/футер, карточки товара и т.д.
  • шаблоны: вайрфрейм целой страницы с «рыбным контентом»
  • страницы: полностью готовый дизайн страницы (например текущая версия главной страницы вашего сайта с реальным контентом
Картинка из книги Брэда Фроста “атомарный дизайн” наглядно показывает различия между составляющими (элементами) системы

Картинка из книги Брэда Фроста «атомарный дизайн» наглядно показывает различия между составляющими (элементами) системы

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

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

Почему мы выбрали именно дизайн систему, а не статичный UI Kit или написание Гайдлайна? Это более комплексный подход, который дает нам такие преимущества (сразу прошу меня извинить за некоторые очевидные пункты, о которых уже сказано-пересказано, но т.к. я хочу, чтобы статья была понятна и для новичков, то перечислим все, которые удалось найти):

  • Ускорение выкатки фич
    С внедрением дизайн системы в работу дизайнер перестает думать и переживать о визуальной части продукта. Его главной заботой становится ux часть задачи (или целой страницы) и как следствие скорость работы возрастает, т.к. дизайнер пользуется уже готовыми визуальными компонентами. Он лишь оформляет их в удобном для пользователя виде. Также при желании (или в экстренной ситуации, например когда все дизайнеры недоступны), любой сотрудник в компании может собрать MVP (minimum viable product) своей идеи за считанные минуты (ну ладно, часы: )) и отдать в разработку, а затем, например, в а/б тест.
  • Назвать каждый элемент правильно
    Дизайн система позволяет обучить минимальному пониманию работы элементов интерфейса каждого сотрудника и повышает насмотренность (это когда ты видел столько вариантов интерфейса, что теперь можешь отличить хороший от плохого). А также дает возможность каждому сотруднику называть элементы дизайна правильно (например навбар ≠ хэдер) и разговаривать на одном языке. Поверьте многие из ваших коллег совсем не разбираются в дизайнерской терминологии и иметь единый источник правды, к которому можно обратиться в любой момент будет полезно для каждой из сторон. Это упростит процесс постановки задачи дизайнеру с одной стороны и понимание задачи для самого дизайнера.
  • Объяснение всех элементов (зачем нужны и почему именно такие)
    Бывает такое, что когда кто-то из коллег задает тебе коварный вопрос «а почему этот инпут именно такой» и зачастую ответа на этот вопрос у тебя нет, потому что этот элемент был выбран если не случайным, то спонтанным образом (или у него была какая-то логика, которая нигде не была записана, и, следовательно, уже была забыта) в какой-то момент для решения какой-то определенной задачи, а потом его просто стали копировать во все проекты. Дизайн система дает возможность заглянув в нее в будущем понять важность и нужность каждого элемента дизайна. И в момент когда кто-нибудь найдет лучшее решение, например для дропдаун меню, мы сможем заменить его и описать чем он лучше и ценнее предыдущего.
  • Элементы с одинаковой логикой работы и дизайном
    Разработчики больше не будут ругаться на новый только что придуманный дизайнером навороченный дропдаун, логику работы которого он придумал только что и теперь это необходимо реализовать. Теперь все элементы будут хорошо продуманы «на берегу», а если мы столкнемся с новой проблемой в каком-то компоненте, мы сможем додумать его и обновить мастер-компонент, который, при желании, поменяется во всех остальных местах нашего дизайна. Поведение при адаптации компонента тоже будут продуманы с самого начала, что облегчит работу в дальнейшем. Даже цвет можно вычислить арифметически (об этом в следующей статье цикла)
  • Большое количество сайтов
    Наша компания поддерживает и развивает множество самостоятельных сайтов на разном дизайне, но в одной тематике. В такой ситуации необходимо структурировать контент так, чтобы сайты выглядели по-разному, но структура некоторых важных элементов оставалась одинаковой (например навбара или формы заказа, которые выглядят одинаково на всех сайтах, но имеют разные цвета или наполнение)
  • Дизайн принципы
    Один раз определившись о том какие принципы дизайна исповедует компания в будущем будет намного проще обсуждать тот или иной элемент интерфейса или принимать продуктовые решения имея четко определенные рамки, за пределы которых нельзя заходить. Например может быть строго запрещено использование темных паттернов в вашем дизайне, такие как скрытая функция отписки от премиум-аккаунта и т.д.
  • Сокращение времени на тестирование
    Так как все элементы интерфейса будут прописаны заранее, тестировщикам не придется уточнять принцип работы какого-либо элемента интерфейса и как следствие будет затрачено меньше времени на проведение тестирования.

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

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

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

Этапы мы наметили себе такие:

1. Работа над атомами (здесь же необходимо предусмотреть всю маркетинговую информацию, как описано выше)

2. Работа над молекулами, организмами

3. Разработка шаблонов и страниц

4. Анимация и микровзаимодействия

5. Аналитика. Что и как измерять в дизайн системе через фигму

Инструмент проектирования

Для разработки дизайн системы подойдет любой известный в дизайнерском мире графический редактор: sketch, adobe xd, даже фотошоп, однако мы в своей компании выбрали фигму и вот почему:

  • Работа на всех ОС. Можно работать как на Windows, так и на Mac. Как во вкладке браузера, так и в десктопном приложении (на IPad OS пока еще есть проблемы даже с внедрением курсора, я думаю в скором времени это пофиксят, т.к. все больше и больше дизайнеров пересаживаются с десктопных устройств на планшетные)
  • Работа через облако. Нет необходимости грузить каждый раз документ в облако и каждый сотрудник компании всегда имеет доступ к самой последней версии файла
  • Новые фичи. Команда фигмы очень качественно подходит к разработке новых функций для своего продукта. Многие необходимые дизайнерскому сообществу опции становятся доступными именно в фигме
  • Figma Community. База бесплатных дизайнерских полезностей прямо в фигме. Позволяет найти и скачать множество полезных штук, от дизайн-систем (ну или Ui-KITов) до шаблонов для ux-исследований (таких как user journey map или шаблонов для проведения дизайн-спринтов)
  • Библиотека компонентов. Это значит, что если у вас есть библиотека компонентов внутри команды, то любой элемент из библиотеки, который вы используете в ваших макетах зависит от родительского элемента в библиотеке и изменив его в исходном компоненте он поменяется во всех ваших проектах
  • Еще у фигмы есть встроенная система аналитики для дизайн систем, где вы можете получить много полезной статистики об используемых компонентах, если будет интересно могу рассказать об этом в последующих статьях

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

Для платного пользователя работа над созданием макета будет выглядеть примерно так, как показано в этом видео:

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

Каждая дизайн система должна иметь название, нашу мы решили назвать excelsior — латинское слово, означающее «всё выше». А также это разновидность шахматной задачи, когда пешка из первоначального положения ход за ходом движется в ферзи. Данное описание очень хорошо подходит под нашу стратегию развития, поэтому мы остановились именно на этом названии

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

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

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

0
2 комментария
Александр Попадьин

Спасибо, огонь.

Ответить
Развернуть ветку
Сергей Галанин

Добавил в закладки и жду продолжения

Ответить
Развернуть ветку
Читать все 2 комментария
null