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

Верхнеуровнево я бы определил следующие варианты детализации прототипа:

скетч — эскиз на бумаге, отлично подходит чтобы в моменте обсудить решение, например на встрече планирования уточнить что команда понимает одинаково решение. Тут нет никаких правил оформления, главное в моменте понять друг друга)

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

макет — наш самый главный артефакт, который мы отдаем в разработку, тестировщикам, продукту, аналитикам, заказчикам и тд, можно сказать наш финальный артефакт по задаче) тут мы показываем отдельными экранами в итоговом UI, как выглядит и работает интерфейс в каждый момент сценария, включая моменты когда что-то пошло не так. C рабочими текстами и изображениями. Так же сопровождаем макеты комментариями (описываем дизайн спецификацию) там где это необходимо, вот тут про это можно почитать: https://habr.com/ru/companies/simpleone/articles/849486/

кликабельный прототип — нужен для тестирования решения до передачи в разработку (или презентации фичи заказчику до разработки), чтобы дешево проверить свое решение до разработки и отдать в разрботку проверенное решение. Обычно когда мы проводим коридорный тест или ux-тестирование, мы просим пользователя пройти конкретный сценарий (который реализовли для задачи и проверяем) — именно его и нужно объединить в кликабельный прототип, все остальные кнопки которые не имеют отношения к тому сценарию который мы тестируем — могут быть не кликабельны) Это может быть просто связанный в прототип простейший линейный порядок экранов, главное — это провести тестирование и увидеть что пользователь понял наше решение)

А если мы используем прототип для презентации — нам важно просто показать в формате презентации реалистично и динамично как работает фича, чтобы не показывать статичные макеты) поэтому тут мы сами опять же вольны делать как угодно прототип сценария, под капот никто смотреть не будет и кликать за нам прототип тоже.

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