dizajn-sistemy

Дизайн-система: что это такое

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

Что такое дизайн-система

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

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

Составляющие дизайн систем

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

Со стороны продуктового дизайна

  • Библиотеки стилей — самые простые неделимые части интерфейса. Суда же сетки, отступы, скругления, шрифтовые решения, палитры;
  • Наборы компонент — минимально осмысленные детали и их группы, из которых можно собрать интерфейс;
  • Шаблоны страниц;
  • Состояния органов интерфейса;
  • Типовые анимации и микровзаимодействия;
  • Методы проектирования;

Со стороны разработки

  • Библиотека компонент в коде — в идеале синхронная с дизайн-библиотекой;
  • Архитектура интерфейса — что во что вставляется, с чем связано и в какой зависимости;
  • Паттерны разработки — как надо и как не надо делать;
  • Сторибук — живая энциклопедия компонент, где их можно трогать, тестировать и вот вообще это всё;

Со стороны менеджмента

  • Стратегия развития дизайн-системы — когда и что должно быть сделано, чтобы команды получили нужные детали синхронно со стратегией развития продуктов;
  • Порядок обновления — какие заказы на дополнение/изменение системы брать, а какие отклонять. Как совмещать между собой продукты с деталями разных версий;
  • Зоны отвественности членов команд между собой;

Со стороны маркетинга

  • Базовые ценности компании и дизайна её продуктов на рынке — аналог платформы бренда, но в цифровом мире;
  • Принципы коммуникации, tone of voice — часто берут из брендбука и развивают;
  • Визуальный стиль — адаптированные под цифровую унификацию гайдлайны;

Зачем нужны дизайн-системы

В разработке есть принцип «Dont Repeat Yourself» — в эквивалентном переводе: «Не изобретай велосипед». Потому что повторять одну и ту же работу вредно не только за собой, но и за другими. Этот же принцип распространяется на дизайн и на всё взаимодействие дизайнеров и разработчиков. Некоторые компании разрабатывают дизайн-системы именно для того, чтобы дизайнеры не плодили уже существующие решения, а разработчики не писали по сто раз одно и то же в разных вариациях.

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

Третье «зачем» — качество. При обогащении систем решениями легко находить аналогичные. Для типовых ситуаций можно оставлять только наилучшие.

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

Как понять нужна ли компании дизайн-система

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

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

В каких случаях его реально вообще уговорить, что новая игрушка принесёт больше, чем на неё потратили? Вот несколько ситуаций:

Несколько отделов в компании одновременно работают над одним проектом

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

Есть потребность масштабировать дизайн на сотни макетов

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

У компании много продуктов, но нет единого источника истины

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

Примеры дизайн-систем

Material Design

Самым известным примерном является система Material Design у гугла. К сожалению, она настолько всеобъемлющая, что силами криворуких разработчиков других компаний, часто выглядит не очень. Её принципы часто нарушаются, а гибкость воспринимается, как призыв ни в чём себя не ограничивать. На ней можно встретить реализованные примеры одних из самых изящных и самых уродливых продуктов — просто открой Play Market. Также она хороша огромными ресурсами гугла, чего стоит их новый конкурент джаваскрипта —Dart, и его фреймворк Flutter, который уже сейчас может экономить массу сил разработке и дизайну. Компоненты в нём называются виджетами и помещаются один в другой. Целый экран может быть виджетом, состоящим из виджетов меньшего порядка.

БЭМ

У продуктов Яндекса есть конструктор, который позволяет компании очень гармонично смотреться и запускать продукты модульно и быстро. Модульно — значит, что ничего не развалится, если где-то открутить связанную часть. По факту дизайн-система, но со своей методологией — БЭМ. Иногда ласково называют «Лего».

Ant Design

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

Прочие

Даже у государственных сервисов есть дизайн-системы. Существуют коллекции открытых дизайн систем. Вот пара примеров:

Как создать дизайн-систему

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

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

Заручись поддержкой всей компании

Когда у тебя есть список жертв, включай партизана. С этим разработчиком по фану пробросьте токены из фигмы к нему в переменные компонент прямо на своём проекте. Раз! И всё отвалилось. Так как это факультативный фан — можно экспериментировать не боясь провалов. Токены — это переменные в коде напрямую из дизайн-библиотек. Подробнее будет отдельная статья, это весело, примерно как тригонометрия.

Ещё хорошо, когда все команды разработки уже имеют свои библиотеки компонент. Тогда их компоненты можно попробовать пробросить в фигму через API, чтобы дизайнеры использовали в дизайне только те компоненты, которые уже сущетсвуют в коде.

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

Организация команд при создании дизайн-системы
«Организация разрозненных команд». Эмоджи, Фигма, 2020 год

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

Организуй ресурсы

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

Разработай принципы дизайна продукта

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

Принципы дизайн-системы Контур
Вот, как выглядят принципы у Контур.Гайды
Принципы дизайн-системы Яндекса
А вот как выглядят принципы у Яндекса

Этот процесс не имеет старта и окончания. Принципы меняются вместе с компанией и её продуктами.

Выбери визуальный язык и тон

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

Уровни визуального языка дизайн-систем
Уровни визуального языка дизайн-систем

Часть стилей отсюда могут стать в коде токенами, часть — атомами для формирования молекул, а из низ органов — компонент. Подробнее читай «Атомарный дизайн». Там наполовину хорошо всё описано, жаль только для идеального мира.

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

Создай компоненты

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

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

Сформируй шаблоны

В русском есть шаблоны страниц и паттерны (что тоже переводится, как шаблоны), это взрывает мозг. В английском проще: templates для шаблонов, и patterns. Их часто смешивают. Терминологический спор — вообще такое характерное свойство дизайн-сообщества, а для себя я выделил такой принцип.

Отличие шаблонов и паттернов
Отличие шаблонов и паттернов

Шаблон — статичное состояние типичной страницы или крупной её части, а паттерн — то, как пользователь привык этим шаблоном пользоваться. Это одновременно:

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

Докуметируй

Всё, что не описано в виде документации — не существует с точки зрения проекта и команды уже через день. А ещё люди приходят и уходят, но система должна жить. Здорово иметь одну базу знаний по дизайн-системе. Для этого даже необязательно поднимать свою вики или сторибук, можно использовать готовые Zeroheight или Storybook. Если дорого, то начать можно в Яндекс Коннекте или Конфлюенсе.

Итог

Сделать дизайн-систему сложно. Это производство средства производства, а потом ручное поддержание шаткого порядка, стремящегося скатиться обратно в балаган в сторону энтропии. Ко всему стоит относиться с известной долей скептицизма, особенно к тому, что транслируют из каждого утюга. Если пришла в голову идея разработать дизайн-систему, перечитай статью и подумай ещё раз. Может быть ты можешь обойтись простым UI китом и быть счастливым румяным карапузом, а не чахлым замученным зомби, который пинает всех вокруг, чтобы хоть что-то работало. Успехов!

Поделиться
Телеграфировать
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Загрузка...

Добавить комментарий