{"id":13587,"url":"\/distributions\/13587\/click?bit=1&hash=a51d1243f4f81fc79ee7c1ba1cd611adea3e20c1cd7283c3a3ca6c54bb325b5c","title":"\u0412\u0430\u0448 \u0441\u0435\u043e\u0448\u043d\u0438\u043a \u0442\u043e\u0447\u043d\u043e \u043d\u0435 \u0436\u0443\u043b\u0438\u043a? ","buttonText":"\u041f\u0440\u043e\u0432\u0435\u0440\u0438\u0442\u044c","imageUuid":"3c239ea7-2144-53e3-94b9-de4e9e0cd5ff","isPaidAndBannersEnabled":false}
Дизайн
Bitepix

Product Design Architecture — Как хранить макеты проектов

Управление командой дизайнеров в том числе включает в себя организацию хранения и передачи макетов. Я расскажу о схеме к которой пришел сам и потом успешно масштабировал на разные команды. Не претендую на открытие Америки — я встречал дизайнеров которые со временем приходили к похожим решениям.

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

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

Погнали

Проект хранится в 4 файлах

  • Master — прямое отражением продакшена.
  • Work — для текущих задач.
  • Archive.
  • Внешняя дизайн система/ui-kit.

Дизайн система

Структура дизайн систем в figma это тема для отдельной статьи. Всё что хочу сказать в рамках данной статьи — дизайн система не должна храниться в файле проекта, а подключаться как внешняя библиотека.

Master

Внутри файл разделен на пэйджы по крупным контекстам.

Внутри контекстов все макеты объединяются в логические блоки и при необходимости показываются переходы между ними.

Так же макеты сопровождаются блок схемой переходов. Я использую для этого библиотеку Omnichart (можно найти в комьюнити).

К некоторым страницам пишутся пояснения по логике работы элементов.

Work

Внутри файла пэйджы разделены по задачам. Один пэйдж = одна задача.
Название «Номер задачи + краткое описание».
Например: DSGNDT905 - Продление.

Необходимо регулярно проверять появились ли задачи в проде или нет и делать соответсвующие пометки:
DSGNDT905 - Продление — нет статуса по задаче
✅ DSGNDT905 - Продление — задача уже на проде
❌ DSGNDT905 - Продление — задача по какой-либо причине не будет выпущена в прод (после тестирования или отказались в ходе работы.)

Каждый год создается новый Work файл.

Archive

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

Структура архива — свободная.

Такая структура позволяет

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

Данная система отлично подходит для старта и в будущем при необходимости легко тюнится конкретно под вашу команду и процессы.

Самое худшее что вы можете сделать — это устроить диктатуру (или как это называют тех.лиды — технофашизм). Позвольте вашей команде влиять на процессы.

Удачной работы!

0
3 комментария
Алексей

Спасибо, полезно

Ответить
Развернуть ветку
Валерия Воробчукова

«Дизайн система не должна храниться в файле проекта и подключаться как внешняя библиотека.» Если эти два варианта не подходят, какой тогда вариант верный по мнению автора?

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

там скорее "не должна храниться, а должна подключаться" - не лучшим образом построил фразу

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