У меня это повторяется из проекта в проект. Клиент приходит за редизайном, а проблема сидит не в цветах и типографике, а между шагами: регистрация, заявка, доступ, повторный вход. В одном B2B-сервисе мы нашли это за 2 дня в FigJam и Figma, и клиент не потратил еще 3 недели на переделку готового UI.
Читать дальше есть смысл по простой причине: прототип нужен не всем. Для части сайтов это реальная экономия, для части - лишний файл, который лежит в Figma и никак не влияет на результат.
Где прототип окупается сразу, а где я бы не стал тратить на него время
Если у вас лендинг на 5-7 экранов, одна аудитория и одна форма, я бы не стал заказывать глубокий кликабельный прототип. Обычно хватает структуры, грубого wireframe и понимания, где должен стоять CTA. Деньги там чаще лежат в оффере, контенте и порядке блоков.
Другая история - личный кабинет, маркетплейс, B2B-платформа, сервис с ролями и статусами. Там ошибка живет не на одном экране, а в цепочке действий. Пользователь нажал «зарегистрироваться», получил письмо, вернулся, увидел пустой экран, не понял следующий шаг - и вы теряете заявку еще до первого касания отдела продаж.
Я смотрю на один критерий: где именно человек может застрять и сколько стоит эта ошибка. Если ответ звучит как «между регистрацией и первым полезным действием», прототип нужен до дизайна.
Нормальный прототип - это не «нарисовать все экраны»
Смотрите: слово «прототип» в проектах используют слишком широко. На практике это как минимум три уровня, и у каждого своя задача.
| Формат | Что проверяем | Когда хватает |
|---|---|---|
| User flow | путь пользователя и развилки | в самом начале |
| Wireframe | структуру, формы, состояния | после согласования логики |
| Clickable prototype | критический сценарий руками | перед UI или MVP |
Для стартапа в 2026 я почти всегда собираю 1 критический сценарий, а не весь продукт. Например, онбординг, загрузку данных и первый результат для клиента. На одном SaaS-проекте это заняло 9 рабочих дней, после чего из MVP вылетела почти половина функций - команда просто увидела, что они не влияют на первый полезный результат.
Хороший прототип сокращает число спорных решений до начала UI и кода.
Был и обратный случай. В прошлом году команда B2B-стартапа сделала почти полный UI платформы за 2 недели, но без user flow. Красиво, быстро, инвестору понравилось, а потом всплыло, что повторный вход, согласование заявки и пустые состояния не продуманы. Часть экранов пришлось выбросить. Я видел это десятки раз: если прототип не сделали вовремя, за это потом платят дизайном и сроками.
Чем делать в 2026 и где инструменты реально помогают
Если мне приносят PDF-ТЗ на 20 страниц, я не начинаю с красивых экранов. Сначала раскладываю роли, шаги и спорные места в FigJam или Miro. Потом иду в Figma и собираю wireframe и переходы.
Базовый набор у нас такой:
- FigJam или Miro - карта сценариев и развилки
- Figma - wireframe, комментарии, интерактивность
- Axure RP - когда много условий, ролей и зависимых состояний
Axure до сих пор полезен, если в проекте сложная логика. Например, кабинет дилеров с RBAC, разными статусами заказа и зависимыми полями формы. В Figma это тоже можно показать, но медленнее и с большим объемом ручной работы.
AI-инструменты я пробовал в прошлом году. Для черновых экранов скорость растет, но решения лучше не становятся. В одном проекте мы слишком рано дали команде генерировать макеты через AI-плагины, и обсуждение сразу скатилось в «нравится / не нравится», хотя сам сценарий еще не был собран. Это была ошибка, и пользы она не дала.
Если email невалиден -> показать ошибку
Если email валиден -> перейти к шагу 2
Если сервер недоступен -> показать retry-state
Если пользователь уже есть -> предложить вход
Если регистрация успешна -> открыть onboarding
Такой кусок логики полезнее красивого экрана. Он сразу показывает, где продукт развалится.
Сколько это стоит и почему считать по экранам - плохая идея
Самая частая ошибка в смете - вопрос «а сколько стоит экран». 10 экранов корпоративного сайта и 10 экранов кабинета с оплатой, ролями и интеграцией с CRM - это разный объем в разы. Цена зависит от числа неизвестных: роли, ошибки, доступы, статусы, мобильные состояния, внешние API.
По нашим вилкам картина обычно такая:
- лендинг - 8-16 часов
- корпоративный сайт - 20-40 часов
- сервис, кабинет, MVP SaaS - 40-80+ часов
У нас был кабинет дистрибутора на Laravel 11 + PostgreSQL 16. Клиент сначала хотел «просто экраны», чтобы сэкономить. После первого разбора стало ясно: 3 роли, разные права, нестандартная форма заказа, зависимые статусы. На прототип ушло 56 часов. После этого разработка стартовала без хаоса, а вопросов от команды в первом спринте стало меньше примерно на 35%.
Быстрый тест «до / после» выглядит так:
- до - спорят о внешнем виде, потому что логика не собрана
- до - дизайнер дорисовывает состояния по ходу работы
- после - у разработки есть сценарии и исключения
- после - правки идут по делу, а не по кругу
Как понять, нужен ли этот этап именно вам
Я обычно задаю клиенту пять вопросов:
- есть ли больше одной роли в системе
- может ли пользователь вернуться в незавершенный процесс
- есть ли ошибки, пустые состояния, ограничения доступа
- зависит ли следующий шаг от предыдущего выбора
- дорого ли менять логику после старта UI
Если хотя бы на 3 пункта ответ «да», прототип почти наверняка окупится.
В ближайшие 6-12 месяцев рисовать экраны станет еще быстрее - AI и шаблоны уже это делают. Дороже будет другое: найти момент, где пользователь теряет смысл следующего шага. Самый дорогой экран в 2026 году - тот, который выглядит готовым слишком рано.
