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

Как стать тимлидом. Часть 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. Да, есть ещё сторибук и его настройка, есть сайт, анонсы, релизы, но это все скорее манкиджоб, чем решение бизнес-задач. При такой ситуации не сложно оказаться в вакууме и перестать искать новые пути совершенствования себя и продукта. Для того, чтобы информационный кислород поступал в команду, я ввел регулярное мероприятие — Дайджест технологий. К каждому дайджесту один из членов команды разработки готовит тему о свежих технологиях и решениях, которые он изучил и локально у себя попробовал. На встрече разработчик рассказывает о всех плюсах и минусах предложенного подхода и самое важное, он рассказывает о ценности такого решения для нашей Дизайн-системы. Тем самым команда постоянно поддерживает свой технический кругозор, а продукту это позволяет быть технически актуальным и смотреть на несколько шагов вперёд. Об этом как раз рассказывал ранее Денис Пушкарь в статье про цикл жизни дизайн-систем. Второе техническое мероприятие в нашей команде — разговоры об архитектуре. Название говорящее, на нем мы прорабатываем новую архитектуру для наших компонентов. Универсальную, доменно-распределенную, понятную. Работаем мы на доске Арти: в совместном обсуждении рисуем абстрактные и конкретные смысловые элементы системы. Такие мероприятия позволяют придерживаться концепции технического лидерства, о котором мы поговорим в следующих постах.

#про_управление Сетапы ДС. Приспособа для дизайнеров В этом цикле постов расскажу о различных сетапах команды и проекта дизайн-системы. Если вы делаете дс, или только предстоит, то вам будет полезно понимать, как обычно это устроено. Все эти этапы мы прошли и мы сами, создавая Дизайн-систему Ростелекома. Классическая история, когда дизайн-систему делают продуктовые дизайнеры, которые участвуют на продукте. Как правило, это изначально инициатива дизайнеров, и лидом проекта выступает самый увлечённый дизайнер. Большинство корпоративных дизайн-систем начинались с этого сетапа. Техническая часть сильно разнообразна, и полностью зависит от стека целевого проекта. Дс заточена под нужды конкретного проекта или продукта — её невозможно переиспользовать без костылей. Лиду дизайн-системы техническая часть, как правило, неподконтрольна, а то и вовсе кода нет. Если же разработка присутствует, то техникой могут заниматься самостоятельно разработчики, по своему усмотрению. Отсюда и неподконтрольность, и неуправляемость: дизайнеру не хватит технического бэкграунда и знаний, чтобы менеджерить разработку. Но есть и исключения, всё зависит от уровня коммуникаций в компании и дружбе конкретных людей. В таком сетапе дизайн-система — это «приспособа» для дизайнеров. ⊕ плюсы: делаешь для себя, как тебе удобно. ⊖ минусы: неудобно всем остальным.