Прототип приложения: как сделать кликабельный прототип за вечер

Прототип, макет, вайрфрейм, дизайн — что чем отличается

Четыре слова, которые в разговоре путают все, включая исполнителей. Разница простая: они отвечают на разные вопросы, и делать их надо в этом порядке.

На практике вайрфрейм и макет часто собирают одним движением — в этом нет ошибки. Ошибка — прыгать сразу в дизайн.

Прототип — это не «красиво», а «понятно». Серые прямоугольники, честные подписи и работающие переходы полезнее, чем три экрана в фирменных цветах и ни одного перехода. У этого есть неочевидная причина: как только прототип становится похож на готовый дизайн, обсуждение съезжает на оттенок синего, и структуру никто уже не оспаривает. А структура — единственное, что дорого менять потом.

Что прототип не делает. Он не считает, не хранит данные, не ходит в базу и не превращается в приложение нажатием кнопки — ни у нас, ни в Figma, ни в любом другом инструменте прототипирования. Если вам обещают «прототип, который станет приложением», речь идёт либо о конструкторе на шаблонах с жёсткими рамками, либо о генерации кода, который всё равно придётся переписывать. Прототип — это документ о намерениях, и ценен он именно этим.

Зачем он вам, если приложение всё равно будут делать программисты

• Оценка. Студия считает по экранам и состояниям. Прототип из 7 экранов оценивается за час, «идея приложения для доставки» — не оценивается вообще.
• Спор до разработки, а не после. Все несогласия про порядок шагов вылезают в момент, когда вы проходите прототип пальцем, — это дешевле, чем на приёмке.
• Проверка на людях. Дайте прототип трём будущим пользователям и молча смотрите, куда они нажимают. Это работает уже на серых прямоугольниках.
• Общий язык. «Полоска снизу с иконками» и «таб-бар» — одно и то же, но пока это не показано, разговор идёт про разные вещи. Про словарь — в разборе как объяснить разработчику.

В каком размере рисовать: цифры, а не «на глаз»

Прототип приложения рисуется в логических точках экрана конкретного устройства, а не в произвольном прямоугольнике. Иначе на реальном телефоне не влезает то, что влезало у вас. Вот размеры, по которым имеет смысл ориентироваться в 2026 году — они же стоят в каталоге устройств редактора Maketa.

Про безопасные зоны. Сверху у современных телефонов живёт вырез или «динамический остров» (примерно 47–62 pt), снизу — полоска жеста (34 pt на iPhone). Туда нельзя класть ничего нажимаемого. В редакторе Maketa эти зоны нарисованы прямо в рамке устройства, и это не украшение: половина присланных нам макетов ставила кнопку «Готово» ровно под полоску жеста.

Про размер нажимаемого. Минимум — 44 × 44 pt для iOS и 48 × 48 dp для Android. Кнопка высотой 28 pt в прототипе выглядит аккуратно, а пальцем не попадает никто. Это единственная «дизайнерская» цифра, которую нужно держать в голове ещё на прототипе, — потому что от неё зависит, сколько всего влезет на экран.

Порядок: семь шагов

Порядок именно такой, потому что каждый следующий шаг опирается на результат предыдущего. Самая частая причина «прототип пришлось переделать» — начали с четвёртого шага.

Шаг 1. Напишите список экранов словами. На бумаге

До всякого редактора: строчками, по одному экрану в строке. «Вход · Список заказов · Карточка заказа · Оформление · Готово». Если список не пишется — значит, вы ещё не решили, что делает приложение, и рисовать рано. Нормальная первая версия — 5–9 экранов. Двадцать экранов в первой версии означают, что туда попало то, что можно сделать во второй.

Шаг 2. Опишите один главный сценарий одной фразой

«Курьер открывает приложение, видит свои заказы на сегодня, открывает заказ, отмечает доставку фотографией, заказ уходит из списка». Прототип строится вокруг этого маршрута; всё остальное — второй эшелон. Один сценарий — это не мало: именно он показывает, работает ли идея.

Шаг 3. Разложите блоки на каждом экране, начиная с главного

Шапка, содержимое, действие. Не рисуйте иконки и не подбирайте цвета — на этом шаге вы решаете, что человек видит первым. Полезный приём: прищурьтесь и посмотрите на экран издалека. Если непонятно, что здесь главное, — на настоящем телефоне будет так же.

Шаг 4. Поставьте настоящие тексты

Не «Заголовок» и не lorem ipsum. Настоящие названия пунктов меню, настоящие суммы, настоящие длинные фамилии. Половина проблем вёрстки видна только на реальном тексте: «Пн» и «Понедельник» ведут себя по-разному, а «Иванов И. И.» и «Мухаметшина-Оганесян А.» — тем более. Это же спасает от спора «а вы уверены, что сюда влезет?».

Шаг 5. Свяжите экраны переходами

Именно этот шаг превращает набор картинок в прототип. Каждой кнопке, которая куда-то ведёт, назначается экран назначения и вид перехода. Проверка простая: пройдите свой главный сценарий от начала до конца, не касаясь мышью ничего, кроме нарисованных кнопок. Не прошли — прототипа ещё нет.

Шаг 6. Добавьте состояния, а не только «всё хорошо»

Самый недооценённый шаг и самый заметный в оценке. У каждого экрана со списком есть минимум три состояния: полный, пустой («заказов пока нет»), ошибка («нет связи»). У формы — незаполненная, с ошибкой в поле, отправленная. Разработчику всё равно придётся их сделать; вопрос только в том, придумаете их вы или он.

Технически это просто копия экрана с другим содержимым. В Maketa для этого есть «копия экрана»: дублируете «Список заказов», называете «Список заказов — пусто» и убираете содержимое. Шесть таких копий добавляют к прототипу полчаса, а к взаимопониманию — очень много.

Шаг 7. Пройдите прототип пальцем и отдайте ссылку

Откройте прототип в режиме просмотра на телефоне и пройдите сценарий сами. Потом дайте ссылку двум-трём людям — и не подсказывайте им. Всё, где они запнулись, — ваши правки на завтра.

Четыре вида перехода — и почему это не мелочь

«Открыть следующий экран» — это четыре разных поведения, и они означают разное для человека и для разработчика. Если в прототипе везде один вид, вы отдаёте выбор программисту, а он выберет то, что быстрее сделать.

Практический критерий. Задайте себе вопрос: «нажав „Назад“, человек должен вернуться сюда?» Да — «вглубь». Нет, и это конец пути — «заменить». Промежуточное решение, которое можно закрыть свайпом вниз, — шторка. Вопрос из одной строки — окно.

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

Восемь ошибок, которые стоят переделки

1. Начать с дизайна. Цвета и шрифты до структуры — гарантированный второй заход. Сначала «что и куда», потом «как выглядит».
2. Рисовать в произвольном размере. Прототип «примерно как телефон» ничего не проверяет. 360 pt — и всё встаёт на места.
3. Показывать только счастливый путь. Прототип без пустых списков и ошибок недооценивает работу минимум в полтора раза.
4. Экраны без переходов. Набор картинок читают по-разному все. Кликабельный маршрут читается однозначно.
5. Lorem ipsum и «Текст текст». На фальшивом тексте не видно ни переполнения, ни того, что название пункта меню не помещается в две строки.
6. Двадцать экранов в первой версии. Прототип — про главный сценарий. Всё остальное дорисовывается, когда главный подтвердился.
7. Мелкие кнопки. 44 pt — не рекомендация дизайнеров, а физика пальца. Экономия высоты в прототипе оборачивается перекомпоновкой в разработке.
8. Отдать прототип без комментария к нему. Ссылку сопровождают двумя строчками: какой сценарий главный и что на каком экране проверить. Иначе получите отзыв про цвет.

Сколько это занимает

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

• Список экранов и сценарий — 20–40 минут, на бумаге.
• Пять-семь экранов вчерне — 1,5–2 часа, если начинать с чистого листа, и 30–40 минут, если взять готовый каркас и переписать под себя.
• Переходы и проверка сценария — 20 минут.
• Состояния (пусто, ошибка, отправлено) — 30 минут.

Итого — вечер. Второй заход после отзывов занимает уже час: править прототип дёшево, в этом весь смысл. Для сравнения: перенести кнопку на другой экран в сделанном приложении — это задача, релиз и очередь на тестирование.

Как отдавать прототип и собирать правки

Прототип живёт в виде ссылки, а не файла: файл устареет в ту же секунду, как вы что-то поправите. Дальше важно, какое право вы даёте по этой ссылке. В Maketa их четыре: редактировать, смотреть и оставлять замечания, только смотреть, только приглашённые.

Рабочий режим для согласования — «смотреть и оставлять замечания»: человек открывает ссылку, тыкает в блок на экране и пишет «здесь нужна цена», представившись только именем — без регистрации и без установки чего-либо. Замечание прикрепляется к самому блоку и остаётся на нём, даже если вы потом переложите экран. Это ровно то место, где обычно теряются правки: скриншоты в мессенджере без привязки к экрану через неделю не расшифровывает никто, включая их автора.

Частые вопросы

Чем прототип отличается от MVP?

Прототип — картинки с переходами, его нельзя дать пользователю в работу. MVP — работающее приложение с урезанным набором возможностей, у него есть база, вход и настоящие данные. Прототип делается за вечер и стоит вашего времени; MVP — это разработка со сроком и бюджетом. Порядок такой: прототип → оценка → MVP.

Можно ли сделать прототип приложения бесплатно?

Да. Редактор, переходы, режим просмотра, ссылка и замечания в Maketa бесплатны и без ограничения по числу макетов — платные у нас только ИИ-помощник и то, что реально стоит нам денег. У Figma есть бесплатный тариф с лимитом на число файлов; у Excalidraw и бумаги — тем более. Инструмент здесь вообще не главное: разница между хорошим и плохим прототипом — в том, есть ли в нём состояния и переходы, а не в том, чем он нарисован. Подробное сравнение — Maketa или Figma.

Прототип интерфейса и прототип дизайна — это одно и то же?

В разговоре — почти. Формально «прототип интерфейса» подчёркивает структуру и поведение, «прототип дизайна» — внешний вид. Если вам сказали «пришлите прототип дизайна», уточните, чего ждут: серые блоки с переходами или готовый вид в фирменных цветах. Это разные объёмы работы, и путаница здесь стоит недели.

А прототип веб-приложения — это то же самое?

Механика та же, размеры и привычки другие: ширина 1440 вместо 390, скролл вместо переходов, курсор вместо пальца, состояния при наведении, которых на телефоне нет. Мы разобрали это отдельно — прототип сайта; для веб-приложения берите оттуда всё, кроме раздела про первый экран лендинга.

Может ли нейросеть нарисовать прототип за меня?

Черновик экрана — да, и это экономит время на рутине: описали «экран списка заказов с фильтром сверху» — получили заготовку, которую дальше правите руками. В Maketa такой помощник есть, и он же разбирает присланный скриншот в редактируемые блоки. Чего нейросеть не сделает — не решит, какие экраны вашему приложению нужны и в каком порядке человек по ним идёт. Это решение и есть прототип; всё остальное — оформление.

Нужен ли прототип, если приложение будет делать знакомый программист?

Тогда он нужен особенно. С подрядчиком по договору спор упирается в ТЗ, со знакомым — в память. Прототип — единственная форма договорённости, которую нельзя понять двумя способами. Заодно он ускоряет саму работу: программист не выдумывает экраны по ходу дела.