Организация файлов и слоёв в Figma: система которая работает через год

Откройте Figma-файл, который вы делали год назад. Найдите там финальную версию главного экрана. Засеките время.

Если ушло больше тридцати секунд — у вас нет системы. У вас есть склад. И это нормально: так выглядит 80% файлов, в которые я заходил на ревью, аудитах и при передаче проектов. «Final», «Final-2», «Final-real», «не трогать», «копия от вторника», фреймы без названий, компоненты в трёх местах, страница «trash» которую никто не удаляет потому что страшно.

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

## Почему это вообще важно

Дизайнерская работа на 30-50% состоит не из дизайна, а из поиска: где последняя версия, что согласовано, какие компоненты живые, какие — мёртвые. Этот налог не виден в одном спринте, но он копится.

Что ломается, когда файл не структурирован:

• Разработчик берёт устаревший макет — фича уходит в продакшн с ошибкой
• Новый дизайнер тратит первую неделю на «понять, где что»
• Ты сам боишься рефакторить компонент, потому что не знаешь, кто им пользуется
• Презентация заказчику — это поиск среди 40 фреймов того, который «вот этот, но без хедера»
• Через год файл становится археологическим раскопом, и проще начать заново

Хорошая новость: система, которая выживает год и больше, строится не из десяти плагинов и не из строгого гайдлайна на 80 страниц. Она строится из пяти-шести решений, принятых один раз и применяемых везде.

## Принцип, который определяет всё остальное

Перед любыми правилами именования и структурой страниц — один вопрос: файл для кого?

Файл для себя одного и файл для команды — это разные жанры. В первом можно держать черновики, эксперименты, артефакты мышления. Во втором всё, что не помечено как «WIP», по умолчанию считается источником правды.

На практике это значит две вещи:

• В командном файле должна быть видимая граница между «готово» и «в работе». Не по интуиции, а по странице, фрейму или цвету заголовка.
• Любой человек, открывший файл впервые, должен за минуту понять: что здесь актуально, что черновик, что архив.

Если эта граница не выражена явно — никакая структура слоёв не спасёт. Люди будут копировать черновики в продакшн, потому что они выглядят одинаково.

## Структура страниц: первый слой защиты

Страницы в Figma — это самый недооценённый инструмент организации. Их видно сразу при открытии, они задают навигацию и они почти ничего не стоят (в отличие от компонентов, которые надо поддерживать).

Базовая структура, которая работает на проектах от лендинга до продукта на сотни экранов:

• — Cover — обложка с названием, статусом, ссылками, ответственными
• — Readme — что в файле, как устроено, где что искать
• △ Components / Styles — библиотека, если она живёт в этом же файле
• ✦ Ready for dev — то, что отдано в разработку, заморожено
• ✦ In progress — текущие задачи
• ○ Explorations — поиски, варианты, дискуссии
• ○ Archive — старое, но удалять жалко
• × Trash — то, что точно удалим через месяц

Символы перед названием — не украшение. Это группировка взглядом: одинаковый префикс = одна категория. Когда страниц становится 20, без префиксов список превращается в кашу.

### Анти-паттерны, которые встречаются почти везде

• Страницы «Page 1», «Page 2», «Page 3» — Figma по умолчанию, никто не переименовал
• Десять страниц «iteration-1»…«iteration-10» без указания, что итерировали
• Одна страница «Design» на 400 фреймов
• Страница «old» рядом с «new» — через полгода непонятно, что из них актуально
• Архив внутри активной страницы (фреймы «old_header» рядом с рабочими)

### Вопросы для ревью структуры страниц

• Может ли человек, открывший файл первый раз, найти актуальный экран за минуту?
• Понятно ли без вопросов, что заморожено, а что в работе?
• Есть ли страница, в которую страшно зайти? Почему она существует?
• Если удалить страницу «Archive» — кто-то заметит? Когда?

Если на последний вопрос ответ «никто и никогда» — её и правда можно удалить. Архив, в который не заходят, это не архив, это эмоциональный балласт.

## Именование слоёв: где проходит граница разумного

Самая частая ошибка — попытка переименовать всё. Дизайнер видит «Rectangle 47», ужасается и тратит час на причёсывание дерева слоёв, до которого никто никогда не доберётся.

Правда в том, что слой Rectangle 47 внутри готового компонента Button / Primary / L никому не мешает. Имя имеет значение там, где на него смотрят: на фреймы, на компоненты, на контейнеры автолейаута, на инстансы которые потом ищут поиском.

Где имена обязаны быть осмысленными:

• Фреймы верхнего уровня — это то, что попадает в превью и в навигацию
• Компоненты и их варианты — по ним идёт поиск в библиотеке
• Контейнеры автолейаута, если внутри логика (header, content, footer)
• Любые слои, на которые ссылается prototype или взаимодействие

Где имена можно не трогать:

• Векторы внутри иконок
• Декоративные элементы внутри готового компонента
• Технические группы, которые дизайнер не открывает

### Анти-паттерн: «причёсывание ради причёсывания»

Если ты переименовываешь Group 12 в Group container — ты тратишь время впустую. Имя должно отвечать на вопрос «что это и зачем», а не «как это называется в Figma по умолчанию».

## Компоненты: главная ловушка масштаба

Компонент — это обещание поддержки. Каждый созданный компонент ты обязуешься обновлять, документировать и держать в курсе изменений системы. Поэтому правило простое: не создавай компонент, пока он не понадобился трижды.

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

### Когда компонент действительно нужен

• Элемент повторяется в трёх и более местах с одинаковым поведением
• Изменение элемента должно автоматически расходиться по макетам
• Элемент имеет состояния (hover, disabled, error) или варианты
• Элемент уйдёт в код как переиспользуемый компонент

### Когда компонент не нужен

• Уникальный экран, который существует в одном месте
• Иллюстрация на лендинге
• Маркетинговый блок с конкретным текстом
• Эксперимент, который, скорее всего, не выживет

Если сомневаешься — не делай. Превратить фрейм в компонент через полгода легко. Распутать клубок неиспользуемых компонентов — почти невозможно.

## Рабочий процесс: гигиена, которая держит файл живым

Структура — это не разовая уборка, это режим. Без него любая система разваливается за квартал.

### Раз в неделю (5 минут)

• Перенести готовое из In progress в Ready for dev
• Удалить или заархивировать эксперименты, к которым не возвращался
• Проверить, что у новых фреймов есть осмысленные имена

### Перед хендоффом разработчику

• Фрейм имеет понятное имя и помечен статусом
• Все используемые стили — из библиотеки, а не локальные
• Нет detached instances там, где должен быть компонент
• Прототип ведёт на актуальные экраны, а не на чёрный draft
• В Cover указано, где искать этот макет и кто за него отвечает

### Раз в квартал

• Пройти по компонентам, выкинуть мёртвые
• Проверить, не выросла ли страница Explorations до состояния отдельной вселенной
• Спросить разработчиков: что они открывают чаще всего? Это и есть боевая часть файла

## Диагностика: признаки того, что файл начал гнить

Не нужно ждать катастрофы. Несколько симптомов, которые видны сразу:

• Ты открываешь файл и тратишь больше минуты, чтобы найти нужный экран
• В чате с разработчиком регулярно появляется «а где актуальный?»
• На странице Components есть компоненты, которые ты не помнишь
• В файле живут локальные стили, дублирующие библиотечные
• Фрейм называется final_v2_real_final
• Никто, кроме автора, не может объяснить структуру файла

Любой из этих признаков — повод остановиться и потратить час на ревизию. Не на полный рефакторинг, а на точечную уборку самого больного места.

## Типичные ошибки, которые встречаются почти у всех

• Дизайн прямо в библиотечном файле. Библиотека — это библиотека. Рабочие макеты — отдельно.
• Копирование компонента вместо использования инстанса. Через месяц копия живёт своей жизнью, расхождение копится.
• Отключение автолейаута, чтобы «быстро подвинуть». Привет, ручная перестройка всего фрейма через неделю.
• Стили только для себя. Если цвет не в библиотеке — его не существует для команды.
• Архив, в который складывают всё подряд. Архив без правил — это свалка с красивым названием.

## Вопросы для ревью своего файла

• Если завтра я уйду в отпуск, сможет ли коллега продолжить работу без созвона со мной?
• Какая страница вызывает у меня тревогу, когда я её открываю? Почему?
• Сколько компонентов в библиотеке использовались за последний месяц?
• Что разработчик откроет первым, если ему дать ссылку на файл?

Если на последний вопрос ты не знаешь ответа — это и есть задача на ближайший час. Cover, Readme, понятная навигация. Файл должен сам объяснять, как им пользоваться.

## Продвинутые сценарии: когда система начинает играть на тебя

База — это структура страниц, именование, библиотека. Дальше начинается следующий уровень: файл, который работает в команде, переживает редизайн и не ломается, когда в него заходит AI-агент через MCP.

### Сценарий: редизайн поверх живого продукта

Самая опасная ситуация — когда ты переделываешь то, что уже в проде. Соблазн открыть существующий файл и «поправить прямо здесь» заканчивается одинаково: через неделю никто не понимает, какой экран актуальный.

Рабочая схема:

• Создаёшь отдельный файл Redesign / Checkout v2, не трогаешь боевой
• В Cover пишешь: что переделываем, зачем, дата старта, кто решает
• На страницу Current state копируешь актуальные экраны как референс — frozen, не редактируешь
• Работа идёт на странице Explorations, потом In progress, потом Ready for dev
• Когда дизайн принят — переносишь готовое в боевой файл одним коммитом, старый redesign-файл архивируешь со ссылкой на результат

Главное правило: не держи две версии правды одновременно. В любой момент кто-то один файл — источник, остальные — черновики.

### Сценарий: дизайн-система живёт отдельно

Как только компонентов больше тридцати — библиотека уезжает в отдельный файл, а лучше в отдельный проект. Боевые макеты подключают её как published library.

Чего нельзя делать в библиотечном файле:

• Рисовать конкретные экраны продукта
• Хранить эксперименты и наброски
• Публиковать компонент, который ещё обсуждается

Каждая публикация библиотеки — это релиз. У него должны быть changelog (можно прямо страницей в файле), ответственный и понятная причина. Иначе через полгода у команды паранойя: «обновлять или сломается?»

## AI и MCP: что меняется, когда в файл заходит агент

AI-инструменты и Figma MCP-серверы читают файл так же, как читал бы новый дизайнер — только без интуиции и без созвона с тобой. Если структура держится на «ну я же помню», агент сгенерирует мусор.

### Что агент видит хорошо

• Осмысленные имена фреймов и компонентов
• Auto layout и переменные вместо магических чисел
• Связанные стили и токены, а не локальные значения
• Понятную иерархию слоёв без Group 47 / Frame 12 / Rectangle 3

### Что агент видит плохо или вообще не видит

• Договорённости в голове у дизайнера
• Контекст вроде «эту кнопку мы используем только в B2B»
• Какой экран актуальный, если их пять с похожими именами
• Прототип-связи как смысл, а не как стрелочки

Практический вывод: чем чище структура, тем полезнее AI. Грязный файл превращает агента в генератор уверенных галлюцинаций — он отдаёт код по случайному detached instance, и ты ловишь это уже в PR.

### Чеклист готовности файла к AI/MCP

• Все боевые экраны лежат на одной странице с понятным префиксом
• У страницы Ready for dev нет дублей и устаревших версий
• Используемые компоненты — из библиотеки, без detached
• Цвета, типографика, отступы — переменные, а не сырые значения
• В Cover или Readme прописано, какие страницы агенту читать, а какие игнорировать

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

## Командный контекст: файл как договор

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

### Роли и зоны ответственности

• Owner файла — один человек, отвечает за структуру и гигиену
• Контрибьюторы — работают по принятой системе, не заводят свои страницы без согласования
• Читатели (PM, разработчики, QA) — заходят за конкретным ответом, не должны разбираться в твоей логике

Если у файла нет owner — он становится общим, а значит ничьим. Через квартал там четыре страницы Explorations от разных людей и три параллельные библиотеки.

### Как объяснять структуру команде

Не на созвоне, не в Slack-сообщении, которое потеряется. На странице Readme внутри самого файла:

• Где лежит актуальный дизайн
• Что значит каждый статус (WIP, Review, Ready for dev, Shipped)
• Куда не надо лазить и почему
• К кому идти с вопросами

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

## Как проверять качество: ревью файла, а не только макетов

Дизайн-ревью обычно про пиксели и логику экранов. Но раз в спринт полезно делать ревью самого файла — отдельно от контента.

Вопросы, которые работают:

• Может ли новый человек за 10 минут найти актуальный экран без подсказки?
• Сколько кликов от Cover до самого важного флоу?
• Есть ли страница, на которую никто не заходил последний месяц? Почему она ещё жива?
• Какие компоненты обновлялись за последние две недели и почему?
• Если открыть файл с телефона разработчика — он поймёт, куда смотреть?

Хорошая практика — раз в квартал смотреть файл вместе с разработчиком, который им пользуется. Не дизайн обсуждать, а навигацию. Его «я всегда теряюсь вот здесь» стоит дороже любого внутреннего аудита.

### Анти-паттерны командной работы

• Файл-крепость. Один человек знает структуру, остальные боятся трогать. Уйдёт в отпуск — проект встанет.
• Файл-демократия. Каждый заводит свои страницы и компоненты «как удобно». Через месяц — хаос без хозяина.
• Молчаливый рефакторинг. Owner переименовал половину страниц, никому не сказал. Половина команды в панике ищет вчерашние макеты.
• Readme на словах. «Я же на стендапе рассказывал» — не работает. Через неделю никто не помнит.

## Короткий итог сегмента

Продвинутый уровень — это когда файл понятен не только тебе, но и коллеге, разработчику и AI-агенту с одинаковой лёгкостью. Это достигается не магией, а скучными вещами: один owner, явные статусы, Readme внутри файла, регулярное ревью структуры. Если завтра в твой файл зайдёт новый человек или MCP-агент и сделает осмысленное действие без вопросов — система работает.

## Сводный чеклист: система, которая переживёт год

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

### Структура и навигация

• Cover внятно отвечает на «куда смотреть» за 5 секунд
• Префиксы страниц задают порядок, а не алфавит решает за тебя
• Архивные страницы лежат в архиве, а не «временно» рядом с боевыми
• Между Cover и любым боевым экраном — не больше двух кликов
• Названия фреймов читаются как пункты в Jira, а не как «Frame 248»

### Слои и компоненты

• Группы только там, где они несут смысл, а не от лени
• Auto layout стоит везде, где элемент может растянуться
• Нет detached инстансов, оставшихся после «быстрой правки»
• Иконки и кнопки — из одной библиотеки, а не из трёх исторических
• Все цвета, размеры шрифтов и отступы — переменные

### Статусы и гигиена

• У каждой страницы понятен статус: WIP, Review, Ready for dev, Shipped
• Нет двух версий «финального» экрана без явной пометки, какая боевая
• Старше квартала и не используется — в архив или удалить
• Readme внутри файла обновлялся за последние два месяца

Если по любому из пунктов ответ «ну, почти» — это и есть та зона, где через полгода начнётся боль.

## Анти-паттерны, которые ломают систему медленно

Большие катастрофы заметны сразу. Опасны мелкие привычки, которые копятся месяцами.

• «Я потом причешу». Никогда. Если ты не причесал в тот же день, не причешешь.
• Параллельные истины. Два экрана с одним названием в разных местах, оба выглядят боевыми. Разработчик угадывает.
• Слой Group 47. Один такой — мелочь. Сто таких — файл, в который страшно заходить.
• Компонент ради компонента. Завёл вариант, использовал один раз, забыл. Через полгода в библиотеке двести компонентов, реально живых — двадцать.
• «У меня свой подход». Локальная логика именования, понятная только автору. На команде это налог, который платит каждый новый человек.
• Скрытая зависимость от Figma-плагина. Половина структуры держится на плагине, который завтра перестанет работать или станет платным.
• Файл-музей. Всё сохранено «на память», ничего не удаляется. Через год это уже не рабочий инструмент, а археологический слой.

## Вопросы для ревью — себе и команде

Не на ретро в конце квартала, а в моменте, когда что-то кажется неудобным. Удобный момент — лучшее время для честного ответа.

• Если бы я открыл этот файл впервые, я бы понял, что здесь происходит?
• Какие три страницы мне страшно трогать? Почему?
• Что я делаю в этом файле руками каждую неделю и можно ли это убрать?
• Есть ли экран, который называется одинаково в двух местах?
• Какой компонент я последний раз использовал «как есть», без правок? А какой — переопределил наполовину?
• Если разработчик откроет файл без меня — он соберёт фичу или придёт с вопросами?
• Если AI-агент прочитает файл — он возьмёт боевые экраны или утащит черновики?

Последние два вопроса — лакмус. Файл, в котором система реально работает, отвечает «да» обоим. Файл, который держится на тебе, — ни одному.

## Что делать прямо сейчас

Не переделывать всё. Это плохая идея — большие рефакторинги дизайн-файлов глохнут на третий день.

• Открой текущий рабочий файл и поставь таймер на 20 минут
• Заведи или обнови страницу Readme: где боевое, где мусор, к кому идти
• Переименуй пять самых частых страниц по понятному префиксу
• Удали или архивируй то, что точно не нужно — без жалости
• Поставь в календарь повтор раз в две недели на такие же 20 минут

Система, которая работает через год, — это не та, которую один раз идеально собрали. Это та, в которую кто-то регулярно вкладывает понемногу. Двадцать минут раз в две недели стоят дешевле, чем неделя разгребания перед запуском.