Привет. На прямой линии команда Дизайн-системы Ростелекома. В этом канале мы будем делиться своими опытом и знаниями в таком деле, как создание дизайн-систем.
Нам интересно писать на темы:
① Менеджмент дизайн-системы;
② Управление командой;
③ Дизайн, проектирование, 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