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

Вот если это соблюдать, расхождений не будет. Но это ж заранее нужно подумать, вложиться в проектирование, соблюдать...

Боль вечная. Это происходит, потому что многие дизайнеры до сих пор проектируют «картинки», а не интерфейсный код. Если фреймворк в Figma собран без оглядки на логику браузерного рендеринга, разработчик физически не сможет перенести его 1-в-1 без костылей.

Как мы у себя решили эту проблему и победили «похоже»:

1. Синхронизация по Flexbox/Grid. Все макеты и автолейауты строятся строго по правилам CSS. Если у разработчика в коде контейнер ведет себя определенным образом, то и в Figma он с самого начала настроен точно так же. Никаких «висящих» элементов.

2. Сквозная 3-tier архитектура токенов. Перешли на жесткие Variables и Modes. Названия токенов в Figma полностью замаплены на переменные в кодовой базе. Кнопка не может стать «серой из старой библиотеки», потому что разработчик берет тот же семантический токен (например, control-disabled-bg), что зашит в макете.

3. Дизайн-ревью внутри DevTools. Самый рабочий фильтр. Перед релизом я иду не в инспект-панель Figma, а открываю DevTools на тестовом стенде и лично проверяю layout-параметры, паддинги и токены в коде.

Когда дизайнер начинает говорить с фронтендерами на языке CSS и DOM-дерева, слово «похоже» исчезает, а хендофф занимает минуты вместо недель взаимных правок.