Управление командой дизайнеров в том числе включает в себя организацию хранения и передачи макетов. Я расскажу о схеме к которой пришел сам и потом успешно масштабировал на разные команды. Не претендую на открытие Америки — я встречал дизайнеров которые со временем приходили к похожим решениям.
Вы должны стремиться к тому чтобы результат вашей работы был понятен без обращения к сторонним источникам информации. То что очевидно вам, совершенно не очевидно для других.
Важно найти баланс. Мало макетов — неинформативно и может вызвать вопросы, много макетов — затрудняет просмотр. Супер подробные пояснения и схемы — тратить время на поддержку этого в будущем, их отсутствие — риск того что дизайн будет неверно интерпретирован.
Погнали
Проект хранится в 4 файлах
- Master — прямое отражением продакшена.
- Work — для текущих задач.
- Archive.
- Внешняя дизайн система/ui-kit.
Дизайн система
Структура дизайн систем в figma это тема для отдельной статьи. Всё что хочу сказать в рамках данной статьи — дизайн система не должна храниться в файле проекта, а подключаться как внешняя библиотека.
Master
Внутри файл разделен на пэйджы по крупным контекстам.
Внутри контекстов все макеты объединяются в логические блоки и при необходимости показываются переходы между ними.
Так же макеты сопровождаются блок схемой переходов. Я использую для этого библиотеку Omnichart (можно найти в комьюнити).
К некоторым страницам пишутся пояснения по логике работы элементов.
Work
Внутри файла пэйджы разделены по задачам. Один пэйдж = одна задача.
Название «Номер задачи + краткое описание».
Например: DSGNDT905 - Продление.
Необходимо регулярно проверять появились ли задачи в проде или нет и делать соответсвующие пометки:
DSGNDT905 - Продление — нет статуса по задаче
✅ DSGNDT905 - Продление — задача уже на проде
❌ DSGNDT905 - Продление — задача по какой-либо причине не будет выпущена в прод (после тестирования или отказались в ходе работы.)
Каждый год создается новый Work файл.
Archive
После того как какая-то задача из Work файла выходит в прод, этот макет должен быть перенесен в Master, а неактуальный из мастера - в архив. Макеты из Work никогда не удаляются.
Структура архива — свободная.
Такая структура позволяет
— быстро посмотреть текущий дизайн любой страницы продукта,
— увидеть доступные переходы и кейсы,
— найти любую старую задачу,
— хранить историю изменения проекта и всегда откатится назад,
— не будет путаницы с версиями страниц в макетах,
— в работу никогда не будет взят неправильный макет.
Данная система отлично подходит для старта и в будущем при необходимости легко тюнится конкретно под вашу команду и процессы.
Самое худшее что вы можете сделать — это устроить диктатуру (или как это называют тех.лиды — технофашизм). Позвольте вашей команде влиять на процессы.
Удачной работы!
Спасибо, полезно
А как насчет перегруженности файла когда все макеты находятся в одном файле? Фигма файл не резиновая же)
Тут нужно понимать принципы работы фигмы. Чем больше объектов нужно отрисовать на странице тем само собой медленнее загрузка, но ... я не делаю что прям все на одной странице а разбиваю на пэйджи. И тут дело скорее даже в оптимизации своих процессов и простоты поиска тех или иных макетов, потому что особой разницы на самом деле нет 50 или 150 макетов так как самым тяжелым являются картинки. Если фигме нужно будет загрузить разом много картинок, учитывая что у неё нет никакой оптимизации а кто-то аватарку 100 на 100 вставляет просто кропнув и сжав фуллсайз снимок с проф камеры... такой файл будет грузится очень долго.
Так что я какие-то проблемы наблюдаю чисто при наличии тяжелой графики - в остальных случаях файл прекрасно себя чувствует.
«Дизайн система не должна храниться в файле проекта и подключаться как внешняя библиотека.» Если эти два варианта не подходят, какой тогда вариант верный по мнению автора?
там скорее "не должна храниться, а должна подключаться" - не лучшим образом построил фразу