logo

Работа

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

Процесс работы над проектом

Чтобы поддерживать дизайн-документацию в системе, важно соблюдать базовый процесс дизайна продуктов.

1. Получение задачи

При постановке задачи менеджер или автор заполняет в Jira специально подготовленный шаблон. В нем он указывает цели и метрики на которые влияет задача, платформу для которой нужны макеты, краткое описание фичи и желаемые сроки.
После того как менеджер поставил вам задачу, создайте файл в вашем проекте Figma. Имя файла должно состоять из номера задачи в Jira и краткого описания фичи. Например, SP-13456_Settings_main_menu.
  • Используйте латинские символы, чтобы ссылка была понятная и короткая
  • Не придумывайте слишком длинные названия, чтобы файл было легче найти и отсортировать

2. Работа над дизайном

Когда работаете над макетами, придерживайтесь нашей системы наименования страниц в одном файле.
  • Release. Последние версии макетов, которые переданы в разработку. Важно поддерживать эти макеты в актуальном состоянии, поскольку тестировщики проверяют реализацию именно по ним. На странице есть статусы проверки текстов, ссылка на переводы от редакции. Так же на этой странице должны находится макеты разметки интерфейса для скринридера, или ссылка на них.
  • Work in progress. На этой странице ведется основная работа, проводятся эксперименты.
  • Archive/Draft. Архив макетов, которые были нарисованы в процессе работы и которые могут пригодиться в будущем.
Также можно создавать отдельные страницы для прототипов.
Эти советы — только рекомендация. Не забывайте, что один из принципов нашей работы — автономность. Мы понимаем, что правила могут не подходить для всех случаев.
Макеты делаются согласно дизайн–системе вашего продукта. При работе с текстами в макетах подключается редакция. Важно чтобы перед исследование прототипом тексты были финальными.

3. Обновления в мастер-файле

Мы рекомендуем создать отдельный проект для хранения мастер-файлов. Мастер-файл содержит реализованные разработкой страницы или наборы компонентов и должен быть отделен от ваших исследований и набросков.
  • Это упростит доступ к решениям и шаблонам внутри продукта
  • Это поможет синхронизироваться с другими разработанными функциями
  • Коллеги всегда будут знать, где найти актуальную информацию
Это может показаться избыточным и трудоемким, но на самом деле скопировать макеты со страницы Release и добавить их в другой файл — очень просто.
Старайтесь не использовать одинаковые тексты или «рыбу» в своих макетах. Помните, что любой макет могут взять для маркетинговых целей. Идеальный макет рисуют с использованием реальных данных, картинок и текстов.

4. Передать макеты в разработку

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

5. Поддержка разработки

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

Создание локальных компонентов

Мы стремимся к тому, чтобы наши макеты состояли из компонентов на 100%. Если базовый набор компонентов Paradigm не покрывает ваши потребности, создайте локальные компоненты в своих проектах или локальных библиотеках.
Компоненты внутри наших продуктов могут быть трех уровней.
  1. Базовые компоненты дизайн-системы. К ним относятся кнопки, модальные окна, снекбары. Все компоненты базовой библиотеки Paradigm. Разработкой и поддержкой компонентов занимается команда дизайн-системы. Изменения в эти компоненты вносятся по запросу к дизайнерам дизайн-системы или при создании задачи в Github.
  1. Локальные компоненты продукта. Компоненты которы создаются специально для нужд продукта. Например ячейка списка писем или карточки новостей. Эти компоненты поддерживаются и разрабатываются командой продукта, команда дизайн-системы выступает в качестве консультантов. При этом мы рекомендуем чтобы все компоненты были покрыты стандартным набором токенов.
  1. Компоненты в файле. Иногда возникают ситуации, когда ни локальный не базовый компонент не покрывают потребностей макета. Или нужно провести эксперимент в котором нужно создать дополнительный компонент. Мы рекомендуем создавать их на отдельной странице файла Figma. Такие компоненты помогут в будущем вносить изменения в макеты и могут вырасти в локальный компонент.