kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Дизайн-система
В прошлом уроке вы узнали, какие элементы интерфейса помогают решать пользовательские задачи. Но для того, чтобы пользователь не запутался в экранах, а дизайнеры и разработчики быстро и слаженно создавали продукт, нужно придерживаться определённых правил по использованию элементов интерфейса. В этом команде разработки помогает дизайн-система.
Что такое дизайн-система
Дизайн-система (design system) — это набор взаимосвязанных и согласованных шаблонов и практик, которые используются для проектирования и реализации пользовательского интерфейса.
В команду разработки дизайн-системы входит несколько человек:
- дизайнеры проектируют шаблоны дизайн-системы;
- фронтенд-разработчики реализуют шаблоны дизайн-системы в коде;
- системный аналитик выявляет требования к шаблонам, описывает их и опирается на них при разработке прототипов.
Некоторые команды разработки выкладывают свои дизайн-системы в сеть и открывают к ним доступ, чтобы повысить узнаваемость брендов и получить обратную связь — например, об ошибках. Другие команды используют готовые дизайн-системы, чтобы сократить затраты на проектирование и реализацию, а также обучиться лучшим практикам.
Вот примеры дизайн-систем, выложенных для свободного использования:
- Paradigm от Mail.ru Group.
- VKUI от ВКонтакте.
- Госуслуги от РТЛабс.
- Gov.design от Минкомсвязи РФ.
- Material Design от Google.
- Atlassian Design System от Atlassian.
Все команды заинтересованы в том, чтобы предоставлять элементы интерфейса с привычным для пользователей поведением, расположением и внешним видом. Выкладывая и используя дизайн-системы, команды разработки во всём мире обеспечивают согласованность пользовательских интерфейсов.
Рассмотрим, из чего состоят дизайн-системы.
Шаблоны
Шаблоны (patterns) в контексте дизайн-системы — это образцы поведения, расположения или внешнего вида элементов интерфейса. Шаблон представляет собой повторяющееся, многократно используемое решение какой-либо проблемы проектирования интерфейса.
В качестве примера возьмём шаблон поисковой строки.
Это решение состоит из набора функциональных элементов (комбинированный список, кнопка) и визуальных решений (цвет, форма, размер и так далее).
Из этого следует, что шаблоны бывают двух видов: функциональные и воспринимаемые.
Функциональные шаблоны, или компоненты
Функциональные шаблоны (functional patterns), или компоненты (components), — это образцы поведения и расположения элементов интерфейса. Они нужны, чтобы пользователь мог выполнять с помощью пользовательского интерфейса свои задачи.
Примеры функциональных шаблонов (компонентов):
- меню,
- кнопка,
- поле ввода,
- раскрывающийся список,
- флажок.
Рассмотрим компоненты на примере дизайн-системы Mail.ru — Paradigm.
Простые функциональные шаблоны, такие как кнопка, могут быть сгруппированы и образовывать другие — сложные шаблоны.
Простыми называют неделимые шаблоны, то есть такие, в которых пользователь может использовать только часть. Сложными называют шаблоны, состоящие из других шаблонов.
Например, шаблон «Кнопка» относится к простым. При этом несколько кнопок могут быть объединены в сложный шаблон — скажем, «Сегментированный переключатель». Это группа кнопок, предназначенных для переключения окон, например, в качестве альтернативы вкладкам.
Воспринимаемые шаблоны, или стили
Воспринимаемые шаблоны (perceptual patterns), или стили (styles), — это образцы внешнего вида элементов интерфейса. В некоторых дизайн-системах их называют дизайн-токенами (design tokens).
Стили нужны, чтобы вызвать у пользователя определённые эмоции, передать ему ценности компании и сделать бренд узнаваемым.
Примеры воспринимаемых шаблонов (стилей):
- цветовая палитра,
- типографика (шрифты),
- иконографика (иконки),
- анимация и звуки,
- интерактивные состояния — внешний вид компонента при взаимодействии с ним, например, при наведении курсора,
- отступы.
Рассмотрим стили на примере той же дизайн-системы Paradigm. Во всех кнопках должны использоваться только описанные в палитре цвета и описанные в типографике шрифты.
Обратите внимание, как известные компании используют цвета и даже собственные шрифты, которые в дальнейшем пользователь неосознанно ассоциирует с этими компаниями. Сможете ли вы узнать компанию по стилю?
Практики
Цель создания шаблонов — согласованность экранов пользовательского интерфейса. Но просто сделать шаблоны недостаточно. Членам команды разработки при использовании шаблонов нужно придерживаться практик.
Практики (practices) в контексте дизайн-системы — это то, как команда разработки проектирует, реализует, документирует и использует шаблоны.
Практики дизайн-системы позволяют:
- Обеспечить согласованность экранов — единое понимание поведения, расположения и стиля элементов интерфейса.
- Начать говорить на одном языке с членами команды, пользователями и заинтересованными лицами.
- Стимулировать сотрудничество и распространение знаний.
- Ускорить проектирование и реализацию пользовательского интерфейса.
- Предоставить документацию по элементам пользовательского интерфейса.
- Сократить вероятность ошибок, например, лишнее добавление шаблонов, использование не по назначению и так далее.
Основные практики дизайн-системы:
- Совместная работа членов команды. Например, дизайнера интерфейсов, системного аналитика и фронтенд-разработчика. Командная работа над дизайн-системой повышает качество шаблонов, способствует взаимному обучению и распространению знаний.
- Проведение регулярных встреч. Например, для обсуждения разработки шаблонов, их документирования и поддержки актуальности дизайн-системы.
- Ведение глоссария. Создание и поддержка глоссария позволяет команде разработки использовать одни и те же термины в устном, письменном общении и даже в программном коде. Команда разработки может вести глоссарий в спецификации требований к ПО или в дизайн-системе.
- Разработка библиотеки шаблонов. Команда разработки организует и документирует шаблоны в виде библиотеки. На основании одной дизайн-системы можно разработать несколько библиотек шаблонов.
Рассмотрим последнюю практику подробнее.
Библиотека шаблонов
Библиотека шаблонов (pattern library) в контексте проектирования и реализации пользовательского интерфейса — это централизованный, структурированный набор шаблонов и документации по ним.
Дизайнер интерфейсов проектирует функциональные и воспринимаемые шаблоны — компоненты и стили.
Фронтенд-разработчик реализует спроектированные дизайнером шаблоны с использованием HTML, CSS и JavaScript. Подробнее об этих фронтенд-технологиях вы узнаете в следующих темах спринта.
Реализованные шаблоны позволяют многократно использовать один и тот же программный код.
Например, фронтенд-разработчик реализует шаблон поля ввода и выкладывает его в библиотеку. Другие фронтенд-разработчики могут просто скопировать это поле из шаблона на экраны, изменив стиль компонента с учётом выполняемой на экране задачи.
Скопированный элемент интерфейса может сохранить связь с шаблоном. Это позволяет фронтенд-разработчикам быстро вносить изменения в элемент, исправляя только связанный с ним шаблон.
Например, если требуется изменить размер шрифта всех полей ввода пользовательского интерфейса, достаточно одному фронтенд-разработчику внести изменения только в воспринимаемый шаблон (стиль) поля ввода — они будут применены ко всем связанным элементам интерфейса.
Команда разработки, в том числе системный аналитик, документирует все спроектированные и реализованные шаблоны. Функциональные шаблоны (компоненты) документируют иначе, чем воспринимаемые (стили), — сейчас расскажем почему.
Документирование компонентов
У каждого компонента в библиотеке шаблонов должны быть:
- Название.
- Назначение.
- Пример.
- Варианты.
Название
Библиотека шаблонов организована как перечень названий всех входящих в неё компонентов. Поэтому в идеале нужно подобрать для каждого компонента такое название, из которого пользователю библиотеки будет понятно его содержание.
Например, для шаблона, отвечающего за отображение шагов пользователя на этапах регистрации, можно использовать название «Progress step», то есть «Шаг прогресса».
Хорошая практика при выборе названия компонента — использовать метафоры. Например, для компонента расчёта условий займа подойдёт название «Калькулятор», а для компонента с дополнительной информацией о компании внизу сайта — «Подвал».
Назначение
Назначение — это описание проблемы проектирования пользовательского интерфейса, которую решает шаблон.
Назначение должно быть описано ёмко — никто не готов читать роман на тему того, какой это невероятный и многофункциональный шаблон 🙂 Достаточно одного-двух предложений, описывающих преимущества шаблона перед другими вариантами. Стоит придерживаться такого формата: что это за шаблон и для каких целей подойдёт лучше всего.
Пример
Хороший пример помогает закрепить верное понимание назначения компонента и используемой в рамках ПО версии.
Пример можно представить в виде изображения шаблона и его конечной реализованной версии:
- Изображение шаблона — начальная версия компонента, которая имеет все основные атрибуты: цвет, форму, размер, текст, обводку, изображение и так далее.
Шаблон выступает «родителем» или отправной точкой для последующих манипуляций с компонентом перед его внедрением в экран ПО. - Реализованный шаблон — интерактивный образец элемента интерфейса.
Это видоизменённое изображение шаблона (финальный вариант), которое используется в интерфейсе с дополнительной анимацией при взаимодействии с ним.
Возможность добавить реализованный шаблон в библиотеку зависит от выбранного инструмента разработки библиотеки.
Варианты
Варианты шаблона позволяют посмотреть на различные состояния компонента в зависимости от сценария взаимодействия с ним.
Например, кнопка может быть доступной для нажатия или заблокированной, подсвечиваться при наведении или выводить дополнительный элемент — пузырь с подсказкой, а при нажатии менять цвет.
Вы познакомились с обязательными атрибутами описания компонентов в библиотеке шаблонов. Пора проверить, правильно ли вы запомнили важность каждого атрибута при документировании. Покажите класс!
Соотнесите этап документирования компонента с его наименованием.
Описание компонента в различных состояниях.
Варианты
Обозначив варианты состояния компонента, можно наглядно показать возможные сценарии взаимодействия с ним.
Отображение сути компонента одним-двумя словами.
Название
Если назвать компонент «Большая форма», не каждый поймёт, за что отвечает компонент. А если дать ему имя «Регистрация», то задача, которую решает компонент, становится очевидной.
Изображение компонента в виде родительского шаблона, который можно видоизменять под новые требования.
Пример
Включение примеров в документацию компонента экономит ресурс дизайнеров и разработчиков при проектировании интерфейса.
Краткое и понятное описание задачи, которую решает компонент.
Назначение
Описание назначения компонента позволяет быстро сориентироваться, для каких возможностей лучше использовать именно этот компонент, а не его аналоги.
Документирование стилей
Документирование каждого стиля уникально, потому что стили не похожи друг на друга. Вы уже видели на примере дизайн-системы Paradigm, что описание цветовой палитры не похоже на описание типографики.
Несмотря на это, есть общие принципы документирования стилей:
- Описание стиля как части описания компонента или отдельно.
- Рекомендации по использованию стиля.
Описание стиля
Стиль может быть описан как часть компонента, если только этот компонент использует стиль.
Например, части описания компонента «Кнопка» — это цвета фона и границ компонента в разных интерактивных состояниях:
- нормальном (normal),
- состоянии наведённого курсора (hover),
- активном (active).
Стили интерактивных состояний могут быть также описаны отдельно, если они относятся сразу к нескольким компонентам.
Например, в дизайн-системе Paradigm отдельно добавлен стиль тонирования элементов интерфейса в зависимости от их состояния. Тонирование дополняет описание возможных цветов фона и границ компонента «Кнопка».
Рекомендации по использованию стиля
Описание стиля, как правило, содержит рекомендации по его использованию — примеры правильного и неправильного применения.
Например, в «Иконографике» рекомендовано использовать иконки вместе с текстом, а также только залитые иконки.
Другая информация
В документацию может входить и другая информация о шаблонах:
- Члены команды разработки. Перечисление участников проектирования, реализации и документирования шаблона позволяет заинтересованным лицам быстро найти того, кто сможет ответить на вопросы о шаблоне или документации.
- Похожие шаблоны. Добавление списка похожих шаблонов снижает риск сделать лишний дубликат уже существующего шаблона.
- Версии шаблонов. Если инструмент разработки библиотеки поддерживает версионирование, важно документировать отличия между версиями шаблонов.
Организация библиотеки шаблонов
Структура библиотеки шаблонов дизайн-системы напоминает упрощённое представление о химическом строении организма: он состоит из молекул, а молекулы состоят из атомов.
В библиотеке шаблоны представлены в виде:
- Атомов — простых шаблонов, которые нельзя разделить на более мелкие элементы, например «Комбинированный список», «Кнопка» или «Иконка».
- Молекул — сложных шаблонов, состоящих из множества простых, например «Поисковая строка».
- Организмов — более сложных шаблонов, например «Шапка сайта».
Организмы также можно объединять и наполнять информацией, чтобы создать ещё более сложные шаблоны и целые экраны.
Перед вами несколько функциональных шаблонов. Выберите, какие из них относятся к атомам, молекулам и организмам.
Подведём итоги
Дизайн-система — это набор взаимосвязанных и согласованных шаблонов и практик, которые используются для проектирования и реализации пользовательского интерфейса.
Дизайн-система состоит из:
- Шаблонов — образцов поведения, расположения и внешнего вида элементов интерфейса.
- Практик — способов создания, организации и использования шаблонов.
Одна из основных практик в дизайн-системе — разработка библиотеки шаблонов. В ней хранятся все шаблоны (атомы, молекулы и организмы), которые проектируются и используются в экранах ПО. Наполняют и документируют библиотеку дизайнеры, фронтенд-разработчики и системные аналитики.
Дизайн-система нужна для:
- повышения узнаваемости бренда и лояльности пользователей за счёт ассоциации дизайна с компанией;
- сокращения времени проектирования и разработки интерфейса, благодаря переиспользованию визуальных элементов и их кода;
- упрощения взаимодействия между пользователем и продуктом, благодаря использованию одинаковой логики в похожих шаблонах, из которых состоит интерфейс ПО.
Системный аналитик выявляет требования к шаблонам, описывает их, а также использует знания о дизайн-системе при разработке прототипов.
