У нас был проект для сервиса записи на услуги. Клиент принес аккуратные макеты из Figma, но путь до бронирования занимал 14 экранов, а команда уже потратила на это 9 недель. На тестах люди начинали путаться на четвертом шаге, и проблема была не в кнопках и цветах - сломана была сама логика сценария.
Когда бизнес заказывает мобильное приложение, почти все сначала смотрят на визуал. Я бы смотрел в другое место: сколько шагов у пользователя до полезного действия, где он отваливается и какие экраны вы оплачиваете просто потому, что их кто-то красиво нарисовал.
Сначала собирается сценарий, потом открывается Figma
Первый экран любят обсуждать все. Но если не зафиксированы ключевое действие, состав MVP и ограничения бизнеса, макеты только создают ощущение движения. Деньги уже потрачены, а продуктовой логики все еще нет.
Мы обычно начинаем с короткой карты сценариев: вход, первое полезное действие, повтор, возврат. На это уходит 3-5 часов с заказчиком. Уже на этом этапе видно, где приложение зарабатывает, а где просто съедает бюджет.
В проекте с записью мы убрали регистрацию до выбора услуги, отдельный экран филиала, лишнее подтверждение даты и финальный экран после оплаты. Путь сократился с 14 до 6 экранов, а доля успешных прохождений на прототипе выросла с 42% до 71%. Разработку на Flutter 3.27 мы еще не начинали, но экономия уже была очевидна.
“If people can’t find what they need, they can’t use what you built.”
Лишний экран почти всегда превращается в лишнюю смету
Когда меня спрашивают, сколько стоит мобильное приложение, я не считаю по числу экранов. Стоимость сидит в состояниях, переходах, ошибках, API, QA и поддержке. Поэтому два проекта с одинаковыми 12 экранами легко расходятся по бюджету на 30-40%.
На проекте интернет-магазина стек был простой и взрослый: React Native 0.76, NestJS 11, PostgreSQL 16. Клиент хотел кастомный фильтр, сложные анимации карточек и свою навигацию каталога. Мы оставили системные паттерны iOS и Android, а все декоративное сдвинули на потом, когда появились бы реальные данные по поведению.
Получилось спокойнее визуально, но для бизнеса лучше: минус 3 недели к сроку и минус 12-18% к бюджету.
| Подход | Что внутри | Что получает бизнес |
|---|---|---|
| A | 12 экранов, кастомные компоненты, сложные переходы | +2-3 недели QA, выше риск багов |
| B | 7 экранов, нативная навигация, стандартные элементы | быстрее MVP, проще поддержка |
Самые дорогие экраны в мобильном продукте - те, которые никто не проходит до конца.
В первом релизе нужен один сильный маршрут
Частая ошибка - запихнуть в MVP каталог, чат, отзывы, бонусы, карту, подписки и «нормальный личный кабинет». Я видел это десятки раз. В мобильном продукте человек обычно решает одну задачу, причем на ходу, одной рукой и без желания разбираться в интерфейсе.
В сервисе доставки мы оставили на главном экране только поиск, повтор прошлого заказа и 3 персональные категории. Убрали баннеры, подборки и перегруженное меню. Время до первого действия сократилось с 18 до 8 секунд.
Один раз мы сами промахнулись на B2B-приложении для выездной команды: добавили новости, карту объектов, чат и историю в стартовую версию, хотя бизнесу нужен был один сценарий - быстро оформить заявку. В итоге получили перегруженный первый экран и 2 недели лишних переделок.
Тут работает набор очень приземленных правил:
- в MVP должно быть 1-2 главных сценария
- вторичные разделы лучше вообще убирать из навигации
- зона нажатия - около 44x44 pt в iOS и 48x48 dp в Android
- если по элементу трудно попасть с первого раза, он уже дорогой
Прототип окупается еще до первой строки кода
Прототипирование - не украшение процесса, а способ не закопать бюджет раньше времени. Обычно хватает Figma для кликабельного сценария, Lyssna или Maze для быстрых тестов, а после релиза - Firebase Analytics или Amplitude. Для проверки логики этого более чем достаточно.
У нас был B2B-сервис для выездных сотрудников. На первом экране приложение просило доступ к геолокации, и внутри команды это казалось разумным. На тестах 4 из 6 человек зависали, потому что еще не понимали, зачем приложению такие права.
Мы перенесли запрос в момент, когда пользователь уже выбирал ближайшую точку. Завершение первого запуска выросло на 24%. В прототипе это заняло 1 день, а в коде на Swift и Kotlin стоило бы уже совсем других денег.
Перед стартом разработки я бы проверил всего четыре вещи:
- понятно ли человеку, что делать в первые 5 секунд
- доходит ли он до ключевого действия без подсказок
- где интерфейс ломается при плохом интернете
- что будет, если пользователь запретит доступы
Подрядчика лучше проверять по тому, что он готов вырезать
Портфолио с красивыми экранами почти ничего не говорит о качестве проектирования. Я бы на созвоне спрашивал другое: что войдет в MVP за 6-8 недель, какие сценарии ключевые, где будут ошибки и offline-режим, какой экран команда уберет первым. По ответу это обычно слышно сразу.
Если подрядчик оценивает проект «по макетам», я настораживаюсь. Если по сценариям, ролям, состояниям и ограничениям платформ, разговор уже взрослый. Разница потом вылезает в сроках, а не в презентации.
Я сам люблю хороший визуал, но он слишком часто усыпляет бдительность. Перед тем как платить за дизайн, попросите у команды не референсы, а черно-белый путь до целевого действия. Если он неубедителен без украшений, приложение будет дорогим и медленным с любым визуалом.
