Как я организую файлы в Figma для клиентских проектов
Почему хаос в Figma — это не проблема инструмента
Каждый дизайнер хоть раз открывал файл в Figma спустя полгода после старта проекта и чувствовал лёгкий укол тревоги. Сорок три страницы с названиями «Page 1» — «Page 43». Фреймы под названием «Copy of Copy of Homepage v2 FINAL». Библиотека компонентов, разбросанная по трём разным файлам, ни один из которых не совпадает с тем, что реально работает на сайте. Мне доставались такие файлы от других дизайнеров, и, если честно, пару таких я создал сам в начале карьеры.
Первый импульс — обвинить Figma. Но дело не в ней. Figma позволяет организовать проект безупречно, а может позволить превратить его в свалку — инструмент нейтрален. Настоящая проблема в том, что большинство из нас сначала проектирует, а организует потом, относясь к структуре файла как к уборке, а не как к части результата работы. Клиенты платят не только за пиксели — они платят за систему, в которой они сами и их следующий сотрудник смогут разобраться без вас в комнате.
За десятки клиентских проектов — от двухнедельных спринтов по лендингам до годовых продуктовых ретейнеров — я выработал систему файлов, которую теперь использую без исключений. Она не экзотична. Она заимствует больше из инженерных конвенций (предсказуемый нейминг, чёткое владение, разделение ответственности), чем из шаблонов самой Figma. Дальше — реальная система, а не её причёсанная версия, включая моменты, которые я усвоил через несколько болезненных проектов.
Отдача от этого не абстрактна. На недавнем 10-недельном редизайне продукта я засёк время, за которое нашёл конкретный флоу, о котором клиент спросил на созвоне спустя три недели после сдачи. Одиннадцать секунд — потому что я точно знал, в каком файле, на какой странице и с каким названием фрейма искать. На более старом проекте, где я работал по старым привычкам, аналогичный поиск однажды занял двадцать минут и закончился извинениями на звонке. Эта разница, помноженная на год клиентской работы, легко даёт сорок-пятьдесят сэкономленных часов — часов, которые либо возвращаются в оплачиваемое время, либо просто перестают съедать вечера.
Архитектура файлов: один проект, несколько файлов, одна карта
Первое решение — в скольких файлах Figma должен жить проект. Начинающие дизайнеры обычно запихивают всё в один файл, потому что так кажется проще. Я делаю наоборот: сознательно разбиваю проект на несколько файлов, потому что один разросшийся файл начинает медленно грузиться, в нём сложно искать, а делиться им рискованно — вы даёте клиенту доступ на редактирование к своим неаккуратным черновым фреймам только для того, чтобы показать один утверждённый экран.
Мой стандартный набор файлов для проекта среднего размера выглядит так:
- [Клиент] — Foundations: дизайн-токены, цветовые и текстовые стили, определения сетки и основная библиотека компонентов. Этот файл почти не меняется после того, как устоялся, и служит единым источником правды, из которого остальные файлы тянут опубликованные библиотеки.
- [Клиент] — Explorations: черновой файл. Концепции, отброшенные направления, быстрые макеты для внутреннего обсуждения. Здесь я «думаю вслух». Этот файл никогда не показывается клиенту, если только он специально не попросил увидеть процесс.
- [Клиент] — Working File: текущий, активный дизайн — то, что реально разрабатывается или проверяется в этом спринте. Именно в этом файле клиент живёт изо дня в день.
- [Клиент] — Archive: прошлые версии, отменённые флоу, всё, что заменено, но стоит хранить для справки или по юридическим причинам (например: «это была страница цен, утверждённая в марте, до пивота»).
- [Клиент] — Handoff / Dev Specs: для проектов с отдельной командой разработки — файл (или отдельный набор страниц), созданный специально для инженеров, без шума черновиков, с редлайнами, аннотациями по отступам и чётко обозначенными состояниями.
Не каждому проекту нужны все пять. Двухнедельному лендингу не нужен файл Archive в первый же день — я создам его, как только появится вторая версия, которую стоит сохранить. Но нейминг для всех пяти я определяю заранее, даже для тех, что ещё не создал, чтобы никогда не пришлось переименовывать задним числом. Именно на переименовании тихо утекают часы: переименовать файл — значит обновить все места, где вы на него ссылались: закреплённые сообщения в Slack, тикеты в таск-трекере, заметки в README, закладки клиента.
Самая важная привычка во всей этой системе — карта проекта. В общем проекте клиента в Figma (контейнер уровня папки, а не файл) самый первый файл — закреплённый наверху, названный с ведущим восклицательным знаком, чтобы всегда сортироваться первым, например «!START HERE» — это лёгкий индекс. Это одна страница в FigJam или Figma с коротким списком: для чего нужен каждый файл, ссылка на него и одна строка со статусом. На создание уходит пять минут, а экономит она время каждому будущему человеку — новому стейкхолдеру со стороны клиента, разработчику, подключившемуся позже, мне самому спустя двухмесячный перерыв — избавляя от необходимости гадать.
Структура файлов, понятная только вам, — это не система. Это дворец памяти, а дворцы памяти не переживают смену сотрудников.
Я усвоил это на собственном опыте, когда руководитель маркетинга клиента ушёл в середине проекта. У её преемницы не было никакого контекста, и без моего индексного файла ей пришлось бы просить меня вживую, на звонке, провести её через шесть недель дизайн-решений. Вместо этого я отправил одну ссылку. Она разобралась сама за двадцать минут.
Структура страниц, которая масштабируется от старта до передачи
Внутри Working File — файла с самым высоким ежедневным трафиком — порядок страниц важен не меньше, чем их нейминг. Страницы в Figma читаются в сайдбаре сверху вниз, и я отношусь к этому порядку как к повествованию: человек должен суметь пролистать список страниц и понять форму проекта, не открывая ни одного фрейма.
Мой порядок страниц по умолчанию, который я адаптирую, но почти никогда не отбрасываю:
- 00 — Cover & Overview: название проекта, логотип клиента, дата последнего обновления и короткий список изменений. Звучит излишне — пока клиент в сороковой раз не спросит «это последняя версия?». Теперь ответ всегда один: «смотри титульную страницу».
- 01 — Flows & IA: пользовательские флоу, карты сайта, диаграммы информационной архитектуры. Хранятся отдельно от визуального дизайна, чтобы стейкхолдеров, рассматривающих структуру, не отвлекали решения по цвету и типографике, и наоборот.
- 02 — Wireframes: низкодетализированная проработка макета. Я сохраняю их даже после готовности финального дизайна, потому что клиенты иногда хотят пересмотреть структурное решение, и наличие логики (а не только финального отполированного экрана) ускоряет этот разговор.
- 03 — [Название фичи/раздела]: по одной странице на крупный раздел или флоу — «Онбординг», «Оформление заказа», «Настройки», «Маркетинговый сайт — Главная». Здесь живёт основная часть визуального дизайна, разбитая по функции, а не по страницам сайта в буквальном смысле. Одна страница «Checkout» может содержать корзину, доставку, оплату и подтверждение — потому что именно так разработчик или тестировщик будут думать о тестировании этого как единого целого.
- 04 — Components (local): компоненты, созданные специально для этого проекта и не относящиеся к общей библиотеке Foundations — разовые иллюстрации, баннеры под конкретную кампанию, слишком специфичные вещи, чтобы их обобщать.
- 05 — Annotations / Redlines: когда приближается передача разработчикам, я дублирую нужные экраны на эту страницу и напрямую добавляю заметки по отступам, состояниям и взаимодействиям, вместо того чтобы захламлять основные фреймы дизайна выносками.
- 99 — Archive / Parking Lot: не отдельный файл Archive, а страница внутри рабочего файла для всего, что я не готов полностью списать — старый вариант шапки, который могу реанимировать, вариант, который клиент попросил «просто оставить на всякий случай». Номер 99 держит эту страницу внизу списка, вне поля зрения, но при этом не удаляет потенциально полезную работу.
Двузначные числовые префиксы — не украшение. Сортировка страниц в Figma по умолчанию — это ручной порядок перетаскивания, что нормально, пока кто-то со стороны клиента случайно не переставит страницы (это случается чаще, чем кажется, особенно при наличии доступа на редактирование) или новый член команды не добавит страницу, не понимая конвенцию. Числовые префиксы делают задуманный порядок очевидным и легко восстановимым. Когда я добавляю новую страницу-фичу в середине проекта, я вставляю её с подходящим номером — 03a, 03b — вместо того чтобы перенумеровывать всё подряд, что избавляет от каскада переименований.
Одно правило, от которого я не отступаю: никакая дизайн-работа не ведётся прямо на титульной странице, и никакая мета-информация с титульной страницы не проникает на страницы с фичами. Хранение мета-информации отдельно от контента дизайна означает, что я могу передать титульную страницу проджект-менеджеру для обновления списка изменений, не боясь, что он что-то сломает во фрейме.
Соглашения о названиях, от которых я никогда не отступаю
Нейминг — наименее эффектная часть этой системы и та, что экономит больше всего времени, потому что именно названия ищут, на них ссылаются в комментариях и их произносят вслух на звонках. Моё правило: название должно быть понятно человеку без какого-либо контекста, спустя полгода, ищущему что-то в спешке.
Для фреймов я использую единый шаблон: [Раздел] – [Экран] – [Состояние/Разрешение]. Так, вместо «Homepage» фрейм называется «Marketing – Homepage – Desktop», а его мобильный собрат — «Marketing – Homepage – Mobile». Вместо «Login copy 2» — «Auth – Login – Error State». Пока печатаешь такое название, оно кажется избыточным, но окупается в момент, когда пользуешься поиском Figma (Cmd/Ctrl+F) — поиск по слову «Error» мгновенно выводит все состояния ошибок во всём файле, что бесценно, когда клиент просит «сделать все сообщения об ошибках более дружелюбными» и нужно разом проверить каждый такой случай.
Несколько привычек по неймингу, родившихся из конкретных болезненных моментов:
- Никаких номеров версий в названиях фреймов, никогда. «Homepage v3» превращается в ложь в тот момент, когда кто-то отредактировал фрейм, забыв переименовать. История версий — это встроенная в Figma система версионирования (подробнее ниже) или список изменений на титульной странице, но никогда не сам объект.
- Никаких имён клиентов как определений внутри фреймов. Я избегаю названий вроде «версия Сары» или «выбор CEO». Вместо этого предпочтения фиксируются в комментариях, закреплённых на фрейме, или в списке изменений. Название должно описывать, что это за объект, а не его политическую историю.
- Единообразный регистр. По умолчанию я использую Title Case для названий фреймов и страниц, sentence case — для слоёв внутри компонентов. Мелочь, но несогласованный регистр странным образом сбивает с толку при быстром просмотре длинного списка слоёв, а ещё это простой признак поспешной, неотполированной передачи.
- Удалять, а не переименовывать в «old». Если фрейм действительно устарел, он отправляется на страницу 99 — Archive или в отдельный файл Archive, а не переименовывается в «Homepage OLD DO NOT USE» и не остаётся рядом с актуальной версией. Каждый «OLD DO NOT USE», который я когда-либо видел, рано или поздно кто-то в спешке использовал по ошибке.
Нейминг слоёв внутри компонентов заслуживает отдельного упоминания, потому что именно здесь выигрывается или проигрывается качество передачи разработчикам. Компонент кнопки со слоями «Rectangle 14», «Frame 27» и «Group 3» ничего не скажет разработчику при инспекции. Я переименовываю каждый слой внутри компонента перед тем, как отправить его в общую библиотеку — «Container», «Label», «Icon — Leading», «Icon — Trailing» — потому что эти названия напрямую отображаются в панели инспекции для разработчиков и в сгенерированных фрагментах кода. На это уходит около девяноста секунд на компонент. Я делаю это один раз для каждого переиспользуемого компонента — и больше никогда не объясняю структуру слоёв на словах.
Компоненты, переменные и как держать библиотеку честной
Файл Foundations — та часть системы, которая больше всего определяет, останется ли проект организованным по мере роста, потому что компоненты и переменные — это слой, от которого зависит всё остальное. Если библиотека расходится с реальностью — если компонент «Button/Primary» в библиотеке не совпадает с тем, что реально используется в рабочем файле — каждый следующий экран незаметно наследует это несоответствие, и никто этого не замечает, пока QA или разработчик не заметят десяток чуть-чуть разных отступов у кнопок.
Мои правила для файла Foundations:
- Переменные раньше стилей, стили раньше жёстко заданных значений. Цвет, отступы и типографика определяются как переменные Figma в первую очередь, везде, где это позволяет план проекта, потому что переменные могут нести смысловое значение (background/surface/primary), а не буквальное (gray-100), что заметно упрощает работу с темизацией и тёмной темой в дальнейшем. Я откатываюсь к обычным стилям цвета/текста только на небольших проектах, где переменные были бы избыточны, и никогда не оставляю жёстко заданное hex-значение в компоненте, который планируется использовать дважды и более.
- Названия компонентов зеркалят структуру папок через слэши. «Button/Primary/Default», «Button/Primary/Hover», «Button/Secondary/Default» — синтаксис со слэшем автоматически превращается в вложенную папку в панели ассетов Figma, а значит библиотека остаётся удобной для навигации, даже когда компонентов становится пятьдесят или сто. Я определяю эту таксономию в начале проекта и фиксирую её на титульной странице Foundations, потому что переименовывать компоненты после того, как они уже размещены сотни раз по рабочему файлу — это по-настоящему мучительная и чреватая ошибками задача.
- Один компонент, все состояния, через варианты. Я никогда не допускаю существования «версии при наведении» как отдельной, несвязанной копии, скопированной из состояния по умолчанию. Каждый интерактивный компонент строится как единый набор компонентов с вариантами по состоянию (default/hover/active/disabled) и, где уместно, по размеру. Это значит, что одно обновление в источнике правды — скажем, клиент решает изменить все скругления углов с 4px на 8px — распространяется всюду мгновенно, вместо того чтобы искать каждое вручную продублированное hover-состояние.
- Раздел «Do Not Ship». Иногда я создаю компонент исключительно для внутреннего исследования — placeholder-иконку, черновой макет карточки, который ещё тестирую. Вместо того чтобы удалить его (вдруг понадобится снова) или оставить болтаться в файле (где кто-то может случайно использовать его в продакшн-дизайне), я держу чётко обозначенный раздел внизу страницы Foundations для экспериментальных компонентов, визуально выделенный красным фоном фрейма, чтобы это было очевидно даже при беглом просмотре.
Я также отношусь к истории версий файла Foundations как к мини-журналу изменений дизайн-системы. Каждый раз, когда я публикую обновление библиотеки, Figma просит указать описание — и я действительно заполняю это поле по существу («Добавлены варианты тёмной темы для всех полей форм», а не «обновление»), потому что спустя полгода этот журнал — самый быстрый способ ответить на вопрос клиента «погодите, а когда мы это поменяли?» без археологических раскопок.
На проектах, достаточно длинных, чтобы это требовалось, я провожу быстрый ежемесячный аудит: открываю рабочий файл, выбираю все экземпляры данного компонента и проверяю на отсоединённые инстансы — копии, отвязавшиеся от библиотеки, обычно потому что кому-то (часто мне самому, в спешке) понадобилась разовая правка, и он забыл вернуть её в нормальный вариант. Отсоединённые инстансы — это тихий долг: сегодня они выглядят нормально, а через год превращаются в пять чуть-чуть разных кнопок. Функция Figma «Select all with same component» делает этот аудит быстрым — обычно меньше пятнадцати минут даже для зрелого файла — и эти пятнадцать минут предотвращают часы разгребания несогласованностей в будущем.
Контроль версий и цикл клиентского ревью
Клиенты редко задумываются об организации файлов напрямую, но они точно чувствуют её отсутствие — обычно как путаницу насчёт того, какая версия актуальна, или тревогу, действительно ли их фидбэк учли. Мой рабочий процесс ревью существует в основном для того, чтобы снять эту тревогу, и структура файлов напрямую этому способствует.
Я никогда не отправляю голую ссылку на редактирование и не надеюсь на лучшее. Мой стандартный процесс ревью:
- Именованные снапшоты версий на каждой вехе. Перед отправкой файла на ревью я использую «Save to version history» в Figma с чётким, датированным названием: «Client Review — Checkout Flow — 14 марта». Это значит, что даже если клиент (или коллега) продолжит редактировать файл после этого, я всегда смогу вернуться к тому состоянию, которое им показали — а это критично, когда кто-то говорит «погодите, я одобрял не это».
- Комментарии закрываются, а не удаляются. Я использую цепочки комментариев Figma как реальную запись принятых решений — «Клиент попросил скруглённые углы здесь, одобрено 14 марта» — и после решения помечаю их как resolved, а не удаляю. Закрытая ветка комментариев — это бумажный след; удалённая — это факт, который никто не сможет восстановить, если позже возникнет спор о том, что было согласовано.
- Отдельная страница «Feedback» для асинхронных раундов. Для клиентов, которые предпочитают письменные заметки живым комментариям, я добавляю временную страницу — «Round 2 Feedback» — со скриншотами нужных фреймов и местом под их заметки, а после того как фидбэк учтён и задокументирован в списке изменений, удаляю эту страницу. Это не даёт их сырым заметкам постоянно захламлять страницы дизайна, при этом сохраняя бумажный след в истории версий.
- Доступ только на просмотр по умолчанию, доступ на редактирование — по запросу. Почти каждый клиент получает доступ на просмотр/комментирование, а не на редактирование Working File. Дело не в контроле ради контроля — а в том, что случайные правки от благонамеренных стейкхолдеров (перетащили фрейм, удалили слой в процессе изучения) — один из самых распространённых источников именно того хаоса, который вся эта система призвана предотвратить. Если клиенту конкретно нужно что-то перемещать — например, команда контента строит собственную структуру текстов прямо в Figma — я даю доступ на редактирование к продублированной, чётко обозначенной копии, а не к исходному файлу.
Это может показаться избыточной формальностью для, в конце концов, дизайн-файла, но реальные накладные расходы невелики — примерно пять дополнительных минут на раунд ревью — а взамен исчезает целая категория трений: разговор «мне казалось, мы договорились об X», который съедает звонок, а иногда и отношения с клиентом. Прозрачная история версий — это не просто организационная гигиена, это тихая форма выстраивания доверия. Клиенты успокаиваются, когда видят чёрным по белому, что именно и когда они утвердили.
Чек-лист передачи, который экономит на последующих письмах
Финальный этап любого проекта — передача команде разработки, штатному дизайнеру или просто будущему себе клиента — это момент, когда неорганизованность обходится дороже всего, потому что именно здесь кому-то другому впервые придётся действовать самостоятельно внутри вашего файла. Я прохожу один и тот же чек-лист каждый раз, слегка адаптируя его в зависимости от того, кто получатель: разработчик, штатный дизайнер или сам клиент.
Чек-лист:
- Титульная страница актуальна. Статус проекта, дата последнего обновления и список изменений отражают реальность, а не снапшот трёхнедельной давности.
- Каждая страница следует числовой конвенции. Никаких случайных пронумерованных страниц, никаких оставшихся черновых страниц, затесавшихся в основную последовательность.
- Все фреймы названы по конвенции, нигде нет «Copy of». Перед каждой передачей я ищу в панели структуры буквальную строку «Copy» — это ловит удивительно много случайно оставшихся дубликатов.
- Библиотека компонентов опубликована и не содержит отсоединённых инстансов. Я прогоняю описанный выше аудит финально перед сдачей, а не только раз в месяц.
- Для всего неочевидного есть редлайны. Отступы, не следующие стандартной сетке, кастомный тайминг взаимодействий, крайние состояния (пустые состояния, ошибки, загрузка) — всё это получает явную аннотацию на странице Redlines, а не остаётся на угадывание разработчику.
- Права доступа соответствуют аудитории. Разработчики получают доступ как минимум к Foundations и файлу Handoff; я дополнительно проверяю, что ни у кого не осталось «зависшего» доступа на редактирование с более ранней фазы проекта, который уже не нужен.
- Короткий письменный обзор сопровождает ссылку на файл. Даже при отличной внутренней организации короткое сообщение из пяти строк — «Начните с титульной страницы для контекста, флоу на странице 01, редизайн оформления заказа — приоритетный раздел этого спринта, все компоненты опубликованы из Foundations» — избавляет получателя от необходимости в первый же день реконструировать вашу систему с нуля.
Последний пункт легко пропустить, потому что сам файл кажется вам самоочевидным — вы же его построили. Но столь же самоочевидным он редко кажется тому, кто сталкивается с ним впервые. Пять минут на написание этого ориентировочного сообщения стабильно предотвращают ручеёк вопросов «слушай, а где найти...», которые иначе капают всю первую неделю после передачи.
Я храню шаблон этого чек-листа как сохранённый сниппет и действительно прохожу по нему построчно на каждом проекте, независимо от размера и от того, насколько я уверен, что всё уже в порядке — потому что именно уверенность и есть тот момент, когда любят прятаться пропущенные дубликаты «Copy of Copy of». На проект среднего размера уходит пятнадцать-двадцать минут. Пропуск этого шага не раз в начале карьеры стоил мне целого дня извинительных писем вместо этого.
Ничего в этой системе не сложно, и ничего не требует плагинов Figma, платных инструментов или развёрнутой документации. Это набор мелких, скучных, последовательно применяемых конвенций — разделение на пять файлов, нумерованный порядок страниц, шаблон нейминга, привычка версионирования, чек-лист перед передачей — которые за жизнь проекта складываются в нечто, реально ведущее себя как система, а не как археологические раскопки. Ценность не в том, что какое-то отдельное правило гениально. А в том, что применение всех их, каждый раз, без исключений, означает, что мне больше не приходится заново изучать собственный проект так, как приходилось раньше — и никому, кому я его передаю, тоже.
