Предприниматель приходит с идеей приложения.
Например, для доставки, записи клиентов, аренды, сервиса, магазина или внутренней автоматизации.
И почти всегда хочется быстрее увидеть результат.
Не таблицу.
Не схему.
Не список ролей.
Не описание статусов.
А красивые экраны.
Главный экран.
Каталог.
Корзину.
Личный кабинет.
Карту.
Кнопки.
Цвета.
Иконки.
На этом этапе часто звучит фраза:
«Давайте сначала нарисуем дизайн, а потом уже разберёмся с деталями».
Звучит логично.
Но именно так проект часто уходит в переделки.
Потому что приложение — это не набор красивых экранов.
Это бизнес-система.
В ней должны работать заказы, заявки, статусы, роли, уведомления, оплата, админка, база клиентов и иногда интеграции с CRM или 1С.
Если это не разобрать до дизайна, макеты могут получиться красивыми, но бесполезными для разработки.
Типовая ситуация
Предприниматель хочет приложение для своего бизнеса.
Например, сервис принимает заявки от клиентов.
На словах всё просто:
клиент открыл приложение, выбрал услугу, нажал кнопку, отправил заявку.
Дизайнер рисует красивый экран.
На нём есть кнопка:
«Оформить заказ»
Выглядит хорошо.
Но дальше начинаются вопросы.
Что происходит после нажатия?
Заявка сразу считается заказом?
Или её должен подтвердить менеджер?
Клиент платит сразу или после подтверждения?
Можно ли отменить заказ?
Кто меняет статус?
Что видит клиент?
Что видит администратор?
Куда приходит уведомление?
Что делать, если услуга недоступна?
Нужна ли интеграция с CRM?
Нужно ли отправлять SMS или push-уведомление?
Должен ли заказ попадать в админку?
Кто отвечает за обработку?
Один экран быстро превращается в бизнес-процесс.
И если этот процесс не разобран заранее, дизайн начинает рассыпаться.
Ошибка не в дизайне
Проблема не в дизайнере.
Дизайнер может нарисовать красивый интерфейс.
Но он не должен угадывать бизнес-логику.
Если предприниматель сам ещё не понимает, как должна работать заявка, дизайнер нарисует внешний слой.
Кнопки будут.
Цвета будут.
Экраны будут.
Но внутри останутся пустые места.
А потом на этапе разработки выяснится:
здесь не хватает статуса,
здесь забыли роль администратора,
здесь нужна отдельная история заказов,
здесь надо подтверждение,
здесь нужна отмена,
здесь нужна связь с оплатой,
здесь нужен другой сценарий.
И начинается переделка.
Сначала макетов.
Потом прототипа.
Иногда уже готового кода.
Почему особенно часто ломается личный кабинет
Личный кабинет кажется простой частью приложения.
На макете обычно всё выглядит понятно:
имя,
телефон,
история заказов,
бонусы,
настройки,
выход из аккаунта.
Но за этим стоит много решений.
Нужна ли обязательная регистрация?
Можно ли оформить заказ без аккаунта?
Как восстанавливать доступ?
Что делать, если клиент сменил номер телефона?
Какие данные он может редактировать?
Что показывать, если заказов ещё нет?
Как связать кабинет с бонусной системой?
Кто видит историю обращений?
Нужно ли хранить адреса доставки?
Нужны ли разные роли пользователей?
Если эти вопросы не разобрать, личный кабинет превращается в набор красивых, но недодуманных экранов.
Выглядит дорого.
Работает слабо.
Где бизнес теряет деньги
Когда проект начинается с дизайна без логики, деньги теряются не сразу.
Сначала всё выглядит нормально.
Есть макеты.
Есть ощущение движения.
Можно показать партнёру, инвестору или команде.
Но потом появляются уточнения.
“А давайте добавим статус заказа”.
“А менеджер где это увидит?”
“А клиент должен получить уведомление”.
“А если оплаты не прошла?”
“А если товара нет?”
“А если заявка нужна не одна, а с несколькими позициями?”
“А если у нас два типа пользователей?”
Каждое такое уточнение может тянуть за собой новые экраны.
А иногда меняет уже нарисованные.
В итоге появляются:
лишние экраны,
дубли функций,
сложные сценарии,
непонятная админка,
переделки дизайна,
рост сроков,
доплаты на разработке.
Особенно неприятно, когда переделки всплывают после утверждения дизайна.
Потому что на этом этапе предприниматель уже считает, что часть проекта готова.
А на деле становится понятно:
готовы картинки, но не готова логика продукта.
Почему проблема не только в интерфейсе
Мобильное приложение для бизнеса редко живёт само по себе.
Обычно рядом есть админка.
Именно там менеджер принимает заявки, меняет статусы, видит клиентов, обрабатывает заказы, выгружает данные и управляет контентом.
Если в дизайне приложения нарисовали кнопку “Заказать”, но не продумали админку, проект всё равно не работает.
Клиент отправил заявку.
А дальше что?
Кто её увидел?
Где она хранится?
Кто назначен ответственным?
Какой у неё статус?
Как менеджер связывается с клиентом?
Что происходит после выполнения?
Попадает ли клиент в базу?
Можно ли потом сделать повторную продажу?
Вот почему сначала надо разбирать не цвет кнопки, а путь заявки.
От клиента до обработки внутри бизнеса.
Что надо проверить до старта дизайна
До дизайна нужно ответить на несколько базовых вопросов.
Кто будет пользоваться приложением?
Какие роли нужны?
Что делает клиент?
Что делает менеджер?
Что делает администратор?
Какие заявки или заказы проходят через систему?
Какие статусы нужны?
Где появляется оплата?
Какие уведомления нужны?
Какие данные нужно хранить?
Какие интеграции нужны сразу?
Что можно не делать в первой версии?
Это не бюрократия.
Это защита бюджета.
Потому что исправить логику на бумаге или в прототипе дешевле, чем переделывать дизайн и код.
Какой MVP логичен в первой версии
Для первой версии обычно не нужно делать всё.
Логичный MVP — это не урезанное приложение ради экономии.
Это первая рабочая версия, которая закрывает главный сценарий бизнеса.
Например, для сервиса это может быть:
клиент выбирает услугу,
оставляет заявку,
получает подтверждение,
видит статус,
менеджер обрабатывает заявку в админке,
клиент получает уведомление.
Для доставки:
клиент выбирает товары,
оформляет заказ,
указывает адрес,
видит сумму,
получает статус,
администратор принимает и обрабатывает заказ.
Для записи клиентов:
клиент выбирает услугу, дату и время,
оставляет контакт,
получает подтверждение,
администратор видит запись и управляет расписанием.
Это уже может быть полезным продуктом.
Без сложных бонусов.
Без лишних ролей.
Без перегруженного личного кабинета.
Без функций “на будущее”.
Что лучше отложить
Часто в первую версию хотят добавить всё сразу:
бонусную систему,
реферальную программу,
чат,
сложную аналитику,
много ролей,
интеграцию со всем подряд,
персональные рекомендации,
внутренний маркетплейс,
гибкие тарифы,
промокоды,
рейтинги,
отзывы,
избранное.
Иногда это действительно нужно.
Но не всегда на старте.
Если основная бизнес-логика ещё не проверена, такие функции только раздувают бюджет и сроки.
Правильнее сначала запустить основной сценарий.
Понять, как клиенты реально пользуются системой.
Где менеджеры тормозят.
Какие статусы нужны.
Какие уведомления лишние.
Что действительно влияет на заявки и повторные обращения.
А потом добавлять второй слой.
Где обычно растёт бюджет
Бюджет чаще всего растёт не из-за “красивого дизайна”.
Он растёт из-за недоговорённой логики.
Например:
не описали роли пользователей,
не продумали статусы заказов,
не учли возвраты и отмены,
не разобрали оплату,
забыли про админку,
не учли уведомления,
слишком поздно вспомнили про CRM или 1С,
решили добавить личный кабинет после дизайна,
поменяли сценарий оформления заказа уже в разработке.
Каждый такой пункт кажется мелким.
Но вместе они могут изменить архитектуру приложения.
А это уже не правка цвета кнопки.
Это изменение продукта.
Практический вывод
Начинать приложение с красивого дизайна — опасная привычка.
Дизайн нужен.
Но не первым шагом.
Правильная последовательность выглядит так:
бизнес-сценарии → логика → прототип → дизайн → разработка.
Сначала надо понять, как приложение должно работать.
Потом — какие экраны для этого нужны.
И только потом — как они должны выглядеть.
Красивый интерфейс не спасает слабую бизнес-логику.
Можно сделать дорогое приложение, в котором клиенту неудобно оставить заявку, а менеджеру неудобно её обработать.
И наоборот.
Можно сначала спокойно разобрать сценарии, убрать лишнее, собрать понятный MVP и только потом рисовать дизайн.
Так проект становится проще.
Понятнее для пользователя.
Удобнее для команды.
Предсказуемее по бюджету.
Легче для дальнейшего развития.
Если коротко
Дизайн отвечает на вопрос:
“Как это выглядит?”
Но перед этим нужно ответить на другой вопрос:
“Как это должно работать в бизнесе?”
Именно там обычно находится главная экономия.
Не в том, чтобы нарисовать дешевле.
А в том, чтобы не переделывать потом.
Если вы думаете о мобильном приложении для бизнеса, лучше начать не с дизайна и не с выбора подрядчика.
Сначала стоит проверить бизнес-логику, MVP, бюджет, роли пользователей, админку, интеграции и риски.
Иногда бизнесу действительно нужно полноценное мобильное приложение.
Иногда быстрее и дешевле начать с Mini App, CRM, бота или простой системы заявок.
В «САП КОД» мы помогаем разобрать проект до разработки: что делать в первой версии, что отложить, где может вырасти бюджет и как не уйти в лишние функции.
Оставить заявку на разбор проекта можно здесь.