#технологии

Часть 1

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

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

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

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

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

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

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

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

#технологии

Часть 1

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

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

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

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

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

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

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

hottg.com/pro_designsystem/17

943 viewsedited  Jul 31, 2023 at 12:29