В первую очередь:

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

Думайте о разработке со старта. Не выделяйте подготовку макета к разработке в отдельный этап дизайна. С самого начала держите в голове, что дизайн не только для клиента, но и для разработчика. Посоветуйтесь с ним насчёт сложных участков и сценариев, изучите возможности и ограничения технологий, примерьте прототипы на реальные устройства, чтобы заранее увидеть проблемы с логикой и взаимодействием.

Будьте последовательны. Во всём макете придерживайтесь системы: отступов, кеглей, цветов. Избегайте «почти, но не совсем» одинаковых элементов, будьте разумны с исключениями из правил. Не загоняйте себя в рамки только ради удобства разработчика, но помните: чем проще и системнее дизайн, тем проще и надёжнее код.

Уберите всё лишнее. Спрячьте от разработчика черновики, неутверждёнку, эксперименты и прочий левак. Всё это создаёт серьёзный риск, что разработчик наделает лишнего.

Не забудьте про состояния. Проверьте интерактивные элементы: продуман ли их вид при наведении курсора, дисейбле и других возможных состояниях? Всё это должно быть в макете на виду, а не спрятано где‑то в служебных артбордах.

Проверьте экспорт графики. Картинки и иконки должны извлекаться из макета без заморочек. Упростите структуру слоёв, проверьте что в экспорт не попадает лишнего. Особо тщательно проверьте элементы с режимами наложения.

Оставьте заметные коменты. Стандартные коменты в Фигме легко пропустить или случайно скрыть. Железобетонно надёжный способ — поставить заметный текст прямо рядом с дизайном.

Объясните сложное с примерами. Сложные состояния или анимацию полезно не только описать, но и наглядно показать прототипами, видео и ссылками референсы.

Наглядно покажите сетку. Советую не расчитывать на режим сетки в Фигме — разработчик может в него не заглянуть. Надёжнее дополнительно показать сетку отдельно, чтобы её точно заметили. Если нужно, объясните принцип работы сетки на разных размерах экрана.

Проверьте ссылки и доступы. Убедитесь, что разработчик сможет открыть макет и попадёт сразу на нужное ему место.

Презентуйте и договоритесь о процессе. Проведите экскурсию по макету на личной встрече, попросите задать вопросы сразу или отдельно письмом. Договоритесь быть на связи во время работы и периодически сверять часы. На презентации советую быть чуть‑чуть «не в порядке». Тут важно, чтобы разработчику было комфортно и ненапряжно сходить к вам за советом, а не забить, проигнорировать проблему или сделать по‑своему.

Как‑то так. Приглашаю уважаемых советчиков дополнить список в коментах.