Для сети клиник МЕДИ мы разработали мобильное приложение, через которое пациенты записываются на приём и получают видеоконсультации: число обращений выросло в 1,5 раза, а повторных обращений — в 2 раза. Для проекта «Предпринимай!» мы спроектировали и разработали приложение для подачи заявления предпринимателями, в котором собрано более 10 интеграций с внешними системами, а срок подачи заявления сократился на 35 % — за счёт того, что часть данных заполняется автоматически, а не вручную при каждом обращении.
Оба примера объединяет одно: приложение не копирует бумажный процесс на экран, а меняет саму логику — убирает шаги, которые нужны были только из-за бумажного документооборота, и оставляет то, что действительно важно пользователю.
Каждый проект начинается с заявки и брифинга, где мы подробно разбираем задачу и аудиторию, затем готовим концепцию решения — архитектуру и состав функциональности — и приступаем к разработке после подписания договора. За 10+ лет на рынке мы придерживаемся простого правила: браться за проект, только если уверены, что сделаем его качественно и в срок.
Приложения для записи, консультаций и заявлений
Мы делаем мобильные приложения для организаций, где у клиента или гражданина есть регулярная потребность взаимодействовать с сервисом: записаться на приём, отследить статус обращения, получить консультацию удалённо, подать документы без визита в офис. Такие приложения включают личный кабинет пользователя, историю обращений, push-уведомления о статусе и, где это нужно, встроенные видеозвонки или чат с оператором — набор функций мы определяем на этапе аналитики вместе с заказчиком, а не берём типовой шаблон.
В приложении МЕДИ мы спроектировали сценарий записи так, чтобы пациент проходил путь от выбора врача до подтверждённого времени приёма за минимальное число шагов, а видеоконсультация запускалась прямо из карточки записи без перехода в сторонние сервисы. В приложении «Предпринимай!» логика была другой: разные типы обращений вели пользователя по разным сценариям подачи заявления, а статус обрабатывался через интеграции с профильными системами, чтобы предпринимателю не приходилось самому уточнять его по телефону или ехать в офис за справкой о ходе рассмотрения.
Такие приложения редко работают в одиночку — почти всегда нужна интеграция с внешними системами и базами данных, авторизация пользователя и защищённая передача персональных данных, поэтому серверная часть проектируется так же внимательно, как интерфейс. Мы отдельно продумываем, что происходит при сбое связи или недоступности внешней системы: пользователь не должен терять уже заполненные данные из-за того, что где-то на бэкенде произошёл разрыв соединения — приложение сохраняет черновик и позволяет продолжить с того же места.
Мы также учитываем, что пользователь сервисного приложения не готов разбираться в сложном интерфейсе ради разовой задачи — если запись на приём или подача заявления занимает больше пары минут, человек скорее позвонит по телефону или придёт лично. Поэтому число шагов до целевого действия мы сокращаем на этапе проектирования, а не пытаемся исправить это после запуска.
Технологии разработки мобильных приложений
Для iOS мы разрабатываем на Swift и поддерживаем проекты на Objective-C, для Android — на Kotlin: нативная разработка даёт быстрый и предсказуемый отклик интерфейса, что особенно важно в сервисах, где пользователь и так тратит время на ожидание ответа от системы, будь то запись к врачу или обработка заявления. Когда нужно быстрее выйти на обе платформы с ограниченным бюджетом, используем кроссплатформенный Flutter.
Серверную часть — API, авторизацию, интеграции с внешними системами и базами данных — пишем на PHP: он выдерживает нагрузку большого числа обращений и хорошо стыкуется с системами заказчика. Для «Предпринимай!» это означало настройку более 10 интеграций так, чтобы заявление предпринимателя автоматически проходило через все нужные системы без ручной пересылки данных между ведомствами и без риска, что часть данных потеряется на стыке систем.
Мы закладываем архитектуру с запасом: сервис для клиники или государственной услуги не может «упасть» в момент высокой нагрузки — например, в начале месяца, когда одновременно приходит много заявлений, или утром, когда пациенты массово записываются на приём. Поэтому мониторинг стабильности и производительности — часть работы, а не опция после жалоб пользователей.
Технологию — нативную разработку или Flutter — обсуждаем с заказчиком на брифинге исходя из задачи: если приложению нужна работа с камерой для сканирования документов или биометрией для подтверждения личности, выбираем нативную разработку; если задача — быстро выпустить понятный MVP на обе платформы и проверить, как сервис примут пользователи, рассматриваем Flutter как более экономичный старт.
Дизайн и UX/UI для сервисных приложений
Дизайн таких приложений делает собственное дизайн-бюро MEN IN DEV — на его счету больше 10 000 макетов — от приложений для конечных пользователей до сложных B2B- и государственных сервисов. Мы проектируем интерфейс так, чтобы человеку, который обращается в сервис нечасто и без особого желания разбираться в новом приложении, было понятно, что делать на каждом экране без инструкции. Профессиональный UX/UI способен увеличить конверсию в целевое действие вдвое — в сервисных приложениях это конверсия в завершённую запись или поданное заявление, а не просто установка.
Мы учитываем аудиторию, для которой делаем продукт: пациентам клиники важны крупные понятные элементы и минимум лишних полей, а не десятки настроек на одном экране; предпринимателю — прозрачный статус заявления на каждом шаге и понятная причина, если что-то требует уточнения. Разница в возрасте, опыте использования смартфона и терпении к новому интерфейсу у этих аудиторий может быть огромной, и хороший дизайн эту разницу учитывает, а не игнорирует. Собираем UI-kit — единую библиотеку компонентов, которая ускоряет разработку новых функций при развитии продукта и сохраняет целостность интерфейса, когда в приложение добавляются новые сценарии и разделы.
Если вам нужно мобильное приложение для клиентского сервиса или подачи заявлений — расскажите о задаче на брифинге, и мы предложим архитектуру решения и модель работы: Fixed Price с зафиксированным ТЗ, Time & Materials с оплатой фактических часов или Retainer с выделенной командой для дальнейшего развития.
После запуска приложение остаётся на нашей поддержке: мы обновляем его под новые версии iOS и Android, следим за стабильностью работы интеграций и дорабатываем сценарии по мере того, как меняются процессы заказчика и растёт число пользователей приложения.
