Как устроены дизайн-файлы и Figma в Дринкит

Сегодня поговорим о том, к чему у дизайнеров никогда не угасает интерес: как организовать работу команды в Figma. За 10 лет в дизайне я насмотрелась на множество подходов к организации и передаче макетов, и хочу поделиться тем, как это устроено сейчас у нас в Дринките. Лайк шер репост, спасибо :*

Я пришла в Дринкит в июне 2025 года и в самые первые дни провела опрос среди разработчиков о том, как они оценивают текущее качество Design Delivery. В целом, немного погуляв по Figma того времени, для меня не стали сюрпризом их ответы: макеты передавались, что я называю, ситуативно-понятийным способом (или, как говорят у нас в России, на вайбе).

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

Этот коллапс передачи знаний приводит к постоянным издержкам на ровном месте: новый дизайнер приходит в команду и заново создаёт свою Главную, свой Профиль, а в фигме уже лежит с двадцать таких же главных, но от предыдущих дизайнеров.

А как должно быть? И возможен ли вообще порядок в фигме? На мой взгляд, возможен, и целевой результат выглядит примерно так:

Давайте теперь последовательно пройдёмся по тому, как у нас всё устроено.

У нас общая Figma с Dodo, и мы сидим на тарифе Organization. Раньше у Дринкита был один проект на всё подряд: приложение, киоск, бренд, маркетинг, дс — в общем в тесноте, да не в обиде. Естественно, первым делом я разнесла это по трём отдельным папкам: Drinkit Product, Drinkit DUI и Drinkit Marketing. Дизайн-систему я вытащила в отдельный проект и впоследствии опубликовала на всю компанию, чтобы её можно было спокойно подключить в любой другой команде.

В папке продуктового дизайна 9 разделов:

Я сознательно отделила эмодзиками только самые важные вкладки: так легче ориентироваться, чем когда они есть у каждой.

Также у нас есть и другие разделы, например, в Public мы храним файлы с внешним доступом, а в Prototypes — прототипы для Pathway.

Дальше я сделала нам обложки. Это красивый, удобный компонент, который сразу преобразил вайб нашей святая святых. На обложках только самое важное: короткое название файла и превью.

Также я специально сделала так, чтобы обложки концептных файлов сильно выделялись: все в команде могут быстро понять, что это work in progress, и отсюда не стоит брать ничего в разработку. Каждый раздел или фича в приложении имеют свой файл, мы всегда следим за тем, чтобы они случайно не съезжались в одно пространство.

4. Структура файла

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

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

У нас очень простой принцип: если дизайн в проде, он лежит в основных макетах во вкладке дизайн, если нет — в бранче.

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

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

5. Главное: как оформлен сам файл

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

Буду рассказывать на примере Drinkit Lab:

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

Дальше мы берём каждый отдельный экран и раскладываем его на следующие секции:

Это выглядит вот так:

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

В случае с Drinkit Lab у меня получилось 4 секции с описанием каждого экрана по одному и тому же формату:

Это очень простой формат, но его может быть очень сложно осознать. Главное — при оформлении перестать мыслить сценариями, а начать мыслить экранами как компонентами.

В общем-то, это всё 😳

Через год я снова провела опрос среди разработчиков, и почти половина команды назвала главным улучшением в дизайне качество оформления макетов (приятноооооо)

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

Пишите свои вопросы мне напрямую в телегу, про дизайн и Дринкит рассказываю в своём LinkedIn, а поставить лайк можно на Dribbble и Behance.

Всем порядка 🫂