Назад
healthcare mobile app development

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

Создание digital-продуктов для зарубежного рынка — это то, чем мы занимаемся уже более 5 лет. Разработка медицинских приложений не является исключением и на это есть причина. Индустрия MHealth (Mobile + Health), или в русском переводе «мобильное здравоохранение», переживает настоящий бум в Америке и Европе.

Ежедневно в магазины приложений по всему миру загружается более 200 сервисов, которые помогают людям следить за своим здоровьем.

Несмотря на такой стремительный рост, рынок еще далек от насыщения. Более того, сейчас меняется сама структура индустрии: например, если еще несколько лет назад топовым направлением в разработке медицинских приложений были лайфстайл решения про сон, тренировки и питание, то сейчас активно растет доля сервисов, которые позволяют общаться с врачами, контролировать свое физическое состояние и анализировать симптомы. Причем исследователи отмечают, что по-прежнему почти не занята ниша мобильных приложений для людей с диагнозами «диабет», «избыточный вес» и «депрессия».

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

В статье делимся главными принципами разработки медицинских приложений, благодаря которым мы создаем крутые решения в нише MHealth для западного рынка.

1. В фокусе не клиника, а пользователи

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

READ MORE  Кейс экспресс-дизайна от агентства Purrweb: как упаковать медицинский стартап за $1500 и привлечь $400 тысяч

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

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

В Америке медицинские сервисы и приложения должны соответствовать стандартам HIPAA (Health Insurance Portability and Accountability Act) — это набор правил по соблюдению конфиденциальности и обеспечению безопасности данных о пациентах. Соответствие этим требованиям служит гарантом для пользователей, что информация о них в безопасности.

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

READ MORE  Особенности разработки мобильного приложения для службы доставки: кейс B2B-сервиса Cargo

2. «Немедицинский» внешний вид сервисов

Основное отличие разработки медицинских приложений за рубежом в том, что их сервисы не выглядят «по-медицински». Минимализм, чистота и спокойная цветовая гамма — вот три принципа, которые определяют их продукты.

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

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

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

READ MORE  SCRUM, щеночки и 5 000+ скачиваний в Google Play: как мы делали немецкое приложение для владельцев домашних животных

Как вариант, часть коммуникации можно автоматизировать. Один из наших клиентов, американский стартап Lytic, для автоматического сбора анамнеза (симптомов и жалоб) использует чат-бот. Он задает наводящие вопросы, предлагает варианты ответа, и, если есть подозрение на заболевание, предлагает записаться к врачу или сдать анализы. Когда пользователь приложения приходит к доктору, у того уже есть вся важная первичная информация, что значительно сокращает время приема.

разработка медицинских приложенийМедицинское приложение Lytic

Так работает чат-бот в приложении Lytic. Он выглядит, как привычный мессенджер, и с его помощью пользователю легко дать описание своего состояния.

3. Геймификация для мотивации

Мы упомянули, что люди любят видеть результаты — и геймификация как раз отличный способ управлять мотивацией через демонстрацию прогресса.

Но для MHealth приложений нужен баланс, потому что забота о здоровье, это все-таки не игра: пользователи не любят слишком веселые, мультяшные решения. Геймификация должна быть увлекательной, содержательной, но при этом достаточно серьезной.

разработка медицинских приложенийДля приложения, которое позволяет врачам назначать пациентам медикаменты, мы создали специальные дашборды и интегрировали туда элементы геймификации

Благодаря подходу с геймификацией мы смогли замотивировать пользователей принимать лекарства вовремя и не бросать курс лечения.

4. Чем больше персонализации тем лучше

Огромная проблема с приложениями MHealth заключается в том, что большинство пользователей скачивают их, открывают один-два раза и больше не используют. Одна из причин — нерелевантность рекомендаций и контента к их повседневности.

Пользователи не хотят слишком сильно напрягаться, чтобы интегрировать заботу о здоровье в свою жизнь, они предпочитают, чтобы и приложение, и забота о здоровье интегрировались в их привычный образ жизни. Да, спорное желание, но здесь есть важный инсайт.

Когда речь идет о медицине, то целевую аудиторию нельзя представлять себе как «активные мужчины 30+ с доходом выше среднего». Здоровье и физическое состояние у всех разное, плюс у всех разные вкусы, способности, привычки и к тому же все эти факторы постоянно меняются.

Справиться с неоднородностью ЦА можно двумя способами. Один из вариантов — создавать максимально кастомизированные сервисы, например, для людей определенной социальной прослойки, которые борются с депрессией.

READ MORE  Как реализовать сложные «хотелки» на проектах?

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

разработка медицинских приложенийПриложение для тренеров FitForce

​В фитнес-приложении FitForce мы реализовали функционал, который дал тренерам возможность составлять свою собственную систему тренировок и обновлять ее в реальном времени.

5. Понятные пользовательские сценарии

Согласно статистике, пользователь предпримет максимум три попытки, чтобы разобраться в приложении. Если у него не получится зарегистрироваться, записаться к врачу или получить рекомендацию, приложение с большой вероятностью отправится в корзину.

Чтобы этого не происходило, надо учитывать, что среди пользователей медицинских приложений — не только миллениалы, но и люди в возрасте 40+ и 50+. Однако даже если ваш сервис ориентирован на такую аудиторию, это не повод делать дизайн в стиле начала 2000-х

Как показывает практика, при разработке интерфейса стоит по-прежнему придерживаться принципов чистоты и минимализма. Но параллельно с этим необходимо добавлять всплывающие подсказки, которые объяснят пользователям принципы работы приложения.

Есть и другие способы упростить взаимодействие с приложением, например, сохранять историю действий, использовать ранее введенную информацию для уменьшения количества шагов в будущем.

разработка медицинских приложенийПриложение по доставке лекарств Saidali

Для этого приложения мы создали отдельную страницу профиля для хранения информации о привязанных картах, рецептах и популярных товарах.

READ MORE  Давай упрощай: как с помощью дизайна привлечь новичков в сложный мир инвестиций. Кейс Purrweb

Выводы

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

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

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

В-третьих, надо правильно распределять приоритеты. Это значит, что ни в коем случае нельзя экономить на дизайне, безопасности и тестировщиках. Зато, даже если у вас неограниченный бюджет, при запуске приложения можно сократить количество фич и не разоряться на дорогие технологии. Например, стартапам нет смысла делать нативное приложение: сейчас значительно вырос уровень кроссплатформенной разработки, поэтому пользователи даже не увидят разницы.