Ниже — мои, немного отредактированные и дополненные, ответы на вопросы Саши Ефремова для его статей на Медиуме и vc.ru про дизайн-системы.
Более 10 лет я работаю в Контуре. Последние 5 лет я работаю над дизайн-системой продуктов Контура — делаю Контур.Гайды. Сразу скажу, что тексты гайдов, компоненты и библиотеки результат долгой и кропотливой работы многих дизайнеров и разработчиков Контура. Гайды и библиотеки поддерживает отдельная команда. Я долгое время был руководителем этой команды, сейчас сочетаю в себе роли аналитика, писателя, проектировщика интерфейсов, тестировщика и менеджера продукта.
Что такое дизайн-система?
Дизайн-система — это сложный организм, который имеет единый источник правды в дизайн-токенах.
В моём понимании дизайн-система это инструмент, который помогает формировать и поддерживать единый пользовательский опыт при взаимодействии с разными продуктами компании, а также оптимизировать расходы компании на создание этих продуктов.
Дизайн-система это синхронизированные между собой библиотеки компонентов для дизайнеров и фронтендеров, имеющие подробную спецификацию, документацию, набор примеров и список бест практис. Это организм, имеющий единый источник правды в дизайн-токенах. Это культура взаимодействия с ним и выделенная команда для его поддержки.
Зачем делать свою дизайн-систему если их и так тьма?
На свою систему влиять проще и в итоге она со временем становится дешевле
Всё зависит от контекста: от продукта, проекта, его возраста и его амбиций.
Если проект только на старте и тебе нужно сделать MVP, то можно делать его на основе любой сторонней бесплатной или платной библиотеки или юай-кита. Сначала сторонняя библиотека может казаться избыточной, но со временем в ней станет тесно.
С развитием продукта будут появляться такие требования к компонентам, которые будет сложно, долго или дорого реализовать с помощью сторонней библиотеки. Придется делать рядом свои компоненты и постепенно переезжать на них.
На свою систему влиять проще и в итоге она со временем становится дешевле. Скорее всего вы не сможете повлиять на разработку дизайн-системы от Google не находясь внутри компании. Или это будет очень трудно.
С чего начать создание дизайн-системы?
Один из вариантов — закинуть опрос
Как всегда, нужно начинать с исследования. Скорее всего в компании уже есть какие-то элементы дизайн-системы, и нужно понять как ими пользуются в компании.
Дизайн-система это продукт, нужно подходить к её развитию, как к развитию продукта: узнавать у пользователей, какие у них есть сложности, что «болит» у дизайнеров, что у фронтендеров, какие сложности есть в коммуникации между ними и в реализации задуманного дизайнерами.
Как один из вариантов что поделать — можно закинуть опрос на каждую из ролей и подумать как решить их проблемы. Может выясниться, что дизайн-система на этом этапе еще не нужна. Будет достаточно нарисовать общий UI. Или, например, у вас есть общий UI, но при этом слишком простые компоненты для фронтендеров, нет системности в их использовании и нужно предоставлять более сложные, но строго унифицированные компоненты.
Какой самый важный параметр хорошей дизайн-системы?
Хорошая система — гибкая и отзывчивая
Если изменение, которое тебе нужно внести в систему и распространить на все продукты занимает неделю или две, то это отзывчивая система. В плохих сценариях изменения могут «раскатываться» годами. Бюрократия и неповоротливость — главный недостаток любой системы.
Тут всё будет зависеть от того, насколько хорошо вы наладите взаимосвязь с сообществом и пользователями системы (дизайнерами, фронтендерами и прочими ролями), и на сколько они будут заинтересованы вмешиваться, влиять на систему и помогать в её развитии. Любая система это коллективный продукт, и её нельзя создать изолированной командой.
Второй признак — удобство использования. Если дизайнер или фронтендер понимает как пользоваться системой не читая длинных инструкций, то скорее всего она удобна, а значит стройна и не противоречива. Хотя, без подробной спецификации и документации всё равно будет не обойтись.
Насколько сложными могут быть компоненты дизайн-системы?
Мы собираем примеры страниц сервисов, чтобы помогать дизайнерами увидеть общую картину
Можно идти в усложнении до тех пор, пока компонент не станет настолько сложным и неповоротливым, что его будут использовать уже только как пример шаблона, который можно детачить (если говорить про компоненты библиотеки в Фигме). При этом отсоединенный компонент всё равно собран и состоит из более мелких компонентов — элементов дизайн системы.
Пример: когда мы работаем с модалками или некоторыми выпадающими меню дизайнеры детачат и модифицируют их. В итоге модалка уже не работает в дизайне как компонент, а переходит в формат шаблона, но состоит из таких компонентов как шапка, подвал, панель с кнопками, вуаль и прочих.
Также мы собираем шаблоны экранов, чтобы помогать дизайнерам держать всё в консистентном виде и отталкиваясь от этих шаблонов создавать новые продукты и понимать заложенные в дизайн-систему принципы. Такие шаблоны уже нельзя назвать компонентами дизайн-системы, но это всё равно её составные части и продолжение применения единых принципов в более крупных масштабах.
Что такое дизайн-токены?
Будьте готовы что с первого раза у вас не получится выстроить достаточно гибкую и стройную систему
Дизайн-токены это один из «источников правды» дизайн-системы и её параметров, наряду со спецификацией компонентов и правилами их использования. Система токенов помогает сократить время на внесение изменений, увеличивает гибкость и уменьшает стоимость разработки. А ещё токены помогают дизайнеру и разработчику понимать друг-друга и общаться на одном языке.
Сейчас в нашей дизайн-системе всё ещё не хватает простой и стройной системы токенов как единого источника правды. Есть достаточно большой набор токенов-переменных, но он сложный для понимания и у него нет спецификации и единой системы нейминга.
Будьте готовы что с первого раза у вас не получится выстроить гибкую и стройную систему, и в какой-то момент придется всё переписать, может быть даже не один раз.
Как вносить изменения в компоненты и не поломать их в продуктах?
Мы делим релизы на мажорные и минорные и глобально обновляемся примерно раз в год
В библиотеках для фронтенда мы придерживаемся стандартной конвенции семантического версионирования, поэтому мы стараемся откладывать критичные, ломающие обновления для мажорных релизов, а в рамках минорных обновлений поддерживаем обратную совместимость, поддерживаем все текущие компоненты, аккуратно добавляем новые фичи и исправляем баги.
В следующем мажорном релизе те компоненты которые мы планируем удалить мы объявляем устаревшими и только через одну мажорную версию удаляем. То есть у дизайнеров и разработчиков есть целый год, чтобы заменить устаревшие компоненты и переписать код на новое АПИ.
Чуть раньше чем для фронтенда мы выпускаем новую библиотеку в Фигме и так же стараемся поддерживать её не внося ломающих изменений. Для стабильности все изменения в компонентах тестируются скриншотными тестами, в том числе и в Фигме.
В данный момент я не ищу работу, но открыт к предложениям от компаний, имеющих офисы разработки в странах Евросоюза. Если вам нужен ведущий дизайнер — напишите мне в телеграм: @dzekh.