Атомарный подход в организации файлов внутри Figma

В этой статье я поделюсь опытом того как мы с коллегами улучшили и оптимизировали файловую структуру проектов внутри Figma в одной крупнейшей телеком компании Казахстана - Kcell. Расскажу о том как мы настроили версионность и актуальность файлов. Система стала понятна для всех сотрудников которые имеют дело с файлами внутри Figma.

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

Внутри нашего файла, есть Страницы (Pages) это почти как атомы. Если грамотно их организовать, то следующим этапом у нас идёт Cover (Обложка) файла, это можно сравнить с молекулами которые строятся на основе атомов. Когда наш файл внутри и снаружи построен, всё это выливается в какой-то организм, а именно организацию рабочего пространства внутри продуктовой команды, то есть в группу Файлов (Files). Когда вы понимаете что у вас готовы все переходные этапы от атомов до организмов, всё это в совокупности превращается в большой и цельный проект.

Конечно все эти вещи могут жить в каком-то виде по отдельности, но вместе они создают единую и понятную систему, которую достаточно легко масштабировать и содержать в чистоте.

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

Рано или поздно вне зависимости от того какой на данный момент размер компании в которой вы работаете, ждёт рост. Это всегда увеличение количества фичей, продуктов и прочего.

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

Могут быть сложности в разработке, ведь разработчик это тоже человек который очень легко может запутаться в файле и начать верстать фичу с файлов iOS вместо Android (К примеру).

Как правильно разбить проекты в большой компании чтобы в случае неизбежного роста, не было проблем? Начнём с создания папок внутри Teams. Давайте представим что вы работаете в компании - RandomName. Внутри компании есть 6 продуктовых команд, к примеру они называются так:

1. Продуктовая команда - Family
2. Продуктовая команда - Size
3. Продуктовая команда - Style
4. Продуктовая команда - Position
5. Продуктовая команда - Font
6. Продуктовая команда - Color

Отлично, мы определились как назвать нашу Teams, и сколько продуктовых команд всего сейчас в компании (6). Что делаем дальше? Давайте визуализируем то как теперь будут выглядеть наша основная рабочая среда.

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

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

Чтобы эффективно сортировать фичи внутри продуктовых команд, нами была подсмотрена у зарубежных коллег система версионности файлов и актуальности за счёт цветных обложек со специальными пометками.

Давайте на примере продуктовой команды Family рассмотрим как мы расположили фичи внутри.

Чуть более подробно по статусам:

Фиолетовый цвет Cover - фича находится на этапе дизайна;
Синий цвет Cover - фича находится в разработке;
Зелёный цвет Cover - фича разработана (в проде);
Жёлтый цвет Cover - фича спроектирована, находится в столе;
Серый цвет Cover - фича находится в архиве.

Отображая файлы таким образом я как дизайнер и любой другой член моей команды может понять по Cover (Обложке) что это за фича, к какой продуктовой команде она относится, на какой стадии она сейчас находится, и кто из дизайнеров занимался этой фичей.

Основная задача обложки максимально быстро и без лишней нагрузки на мозг дать понять любому кто на неё посмотрит информацию о фиче.

В целом, тут всё ограничено лишь вашей фантазией. Я уверен, что развивать обложку можно бесконечно и это точно не её финальная стадия. Что мы отображаем на нашей обложке?

Сверху отображаем название команды которая работает над этой фичей и её статус (статусы я объяснил чуть выше). Обязательно название фичи. Вся информация должна легко читаться с миниатюры при просмотре файлов внутри фигмы, поэтому не жалейте размеров. Фотография и имя дизайнера для быстрого определения кто из дизайн команды работает над этой фичей. Фотография и имя так же помогают понять к кому можно обращаться если у тебя появились вопросы по фичам другой команды.

Тут на самом деле всё индивидуально, заточено под ваши задачи и конкретно ваш стиль работы в компании. У каждой компании он свой, поэтому просто расскажу как мы организовываем pages.

По каждому из пунктов в шаблоне останавливаться не буду, просто объясню как удобно вести и соблюдать версионность. В pages есть четыре основные вкладочки это Дизайнится / В разработке / Реализовано и Архив

Так вот, это что-то типа заголовков, эти страницы в основном пустые. Вся работа проходит под ними. Предположим что у нас есть Крутая фича 1.0

Она уже есть на бою, поэтому актуальный дизайн находится под страницей Реализовано. Если вдруг возникает потребность в том, чтобы провести редизайн, мы просто создаем новую страницу Крутая фича 1.1 или же Крутая фича 2.0 (Как вам удобнее) под страницей Дизайнится. Потом двигаем её по мере статуса В разработку, в реализовано.

Крутая фича 1.1 заменяет старую Крутую фичу 1.0. Крутая фича 1.0 улетает под страницу Архив, и курит там на случай если будет нужна.

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

Остальные страницы внутри файла вспомогательные, в них мы можем накидывать драфты, цеплять ивенты на нужные нам кнопки, собирать рефы, прототипы, схемы, CJM и многое другое.

По итогу к какой бы вы схеме работы не пришли, самое главное чтобы она была максимально понятна вам и членам вашей команды. Могла масштабироваться в любой момент по мере расширения компании и кол-ва фичей.

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