В команде из нескольких дизайнеров Figma быстро превращается не только в макеты, но и в систему правил: кто публикует компоненты, кто меняет стили, кому можно редактировать библиотеку, а кому достаточно просмотра. На практике именно права доступа и неаккуратные обновления часто создают больше проблем, чем сама работа над интерфейсом.
Как вы организуете библиотеки в совместном проекте? Выносите компоненты, цвета и типографику в отдельный файл или держите всё рядом с макетами продукта? Интересно сравнить подходы: одни предпочитают одну общую библиотеку с ответственными владельцами, другие делают отдельные библиотеки для продукта, экспериментов и конкретных команд.
Отдельный вопрос — процесс изменений. Нужно ли закрывать публикацию библиотек для большинства участников, использовать копии для экспериментов и заранее предупреждать о переименовании компонентов? Поделитесь рабочей схемой: какие роли и права реально помогают не сломать систему, как вы проверяете обновления и что делаете с устаревшими компонентами, которые всё ещё используются в макетах.
Как вы организуете библиотеки в совместном проекте? Выносите компоненты, цвета и типографику в отдельный файл или держите всё рядом с макетами продукта? Интересно сравнить подходы: одни предпочитают одну общую библиотеку с ответственными владельцами, другие делают отдельные библиотеки для продукта, экспериментов и конкретных команд.
Отдельный вопрос — процесс изменений. Нужно ли закрывать публикацию библиотек для большинства участников, использовать копии для экспериментов и заранее предупреждать о переименовании компонентов? Поделитесь рабочей схемой: какие роли и права реально помогают не сломать систему, как вы проверяете обновления и что делаете с устаревшими компонентами, которые всё ещё используются в макетах.
Комментарии 7
Обсуждение темы — по порядку