#дайджест июль 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
Анима предлагает проверить ваши токены на соответствие будущей спецификации для дизайн-токенов. Зачем? Соответствие стандартам обеспечит совместимость с широким набором инструментов проектирования в будущем.
① Стартовал 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
Анима предлагает проверить ваши токены на соответствие будущей спецификации для дизайн-токенов. Зачем? Соответствие стандартам обеспечит совместимость с широким набором инструментов проектирования в будущем.
👍7❤3🔥1🥰1🤷1
#про_управление
Сетапы ДС. Приспособа для дизайнеров
В этом цикле постов расскажу о различных сетапах команды и проекта дизайн-системы. Если вы делаете дс, или только предстоит, то вам будет полезно понимать, как обычно это устроено. Все эти этапы мы прошли и мы сами, создавая Дизайн-систему Ростелекома.
Классическая история, когда дизайн-систему делают продуктовые дизайнеры, которые участвуют на продукте. Как правило, это изначально инициатива дизайнеров, и лидом проекта выступает самый увлечённый дизайнер. Большинство корпоративных дизайн-систем начинались с этого сетапа.
Техническая часть сильно разнообразна, и полностью зависит от стека целевого проекта.
Дс заточена под нужды конкретного проекта или продукта — её невозможно переиспользовать без костылей. Лиду дизайн-системы техническая часть, как правило, неподконтрольна, а то и вовсе кода нет. Если же разработка присутствует, то техникой могут заниматься самостоятельно разработчики, по своему усмотрению.
Отсюда и неподконтрольность, и неуправляемость: дизайнеру не хватит технического бэкграунда и знаний, чтобы менеджерить разработку. Но есть и исключения, всё зависит от уровня коммуникаций в компании и дружбе конкретных людей.
В таком сетапе дизайн-система — это «приспособа» для дизайнеров.
⊕ плюсы: делаешь для себя, как тебе удобно.
⊖ минусы: неудобно всем остальным.
Сетапы ДС. Приспособа для дизайнеров
В этом цикле постов расскажу о различных сетапах команды и проекта дизайн-системы. Если вы делаете дс, или только предстоит, то вам будет полезно понимать, как обычно это устроено. Все эти этапы мы прошли и мы сами, создавая Дизайн-систему Ростелекома.
Классическая история, когда дизайн-систему делают продуктовые дизайнеры, которые участвуют на продукте. Как правило, это изначально инициатива дизайнеров, и лидом проекта выступает самый увлечённый дизайнер. Большинство корпоративных дизайн-систем начинались с этого сетапа.
Техническая часть сильно разнообразна, и полностью зависит от стека целевого проекта.
Дс заточена под нужды конкретного проекта или продукта — её невозможно переиспользовать без костылей. Лиду дизайн-системы техническая часть, как правило, неподконтрольна, а то и вовсе кода нет. Если же разработка присутствует, то техникой могут заниматься самостоятельно разработчики, по своему усмотрению.
Отсюда и неподконтрольность, и неуправляемость: дизайнеру не хватит технического бэкграунда и знаний, чтобы менеджерить разработку. Но есть и исключения, всё зависит от уровня коммуникаций в компании и дружбе конкретных людей.
В таком сетапе дизайн-система — это «приспособа» для дизайнеров.
⊕ плюсы: делаешь для себя, как тебе удобно.
⊖ минусы: неудобно всем остальным.
👍5🔥4❤1🤷♂1👏1
#технологии
Дизайн-система — технически специфичный проект. В основном, команда разработки реализует компоненты для ui-kit. Да, есть ещё сторибук и его настройка, есть сайт, анонсы, релизы, но это все скорее манкиджоб, чем решение бизнес-задач.
При такой ситуации не сложно оказаться в вакууме и перестать искать новые пути совершенствования себя и продукта. Для того, чтобы информационный кислород поступал в команду, я ввел регулярное мероприятие — Дайджест технологий. К каждому дайджесту один из членов команды разработки готовит тему о свежих технологиях и решениях, которые он изучил и локально у себя попробовал. На встрече разработчик рассказывает о всех плюсах и минусах предложенного подхода и самое важное, он рассказывает о ценности такого решения для нашей Дизайн-системы.
Тем самым команда постоянно поддерживает свой технический кругозор, а продукту это позволяет быть технически актуальным и смотреть на несколько шагов вперёд. Об этом как раз рассказывал ранее Денис Пушкарь в статье про цикл жизни дизайн-систем.
Второе техническое мероприятие в нашей команде — разговоры об архитектуре. Название говорящее, на нем мы прорабатываем новую архитектуру для наших компонентов. Универсальную, доменно-распределенную, понятную. Работаем мы на доске Арти: в совместном обсуждении рисуем абстрактные и конкретные смысловые элементы системы.
Такие мероприятия позволяют придерживаться концепции технического лидерства, о котором мы поговорим в следующих постах.
Дизайн-система — технически специфичный проект. В основном, команда разработки реализует компоненты для ui-kit. Да, есть ещё сторибук и его настройка, есть сайт, анонсы, релизы, но это все скорее манкиджоб, чем решение бизнес-задач.
При такой ситуации не сложно оказаться в вакууме и перестать искать новые пути совершенствования себя и продукта. Для того, чтобы информационный кислород поступал в команду, я ввел регулярное мероприятие — Дайджест технологий. К каждому дайджесту один из членов команды разработки готовит тему о свежих технологиях и решениях, которые он изучил и локально у себя попробовал. На встрече разработчик рассказывает о всех плюсах и минусах предложенного подхода и самое важное, он рассказывает о ценности такого решения для нашей Дизайн-системы.
Тем самым команда постоянно поддерживает свой технический кругозор, а продукту это позволяет быть технически актуальным и смотреть на несколько шагов вперёд. Об этом как раз рассказывал ранее Денис Пушкарь в статье про цикл жизни дизайн-систем.
Второе техническое мероприятие в нашей команде — разговоры об архитектуре. Название говорящее, на нем мы прорабатываем новую архитектуру для наших компонентов. Универсальную, доменно-распределенную, понятную. Работаем мы на доске Арти: в совместном обсуждении рисуем абстрактные и конкретные смысловые элементы системы.
Такие мероприятия позволяют придерживаться концепции технического лидерства, о котором мы поговорим в следующих постах.
👍12🔥5❤1💊1
#про_управление
Сетапы ДС. Внутреняя контрибьюция, она же «партизанская разработка»
Продолжаем делиться опытом о вариантах организации проекта дизайн-системы в компании.
В этом сетапе дизайн-система разрабатывается как смежный инструмент для уже нескольких проектов внутри компании. Лид дизайн-системы по-прежнему дизайнер.
Задача дс здесь понятная — консистентность нескольких проектов компании, включая стандартизацию стека фронтенда.
⊕ плюсы: большое пространство для дизайнеров, сама дизайн-система интереснее, появляется возможность создавать экосистему, общие ux-паттерны, или даже методологию проектирования. В фигме дизайн-система может быть качественной: с продуманной архитектурой, компонентами на вариантсах и автолэйаутах, с гайдлайнами.
⊖ минусы: как правило, выделенной разработки с техлидом нет. Для реализации дс в коде привлекаются разработчики из проектов в рамках добровольной контрибьюции — кто захотел, тот и помог.
К сожалению, разработка дс в партизанском режиме редко взлетает — нет контроля и управляемости, нет ответственного за разработку, соответственно невозможно обещать качество.
Коммьюнити тоже развито слабо, т. к это не массовый опенсорс, а закрытая система на ограниченное количество контрибьюторов (бесплатно вносят улучшения) в рамках одной компании. Это означает ущербно низкие темпы разработки и качества, по сравнению с мировыми опенсорс проектами. У разработчиков перманентно не хватает времени для контрибьюции в дизайн-систему!
Сравните с опенсорс проектами: там добровольная контрибьюция работает в силу массовости проекта. К примеру в ant.design 440к пользователей, из них 2 тысячи контрибьюторов. Это менее половины процента! Сколько у вас в компании разработчиков? Допустим 1000. Сколько из них будут стабильно контрибьютить? 5-10. И это не фуллтайм, в лучшем случае вы можете рассчитывать, что вашей дизайн-системе будут уделять пару часов в неделю.
продолжение в следующем посте
Сетапы ДС. Внутреняя контрибьюция, она же «партизанская разработка»
Продолжаем делиться опытом о вариантах организации проекта дизайн-системы в компании.
В этом сетапе дизайн-система разрабатывается как смежный инструмент для уже нескольких проектов внутри компании. Лид дизайн-системы по-прежнему дизайнер.
Задача дс здесь понятная — консистентность нескольких проектов компании, включая стандартизацию стека фронтенда.
⊕ плюсы: большое пространство для дизайнеров, сама дизайн-система интереснее, появляется возможность создавать экосистему, общие ux-паттерны, или даже методологию проектирования. В фигме дизайн-система может быть качественной: с продуманной архитектурой, компонентами на вариантсах и автолэйаутах, с гайдлайнами.
⊖ минусы: как правило, выделенной разработки с техлидом нет. Для реализации дс в коде привлекаются разработчики из проектов в рамках добровольной контрибьюции — кто захотел, тот и помог.
К сожалению, разработка дс в партизанском режиме редко взлетает — нет контроля и управляемости, нет ответственного за разработку, соответственно невозможно обещать качество.
Коммьюнити тоже развито слабо, т. к это не массовый опенсорс, а закрытая система на ограниченное количество контрибьюторов (бесплатно вносят улучшения) в рамках одной компании. Это означает ущербно низкие темпы разработки и качества, по сравнению с мировыми опенсорс проектами. У разработчиков перманентно не хватает времени для контрибьюции в дизайн-систему!
Сравните с опенсорс проектами: там добровольная контрибьюция работает в силу массовости проекта. К примеру в ant.design 440к пользователей, из них 2 тысячи контрибьюторов. Это менее половины процента! Сколько у вас в компании разработчиков? Допустим 1000. Сколько из них будут стабильно контрибьютить? 5-10. И это не фуллтайм, в лучшем случае вы можете рассчитывать, что вашей дизайн-системе будут уделять пару часов в неделю.
продолжение в следующем посте
👍6❤2🔥2🗿1
Про дизайн-системы
#про_управление Сетапы ДС. Внутреняя контрибьюция, она же «партизанская разработка» Продолжаем делиться опытом о вариантах организации проекта дизайн-системы в компании. В этом сетапе дизайн-система разрабатывается как смежный инструмент для уже нескольких…
продолжение
Вы возразите, а почему так пессимистично? А я отвечу: потому что у проектов есть владельцы, зачастую это не одно лицо. В их интересах, чтобы разработчики в первую очередь уделяли время целевым проектам, а не чему-то «общему». Вы ещё раз возразите и скажете что разработчики всё равно заверстают ui-киты по одному дизайну, а значит это всё можно объединить и переиспользовать. На что я вам скажу: так не работает. Разработчики разные, владельцы проектов разные, требования разные, стайлгайды разные, роадмапы разные. В парадигме заказной разработки или в крупных продуктах между проектами как правило низкий уровень обмена опытом и стандартизации.
Каждый проект — отдельное княжество со своими процессами и бюджетодержателями: нет заинтересованных в обмене. Вы не можете придти к разработчикам из других отделов и дать им поручение: вы не их босс.
Как следствие у вас будет несколько несовместимых юи китов разного уровня качества и недоделки. Сколько проектов, столько и китов, если не больше. Подробнее я рассказывал в статье Дизайн-система не равно ui-kit.
Поэтому я и называю этот сетап партизанским: чем дальше в лес, тем толще разрабы-партизаны. Так что, в таком сетапе систему если и используют, то чаще в качестве донора для форков с дальнейшим допиливанием под себя. У того же ант дизайн 40к форков. Каждый десятый пользователь создал по одному форку!
P. S. Моё любимое — когда разработка только начинается, часть разрабов будет бурно сраться в чатиках про то, какой стек технологий выбрать. Кто-то даже начнёт что-то кодить, но ему непременно скажут, что он сделал говно, и это надо переделывать, «по-нормальному».
Вы возразите, а почему так пессимистично? А я отвечу: потому что у проектов есть владельцы, зачастую это не одно лицо. В их интересах, чтобы разработчики в первую очередь уделяли время целевым проектам, а не чему-то «общему». Вы ещё раз возразите и скажете что разработчики всё равно заверстают ui-киты по одному дизайну, а значит это всё можно объединить и переиспользовать. На что я вам скажу: так не работает. Разработчики разные, владельцы проектов разные, требования разные, стайлгайды разные, роадмапы разные. В парадигме заказной разработки или в крупных продуктах между проектами как правило низкий уровень обмена опытом и стандартизации.
Каждый проект — отдельное княжество со своими процессами и бюджетодержателями: нет заинтересованных в обмене. Вы не можете придти к разработчикам из других отделов и дать им поручение: вы не их босс.
Как следствие у вас будет несколько несовместимых юи китов разного уровня качества и недоделки. Сколько проектов, столько и китов, если не больше. Подробнее я рассказывал в статье Дизайн-система не равно ui-kit.
Поэтому я и называю этот сетап партизанским: чем дальше в лес, тем толще разрабы-партизаны. Так что, в таком сетапе систему если и используют, то чаще в качестве донора для форков с дальнейшим допиливанием под себя. У того же ант дизайн 40к форков. Каждый десятый пользователь создал по одному форку!
P. S. Моё любимое — когда разработка только начинается, часть разрабов будет бурно сраться в чатиках про то, какой стек технологий выбрать. Кто-то даже начнёт что-то кодить, но ему непременно скажут, что он сделал говно, и это надо переделывать, «по-нормальному».
👍4❤2🔥1😢1🤪1
#про_управление
Сетапы ДС. Минимальная выделенная команда
Если в предыдущих сетапах вы показали хорошие результаты, то у вас есть возможность получить бюджет на собственную команду! А если вдобавок вы дружите с финансовым директором, тогда можете расчитывать на бюджет побольше, возможно вам даже хватит на двух джунов-разработчиков! Неплохо же.
Словом, не нищебродский сетап, а выделенная команда! Руководит дизайн-системой по прежнему дизайн-лид, но теперь у него в подчинении целый разработчик, или целых два.
Плюсы: повышенная самооценка дизайн-лида (недолго), можно уже ходить по митапам и с умным видом рассказывать про «слияние» дизайн-систем, единые стандарты, и прочие банальности.
Как это ни парадоксально, но то что у вас появился целый один (или даже два) разработчика не означает прогресс в качестве дизайн-системы.
⊕ плюсы: нет.
⊖ минусы: вы теперь несёте ответственность за качество кода.
При этом неподконтрольность и неуправляемость никуда не делись: дизайн-лиду не хватит технического бэкграунда и знаний чтобы менеджерить разработку.
Эта немощность не сразу очевидна дизайнерам: они в основном слабо разбираются в разработке. Считают, что если к ним присоединяется фронтендер, то половина дела сделана — дальше всё будет круто. А нифига.
Важно помнить, что дизайн-системы — технологически сложный инструмент. Когда разработкой кода занимается один человек, вы зависите, вы не понимаете правильность его решений, вы не можете ничего контролировать. Это риск. Фидбэк от других разрабов тоже не поможет.
Если вы транслируете, что у вас выделенная команда, тем более, если вы заявляете что вы «продукт!», то готовьтесь к потоку хейта со стороны других разрабов. Они будут приходить и говорить, что вы всё делаете неправильно, при этом советы, как правильно, будут один чуднее другого. Ваш целый один разработчик (или даже два) будут тотально под прессингом токсичной среды разработчиков. Но разгребать вам.
Советую долго не находиться в этом сетапе, а сразу переходить в следующий, иначе выгорите.
Сетапы ДС. Минимальная выделенная команда
Если в предыдущих сетапах вы показали хорошие результаты, то у вас есть возможность получить бюджет на собственную команду! А если вдобавок вы дружите с финансовым директором, тогда можете расчитывать на бюджет побольше, возможно вам даже хватит на двух джунов-разработчиков! Неплохо же.
Словом, не нищебродский сетап, а выделенная команда! Руководит дизайн-системой по прежнему дизайн-лид, но теперь у него в подчинении целый разработчик, или целых два.
Плюсы: повышенная самооценка дизайн-лида (недолго), можно уже ходить по митапам и с умным видом рассказывать про «слияние» дизайн-систем, единые стандарты, и прочие банальности.
Как это ни парадоксально, но то что у вас появился целый один (или даже два) разработчика не означает прогресс в качестве дизайн-системы.
⊕ плюсы: нет.
⊖ минусы: вы теперь несёте ответственность за качество кода.
При этом неподконтрольность и неуправляемость никуда не делись: дизайн-лиду не хватит технического бэкграунда и знаний чтобы менеджерить разработку.
Эта немощность не сразу очевидна дизайнерам: они в основном слабо разбираются в разработке. Считают, что если к ним присоединяется фронтендер, то половина дела сделана — дальше всё будет круто. А нифига.
Важно помнить, что дизайн-системы — технологически сложный инструмент. Когда разработкой кода занимается один человек, вы зависите, вы не понимаете правильность его решений, вы не можете ничего контролировать. Это риск. Фидбэк от других разрабов тоже не поможет.
Если вы транслируете, что у вас выделенная команда, тем более, если вы заявляете что вы «продукт!», то готовьтесь к потоку хейта со стороны других разрабов. Они будут приходить и говорить, что вы всё делаете неправильно, при этом советы, как правильно, будут один чуднее другого. Ваш целый один разработчик (или даже два) будут тотально под прессингом токсичной среды разработчиков. Но разгребать вам.
Советую долго не находиться в этом сетапе, а сразу переходить в следующий, иначе выгорите.
👍8❤3🔥2💅1
#дайджест август 2023
① Аддон в Storybook для визуального тестирования
Сравнивает разные версии в стори, выявляет регресс и показывает отличия прямо в Сторибуке. Выполняет проверку в различных браузерах и разрешениях. В навигационной панели Сторибука подсвечивает стори, в которых есть изменения. Аддон пока в статусе альфа, получить ранний доступ можно по запросу.
② Новая Figma-библиотека дизайн-системы Carbon с нативными переменными (открывать под vpn)
В Carbon, дизайн-системе IBM, отказались от стилей и перешли на variables. Это позволило объединить 4 темы в одном файле. И добавить токены для спейсингов, брейкпоинтов, радиусов и прочего. Находим файл в комьюнити Фигмы и изучаем решение.
③ Эволюция дизайн-системы Encore в кросс-платформенность
Spotify рассказали о развитии системы, столкнувшейся с необходимостью поддержки 45 платформ и 2000+ устройств. Новая версия дизайн-системы стремится к «сплоченности» при которой компоненты стали кросс-платформенными. Для этого были созданы единые правила, одинаковые на всех платформах и учитывающие их особенности.
④ Figma дорабатывает переменные
Появилась возможность настраивать свойства нескольких переменных одновременно. Имя переменной теперь редактируется и поддерживает разные платформы. Можно указать в каких свойствах будет доступна переменная цвета. И доступна смена режима в слоях инстанса. Как видим, доработки косметические, типографику и эффекты всё ещё не завезли. Ждём!
⑤ Пишем документацию для дизайн-системы с помощью AI
Zeroheight поделились рекомендациями по работе с Chat GPT. Самое важное в этом деле — точно сформулированные запросы с вашим контекстом. В статье приводится подробный пример промпта для документации. И еще один метод, от тех же авторов. Комбинируя оба подхода, можно быстро получить стартовый материал для дальнейшей проработки.
① Аддон в Storybook для визуального тестирования
Сравнивает разные версии в стори, выявляет регресс и показывает отличия прямо в Сторибуке. Выполняет проверку в различных браузерах и разрешениях. В навигационной панели Сторибука подсвечивает стори, в которых есть изменения. Аддон пока в статусе альфа, получить ранний доступ можно по запросу.
② Новая Figma-библиотека дизайн-системы Carbon с нативными переменными (открывать под vpn)
В Carbon, дизайн-системе IBM, отказались от стилей и перешли на variables. Это позволило объединить 4 темы в одном файле. И добавить токены для спейсингов, брейкпоинтов, радиусов и прочего. Находим файл в комьюнити Фигмы и изучаем решение.
③ Эволюция дизайн-системы Encore в кросс-платформенность
Spotify рассказали о развитии системы, столкнувшейся с необходимостью поддержки 45 платформ и 2000+ устройств. Новая версия дизайн-системы стремится к «сплоченности» при которой компоненты стали кросс-платформенными. Для этого были созданы единые правила, одинаковые на всех платформах и учитывающие их особенности.
④ Figma дорабатывает переменные
Появилась возможность настраивать свойства нескольких переменных одновременно. Имя переменной теперь редактируется и поддерживает разные платформы. Можно указать в каких свойствах будет доступна переменная цвета. И доступна смена режима в слоях инстанса. Как видим, доработки косметические, типографику и эффекты всё ещё не завезли. Ждём!
⑤ Пишем документацию для дизайн-системы с помощью AI
Zeroheight поделились рекомендациями по работе с Chat GPT. Самое важное в этом деле — точно сформулированные запросы с вашим контекстом. В статье приводится подробный пример промпта для документации. И еще один метод, от тех же авторов. Комбинируя оба подхода, можно быстро получить стартовый материал для дальнейшей проработки.
❤6👍4🔥2☃1👏1👌1
#софты
Как стать тимлидом. Часть 1
Кратко
1. Воспитывать в себе качества лидера.
2. Искать условия, где есть вызовы, свобода действий и ответственность.
Подробнее
Начну с главного, что порой утекает из внимания айтишного сообщества в вопросах пипл-менеджмента и роста людей.
Тимлид — это лидер. Лидер команды. Не самый опытный разраб, не лучший дизайнер, не самый умный аналитик, и т.д.
Какие черты личности и характера отражают способность человека стать лидером группы?
Это: интеллект, общая эрудиция, воля и упорство, справедливость, умение воодушевить людей, но и умение признавать свои ошибки. Разумеется лидер хорош в своём профессиональном деле, у него всегда есть чему поучиться! А ещё он рисует картинку в пространстве-времени, к которой движется команда, т.е. ставит цель, да такую что охренеешь (по-хорошему) достигать. Но при этом лидер проявляет заботу и защищает команду.
Выкинь хоть одно из этих качеств и вместо лидера будет клякса.
Пример ①
Представьте что человек профессионал, умеет воодушевить, есть упорство. Но тупой как хлебушек. А цели которые он ставит — слабенькие и приземлённые, т.к интеллекта и общей эрудиции не хватает для визионерства. А то вообще никаких целей, вся команда закрывает отчетности. Вы пойдёте за таким?
Пример ②
Человек и профессионал, и визионер, и с командой по душам поговорит, все его любят, но не особо уважают. Потому что он бесхребетный тряпка, который сдаётся после любой неудачи и начинает ныть. Вы пойдёте за таким?
Пример ③
Умный, талантливый, настоящий визионер, но совершенно не умеет работать с людьми. Ни зарядить энергий, ни воодушевить. Ни цель нормально обозначить. А стиль управления через манипуляции, давление, и бесконечные обесценивания: «вы опять просрали дедлайны!», «можно было и лучше». Никогда не признаёт своих ошибок, но всегда найдёт их у вас. Достиженец и царь токсичного болота. Вы пойдёте за таким?
Вы уже поняли к чему я клоню. Тимлид это про конкретные лидерскик качества, и они все важны.
продолжение в следующем посте
Как стать тимлидом. Часть 1
Кратко
1. Воспитывать в себе качества лидера.
2. Искать условия, где есть вызовы, свобода действий и ответственность.
Подробнее
Начну с главного, что порой утекает из внимания айтишного сообщества в вопросах пипл-менеджмента и роста людей.
Тимлид — это лидер. Лидер команды. Не самый опытный разраб, не лучший дизайнер, не самый умный аналитик, и т.д.
Какие черты личности и характера отражают способность человека стать лидером группы?
Это: интеллект, общая эрудиция, воля и упорство, справедливость, умение воодушевить людей, но и умение признавать свои ошибки. Разумеется лидер хорош в своём профессиональном деле, у него всегда есть чему поучиться! А ещё он рисует картинку в пространстве-времени, к которой движется команда, т.е. ставит цель, да такую что охренеешь (по-хорошему) достигать. Но при этом лидер проявляет заботу и защищает команду.
Выкинь хоть одно из этих качеств и вместо лидера будет клякса.
Пример ①
Представьте что человек профессионал, умеет воодушевить, есть упорство. Но тупой как хлебушек. А цели которые он ставит — слабенькие и приземлённые, т.к интеллекта и общей эрудиции не хватает для визионерства. А то вообще никаких целей, вся команда закрывает отчетности. Вы пойдёте за таким?
Пример ②
Человек и профессионал, и визионер, и с командой по душам поговорит, все его любят, но не особо уважают. Потому что он бесхребетный тряпка, который сдаётся после любой неудачи и начинает ныть. Вы пойдёте за таким?
Пример ③
Умный, талантливый, настоящий визионер, но совершенно не умеет работать с людьми. Ни зарядить энергий, ни воодушевить. Ни цель нормально обозначить. А стиль управления через манипуляции, давление, и бесконечные обесценивания: «вы опять просрали дедлайны!», «можно было и лучше». Никогда не признаёт своих ошибок, но всегда найдёт их у вас. Достиженец и царь токсичного болота. Вы пойдёте за таким?
Вы уже поняли к чему я клоню. Тимлид это про конкретные лидерскик качества, и они все важны.
продолжение в следующем посте
👍18❤1🔥1🍌1🎄1
#дайджест сентябрь 2023
① Редизайн сайта Google Fonts
Обновили навигацию для десктопа и мобилок компонентами из Material 3. Переработали фильтрацию и перенесли её в сайдбар. Цветовая схема теперь тоже из Material 3, для светлого и тёмных режимов. Отличная демонстрация новой дизайн-системы от Google в деле!
② Чек-лист по процессу создания и внедрения дизайн-системы
Кnapsack собрали основные моменты, на которые следует обратить внимание при создании дизайн-системы. И это не про количество компонентов или следование стандартам, а про аудит, видение, стратегию, команду и выстраивание правильных процессов.
③ Агрегатор мероприятий по нашей теме
Энтузиасты дизайн-систем запустили сайт с предстоящими событиями, лекциями, вебинарами по тематике дизайн-систем. На многие бесплатный вход. Для хардкорных олдов есть RSS подписка =)
④ Финалисты Design Systems Awards
Собственный конкурс от Zeroheight, о котором мы недавно рассказывали, объявил финалистов по всем категориям. Стоит ознакомиться с лучшими дизайн-системами и статьями в индустрии (по мнению уважаемого жюри конкурса). Победителей объявят 30 ноября.
⑤ Плагин для автоматической локализации Variables Translator
Если в интерфейсе требуется поддержка нескольких языков, то вы уже оценили силу Figma-переменных. Этот плагин переведёт коллекцию string переменных на другой язык (русский в комплекте!) и добавит новый mode в коллекцию.
⑥ Сборник ресурсов по Figma-переменным
Для тех, кто еще не разобрался с variables. Около 50 ссылок на статьи, видео и файлы-примеры, объясняющие принципы работы и техники использовавния. Не отстаём, догоняем прогресс и переходим на переменные!
① Редизайн сайта Google Fonts
Обновили навигацию для десктопа и мобилок компонентами из Material 3. Переработали фильтрацию и перенесли её в сайдбар. Цветовая схема теперь тоже из Material 3, для светлого и тёмных режимов. Отличная демонстрация новой дизайн-системы от Google в деле!
② Чек-лист по процессу создания и внедрения дизайн-системы
Кnapsack собрали основные моменты, на которые следует обратить внимание при создании дизайн-системы. И это не про количество компонентов или следование стандартам, а про аудит, видение, стратегию, команду и выстраивание правильных процессов.
③ Агрегатор мероприятий по нашей теме
Энтузиасты дизайн-систем запустили сайт с предстоящими событиями, лекциями, вебинарами по тематике дизайн-систем. На многие бесплатный вход. Для хардкорных олдов есть RSS подписка =)
④ Финалисты Design Systems Awards
Собственный конкурс от Zeroheight, о котором мы недавно рассказывали, объявил финалистов по всем категориям. Стоит ознакомиться с лучшими дизайн-системами и статьями в индустрии (по мнению уважаемого жюри конкурса). Победителей объявят 30 ноября.
⑤ Плагин для автоматической локализации Variables Translator
Если в интерфейсе требуется поддержка нескольких языков, то вы уже оценили силу Figma-переменных. Этот плагин переведёт коллекцию string переменных на другой язык (русский в комплекте!) и добавит новый mode в коллекцию.
⑥ Сборник ресурсов по Figma-переменным
Для тех, кто еще не разобрался с variables. Около 50 ссылок на статьи, видео и файлы-примеры, объясняющие принципы работы и техники использовавния. Не отстаём, догоняем прогресс и переходим на переменные!
🔥12👍4❤1🎅1
#софты
Как стать тимлидом. Часть 2
Развивать и воспитывать в себе качества лидера:
— Наличие интеллекта выше чем у хлебушка;
— Насмотренность и эрудированность;
— Воля и упёртость;
— Справедливость и честность: похвалить за результат, поругать за дело, помочь, когда команда на излёте, принести ништяков за работу, признать собственные ошибки;
— Профессионализм: хорошо делать, учиться, приносить новые знания команде;
— Ставить интересные вызовы и цели, благодаря которым команда растёт;
— Защищать команду от внешних потрясений (политика, неадекватные заказчики, отдел командировок и т.д).
Что дальше? Вам нужны условия, в которых ваши качества лидера смогут раскрываться и работать. Я для себя всегда отмечал несколько важных аспектов, без которых вы скорее останетесь ведомым, а не ведущим.
① Первое, оно же как базовая гигиена — вам должно нравиться то что вы делаете. Занимаетесь дизайном, продуктом, или разработкой — без любви к делу вы просто не сможете вести за собой людей, это чувствуется сразу, моментально.
② Второе, внутренняя энергия. Её должно быть несколько больше чем у команды. Энергия это горящие глаза и шило в попе. Это когда вы просыпаетесь и уже знаете что будете сегодня делать, и вам не нужна третья кружка кофе чтобы начать. Свою энергию нужно беречь, и не доводить себя до выгорания.
③ Третье, самое важное. Ответственность не дают, её берут. Ваши возможности ограничивает неповоротливая бюрократия, политические подковерные игры, либо голова упирается в потолок роста на текущем месте? Убирайте эти ограничения, и ищите не возделанную полянку, где вы ударите кулаком по столу и громогласно заявите что теперь вы за это отвечаете.
Пишите в комментах, что раскрыть подробнее.
Как стать тимлидом. Часть 2
Развивать и воспитывать в себе качества лидера:
— Наличие интеллекта выше чем у хлебушка;
— Насмотренность и эрудированность;
— Воля и упёртость;
— Справедливость и честность: похвалить за результат, поругать за дело, помочь, когда команда на излёте, принести ништяков за работу, признать собственные ошибки;
— Профессионализм: хорошо делать, учиться, приносить новые знания команде;
— Ставить интересные вызовы и цели, благодаря которым команда растёт;
— Защищать команду от внешних потрясений (политика, неадекватные заказчики, отдел командировок и т.д).
Что дальше? Вам нужны условия, в которых ваши качества лидера смогут раскрываться и работать. Я для себя всегда отмечал несколько важных аспектов, без которых вы скорее останетесь ведомым, а не ведущим.
① Первое, оно же как базовая гигиена — вам должно нравиться то что вы делаете. Занимаетесь дизайном, продуктом, или разработкой — без любви к делу вы просто не сможете вести за собой людей, это чувствуется сразу, моментально.
② Второе, внутренняя энергия. Её должно быть несколько больше чем у команды. Энергия это горящие глаза и шило в попе. Это когда вы просыпаетесь и уже знаете что будете сегодня делать, и вам не нужна третья кружка кофе чтобы начать. Свою энергию нужно беречь, и не доводить себя до выгорания.
③ Третье, самое важное. Ответственность не дают, её берут. Ваши возможности ограничивает неповоротливая бюрократия, политические подковерные игры, либо голова упирается в потолок роста на текущем месте? Убирайте эти ограничения, и ищите не возделанную полянку, где вы ударите кулаком по столу и громогласно заявите что теперь вы за это отвечаете.
Пишите в комментах, что раскрыть подробнее.
🔥15👍3❤1🤔1🫡1
#дайджест октябрь 2023
① WCAG 2.2 опубликован как рекомендуемая версия
В стандарты по обеспечению доступности добавили 9 новых критериев и 1 удалили (про parsing). Для более подробной информации смотрите официальный список отличий от W3C и подборку лучших статей на Smashing Magazine.
② В Polaris обновили визуальный язык
Дизайн-система от Shopify заслуженно попадает во все подборки топ систем — у них есть чему научиться. В Polaris пересмотрели подход к дизайну и полностью изменили компоненты. В новом дизайн языке приоритет отдается эффективности и интуитивному взаимодействию, ориентированному на повседневные повторяющиеся задачи. Статья о процессе редизайна (нужен впн) от авторов.
③ Josh Clark о скорости развития дизайн-систем
Успешные дизайн-системы развиваются медленнее, чем продукты, которые они поддерживают — и это нормально! Почему так происходит? Качество важнее скорости. Как не стать бутылочным горлышком для продукта? Продукт делает своё решение с оглядкой на стандарты дизайн-системы, которое после может быть адаптировано как часть дизайн-системы.
④ Brad Frost про экосистему дизайн-системы
Простая, но успешная и востребованная система, встречаясь с новыми вызовами, вырастает в большую комплексную структуру. Автор модели атомарного дизайна рассказывает как может выглядеть «взрослая» дизайн-система в большой организации. Многослойная структура и связи между элементами предлагают надежный способ организации системы. Есть куда расти!
⑤ Искусственный интеллект в дизайн-системах
Запись выступления спикеров из Knapsack c конференции Into Design Systems. Дизайн-система может задавать контекст и необходимые ограничения для AI, они как будто созданы друг для друга. AI будет помогать пользователям исследовать и использовать, а разработчикам создавать и менеджерить систему.
① WCAG 2.2 опубликован как рекомендуемая версия
В стандарты по обеспечению доступности добавили 9 новых критериев и 1 удалили (про parsing). Для более подробной информации смотрите официальный список отличий от W3C и подборку лучших статей на Smashing Magazine.
② В Polaris обновили визуальный язык
Дизайн-система от Shopify заслуженно попадает во все подборки топ систем — у них есть чему научиться. В Polaris пересмотрели подход к дизайну и полностью изменили компоненты. В новом дизайн языке приоритет отдается эффективности и интуитивному взаимодействию, ориентированному на повседневные повторяющиеся задачи. Статья о процессе редизайна (нужен впн) от авторов.
③ Josh Clark о скорости развития дизайн-систем
Успешные дизайн-системы развиваются медленнее, чем продукты, которые они поддерживают — и это нормально! Почему так происходит? Качество важнее скорости. Как не стать бутылочным горлышком для продукта? Продукт делает своё решение с оглядкой на стандарты дизайн-системы, которое после может быть адаптировано как часть дизайн-системы.
④ Brad Frost про экосистему дизайн-системы
Простая, но успешная и востребованная система, встречаясь с новыми вызовами, вырастает в большую комплексную структуру. Автор модели атомарного дизайна рассказывает как может выглядеть «взрослая» дизайн-система в большой организации. Многослойная структура и связи между элементами предлагают надежный способ организации системы. Есть куда расти!
⑤ Искусственный интеллект в дизайн-системах
Запись выступления спикеров из Knapsack c конференции Into Design Systems. Дизайн-система может задавать контекст и необходимые ограничения для AI, они как будто созданы друг для друга. AI будет помогать пользователям исследовать и использовать, а разработчикам создавать и менеджерить систему.
👍10🔥4⚡2🤗2
#дайджест декабрь 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
Друзья, наша команда желает вам новых компонентов, проектов, дизайн-систем и успехов в новом году! 🧡
① Мы выпустили дизайн-систему Атомаро для команд и бизнеса
Атомаро — это сервис и конструктор для создания дизайн-систем для любой задачи. 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
Друзья, наша команда желает вам новых компонентов, проектов, дизайн-систем и успехов в новом году! 🧡
🔥20👍8❤7🤩1🏆1😨1