{"id":13755,"url":"\/distributions\/13755\/click?bit=1&hash=4a49bc9ad259aa8d20fdf5f5cb6cf844e7de4bb2ba8ca3a458efcedefcf5ada8","title":"\u041d\u043e\u0432\u044b\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0434\u043b\u044f \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0439, \u0441\u043e\u0437\u0434\u0430\u044e\u0449\u0438\u0445 \u043a\u043e\u043d\u0442\u0435\u043d\u0442 \u043d\u0430 vc.ru","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}

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

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

Атомарный подход

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

Дьявол кроется в деталях

Ludwig Mies van der Rohe

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

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

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

TEAMS (Продуктовые команды)

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

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

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

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

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

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

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

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

FILES (Среда продуктовой команды)

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

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

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

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

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

COVER (Обложка)

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

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

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

PAGES (Страницы)

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

Вот так выглядит шаблон для создания проекта в Figma с нуля.

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

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

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

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

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

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

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

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

0
5 комментариев
Vladislav Kurguzov
Автор

Если у вас есть свои какие-то лайфхаки в упрощении работы над большими проектами внутри Figma, буду рад любой обратной связи)

Ответить
Развернуть ветку
Bitepix

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

Ответить
Развернуть ветку
Vladislav Kurguzov
Автор

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

Ответить
Развернуть ветку
Bitepix

А разве не должен быть подход когда все понятно без объяснения и траты времени на обучение того как красить обложки и куда что вписывать? Учитывая что обучать нужно не только дизайнеров но и всевозможный менеджмент и разработку. И тем более дизайнеры все должны работать одинаково а не кто как хочет чтобы не было проблем с тем что кто-то не понимаем чужие файлы.

Ответить
Развернуть ветку
Vladislav Kurguzov
Автор

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

Ответить
Развернуть ветку
Читать все 5 комментариев
null