Что такое дизайн-система, как её внедрять и нужна ли она в компании. Все об этом пишут, решил и я — со своей перспективы. Технологический прогресс — прекрасный аспект в истории человечества. Благодаря ему появился печатный станок, например. Благодаря ему же появились цифровые носители, а за ними сайты, приложения, игрушки и всё, что мы так любим. В дизайне тоже всё не стоит на месте: корел был выкинут из веб-дизайна фотошопом, фотошоп скетчом, а скетч истошно сопротивляется, но скоро будет убит фигмой. Библиотеки компонент для унификации, которые каждый дизайнер хранил у себя, теперь стали командными, а передача в разработку статичных картинок воспринимается, как моветон. Совместно разработка и дизайн идут дальше и создают дизайн-системы. Что это — дальше в статье.
Что такое дизайн-система
В разных источниках дизайн-система подаётся либо очень однобоко, либо очень подробно, но не по делу. Однобоко: набор компонент или токены. Подробно и не по делу: перечисление всех составляющих, процессов создания и поддержки.
Это всё тут в статье тоже будет, но я сразу оговорюсь, что это лишь следствия. Цемент дизайн-систем — это коммуникации в команде, работающей над продуктом. Все эти статьи для меня выглядят примерно так же, как статья «что такое человек» — и перечисление в ней его внутренних органов с процессом зачатия.
Составляющие дизайн систем
В идеальном мире большая часть артефактов дизайн-системы — сквозная. То есть одной актуальной версии компонента в дизайне соответствует одна актуальная версия этого компонента в коде. Они имеют идентичную архитектуру, а при смене стилей в рамках разных продуктов ведут себя одинаково. В жизни не так, но всё к этому стремится. Какие артефакты входят:
Со стороны продуктового дизайна
- Библиотеки стилей — самые простые неделимые части интерфейса. Суда же сетки, отступы, скругления, шрифтовые решения, палитры;
- Наборы компонент — минимально осмысленные детали и их группы, из которых можно собрать интерфейс;
- Шаблоны страниц;
- Состояния органов интерфейса;
- Типовые анимации и микровзаимодействия;
- Методы проектирования;
Со стороны разработки
- Библиотека компонент в коде — в идеале синхронная с дизайн-библиотекой;
- Архитектура интерфейса — что во что вставляется, с чем связано и в какой зависимости;
- Паттерны разработки — как надо и как не надо делать;
- Сторибук — живая энциклопедия компонент, где их можно трогать, тестировать и вот вообще это всё;
Со стороны менеджмента
- Стратегия развития дизайн-системы — когда и что должно быть сделано, чтобы команды получили нужные детали синхронно со стратегией развития продуктов;
- Порядок обновления — какие заказы на дополнение/изменение системы брать, а какие отклонять. Как совмещать между собой продукты с деталями разных версий;
- Зоны отвественности членов команд между собой;
Со стороны маркетинга
- Базовые ценности компании и дизайна её продуктов на рынке — аналог платформы бренда, но в цифровом мире;
- Принципы коммуникации, tone of voice — часто берут из брендбука и развивают;
- Визуальный стиль — адаптированные под цифровую унификацию гайдлайны;
Зачем нужны дизайн-системы
В разработке есть принцип «Dont Repeat Yourself» — в эквивалентном переводе: «Не изобретай велосипед». Потому что повторять одну и ту же работу вредно не только за собой, но и за другими. Этот же принцип распространяется на дизайн и на всё взаимодействие дизайнеров и разработчиков. Некоторые компании разрабатывают дизайн-системы именно для того, чтобы дизайнеры не плодили уже существующие решения, а разработчики не писали по сто раз одно и то же в разных вариациях.
Второе, вытекающее из первого, назначение дизайн-систем — масштабируемость. Когда нужно сделать тысячи экранных форм по десяткам шаблонов. Без систематизации будет трудно запускать и поддерживать. При этом трудоёмкость будет расти как снежный ком. Хорошо организованная дизайн-система требует одинаковых усилий для поддержания. Плохо организованный процесс требует растущих усилий при равных доработках вплоть до тупиковых состояний.
Третье «зачем» — качество. При обогащении систем решениями легко находить аналогичные. Для типовых ситуаций можно оставлять только наилучшие.
Четвёртое — единообразие. Консистентные внутри себя и между друг другом продукты воспринимаются цельно и могут становиться даже средой для формирования новых, нужных компаниям, пользовательских привычек.
Как понять нужна ли компании дизайн-система
Спроси дизайнера, обдолбанного статьями, типа этой, и он восторженно закричит «даааа!», но именно в этой ситуации, правильный ответ чаще «нет». В бизнесе, вопреки представлениям дизайнеров, не благотворительность, и каждый проект, в который вливаются деньги, должен их приносить больше, чем съел. А дизайн-система — это очень дорогостоящий проект.
Часто это решается выделением отдельной команды, изменением процесса и рабочих привычек целых отделов — это тоже можно смело списывать на расходы. Компаниям, у которых нет подобных ресурсов и не предвидится большого роста артефактов, скорее всего, стоит воздержаться от подобных вложений. Так что первый, кто должен отвечать на этот вопрос в компании должен быть финансовый директор.
В каких случаях его реально вообще уговорить, что новая игрушка принесёт больше, чем на неё потратили? Вот несколько ситуаций:
Несколько отделов в компании одновременно работают над одним проектом
Если таких отделов мало, то они прекрасно самоорганизуются, наделают библиотек, договорятся о принципах, просто чтобы не ломать руки о процесс друг друга. И никакая дизайн-система им не нужна. Если в компании сто человек делают видимую часть продукта — стоит задуматься о том, чтобы систематизировать их работу.
Есть потребность масштабировать дизайн на сотни макетов
Даже если команда маленькая, иногда однотипной работы невероятно много. Может оказаться выгодно её автоматизировать, тогда стоит задумываться о создании дизайн-системы.
У компании много продуктов, но нет единого источника истины
Здесь что-то решается всплывающим окном, а там — кнопкой. Тут действие мгновенно применяется, а там надо что-то нажать. Такое случается очень часто, когда компания быстро растёт и добавляет продукты в портфель. В какой-то момент ценность продуктов для конечного пользователя сильно повысится простым причёсыванием работы всех интерфейсов. В этой ситуации дизайн-система может окупиться.
Примеры дизайн-систем
Material Design
Самым известным примерном является система Material Design у гугла. К сожалению, она настолько всеобъемлющая, что силами криворуких разработчиков других компаний, часто выглядит не очень. Её принципы часто нарушаются, а гибкость воспринимается, как призыв ни в чём себя не ограничивать. На ней можно встретить реализованные примеры одних из самых изящных и самых уродливых продуктов — просто открой Play Market. Также она хороша огромными ресурсами гугла, чего стоит их новый конкурент джаваскрипта —Dart, и его фреймворк Flutter, который уже сейчас может экономить массу сил разработке и дизайну. Компоненты в нём называются виджетами и помещаются один в другой. Целый экран может быть виджетом, состоящим из виджетов меньшего порядка.
БЭМ
У продуктов Яндекса есть конструктор, который позволяет компании очень гармонично смотреться и запускать продукты модульно и быстро. Модульно — значит, что ничего не развалится, если где-то открутить связанную часть. По факту дизайн-система, но со своей методологией — БЭМ. Иногда ласково называют «Лего».
Ant Design
Китайская открытая библиотека компонент и принципов проектирования. Очень хорошо продумана. По факту не является дизайн-системой, но может служить прекрасным фундаментом, чтобы развивать свою.
Прочие
Даже у государственных сервисов есть дизайн-системы. Существуют коллекции открытых дизайн систем. Вот пара примеров:
Как создать дизайн-систему
От компании к компании процесс может сильно отличаться, так как заинтересованные люди могут либо вовсе отсутствовать, либо не осознавать своей личной потребности в каких-то улучшениях процессов. Хорошо бы для начала собрать информацию, познакомиться со всеми отделами. Детально пообщаться, выявить их боли и не заикаться ни о какой дизайн-системе, пока не увидишь, вот их личную выгоду, которую позднее можно предложить. Практически всегда есть инициативные разработчики, дизайнеры и менеджеры, которых задолбал бардак — с ними дружи больше прочих.
Можно идти сверху или снизу. Снизу — самый долгий, но самый надёжный в консервативных компаниях путь. Сверху — только если можешь составить детальный финансовый план безубыточности проекта. Или знаешь, кому принести коньяк, но я не советую.
Заручись поддержкой всей компании
Когда у тебя есть список жертв, включай партизана. С этим разработчиком по фану пробросьте токены из фигмы к нему в переменные компонент прямо на своём проекте. Раз! И всё отвалилось. Так как это факультативный фан — можно экспериментировать не боясь провалов. Токены — это переменные в коде напрямую из дизайн-библиотек. Подробнее будет отдельная статья, это весело, примерно как тригонометрия.
Ещё хорошо, когда все команды разработки уже имеют свои библиотеки компонент. Тогда их компоненты можно попробовать пробросить в фигму через API, чтобы дизайнеры использовали в дизайне только те компоненты, которые уже сущетсвуют в коде.
Когда со стороны разработки основные страхи будут закрыты — можно идти к продакт и проджект менеджменту и выяснять, сколько разработка будет тратить денег в одном случае, а сколько в другом. У тебя уже есть почва в виде экспериментов с разработчиками. Хорошо бы уже тут учесть динамику появления новых компонент, чтобы оценить грубо стоимость поддержки системы.
Аналитики, описывающие твои шедевры методом обратного инжиниринга уже писали спецификации копипастой, просто спроси, как много они это делали и покажи, что можно сделать один общий гайд не на тысяче страниц, а на пятидесяти с взаимосвязями. Всё равно писать, почему бы не сразу структурно о какой-то части, а потом просто ссылаться туда каждый раз.
Организуй ресурсы
Когда финансовый департамент окажется в окружении из твоих новых союзников, сигнализируй наступление. Ладно, шутки в сторону. В каждой команде уже есть ресурсы на развитие продуктов. Можно вплетать туда задачи, вроде «вместо гуляния по макетам и сверки артефактов и спек, поговори со всеми, кто что-то такое уже делал и положите в одно место, назовите библиотекой, усредните параметры, чтобы если у кого поехал дизайн — он поехал минимально». Делай так долго, упорно и регулярно. Новые продукты сразу предлагай делать из библиотеки. Если какой-то компонент встречается только в одном продукте — иметь вторичную библиотеку для каждого продукта нормально, главное, поддерживать общие принципы.
Разработай принципы дизайна продукта
Будет ли это доступность, человеко-ориентированный дизайн, объектный дизайн или блочный, как у Яндекса, этот принцип должен соблюдаться всюду. Принципы могут дополняться правилами и исключениями, самое главное, чтобы они оставались логически связанными и понятными к однозначной интерпретации всеми участниками процесса.
Этот процесс не имеет старта и окончания. Принципы меняются вместе с компанией и её продуктами.
Выбери визуальный язык и тон
Зелёный — хорошо, а красный — плохо в рамках одного продукта, а в рамках другого хорошо — это синий. Чтобы никто не путался, это надо записать и добиваться использования одного языка. Помимо цветов в одних и тех ситуациях надо договориться использовать одни и те же сетки, шрифтовые решения с размерами и их реакцией на размеры экрана, отступы, стиль иллюстраций и так далее. Иногда визуальный язык включают в принципы.
Часть стилей отсюда могут стать в коде токенами, часть — атомами для формирования молекул, а из низ органов — компонент. Подробнее читай «Атомарный дизайн». Там наполовину хорошо всё описано, жаль только для идеального мира.
Если продуктов уже много и они похожи на зоопарк — сваливайте командой все типовые решения в кучу, накладывайте и усредняйте. Мы как раз сейчас таким занимаемся в Манго. Получается примерно как в картинках, где нейросеть усредняет лица людей. Минимальной кровью продукты станут единообразными, покрываясь со временем новыми универсальными компонентами. Плюс так централизованное обновление стилей станет хотя бы вообще возможным.
Создай компоненты
К этому этапу стоит отнестись внимательно. Моя прошлая команда знает, что выходит, когда компонент уже используется в сотнях макетов, и тут прилетает обновление, в котором старые слои удалены и вместо них новые. Спойлер — слетают все применённые поверх старых слоёв стили и тексты. Лучше сразу делать архитектуру так, чтобы потом не пришлось переделывать сильно.
Сформируй шаблоны
В русском есть шаблоны страниц и паттерны (что тоже переводится, как шаблоны), это взрывает мозг. В английском проще: templates для шаблонов, и patterns. Их часто смешивают. Терминологический спор — вообще такое характерное свойство дизайн-сообщества, а для себя я выделил такой принцип.
Шаблон — статичное состояние типичной страницы или крупной её части, а паттерн — то, как пользователь привык этим шаблоном пользоваться. Это одновременно:
- Крупными мазками привычки пользователя искать меню слева, а кнопки управления внизу, которые лучше не ломать,
- Динамика реализации какого-то одинакового мини-сценария, который часто становится деталью более крупных сценариев, но всегда в одинаковой форме. Например, редактирование сущности или навигация.
Докуметируй
Всё, что не описано в виде документации — не существует с точки зрения проекта и команды уже через день. А ещё люди приходят и уходят, но система должна жить. Здорово иметь одну базу знаний по дизайн-системе. Для этого даже необязательно поднимать свою вики или сторибук, можно использовать готовые Zeroheight или Storybook. Если дорого, то начать можно в Яндекс Коннекте или Конфлюенсе.
Итог
Сделать дизайн-систему сложно. Это производство средства производства, а потом ручное поддержание шаткого порядка, стремящегося скатиться обратно в балаган в сторону энтропии. Ко всему стоит относиться с известной долей скептицизма, особенно к тому, что транслируют из каждого утюга. Если пришла в голову идея разработать дизайн-систему, перечитай статью и подумай ещё раз. Может быть ты можешь обойтись простым UI китом и быть счастливым румяным карапузом, а не чахлым замученным зомби, который пинает всех вокруг, чтобы хоть что-то работало. Успехов!
(No Ratings Yet)
Загрузка...