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

#дайджест декабрь 2023

① Мы выпустили дизайн-систему Атомаро для команд и бизнеса
Атомаро — это сервис и конструктор для создания дизайн-систем для любой задачи. Figma и React библиотеки, дизайн-токены и простая темизация, все решения проверены на 150+ проектах. Система будет развиваться и наполняться ценностью, присоединяйтесь!

② Объявлены финалисты Design Systems Awards 2023
Победители конкурса в основных номинациях: Pinterest — сотрудничество, Wise — внедрение, Schneider Electric — управление, Eventbrite — документация. Лучший плагин — Tokens Studio, лучшая статья — о карьере в индустрии дизайн-систем, лучший доклад — Multidimensional Design Systems

③ Материал обновили свой генератор темы
Плагин для Figma Material Theme Builder обновился до версии 2.0. Разработчики переработали интерфейс, объединив работу с динамическим цветом и core цветами на одном экране, улучшили менеджмент тем и UX, добавили больше платформ для экспорта

④ Figma поделилась планами на развитие variables
Рассказали о последних апдейтах, способах совмещения переменных со стилями и планах. Главная цель — предоставить опыт, который обеспечивает бесконечные возможности настройки, но при этом прост в применении.

⑤ Сторибук обновился до версии 7.6
Повысили перфоманс, добавили режим тестирования, диагностику при миграциях на новую версию, вынесли React из peer dependency и отказались от поддержки Vue2

Друзья, наша команда желает вам новых компонентов, проектов, дизайн-систем и успехов в новом году! 🧡

#дайджест октябрь 2023

① WCAG 2.2 опубликован как рекомендуемая версия
В стандарты по обеспечению доступности добавили 9 новых критериев и 1 удалили (про parsing). Для более подробной информации смотрите официальный список отличий от W3C и подборку лучших статей на Smashing Magazine.

② В Polaris обновили визуальный язык
Дизайн-система от Shopify заслуженно попадает во все подборки топ систем — у них есть чему научиться. В Polaris пересмотрели подход к дизайну и полностью изменили компоненты. В новом дизайн языке приоритет отдается эффективности и интуитивному взаимодействию, ориентированному на повседневные повторяющиеся задачи. Статья о процессе редизайна (нужен впн) от авторов.

③ Josh Clark о скорости развития дизайн-систем
Успешные дизайн-системы развиваются медленнее, чем продукты, которые они поддерживают — и это нормально! Почему так происходит? Качество важнее скорости. Как не стать бутылочным горлышком для продукта? Продукт делает своё решение с оглядкой на стандарты дизайн-системы, которое после может быть адаптировано как часть дизайн-системы.

④ Brad Frost про экосистему дизайн-системы
Простая, но успешная и востребованная система, встречаясь с новыми вызовами, вырастает в большую комплексную структуру. Автор модели атомарного дизайна рассказывает как может выглядеть «взрослая» дизайн-система в большой организации. Многослойная структура и связи между элементами предлагают надежный способ организации системы. Есть куда расти!

⑤ Искусственный интеллект в дизайн-системах
Запись выступления спикеров из Knapsack c конференции Into Design Systems. Дизайн-система может задавать контекст и необходимые ограничения для AI, они как будто созданы друг для друга. AI будет помогать пользователям исследовать и использовать, а разработчикам создавать и менеджерить систему.

#софты

Как стать тимлидом. Часть 2

Развивать и воспитывать в себе качества лидера:

— Наличие интеллекта выше чем у хлебушка;
— Насмотренность и эрудированность;
— Воля и упёртость;
— Справедливость и честность: похвалить за результат, поругать за дело, помочь, когда команда на излёте, принести ништяков за работу, признать собственные ошибки;
— Профессионализм: хорошо делать, учиться, приносить новые знания команде;
— Ставить интересные вызовы и цели, благодаря которым команда растёт;
— Защищать команду от внешних потрясений (политика, неадекватные заказчики, отдел командировок и т.д).

Что дальше? Вам нужны условия, в которых ваши качества лидера смогут раскрываться и работать. Я для себя всегда отмечал несколько важных аспектов, без которых вы скорее останетесь ведомым, а не ведущим.

① Первое, оно же как базовая гигиена — вам должно нравиться то что вы делаете. Занимаетесь дизайном, продуктом, или разработкой — без любви к делу вы просто не сможете вести за собой людей, это чувствуется сразу, моментально.

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

③ Третье, самое важное. Ответственность не дают, её берут. Ваши возможности ограничивает неповоротливая бюрократия, политические подковерные игры, либо голова упирается в потолок роста на текущем месте? Убирайте эти ограничения, и ищите не возделанную полянку, где вы ударите кулаком по столу и громогласно заявите что теперь вы за это отвечаете.

Пишите в комментах, что раскрыть подробнее.

#дайджест сентябрь 2023

① Редизайн сайта Google Fonts
Обновили навигацию для десктопа и мобилок компонентами из Material 3. Переработали фильтрацию и перенесли её в сайдбар. Цветовая схема теперь тоже из Material 3, для светлого и тёмных режимов. Отличная демонстрация новой дизайн-системы от Google в деле!

② Чек-лист по процессу создания и внедрения дизайн-системы
Кnapsack собрали основные моменты, на которые следует обратить внимание при создании дизайн-системы. И это не про количество компонентов или следование стандартам, а про аудит, видение, стратегию, команду и выстраивание правильных процессов.

③ Агрегатор мероприятий по нашей теме
Энтузиасты дизайн-систем запустили сайт с предстоящими событиями, лекциями, вебинарами по тематике дизайн-систем. На многие бесплатный вход. Для хардкорных олдов есть RSS подписка =)

④ Финалисты Design Systems Awards
Собственный конкурс от Zeroheight, о котором мы недавно рассказывали, объявил финалистов по всем категориям. Стоит ознакомиться с лучшими дизайн-системами и статьями в индустрии (по мнению уважаемого жюри конкурса). Победителей объявят 30 ноября.

⑤ Плагин для автоматической локализации Variables Translator
Если в интерфейсе требуется поддержка нескольких языков, то вы уже оценили силу Figma-переменных. Этот плагин переведёт коллекцию string переменных на другой язык (русский в комплекте!) и добавит новый mode в коллекцию.

⑥ Сборник ресурсов по Figma-переменным
Для тех, кто еще не разобрался с variables. Около 50 ссылок на статьи, видео и файлы-примеры, объясняющие принципы работы и техники использовавния. Не отстаём, догоняем прогресс и переходим на переменные!

#софты

Как стать тимлидом. Часть 1

Кратко

1. Воспитывать в себе качества лидера.
2. Искать условия, где есть вызовы, свобода действий и ответственность.

Подробнее

Начну с главного, что порой утекает из внимания айтишного сообщества в вопросах пипл-менеджмента и роста людей.

Тимлид — это лидер. Лидер команды. Не самый опытный разраб, не лучший дизайнер, не самый умный аналитик, и т.д.

Какие черты личности и характера отражают способность человека стать лидером группы?

Это: интеллект, общая эрудиция, воля и упорство, справедливость, умение воодушевить людей, но и умение признавать свои ошибки. Разумеется лидер хорош в своём профессиональном деле, у него всегда есть чему поучиться! А ещё он рисует картинку в пространстве-времени, к которой движется команда, т.е. ставит цель, да такую что охренеешь (по-хорошему) достигать. Но при этом лидер проявляет заботу и защищает команду.

Выкинь хоть одно из этих качеств и вместо лидера будет клякса.

Пример ①
Представьте что человек профессионал, умеет воодушевить, есть упорство. Но тупой как хлебушек. А цели которые он ставит — слабенькие и приземлённые, т.к интеллекта и общей эрудиции не хватает для визионерства. А то вообще никаких целей, вся команда закрывает отчетности. Вы пойдёте за таким?

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

Пример ③
Умный, талантливый, настоящий визионер, но совершенно не умеет работать с людьми. Ни зарядить энергий, ни воодушевить. Ни цель нормально обозначить. А стиль управления через манипуляции, давление, и бесконечные обесценивания: «вы опять просрали дедлайны!», «можно было и лучше». Никогда не признаёт своих ошибок, но всегда найдёт их у вас. Достиженец и царь токсичного болота. Вы пойдёте за таким?

Вы уже поняли к чему я клоню. Тимлид это про конкретные лидерскик качества, и они все важны.

продолжение в следующем посте

#дайджест август 2023

① Аддон в Storybook для визуального тестирования
Сравнивает разные версии в стори, выявляет регресс и показывает отличия прямо в Сторибуке. Выполняет проверку в различных браузерах и разрешениях. В навигационной панели Сторибука подсвечивает стори, в которых есть изменения. Аддон пока в статусе альфа, получить ранний доступ можно по запросу.

② Новая Figma-библиотека дизайн-системы Carbon с нативными переменными (открывать под vpn)
В Carbon, дизайн-системе IBM, отказались от стилей и перешли на variables. Это позволило объединить 4 темы в одном файле. И добавить токены для спейсингов, брейкпоинтов, радиусов и прочего. Находим файл в комьюнити Фигмы и изучаем решение.

③ Эволюция дизайн-системы Encore в кросс-платформенность
Spotify рассказали о развитии системы, столкнувшейся с необходимостью поддержки 45 платформ и 2000+ устройств. Новая версия дизайн-системы стремится к «сплоченности» при которой компоненты стали кросс-платформенными. Для этого были созданы единые правила, одинаковые на всех платформах и учитывающие их особенности.

④ Figma дорабатывает переменные
Появилась возможность настраивать свойства нескольких переменных одновременно. Имя переменной теперь редактируется и поддерживает разные платформы. Можно указать в каких свойствах будет доступна переменная цвета. И доступна смена режима в слоях инстанса. Как видим, доработки косметические, типографику и эффекты всё ещё не завезли. Ждём!

⑤ Пишем документацию для дизайн-системы с помощью AI
Zeroheight поделились рекомендациями по работе с Chat GPT. Самое важное в этом деле — точно сформулированные запросы с вашим контекстом. В статье приводится подробный пример промпта для документации. И еще один метод, от тех же авторов. Комбинируя оба подхода, можно быстро получить стартовый материал для дальнейшей проработки.

#про_управление

Сетапы ДС. Минимальная выделенная команда

Если в предыдущих сетапах вы показали хорошие результаты, то у вас есть возможность получить бюджет на собственную команду! А если вдобавок вы дружите с финансовым директором, тогда можете расчитывать на бюджет побольше, возможно вам даже хватит на двух джунов-разработчиков! Неплохо же.

Словом, не нищебродский сетап, а выделенная команда! Руководит дизайн-системой по прежнему дизайн-лид, но теперь у него в подчинении целый разработчик, или целых два.
Плюсы: повышенная самооценка дизайн-лида (недолго), можно уже ходить по митапам и с умным видом рассказывать про «слияние» дизайн-систем, единые стандарты, и прочие банальности.

Как это ни парадоксально, но то что у вас появился целый один (или даже два) разработчика не означает прогресс в качестве дизайн-системы.

⊕ плюсы: нет.

⊖ минусы: вы теперь несёте ответственность за качество кода.

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

Важно помнить, что дизайн-системы — технологически сложный инструмент. Когда разработкой кода занимается один человек, вы зависите, вы не понимаете правильность его решений, вы не можете ничего контролировать. Это риск. Фидбэк от других разрабов тоже не поможет.
Если вы транслируете, что у вас выделенная команда, тем более, если вы заявляете что вы «продукт!», то готовьтесь к потоку хейта со стороны других разрабов. Они будут приходить и говорить, что вы всё делаете неправильно, при этом советы, как правильно, будут один чуднее другого. Ваш целый один разработчик (или даже два) будут тотально под прессингом токсичной среды разработчиков. Но разгребать вам.

Советую долго не находиться в этом сетапе, а сразу переходить в следующий, иначе выгорите.

продолжение

Вы возразите, а почему так пессимистично? А я отвечу: потому что у проектов есть владельцы, зачастую это не одно лицо. В их интересах, чтобы разработчики в первую очередь уделяли время целевым проектам, а не чему-то «общему». Вы ещё раз возразите и скажете что разработчики всё равно заверстают ui-киты по одному дизайну, а значит это всё можно объединить и переиспользовать. На что я вам скажу: так не работает. Разработчики разные, владельцы проектов разные, требования разные, стайлгайды разные, роадмапы разные. В парадигме заказной разработки или в крупных продуктах между проектами как правило низкий уровень обмена опытом и стандартизации.

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

Поэтому я и называю этот сетап партизанским: чем дальше в лес, тем толще разрабы-партизаны. Так что, в таком сетапе систему если и используют, то чаще в качестве донора для форков с дальнейшим допиливанием под себя. У того же ант дизайн 40к форков. Каждый десятый пользователь создал по одному форку!

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

#про_управление

Сетапы ДС. Внутреняя контрибьюция, она же «партизанская разработка»

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

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

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

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

Сравните с опенсорс проектами: там добровольная контрибьюция работает в силу массовости проекта. К примеру в ant.design 440к пользователей, из них 2 тысячи контрибьюторов. Это менее половины процента! Сколько у вас в компании разработчиков? Допустим 1000. Сколько из них будут стабильно контрибьютить? 5-10. И это не фуллтайм, в лучшем случае вы можете рассчитывать, что вашей дизайн-системе будут уделять пару часов в неделю.

продолжение в следующем посте

#технологии

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

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

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

Второе техническое мероприятие в нашей команде — разговоры об архитектуре. Название говорящее, на нем мы прорабатываем новую архитектуру для наших компонентов. Универсальную, доменно-распределенную, понятную. Работаем мы на доске Арти: в совместном обсуждении рисуем абстрактные и конкретные смысловые элементы системы.

Такие мероприятия позволяют придерживаться концепции технического лидерства, о котором мы поговорим в следующих постах.

#про_управление

Сетапы ДС. Приспособа для дизайнеров

В этом цикле постов расскажу о различных сетапах команды и проекта дизайн-системы. Если вы делаете дс, или только предстоит, то вам будет полезно понимать, как обычно это устроено. Все эти этапы мы прошли и мы сами, создавая Дизайн-систему Ростелекома.

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

Техническая часть сильно разнообразна, и полностью зависит от стека целевого проекта.

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

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

В таком сетапе дизайн-система — это «приспособа» для дизайнеров.

⊕ плюсы: делаешь для себя, как тебе удобно.
⊖ минусы: неудобно всем остальным.

#дайджест июль 2023

① Стартовал Design System Awards 2023
Zeroheight, известные ежегодным исследованием индустрии How We Document, продолжают наводить движуху в комьюнити и запускают премию Design System Awards. Заявленная цель — признание выдающихся дизайн-систем и команд, стоящих за ними. Соревнование проводится в 8 категориях, заявки принимаются до 1 сентября.

② Новые дизайн-киты от Apple
Apple предоставила новые материалы для разработки приложений в Figma и Sketch. Библиотеки для новых visionOS, iOS 17 и iPadOS 17, macOS Sonoma, watchOS. Обновились гайды Human Interface Guidelines. Шрифт с символами SF Symbols пополнился еще 700+ новыми пиктограммами.

③ Обновления Storybook 7.1 и 7.2
После долгой паузы Сторибук выкатили обновление и за ним сразу же еще одно. Добавили обучающий онбординг, автоматическую настройку Сторибука под популярные библиотеки, TypeScript стал языком по-умолчанию для доков и еще несколько улучшений.

④ Поддержка новых фигма-переменных плагинами:
Token Studio выпустили релиз с поддержкой новой фичи сразу же после Config. В июле докручивали и фиксили баги, связанные с переменными.
EightShapes Specs, плагин для генерации спецификаций компонента, так же научился работать с переменными и с токенами из Token Studio. Но только в платной Pro версии.
Apply Variables — новый плагин от разработчиков Token Studio. Корректно заменит стили на переменные, автоматически подставит переменные в свойства при совпадении значений.

⑤ Visual Difference, новый плагин от Nathan Curtis
Сравнивает скриншоты объектов для визуального обнаружения изменений. Поможет обнаружить различия, вызванные обновлением библиотек, мерджем веток, сравнить разные версии скриншотов и быстро исправить все ошибки.

⑥ Валидатор дизайн-токенов от Anima
Анима предлагает проверить ваши токены на соответствие будущей спецификации для дизайн-токенов. Зачем? Соответствие стандартам обеспечит совместимость с широким набором инструментов проектирования в будущем.

#инструменты

Часть 2

Теперь посмотрим на инструменты от разработчиков известных дизайн-систем. Они сделали утилиты для себя и своих пользователей, но решили поделиться со всем сообществом. Поблагодарим их и пойдём подбирать идеальные цвета для своего проекта! Часть 1 тут

④ leonardocolor.io
набор опен-сорс инструментов от Adobe (Spectrum) для работы с цветовыми системами. Один из них, Adaptive color theme, помогает создать набор доступных цветовых палитр для пользовательского интерфейса. Настройка светлоты, контраста и насыщенности всей темы. Проверка по WCAG или APCA. Поддерживает 9 цветовых пространств. Для оценки результата и точной визуализации строит диаграммы цветов, яркости и даже 3D модель. Экспорт для Javascript, CSS и в формате JSON-токенов. Больше о возможностях приложения в вводной статье от автора (для просмотра нужен впн).

⑤ primer.style/prism
генератор от GitHub (Primer) для создания и поддержки целостных, согласованных и доступных цветовых палитр. С его помощью команда дизайн-системы Primer усовершенствовала свой воркфлоу генерации новых тем. Использует пространство HSLuv, что позволяет подбирать однородные палитры для разных цветов. Умеет настраивать кривые HSL сразу для нескольких цветовых шкал одновременно. Проверяет контраст полученных цветовых пар по WCAG. Результат можно экспортировать/импортировать в формате JSON. Статья о генераторе и воркфлоу в github.blog.

⑥ m3.material.io/theme-builder
генератор темы для нового Material 3. Из четырёх базовых цветов создаёт полный набор для темы со светлой и тёмной схемой. В дополнение к основной палитре может сгенерить палитры из дополнительных цветов. Больше настроек нет, всё жестко ограничено и подчинено алгоритму, работающему в собственном цветовом пространстве HCT. Экспорт для Android и Flutter, СSS-переменными и токенами в формате DSP. Дизайнеры могут вспользоваться плагином-генератором для Figma.

#инструменты

Часть 1

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

① https://huetone.ardov.me/
Генератор «доступных» цветовых систем с предсказуемой контрастностью. Работает в пространстве LCH. Помогает добиться однородной воспринимаемой яркости цветов в градациях. Проверяет контрастность по стандартам WCAG 2 и APCA. Экспорт в Token Studio или CSS-переменными. Тред про генератор от автора (для просмотра нужен впн).

② https://accessiblepalette.com/
Генератор «доступных» цветовых систем с консистентой яркостью и предсказуемым коэффициентом контрастности на всех уровнях цвета. Работает в пространствах CIELAB или RGB. Проверяет контрастность по стандартам WCAG 2 и WCAG 3. Экспорта нет. Статья про генератор от автора.

③ https://www.genomecolor.space/
Еще один инструмент, похожий на предыдущий генератор. Работает в пространстве Oklab. Не так гибок в настройке шагов градации и количества оттенков. Может добавлять закрепленные цвета и названия оттенков. Проверяет доступность по WCAG горячими клавишами по степени контраста. Экспорт в JSON и в Figma с помощью собственного плагина. Статья про генератор от автора (для просмотра нужен впн).

Продолжение в следующей части.

#технологии

Часть 2

Продолжаем рассказывать о критериях, по которым мы определяем, нужно ли выводить новую функциональность в пропс. Часть 1 тут

③ Универсальный пропс > монофункциональный пропс. Яркий пример — валидация. Зачастую нас просят добавить валидацию, например на корректность почты. Доработка хорошая, но зачем ограничиваться почтой, если можно добавить пропс validationRules и дать возможность разработчику самому определять правила валидации. Тут нужен и важен баланс, иначе можно прийти к одному объектному пропсу, в который нужно будет прокидывать конфигурацию для всего компонента.

④ Непродуктовая фича. Важно найти оптимальное сочетание между навешиванием рычагов на вообще всё и абсолютно неповоротливым, заточенным под один продукт, компонентом. Яркий пример перегиба в одну сторону — компонент InputDate. В какой-то момент мы поняли, что у нас около 40 пропсов. Добавить легко, удалить сложно. Удаление пропса или изменение его нейминга неизбежно ведет к breaking changes и обновлению мажорной версии. Должны быть очень веские аргументы, для того, чтобы мы добавили к нему новый параметр в текущей версии. Клепать часто мажоры нельзя, поэтому мы подготавливаем список семантических и функциональных изменений к новой версии и начинаем внедряем декоратор deprecated.

Похожим образом, мы выводим критерии и ищем свой дзен, проектируя дизайн-токены. Подробнее о токенах в нашем канале расскажет Денис Плешаков — продакт Дизайн-системы Ростелекома.

#статья

У нас вышел лонгрид на хабре про цикл жизни дизайн-систем.

Из статьи вы узнаете:

① Про универсальные принципы систем и закон Эшби;
② Циклы перерождений;
③ Майлстоуны и линейное развитие;
④ Как смотреть в будущее.

Оставляйте комменты, ставьте лайки, нам важно ваше мнение, чтобы улучшать контент =)

#технологии

Часть 1

Любой компонент дизайн-системы состоит из набора параметров/пропсов — props (properties). Если их нет, то это скорей всего локальный ui-kit, заточенный под 1-2 проекта. Подробнее мы рассказывали в нашей статье о разнице дизайн-системы и ui-kit. Пропсы — своего рода рычаги, с помощью которых компонент управляется, регулируется, кастомизируется. Иногда это портал вовнутрь компонента, например рендер-функции или колбэк-функции, возвращающие изменения значений.

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

Для Дизайн-системы Ростелекома мы вывели следующие критерии:

① Массовость. Востребованность функциональности должна быть у большинства разработчиков. Понимаем это с помощью интервью наших пользователей, изучению других дизайн-систем, на основе собственного опыта. К примеру, графики и диаграммы. На предыдущем проекте мне нужны были графики и я очень хотел, чтобы они были в нашей Дизайн-системе. Когда я начал работать внутри команды дс, то понял, что сделать +- универсальные графики сложно и смысла в этом нет. Тем более, они нужны единицам. Проще воспользоваться старым-добрым хайчартом.

② Невозможность реализовать функциональность на стороне пользователя. Большинство запросов на доработки от пользователей можно закрыть, предоставив пример реализации без изменения компонента. Для пользователей это является элементом обучения по использованию дс, а для нас возможность расширить и детализировать документацию.

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

Есть ещё 2 критерия, которые мы для себя определили. О них я расскажу в следующем посте.

#дайджест июнь 2023

① Большое обновление Figma
На июньском Config 2023 команда Фигмы презентовала улучшения, которые помогут разработчикам дизайн-систем и юай-китов в их непростой работе. Переменные: для дизайн-токенов, локализаций интерфейса и темизации. Autolayout: минимальная ширина и высота, врапинг. Новый Dev. Mode с Component Playground и интеграциями со Storybook и Zeroheight. Изучаем нововведения и улучшаем свои библиотеки, работы много!

② Microsoft Fluent 2
Эволюция дизайн-системы Майкрософт обещает плавное движение от дизайна к разработке между приложениями и платформами. Обновили цветовые стили и токены, расширили возможности настройки системы и доработали руководства и рекомендации по стандартам доступности. Несоответствие приятных ярких 3D иллюстраций с максимально утилитарными компонентами вызывает небольшой диссонанс

③ Material Design переизобрели карусель
И поделились процессом в блоге. Технологии нового Материала: система динамических шейпов, система анимаций и скрола, соединяясь, предложили свежение решение для привычного паттерна.

④ В Atlassian Design System появился мастер выбора подходящего токена
Чем больше возможностей предлагает система, тем сложнее с ней разобраться. Мало кто любит читать документацию, изучать огромные списки токенов… И тут на помощь приходит Token Picker!

⑤ Визуализация связей между токенами от Adobe Spectrum
Продолжаем тему документации токенов. Если в ваших токенах чёрт ногу сломит, приходится рисовать многоуровневые макароны. Разобраться что к чему теперь действительно проще.

⑥ Design Tokens Generator (для открытия нужен впн)
Ммм, опять токены… Горячая тема! Инструмент для упрощения менеджмента токенов предлагает сосредоточиться на внешнем виде, а приложение позаботится об утомительных аспектах таксономии. Вот тут можно почитать о возможностях. Интерфейс генератора сбивает с ног =)

#про_управление

Из Википедии: «продукт — товар или услуга, которую можно предложить для рынка, и которая будет удовлетворять потребности потребителей».

Дизайн-система не что иное как цифровой товар, инструмент, и он должен удовлетворять потребностям конечных пользователей — end-users, т.е. разработчикам и дизайнерам. А также ЛПР, бизнесу, и закрывать их kpi. Иначе бизнес не будет платить за дизайн-систему. А дизайн-система — дорогая игрушка, в среднем разработка и внедрение для компании стоит 50-100 млн ₽ в год.

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

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

#про_управление

Индустрия набирает ход в сторону сближения и автоматизации разработки и дизайна. Самый главный инструмент для UI-UX дизайнеров — Figma, уже представляет из себя что-то среднее между граф. редактором и CSS. Механика вариантов и автолэйаута пришла напрямую из фронтенда, а вся правая панель фигмы это, по сути, урезанный css в виде юзер-френдли интерфейса. А после недавнего обновления с dev-режимом, фигма уже может генерировать код из макета.

Low-code проекты, такие как Framer — ещё один яркий представитель мощного инструментария для дизайна и разработки одновременно. Начинался проект как софтина для создания анимированных прототипов. Сейчас же это комбайн в котором можно создавать рабочие сайты, с кодом, дизайном как в фигме, анимацией, и прочим.
Сравните с тем что было 15 лет назад: дизайнеры рисовали сайты в программе для ретуширования фото.

Автоматизация для разработчиков продвинулась ещё дальше. GitHub Copilot, OpenAI Codex, Starcoder. Все движки дописывают работающий (!) код в режиме «скажи что надо, я напишу код». Copilot вообще встроен в репозиторий.

Дизайн-системы вполне очевидно идут в эту же тенденцию. Как технология, дс прошли свой пик хайпа пару лет назад и долину разочарования, и выходят на плато размеренного развития.

Так что очень скоро можно ожидать, что дизайн-системы превратятся из дорогой игрушки для корпораций во вполне ежедневный продвинутый молоток для дизайнеров и разработчиков. Ну а там уже и нейронки подъедут.