что такое дизайн система и как ее проектировать
Подборка толковых материалов, которые помогут понять, что такое дизайн-системы, зачем они нужны (и когда не нужны) и как их создавать.
Что такое дизайн-системы и чем полезны
Дизайн-системы — большие наборы правил и готовых элементов интерфейса, которые дизайнеры и разработчики создают, чтобы ускорить и удешевить разработку новых версий сайтов и приложений. Дизайн-системы помогают создавать интерфейсы, которые понятны людям, логично устроены и оформлены в едином стиле. Самый, наверное, известный пример, это дизайн-система Material Design от Google, на которой строится множество приложений на Андроиде.
Обычно дизайн система включает в себя несколько больших разделов. Набор разделов может варьироваться в зависимости от компании и количества продуктов у неё. Чем больше компания, тем более полная и продуманная дизайн-система ей нужна. Вот, что в них может входить:
Ниже я собрал материалы, которые пригодятся, чтобы понять пользу дизайн-систем и внедрить их у себя в компании.
Статьи про дизайн-системы
Дизайн-системы: UI-киты, CSS-фреймворки, гайдлайны
Лонгрид, часть тильдовского курса «Дизайн в цифровой среде», рассказывающая про разные виды компонентов дизайн-систем.
По каждому виду компонентов разбирают, что это такое, кто и зачем применяет в работе, из каких элементов состоит, где скачать.
Есть примеры и чеклисты, которые помогут собрать гайд или кит для вашего проекта или продукта.
Everything I Know About Style Guides, Design Systems, and Component Libraries
Прикладная статья Ли Робинсона, в которой он суммирует свои знания о гайдах, дизайн-системах и библиотеках компонентов.
Названия разделов и их супер короткая суть:
Design Systems
Команда Figma обновила свой сайт с коллекцией статей о проектировании и развитии дизайн-систем.
Создание дизайн-систем с помощью Atomic Design
Очень хорошая статья, которая будет полезна тем дизайнерам сайтов и интерфейсов, которые ещё не знакомы с методикой атомарного дизайна на практике.
Атомарный дизайн — методика проектирования, в которой вы описываете дизайн на пяти уровнях компонентов:
Автор (Игорь Сивец, Senior Experience Designer в EPAM Киев) рассказывает:
The 2019 Design Systems Survey by Sparkbox
Отчёт об исследовании «рынка» дизайн-систем. Кто и как использует, в каком состоянии, что дают.
Книги про дизайн-системы
Обзор книг Юрия Ветрова
Юрий — бывший дизайн-директор Mail Ru Group. Человек, который знает о дизайн-системах, пожалуй, больше всех в России. Вот, какие книги из прочитанных им он рекомендует:
Вот, что я могу посоветовать дополнительно:
Нюансы разработки дизайн-систем
The ABCs of Design Systems
Толковые советы по разработке и управлению дизайн-системой, оформленные в формате азбуки: A is for Adoption, B is for Beta, C is for Canon и так далее. С развёрнутым пояснением к каждой букве.
Как включить анимацию в вашу дизайн-систему
Перевод материала Калеба Барклэя, консультанта по дизайну, помогает компаниям проектировать дизайн-системы.
Typography in Design Systems
Подробный рассказ о грамотном описании типографики в дизайн-системах.
Дизайн-система: как хорошо начать и не закончить плохо
Базовая статья Ксении Толокновой, UX/UI дизайнера и арт-директора в Газпромбанке, о сетках, типографике и цветах в дизайн-системах.
Project Worlds — Achieving God Mode in Digital Design
Статья предлагает оригинальную ментальную модель для проектирования дизайн-систем — «миры». Это своеобразное развитие идей атомарного дизайна. Автор предлагает рассматривать разные уровни дизайн-системы как маленькие «миры»: у каждого есть входные данные, внутренние правила/алгоритмы и выходные данные. Звучит сложно, но прочитайте или хотя бы пролистайте. Станет понятно.
Including Animation In Your Design System
О том, как грамотно описать интерфейсную анимацию в дизайн-системе. С примерами.
Дизайн-системы в сайтостроении
Лекция Александра Гладких, сооснователя и арт-директора Charmer.
Методы построения гибкой цветовой палитры для вашей дизайн-системы, перевод статьи Designing Systematic Colors
В статье подробно и обстоятельно разбирается, как разработать работающую и гибкую систему цветов, основанную на логике.
Design System in Figma
Бесплатный курс по созданию дизайн-систем в Figma от создателя DesignCode.io.
Примеры дизайн-систем
Инструментарий
Программы и сервисы, которые могут дополнить общепринятые в индустрии решения: Figma, Sketch, Adobe XD и Zeplin.
Бонус
Если этих материалов оказалось мало, идите на Design Systems Repo — сайт с большой коллекцией статей, книг, докладов и инструментов по теме.
Добавляйте в комментариях годные материалы по теме, которые не вошли в подборку.
Что такое дизайн-системы и где они применяются
О них говорят почти на каждой важной конференции, и CodeFest, про который мы недавно рассказывали, не стал исключением. Сложно не заметить тренд. Немного рассказали о явлении и поразмышляли над тем, как практика дизайн-систем применима к проектной разработке.
Дизайн-система — это набор правил и инструментов для визуального и технического исполнения, который отражает философию продукта и постоянно развивается. Это если попытаться в одном предложении. Получилось плохо, как видите — дальше станет понятнее.
То, что сегодня дизайн-системы и само явление унификации на пике популярности, вполне закономерно. Когда веб только начинался, тем, кто его создавал, было не на что ориентироваться. Каждый новый интерфейс становился экспериментом. Веб был про эмоции, а не про удобство.
Пользователь то и дело находил что-то новое, удивлялся: «вау, как они хитро замаскировали меню!». Владельцы заводов показывали сайты друг другу за кружкой пива, восторженно тыкая пальцем на крутящийся и сверкающий flash-логотип. Сайты предваряли специальные странички, на которых пользователю рассказывали, как всем этим пользоваться. Такого понятия, как юзабили, в принципе не существовало — его и не могло быть при том уровне интернет-грамотности.
Со временем произошли три логичные вещи:
Сегодня любой сайт — это в первую очередь решение проблемы. Чем быстрее человек разберется, куда нажимать, тем выше вероятность того, что он здесь останется — а не уйдет к конкурентам. Унификация — это хорошо, потому что если все сайты и элементы управления будут более-менее похожи друг на друга, ими будет проще пользоваться.
Первой осмысленной попыткой масштабной веб-унификации можно назвать Material Design от Google. Над идеей начали работать в 2011 году, а в 2014 представили готовую дизайн-систему.
Как построить дизайн-систему
При поддержке канала https://t.me/uxidesign
Дизайн-система — это, по сути, библиотека компонентов, руководствуясь четким набором стандартов и руководств, и онасовсем не похожа на статическое руководство по стилю, которое содержит ссылки на спецификации. Мы создаем компоненты по мере того, как мы открываем возможности продуктов и постоянно добавляем их в библиотеку для будущего использования.
Эта библиотека может использоваться многократно, поэтому, когда в будущем требуются аналогичные компоненты на разных уровнях — атомном, молекулярном, организменном, шаблонном — их можно повторно использовать для быстрого создания страниц. Дизайн — система всегда готова к использованию, но никогда не завершается, поэтому некоторые называют ее живым документом.
Создать и поддерживать дизайн-систему — это значит создавать и поддерживать сам продукт. Дизайн-система требует обслуживания и обновления в течение всего жизненного цикла продукта. Важно прилагать особые усилия для разработки масштабируемых систем, которые обеспечивают бесперебойную согласованность на платформе и связанных устройствах. Другие преимущества включают в себя:
1. Простота масштабируемости
3. Согласованность между командой и платформами
4. Возможность повторного использования
5. Быстрое прототипирование и повторение
6. Увеличение темпов разработки программного обеспечения
7. Снижение энтропии дизайна
Разработчики могут обратиться к дизайн-системе для получения спецификаций компонентов, которые будут аналогичны их хранилищу разработки. Для ссылки на макет они могут ссылаться на утвержденные экраны, чтобы они могли подключаться и работать с компонентами для создания нового экрана в соответствии с требованиями.
Атомный дизайн, разработанный Брэдом Фростом, представляет собой метод, в котором макет веб-сайта разбит на основные компоненты. Эти компоненты затем повторно используются по всему сайту. Название атомного дизайна происходит от концепции того, как вся материя во вселенной может быть разбита на конечный набор небольших элементов, называемых атомами. Точно так же это может быть применено к созданию дизайн-систем, где наши интерфейсы могут быть разделены на конечный набор элементов. Затем эти элементы работают вместе, чтобы создать эффективные дизайн-системы интерфейсов в модели, которая не является линейной, но является ментальной. Это помогает нам рассматривать пользовательские интерфейсы как целостные объекты, а также тот факт, что они были созданы с помощью наборов деталей.
Десять лет назад они были известны как библиотеки шаблонов, еще до появления атомного дизайна, который дал более полное понимание дизайн-систем. После того как Google представила Material Design в 2014 году, концепция дизайн-систем наконец-то созрела. Теперь, после появления многих таких систем, принцип атомного дизайна используется в качестве ментальной модели при создании системы, работающей в связке с репозиторием разработчика. Чтобы узнать больше об атомном дизайне, посетите: http://atomicdesign.bradfrost.com/.
Использование дизайн-системы действительно впечатляет. Ее можно использовать для создания нового продукта, веб-сайта электронной коммерции и т. д. Пока у вас есть команда и время для создания и обслуживания дизайн-системы, вы можете быть уверены, что сможете воспользоваться её преимуществами.
Так каков процесс создания дизайн-системы? Ниже приведен подробный пошаговый процесс построения дизайн-системы с помощью The Material Theme Editor.
Отличным примером дизайн-системы является Material Design System, которая является собственной дизайн-системой Google. Также известна как material.io, вы можете узнать больше на https://material.io/.
3. Как только вы загрузите тему материала из редактора, вы обнаружите, что все компоненты организованы в виде вложенных символов, что делает ее системой на странице, называемой руководством по стилю. Эти компоненты могут использоваться повторно, в отличие от статического направляющего компонента, благодаря тому, что они вложены и подключены с помощью внутренних связей к системе.
Вложенный символ содержит несколько символов внутри себя на разных уровнях, и каждый из них связан с различными параметрами, такими как цвета, округлость, состояние выделения и т. д.
Это позволяет разработчику повторно использовать компонент и выполнять различные действия, такие как изменение цвета и текста на кнопке, отключение кнопки, изменение значка и т. д.
Все эти изменения происходят изнутри системы, поскольку они связаны и структурированы так, чтобы быть доступными из переопределений. Это гарантирует, что дизайн последователен.
Например, мы можем структурировать типы FAB с различными вариантами внутри, как показано выше. Создавая символы, нам нужно использовать косую черту при наименовании, чтобы разветвлять эту категорию для чистой организации.
Этот редактор тем также состоит из типографских шкал и весов, которые можно сгенерировать с помощью плагина. Вы можете выбрать нужный шрифт Google на панели редактора, и он автоматически генерирует все размеры и вес заголовка в соответствии с выбранным шрифтом, как показано ниже. Поправки в иерархии или весе могут быть сделаны на холсте / документе руководства по стилю.
По всей панели мы можем изменить основной и дополнительный цвета на желаемый фирменный цвет, и каждый элемент в руководстве по стилю и компонентам будет автоматически заменен новыми фирменными цветами. В этом волшебство использования вложенных и проводных компонентов. До сих пор редактор тем допускал два цвета, мы можем добавить больше в документ руководства по стилю, но это еще не отражено на панели.
Material design предоставляет вам 4 типа наборов системных значков, которые заполнены, заострены, закруглены и двухцветны. Как и другие вещи, мы можем добавить больше в эту библиотеку с помощью наших пользовательских значков.
Материал дизайна использует 8-балльную сеточную систему. Это означает, что независимо от того, какую платформу вы строите, она использует базовую единицу измерения 8 и кратную 8, чтобы поддерживать баланс при проектировании для всех платформ. Поскольку все устройства, для которых мы разрабатываем, имеют ширину экрана, кратную 8, эта сеточная система стала очень популярной в отрасли.
С чего начать разработку дизайн-системы и зачем она нужна
Руководство дизайн-студии EightShapes — от формирования стратегии до запуска первой версии.
Нетипично разрабатывать дизайн-систему для своего портфолио. Конечно, благодаря приложенным усилиям появляются такие побочные продукты, как визуальный язык или компоненты интерфейса пользователя.
Однако основной потенциал системы заключается не в создании библиотеки, а в том, чтобы постоянный опыт распространялся на продукты и поддерживался стабильной, предсказуемой методикой программирования.
Сторонники систем должны стать предпринимателями, продвигать и продавать идеи. Со временем система достигнет значительных результатов за счёт координирования работы и взаимодействия сотрудников из разных отделов.
Эффективность такой схемы создания системы — разработка стратегии, запуск первой версии, регулярное применение системы, которое способствует её адаптации и формированию сообщества, — доказана пятью системами, созданием которых я руководила с начала 2016 года. Все они созданы, внедрены и продолжают работать и по сей день. Мероприятия и сроки описаны ниже.
Разработка дизайн-системы начинается не с выбора цвета. Её основой должна стать стратегия, которая определяет потребности покупателя, ставит цели, исследует и концентрируется на направлении дизайна и получает поддержку организации.
Как и в случае с каждым продуктом, который мы создаём и разрабатываем, дизайн-система должна удовлетворять потребности команд внедрения продуктов в рамках текущей культуры, инструментов, существующих систем и методов работы.
Исследовательская деятельность может включать в себя:
Новые решения в компании обсуждают на совещаниях, личных встречах, показывают на презентациях — всё это для подведения итогов достигнутого прогресса и сбора дополнительной информации. Мы будем проводить совещания с большими группами дизайнеров, инженеров, руководителей и других сотрудников, чтобы:
Довольно часто создание системы совпадает с разработкой нового визуального языка с нуля и с применением этого языка к тем компонентам интерфейса пользователя, которые согласна использовать команда по продукту. Успех зависит от того, примет ли компания направление, которое вы выбрали.
Следовательно, важно концептуально демонстрировать новое визуальное направление с помощью изображений реального использования вашего продукта до и после того, как будет применена дизайн-система. Этот процесс должен включать и даже вовлекать членов сообщества на каждом шаге пути.
Больше на тему подготовки и презентации концептов можно прочитать здесь.
Стратегия ничего не значит, если важные люди — как руководители с фондами, так и сообщества, использующие продукт, — не принимают её. Поэтому вы должны проводить презентацию стратегии.
Обычно наша презентация стратегии охватывает следующие темы:
Не стесняйтесь. Вам предстоит запустить новый продукт, у вас неизбежно появятся требования. Что нужно требовать?
Часто мы отказываемся от проектов, на которые получили прямое или подразумевающееся одобрение на дальнейшую работу. Я невероятно радуюсь, когда во время нашего с коллегами совещания в кабинет заходит генеральный директор компании и говорит:
То, что вы показали, очень интересно и ценно. Отличная работа. Дайте мне знать, если что-то понадобится для реализации проекта.
Однако вербальное одобрение совсем не значит, что можно начинать завтра. Иногда всё стопорится.
Существует множество факторов, способных отложить момент принятия решения. Может быть, ваша первая презентация запустила последующие презентации по оперативным вопросам, или отдел HR решил поменять состав команды. А может, вам придётся ждать следующего квартала, когда компания будет пересматривать операционный бюджет.
Или просто возникнет переходный период, когда команда, которая будет заниматься системой, закончит работу, назначенную им в команде по продукту. Не отступайте от цели. Будьте настойчивы. И вы обязательно добьётесь желаемого.
И в какой-то момент, получив одобрение, вы официально начнёте создавать систему.
Вы определились с организационными задачами, командой дизайнеров, инженеров, руководителей и прочих сотрудников. Объём работы понятен. Настало время разрабатывать, создавать и документировать систему шаг за шагом, чтобы добраться до первого релиза.
Когда появляются основные части системы, версия альфа 0.1 предоставляется ранним пользователям для предварительного ознакомления. По мере роста библиотеки компонентов пилотный запуск можно производить через бета-версии, начиная с 0.3 и выше.
И хотя спринты ведут к постепенному выходу релизов и закрепляют процесс работы над дизайн-системой, вы должны постоянно держать в поле зрения финальный релиз.
Циклы первого релиза внедряют то, чего раньше не было. По мере развития системы её покупатели, спонсоры и даже сама команда должны понимать, что будет сделано и к какому времени, ощущать комфорт от существования точных сроков завершения работы над каждой частью системы.
В течение этого времени недавно сформированная команда сможет приспособиться к процессу разработки. Ниже период дизайна и разработки обозначен оранжевым, а документация и публикация — тёмно-серым цветом.
Для высокоуровневого планирования необязательно детально расписывать рабочий процесс по каждому пункту. Также не важен порядок или названия конкретных компонентов, указанных в примере выше (хотя, если честно, это общепринятый алгоритм). Вместо этого я больше концентрируюсь на том, как наша команда:
В чём все должны быть уверены? Что команда, разрабатывающая систему, предоставит начальную библиотеку — осмелюсь сказать, «минимально жизнеспособный продукт», — который будет принят к определённому ожидаемому сроку. Поэтому я буду неоднократно подчёркивать, что мы на пути к запуску версии 1.0, которая обеспечит сильную визуальную основу и от 12 до 16 компонентов UI.
С самого начала работы над дизайн-системой, даже на собеседованиях и совещаниях на этапе исследований очень важно постоянно доносить до людей, что дизайн-система — это не проект, это продукт. Он будет реализован, и со временем его надо будет поддерживать. Работа не закончится версией 1.0.
Как следствие, я буду работать с руководством, чтобы организовать работу и наладить процессы для периода после релиза, пока сама команда ещё в самой середине работы над циклом первого релиза.
Второй цикл разработки тоже принимает форму регулярного планирования и внедрения, разбивается на модули, состоящие из шести или семи спринтов. Здесь цель состоит не в том, чтобы неожиданно запустить версию 2.0, что будет преждевременно. Наоборот, в отличие от интенсивной погони за версией 1.0, команда должна начать дисциплинированно работать, и это должно восприниматься в компании как обычная практика.
Эта действующая программа требует сдвига от производственного мышления к функциональному мышлению. Деятельность больше не ограничена внедрением базовой функциональности и поэтому становится более разнообразной:
В частности, чтобы помочь компании, разрабатывающей продукты, принять дизайн-систему, требуется сознательное, целенаправленное и требующее усилий взаимодействие. Будьте вооружены презентациями и демо-версиями и будьте готовы показывать их снова и снова. Концентрация внимания на внедрении в высокоуровневых планах сдвигает фокус вашего внимания на наиболее важные отношения: отношение системы и всех продуктов, которые её приняли.
Помимо постоянно растущей библиотеки, система должна внедрять новые бизнес-возможности, которые можно демонстрировать.
Каждый квартал вы можете добавлять определённые компоненты:
Если продвинуться ещё дальше во времени, то зрелые системы перерастают в закреплённые цели или темы, которые каждый год пересматриваются и отслеживаются так же, как и любой другой продукт, портфолио или программа.
Если вы только запускаете систему, то вам может показаться, что до этого ещё слишком далеко, или такая перспектива может пугать. Но даже когда вы просто внедряете базовую функциональность, вы уже можете использовать концепты регулярного планирования, базовых компонентов и тем, чтобы показать, куда может привести дальнейшая работа с дизайн-системой.
Делаем технически правильные макеты с помощью дизайн-систем
Один из принципов правильного и удобного взаимодействия пользователя с digital-продуктом — это модульная дизайн-система. Многослойная, но логичная и простая система, в которой все блоки, кнопки и элементы функциональны, интуитивно понятны и гармонируют друг с другом
Пользователь не в курсе некоторых нюансов взаимодействия дизайнеров и верстальщиков, а между тем, они оказывают большое влияние на конечный продукт. Например, со стороны верстальщиков часто поступают вопросы к макету или макет отправляется на доработку по техническим причинам:
разные отступы у элементов;
не прорисованы состояния кнопок;
не хватает нужных элементов и т. д.
Со стороны верстальщиков поступают претензии, что в конечном продукте не продумано взаимодействие определённых механик, из-за чего приходится постоянно перерабатывать дизайн.
Чтобы улучшить итоговый продукт и упростить взаимодействие между разработчиками, для каждого digital-продукта продумывают и постепенно нарабатывают библиотеку блоков, стилей и компонентов. Это помогает штатным дизайнерам, а также позволяет привлекать других специалистов, которые могут сразу начать собирать макеты из готовых элементов.
Плюсы дизайн-систем
Сокращение трудозатрат на разработку дизайн-макетов и прототипов.
«Одночитаемость» и узнаваемость макета, позволяющая пользователю запомнить фирменный стиль компании.
Возможность работать с готовой технической библиотекой компонентов, вместо того чтобы разбираться в макетах.
Минусы дизайн-систем
1. Творческие ограничения для дизайнеров, которым приходится проявлять себя сугубо в рамкам дизайн-системы и её готовых шаблонов.
2. При разработке нового продукта дизайн-систему приходится создавать с нуля, что требует много ресурсов.
Правила создания дизайн-систем
Каких-то определённых правил для создания дизайн-систем не существует. Каждый продукт обладает своими особенностями, и дизайн-система создаётся, исходя из его потребностей.
Как пример дизайн-систем для масштабных digital-продуктов можно рассматривать отечественные разработки для сайтов государственных систем, Ratio — дизайн-систему «Рамблера», дизайн-систему для «Альфа-Банка».
Но, несмотря на то что при создании дизайн-систем у разработчиков есть большая степень свободы, есть определённые составляющие, которые должны входить в правильную систему:
В хорошей дизайн-системе обязательно есть принцип составления интерфейсов или свод правил, на основании которых принимаются дизайн-решения.
Библиотека шаблонов или набор готовых отрисованных решений, которые дизайнеры могут использовать для составления визуала.
Технические шаблоны (UI-kit) или готовый код для кнопок, полей и блоков.
Как создаются дизайн-системы
Процесс создания дизайн-систем можно разбить на отдельные этапы. При этом целесообразно придерживаться основных принципов атомарного дизайна, с которыми работа над созданием дизайн-системы для проекта выглядит примерно так:
Этап 1. Анализ готовых страниц
На данном этапе страницы, где нет подробно проработанной системы, анализируются путем разбивания интерфейса на составные части:
атомы (форма, поле ввода, кнопка, лейблы);
молекулы (кнопка + поле ввода);
организмы (кнопка + поле ввода + лейблы).
Этап 2. Сборка шаблонов
Полученные организмы уже могут послужить основой будущей дизайн-системы, из них собираются шапки, слайдеры, страницы и другие элементы.
Этап 3. Доработка и расширение дизайн-системы
По мере расширения проекта растёт и дизайн-система, она постоянно пополняется и видоизменяется. Но на этом этапе с ней уже можно полноценно работать.
Для тех, кто хочет узнать об атомарном дизайне более подробно, мы рекомендуем статьи Бреда Фроста (например) или их переводы на «Хабре».
Вывод
Дизайн-система — это не только набор шаблонов: это инструмент, который помогает устранить конфликты в рабочей команде верстальщиков и дизайнеров. А ещё он позволяет легко включать в команду других специалистов и не тратить время на длительное вхождение в проект.
Дизайн-система — гибкий инструмент, который постоянно пополняется и совершенствуется. В неё добавляются решения для новых ситуаций в рамках уже готового принципа составления интерфейса.
В следующей статье мы расскажем, как организовывать дизайн-систему со стороны технических шаблонов. А вы используете дизайн-системы в своей работе? Какие проблемы они помогают вам решить?