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

Агентство Purrweb уже более пяти лет занимается разработкой приложений на зарубежный рынок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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