Привет. На прямой линии команда Дизайн-системы Ростелекома. В этом канале мы будем делиться своими опытом и знаниями в таком деле, как создание дизайн-систем.
Нам интересно писать на темы:
① Менеджмент дизайн-системы;
② Управление командой;
③ Дизайн, проектирование, Figma;
④ Технологии: фронтенд, react, языковые модели;
⑤ Дайджест новостей;
⑥ Краткие выжимки и переводы статей, исследований;
⑦ Интервью с интересными специалистами;
⑧ Инструменты.
Чего не будет: перепостов и рекламы.
Поехали!
Нам интересно писать на темы:
① Менеджмент дизайн-системы;
② Управление командой;
③ Дизайн, проектирование, Figma;
④ Технологии: фронтенд, react, языковые модели;
⑤ Дайджест новостей;
⑥ Краткие выжимки и переводы статей, исследований;
⑦ Интервью с интересными специалистами;
⑧ Инструменты.
Чего не будет: перепостов и рекламы.
Поехали!
🔥15❤1👾1
#кратко
В вашей компании нет дизайн-системы и нужно убедить руководство в необходимости её внедрения? Статья Jules Mahe из Zeroheight поможет продемонстрировать ценность и преимущества дизайн-системы. Автор приводит результаты исследований, опубликованные несколькими командами цифровых продуктов.
① Один из лучших аргументов в пользу дизайн-системы — объяснение как изменится эффективность команд. Разработчики смогут экономить около 35% времени на технические затраты. Снизится стоимость дизайна на 27%. Быстрее производите — больше поставляете.
② В следующей группе преимуществ повышение качества. Дизайн-система обеспечивает консистентность, что, по исследованию Forbes, в итоге повышает доход (Revenue). Техническое качество уменьшает кодовую базу и снижает расходы на обслуживание.
③ Человеческий фактор. Лучшая коммуникация между членами команд на 50% снижает потери времени на этапе передачи дизайна в разработку. Дизайн-системы могут иметь косвенное положительное влияние на привлечение и удержание талантов в компании. А так же, ускоряют онбординг новых сотрудников.
④ Как следствие, накапливается экономический эффект. Очевидно повышение ROI за счет избавления от повторяющихся задач. Если рассматривать создание дизайн-системы как инвестиции, то выгоды которые вы получите от неё, того стоят.
В вашей компании нет дизайн-системы и нужно убедить руководство в необходимости её внедрения? Статья Jules Mahe из Zeroheight поможет продемонстрировать ценность и преимущества дизайн-системы. Автор приводит результаты исследований, опубликованные несколькими командами цифровых продуктов.
① Один из лучших аргументов в пользу дизайн-системы — объяснение как изменится эффективность команд. Разработчики смогут экономить около 35% времени на технические затраты. Снизится стоимость дизайна на 27%. Быстрее производите — больше поставляете.
② В следующей группе преимуществ повышение качества. Дизайн-система обеспечивает консистентность, что, по исследованию Forbes, в итоге повышает доход (Revenue). Техническое качество уменьшает кодовую базу и снижает расходы на обслуживание.
③ Человеческий фактор. Лучшая коммуникация между членами команд на 50% снижает потери времени на этапе передачи дизайна в разработку. Дизайн-системы могут иметь косвенное положительное влияние на привлечение и удержание талантов в компании. А так же, ускоряют онбординг новых сотрудников.
④ Как следствие, накапливается экономический эффект. Очевидно повышение ROI за счет избавления от повторяющихся задач. Если рассматривать создание дизайн-системы как инвестиции, то выгоды которые вы получите от неё, того стоят.
👍8❤4🔥1😎1
#про_управление
Индустрия набирает ход в сторону сближения и автоматизации разработки и дизайна. Самый главный инструмент для UI-UX дизайнеров — Figma, уже представляет из себя что-то среднее между граф. редактором и CSS. Механика вариантов и автолэйаута пришла напрямую из фронтенда, а вся правая панель фигмы это, по сути, урезанный css в виде юзер-френдли интерфейса. А после недавнего обновления с dev-режимом, фигма уже может генерировать код из макета.
Low-code проекты, такие как Framer — ещё один яркий представитель мощного инструментария для дизайна и разработки одновременно. Начинался проект как софтина для создания анимированных прототипов. Сейчас же это комбайн в котором можно создавать рабочие сайты, с кодом, дизайном как в фигме, анимацией, и прочим.
Сравните с тем что было 15 лет назад: дизайнеры рисовали сайты в программе для ретуширования фото.
Автоматизация для разработчиков продвинулась ещё дальше. GitHub Copilot, OpenAI Codex, Starcoder. Все движки дописывают работающий (!) код в режиме «скажи что надо, я напишу код». Copilot вообще встроен в репозиторий.
Дизайн-системы вполне очевидно идут в эту же тенденцию. Как технология, дс прошли свой пик хайпа пару лет назад и долину разочарования, и выходят на плато размеренного развития.
Так что очень скоро можно ожидать, что дизайн-системы превратятся из дорогой игрушки для корпораций во вполне ежедневный продвинутый молоток для дизайнеров и разработчиков. Ну а там уже и нейронки подъедут.
Индустрия набирает ход в сторону сближения и автоматизации разработки и дизайна. Самый главный инструмент для UI-UX дизайнеров — Figma, уже представляет из себя что-то среднее между граф. редактором и CSS. Механика вариантов и автолэйаута пришла напрямую из фронтенда, а вся правая панель фигмы это, по сути, урезанный css в виде юзер-френдли интерфейса. А после недавнего обновления с dev-режимом, фигма уже может генерировать код из макета.
Low-code проекты, такие как Framer — ещё один яркий представитель мощного инструментария для дизайна и разработки одновременно. Начинался проект как софтина для создания анимированных прототипов. Сейчас же это комбайн в котором можно создавать рабочие сайты, с кодом, дизайном как в фигме, анимацией, и прочим.
Сравните с тем что было 15 лет назад: дизайнеры рисовали сайты в программе для ретуширования фото.
Автоматизация для разработчиков продвинулась ещё дальше. GitHub Copilot, OpenAI Codex, Starcoder. Все движки дописывают работающий (!) код в режиме «скажи что надо, я напишу код». Copilot вообще встроен в репозиторий.
Дизайн-системы вполне очевидно идут в эту же тенденцию. Как технология, дс прошли свой пик хайпа пару лет назад и долину разочарования, и выходят на плато размеренного развития.
Так что очень скоро можно ожидать, что дизайн-системы превратятся из дорогой игрушки для корпораций во вполне ежедневный продвинутый молоток для дизайнеров и разработчиков. Ну а там уже и нейронки подъедут.
👍7🔥3🙏1🙊1
#про_управление
Из Википедии: «продукт — товар или услуга, которую можно предложить для рынка, и которая будет удовлетворять потребности потребителей».
Дизайн-система не что иное как цифровой товар, инструмент, и он должен удовлетворять потребностям конечных пользователей — end-users, т.е. разработчикам и дизайнерам. А также ЛПР, бизнесу, и закрывать их kpi. Иначе бизнес не будет платить за дизайн-систему. А дизайн-система — дорогая игрушка, в среднем разработка и внедрение для компании стоит 50-100 млн ₽ в год.
В Ростелекоме мы за три года существования Дизайн-системы испробовали несколько сетапов позиционирования проекта. А также несколько раз пересобирали команду под эти сетапы. Сейчас мы остановились на пятом по счёту, и я абсолютно точно убеждён, что дизайн-система кроме как в продуктовой парадигме существовать не может.
Дизайн-система может жить и развиваться только имея рынок, продуктовую команду, знание сегментов, и решение задач пользователей. О том, какие сетапы мы прошли, расскажем в следующих постах.
Из Википедии: «продукт — товар или услуга, которую можно предложить для рынка, и которая будет удовлетворять потребности потребителей».
Дизайн-система не что иное как цифровой товар, инструмент, и он должен удовлетворять потребностям конечных пользователей — end-users, т.е. разработчикам и дизайнерам. А также ЛПР, бизнесу, и закрывать их kpi. Иначе бизнес не будет платить за дизайн-систему. А дизайн-система — дорогая игрушка, в среднем разработка и внедрение для компании стоит 50-100 млн ₽ в год.
В Ростелекоме мы за три года существования Дизайн-системы испробовали несколько сетапов позиционирования проекта. А также несколько раз пересобирали команду под эти сетапы. Сейчас мы остановились на пятом по счёту, и я абсолютно точно убеждён, что дизайн-система кроме как в продуктовой парадигме существовать не может.
Дизайн-система может жить и развиваться только имея рынок, продуктовую команду, знание сегментов, и решение задач пользователей. О том, какие сетапы мы прошли, расскажем в следующих постах.
👍7❤6🔥2😘1
#дайджест июнь 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 (для открытия нужен впн)
Ммм, опять токены… Горячая тема! Инструмент для упрощения менеджмента токенов предлагает сосредоточиться на внешнем виде, а приложение позаботится об утомительных аспектах таксономии. Вот тут можно почитать о возможностях. Интерфейс генератора сбивает с ног =)
① Большое обновление 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 (для открытия нужен впн)
Ммм, опять токены… Горячая тема! Инструмент для упрощения менеджмента токенов предлагает сосредоточиться на внешнем виде, а приложение позаботится об утомительных аспектах таксономии. Вот тут можно почитать о возможностях. Интерфейс генератора сбивает с ног =)
👍8🔥5❤2🦄1
#технологии
Часть 1
Любой компонент дизайн-системы состоит из набора параметров/пропсов — props (properties). Если их нет, то это скорей всего локальный ui-kit, заточенный под 1-2 проекта. Подробнее мы рассказывали в нашей статье о разнице дизайн-системы и ui-kit. Пропсы — своего рода рычаги, с помощью которых компонент управляется, регулируется, кастомизируется. Иногда это портал вовнутрь компонента, например рендер-функции или колбэк-функции, возвращающие изменения значений.
При проектировании нового компонента и последующем его развитии необходимо четко определить критерии, которые говорили бы о том, нужна ли нам новая функциональность и соответственно новый пропс.
Для Дизайн-системы Ростелекома мы вывели следующие критерии:
① Массовость. Востребованность функциональности должна быть у большинства разработчиков. Понимаем это с помощью интервью наших пользователей, изучению других дизайн-систем, на основе собственного опыта. К примеру, графики и диаграммы. На предыдущем проекте мне нужны были графики и я очень хотел, чтобы они были в нашей Дизайн-системе. Когда я начал работать внутри команды дс, то понял, что сделать +- универсальные графики сложно и смысла в этом нет. Тем более, они нужны единицам. Проще воспользоваться старым-добрым хайчартом.
② Невозможность реализовать функциональность на стороне пользователя. Большинство запросов на доработки от пользователей можно закрыть, предоставив пример реализации без изменения компонента. Для пользователей это является элементом обучения по использованию дс, а для нас возможность расширить и детализировать документацию.
Примеры и качественная документация — сильно сокращают количество возникающих вопросов/запросов от разработчиков. Эта тема достойна того, чтобы раскрыть её отдельно.
Есть ещё 2 критерия, которые мы для себя определили. О них я расскажу в следующем посте.
Часть 1
Любой компонент дизайн-системы состоит из набора параметров/пропсов — props (properties). Если их нет, то это скорей всего локальный ui-kit, заточенный под 1-2 проекта. Подробнее мы рассказывали в нашей статье о разнице дизайн-системы и ui-kit. Пропсы — своего рода рычаги, с помощью которых компонент управляется, регулируется, кастомизируется. Иногда это портал вовнутрь компонента, например рендер-функции или колбэк-функции, возвращающие изменения значений.
При проектировании нового компонента и последующем его развитии необходимо четко определить критерии, которые говорили бы о том, нужна ли нам новая функциональность и соответственно новый пропс.
Для Дизайн-системы Ростелекома мы вывели следующие критерии:
① Массовость. Востребованность функциональности должна быть у большинства разработчиков. Понимаем это с помощью интервью наших пользователей, изучению других дизайн-систем, на основе собственного опыта. К примеру, графики и диаграммы. На предыдущем проекте мне нужны были графики и я очень хотел, чтобы они были в нашей Дизайн-системе. Когда я начал работать внутри команды дс, то понял, что сделать +- универсальные графики сложно и смысла в этом нет. Тем более, они нужны единицам. Проще воспользоваться старым-добрым хайчартом.
② Невозможность реализовать функциональность на стороне пользователя. Большинство запросов на доработки от пользователей можно закрыть, предоставив пример реализации без изменения компонента. Для пользователей это является элементом обучения по использованию дс, а для нас возможность расширить и детализировать документацию.
Примеры и качественная документация — сильно сокращают количество возникающих вопросов/запросов от разработчиков. Эта тема достойна того, чтобы раскрыть её отдельно.
Есть ещё 2 критерия, которые мы для себя определили. О них я расскажу в следующем посте.
👍11❤10🔥3🙉1
#статья
У нас вышел лонгрид на хабре про цикл жизни дизайн-систем.
Из статьи вы узнаете:
① Про универсальные принципы систем и закон Эшби;
② Циклы перерождений;
③ Майлстоуны и линейное развитие;
④ Как смотреть в будущее.
Оставляйте комменты, ставьте лайки, нам важно ваше мнение, чтобы улучшать контент =)
У нас вышел лонгрид на хабре про цикл жизни дизайн-систем.
Из статьи вы узнаете:
① Про универсальные принципы систем и закон Эшби;
② Циклы перерождений;
③ Майлстоуны и линейное развитие;
④ Как смотреть в будущее.
Оставляйте комменты, ставьте лайки, нам важно ваше мнение, чтобы улучшать контент =)
👍10🔥5❤3💘1
#технологии
Часть 2
Продолжаем рассказывать о критериях, по которым мы определяем, нужно ли выводить новую функциональность в пропс. Часть 1 тут
③ Универсальный пропс > монофункциональный пропс. Яркий пример — валидация. Зачастую нас просят добавить валидацию, например на корректность почты. Доработка хорошая, но зачем ограничиваться почтой, если можно добавить пропс validationRules и дать возможность разработчику самому определять правила валидации. Тут нужен и важен баланс, иначе можно прийти к одному объектному пропсу, в который нужно будет прокидывать конфигурацию для всего компонента.
④ Непродуктовая фича. Важно найти оптимальное сочетание между навешиванием рычагов на вообще всё и абсолютно неповоротливым, заточенным под один продукт, компонентом. Яркий пример перегиба в одну сторону — компонент InputDate. В какой-то момент мы поняли, что у нас около 40 пропсов. Добавить легко, удалить сложно. Удаление пропса или изменение его нейминга неизбежно ведет к breaking changes и обновлению мажорной версии. Должны быть очень веские аргументы, для того, чтобы мы добавили к нему новый параметр в текущей версии. Клепать часто мажоры нельзя, поэтому мы подготавливаем список семантических и функциональных изменений к новой версии и начинаем внедряем декоратор deprecated.
Похожим образом, мы выводим критерии и ищем свой дзен, проектируя дизайн-токены. Подробнее о токенах в нашем канале расскажет Денис Плешаков — продакт Дизайн-системы Ростелекома.
Часть 2
Продолжаем рассказывать о критериях, по которым мы определяем, нужно ли выводить новую функциональность в пропс. Часть 1 тут
③ Универсальный пропс > монофункциональный пропс. Яркий пример — валидация. Зачастую нас просят добавить валидацию, например на корректность почты. Доработка хорошая, но зачем ограничиваться почтой, если можно добавить пропс validationRules и дать возможность разработчику самому определять правила валидации. Тут нужен и важен баланс, иначе можно прийти к одному объектному пропсу, в который нужно будет прокидывать конфигурацию для всего компонента.
④ Непродуктовая фича. Важно найти оптимальное сочетание между навешиванием рычагов на вообще всё и абсолютно неповоротливым, заточенным под один продукт, компонентом. Яркий пример перегиба в одну сторону — компонент InputDate. В какой-то момент мы поняли, что у нас около 40 пропсов. Добавить легко, удалить сложно. Удаление пропса или изменение его нейминга неизбежно ведет к breaking changes и обновлению мажорной версии. Должны быть очень веские аргументы, для того, чтобы мы добавили к нему новый параметр в текущей версии. Клепать часто мажоры нельзя, поэтому мы подготавливаем список семантических и функциональных изменений к новой версии и начинаем внедряем декоратор deprecated.
Похожим образом, мы выводим критерии и ищем свой дзен, проектируя дизайн-токены. Подробнее о токенах в нашем канале расскажет Денис Плешаков — продакт Дизайн-системы Ростелекома.
👍11❤5🔥3🆒1
#инструменты
Часть 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 с помощью собственного плагина. Статья про генератор от автора (для просмотра нужен впн).
Продолжение в следующей части.
Часть 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 с помощью собственного плагина. Статья про генератор от автора (для просмотра нужен впн).
Продолжение в следующей части.
👍11❤5🔥5😡1
#инструменты
Часть 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.
Часть 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.
👍9❤3🔥2🤷♀1
#дайджест июль 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