Рассказываю о переезде из Sketch в Figma и поиске понятного способа организации дизайн-файлов.

Немного обо мне

Я Толя Вербицкий, Principal Designer в AliExpress. До этого я работал в ЮMoney (бывшие Яндекс.Деньги).

Помимо основных продуктовых задач, мне всегда было интересно заниматься процессами в UX-команде и добиваться того, чтобы наша работа была понятна всем остальным в компании.

Проблема

Раньше работа над новой задачей начиналась с пустого файла в Figma. Такой подход может сработать при небольших объёмах, но когда у вас 50, 100 или даже 1 000 макетов в одном файле — в них уже слишком сложно ориентироваться.

Я собрал основные проблемы, которые были непонятны тем, кто перешёл к файлу из задачи в Jira:
— О чём задача и какую проблему она решает.
— Как решается эта проблема у конкурентов и почему мы выбрали текущее решение.
— Какой статус файла и как отслеживать его изменения.
— Согласован ли дизайн и текст макета.
— Где найти историю изменений файла.
— Актуален ли ещё макет.

Поясню: в 2019 году ещё не было сообщества Figma Community, и каждая команда, включая мою, искала свой путь решения проблемы. Расскажу, какую цель мы ставили и как её в итоге достигли.

Цель

Основным принципом работы над задачей всегда была открытость. В команде мы активно призываем всех исследовать проблемы и находить решение вместе. UX создаёт не только дизайнер и редактор, а все участники команды — от продакт-менеджера до разработчика. Чтобы работа над задачей была прозрачной и понятной для всех, я начал искать простые способы организации макетов в Figma. Каждый файл должен был отвечать на вопросы:

— О чём задача кратко.
— Где взять связанные ссылки на PRD, задачу в Jira, доску в Miro, UX-исследования и пр.).
— В чём проблемы пользователей и бизнеса.
— Как мы предлагаем их решить.
— Как мы будем проверять решение.

Решение

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

Общая структура файла

Базовая

— Overview. Описание файла, проблемы и решения.
— Design. Актуальная версия макетов одной задачи.
— Local components. Страница для хранения компонентов необходимых для упрощения управления текущим файлом.
— Inspiration & Research. Мудборды и подробные исследования конкурентов.
— Handoff. Описание для разработчиков: как ведут себя ключевые экраны, блоки, взаимодействия, ссылки на компоненты в Storybook или репозитории с реальными компонентами в коде.
— Draft. Первые наброски и идеи. Можно делать копии страниц Draft 2, Draft 3 и т.д.
— Prototype. Страница для прототипов. Названия страницы соответствуют сценарию в прототипе.
— Archive. Неактуальные идеи — вдруг потом пригодятся.
— Settings. Компоненты для оформления страниц и обложка файла.

Изменения для небольших файлов

— Процесс дизайна начинается сразу на странице Design. Описание задачи, проблема, решение и ссылки — всё храним тут.
— Удаляем Overview и всё, что вам не пригодится (Draft, Prototype и пр.).

Изменения для больших файлов

— Overview. Храним ссылки на связанные задачи — как на трекер задач, так и на другие файлы и страницы в Figma.
— Design. Служит источником правды и поддерживается в актуальном состоянии. Если файл долго не обновляется, то в обложке стоит сменить статус на «Устарел».
— Ниже создаются страницы с номерами из трекера задач (например: DESiGN-1504). У каждой страницы есть свой блок с описанием задачи, проблемой, решением и ссылками на задачу и PRD.

Варианты использования файла

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

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

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

Ничего не менять.

Что ещё скрыто внутри

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

Чеклист готовности дизайна. На этот же шаблон страницы перенёс чеклист готовности дизайна от Dropbox.

Компоненты статуса макетов. Чтобы все в команде понимали статус дизайна и текста у каждого макета на странице находится компонент статуса. Когда нужно сменить сразу все статусы, просто выбирайте компонент и *Edit/Select All with the same Instance* / Меняем состояния.

Changelog отдельного макета. По необходимости к макету можно добавить подробную историю изменений. Игорь Ланко написал подробную статью про это.

Лучшие практики. Собрал ссылки на видео о том, как передавать макеты в разработку и документировать исследования:
— Передача в разработку — Александр Дьяков
— How to handoff your designs to Engineering | femke.design
— Working with Developers | Jesse Showalter
— How to create a UX Research Report | femke.design
— Level up your design documentation with a Design Deck | femke.design
— How to Mood Board for Web Design | Jesse Showalter


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

Отличия этого файла внутри компании

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

В завершении

Вскоре после релиза Figma Community, Dropbox добавил свой шаблон проекта, из которого я почерпнул многое про подход к структуре. Spotify тоже поделился своим подходом к процессу дизайна — изучите как будет время.

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


—
Подписывайтесь на мой канал в Телеграм, чтобы узнавать о новых заметках и постах.