Comments 3
Очень классный подход! Для больших команд, думаю, это настоящее спасение
Я единственный дизайнер в стартапе (15 человек), поэтому сама продумывала структуру нашей команды в Figma. Перед этим изучала, как организуют работу в крупных компаниях, но в итоге ни один из подходов нам не подошел
Сейчас у нас все разбито по проектам: "Дизайн-макеты", "Флоу", "Презентации" и т.д. Внутри "Дизайн-макетов" каждый Figma-файл соответствует определенному продуктовому этапу (MVP, Pilot и др.), а страницы уже разделены по функциональности. Для нас это оказалось удобнее, чем создавать множество отдельных файлов под каждый фиче-блок: мы пока стартап, видение продукта постоянно меняется, поэтому важно быстро переключаться между разными экранами и сценариями
Главный минус нашего подхода: сложно отслеживать историю изменений. Пробовали использовать версионирование Figma, но тогда мы чуть не потеряли важные макеты. Думаю, когда продукт станет стабильнее и интерфейс устоится, мы уже придем к Storybook и более зрелой организации дизайн-системы
В своих файлах я делаю отдельный проект для дизайн-системы, исследований и прочего (называю Source), там лежит файл компонентов (Components), дизайн-системы (Design system), UI-kit сложных структурных компонентов с объяснениями для разработчиков (Structures) и файл с шаблонами страниц (Templates).
Отдельный проект создаю для макетов конкретного проекта (называю именем проекта). В нём есть файл с текущей работой (Project name ongoing). В этом файле каждый раздел или фича находятся на отдельной странице Feature name (например Video player).
Каждый раз при крупном изменении на странице Feature name я копирую нужные макеты в отдельную секцию Iteration N. И рядом с ней создаю другие секции по необходимости.
После окончания итерации и финализации результатов:
Беру секцию Iteration N и связанные с ней и отправляю на отдельную страницу Feature name iteration N. Все страницы с таким именем отделяю разделителем, чтоб удобнее было.
Из финализированных макетов собираю отдельную секцию и копирую её в другой файл — Project name for devs. В нём, во-первых, не подключены библиотеки, что снимает проблему с обновлением компонентов на старых макетах. Во-вторых, все макеты организованы по секциям, названным по задачам в Jira для разработки. Делаю там секцию с новыми макетами и называю по имени задачи в Jira с этой фичей. Например ST-208 Video player 1.0. Ставлю комменты и аннотации для разработчиков. Помечаю как Ready for Dev. Все, теперь я эти макеты не трогаю никогда.
Теперь если в эту итерацию вносятся какие-то изменения, я делаю в For devs рядом новую секцию с именем [номер задачи] Feature name 1.1, добавляю туда только макеты с изменением, в аннотациях пишу что изменилось по сравнению с Feature name 1.0. Таким образом, разработчики могут посмотреть всю историю изменений макетов наглядно, без лишнего мусора. Все старые итерации в этой странице, которым больше года, убираю в отдельную страницу Archive.
Если файл становится слишком громоздким, все старые итерации убираю в отдельный файл Project name Archive N. Также и с For devs archive N. Храню их в отдельном проекте Archives.
Декомпозиционный подход организации пространства в Фигме