Slava Kivichhttps://teletype.in/atom/ezhifisher2026-06-24T07:09:11.371Zezhifisher:itUg-6-i7F22025-01-04T10:33:36.150Z2025-01-04T10:33:36.150Z

Привет)

<p id="aO3A"><strong>Привет) </strong></p> <p id="u9Kz">тут важно, что ты сама определяешь детализацию прототипа исходя из текущей задачи.</p> <p id="Q3Fa">Верхнеуровнево я бы определил следующие варианты детализации прототипа:</p> <p id="tYxj"><strong>скетч</strong> — эскиз на бумаге, отлично подходит чтобы в моменте обсудить решение, например на встрече планирования уточнить что команда понимает одинаково решение. Тут нет никаких правил оформления, главное в моменте понять друг друга)</p> <p id="ccaX"><strong>вайрфрейм</strong> — более детализированный артефакт чем скетч, который может уже стать первым артефактом для разработки и тестирования. Тут важно показать структуру каждого экрана и ключевые элементы на экране, поэтому важно показывать: кнопки и их название, название инпутов, другие кликабельные элементы, прописывать заголовки. Текстовый контент (абзацы) и изображения можно не прописывать. Такой вайрфрейм можно уже использовать для согласования структуры экранов с заказчиком (до того как мы примемся красоту наводить), а так же отдать разрабам, чтобы начинали делать базу в коде для решения</p> <p id="p0QI"><strong>макет</strong> — наш самый главный артефакт, который мы отдаем в разработку, тестировщикам, продукту, аналитикам, заказчикам и тд, можно сказать наш финальный артефакт по задаче) тут мы показываем отдельными экранами в итоговом UI, как выглядит и работает интерфейс в каждый момент сценария, включая моменты когда что-то пошло не так. C рабочими текстами и изображениями. Так же сопровождаем макеты комментариями (описываем дизайн спецификацию) там где это необходимо, вот тут про это можно почитать: https://habr.com/ru/companies/simpleone/articles/849486/</p> <p id="u9Ep"><strong>кликабельный прототип</strong> — нужен для тестирования решения до передачи в разработку (или презентации фичи заказчику до разработки), чтобы дешево проверить свое решение до разработки и отдать в разрботку проверенное решение. Обычно когда мы проводим коридорный тест или ux-тестирование, мы просим пользователя пройти конкретный сценарий (который реализовли для задачи и проверяем) — именно его и нужно объединить в кликабельный прототип, все остальные кнопки которые не имеют отношения к тому сценарию который мы тестируем — могут быть не кликабельны) Это может быть просто связанный в прототип простейший линейный порядок экранов, главное — это провести тестирование и увидеть что пользователь понял наше решение)</p> <p id="ZB4V">А если мы используем прототип для презентации — нам важно просто показать в формате презентации реалистично и динамично как работает фича, чтобы не показывать статичные макеты) поэтому тут мы сами опять же вольны делать как угодно прототип сценария, под капот никто смотреть не будет и кликать за нам прототип тоже.</p> <p id="DVpr">У нас нет задачи в фигме воссоздавать полностью рабочую клюкабельную версию работающего приложения, чтобы можно было зайти в режим прототипа и прокликать приложение как будто в фигме целиком, это дорого)</p>