{"id":13664,"url":"\/distributions\/13664\/click?bit=1&hash=f8e0aba14203df6cd2281fdd3f7f0563673921d2f335ea835255d6e0e69e1151","title":"\u041a\u0430\u043a \u0441\u0432\u044f\u0437\u0430\u043d\u0430 \u0431\u0435\u0441\u043f\u043b\u0430\u0442\u043d\u0430\u044f \u043a\u0430\u0440\u0442\u0430 Tinkoff Black \u0438 \u043a\u0430\u0440\u0442\u0438\u043d\u044b \u0422\u0440\u0435\u0442\u044c\u044f\u043a\u043e\u0432\u043a\u0438","buttonText":"\u041a\u0430\u043a?","imageUuid":"86efc643-7e85-501c-b3c6-e2620ee53cdf","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