Приложение для врачей с руководством по экстренной помощи

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

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

Совсем иначе выглядит экстренная ситуация в условиях, например, стоматологического кабинета. Пациент внезапно теряет сознание. Что делать? Что-то рассказывали на семинаре в прошлом месяце, что-то вспоминается из вузовских лекций, что-то — из рассказов коллег. Проблема в том, что вспоминать некогда, надо действовать прямо сейчас. И все это в условиях высочайшего стресса.

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

Задача заказчика

Наш заказчик создал систему #ALGOHELP — набор нелинейных инструкций для оказания экстренной первой помощи. Система состоит из диагностического плаката, шестнадцати алгоритмов и маркировки для препаратов.   

Автор — Антон Борисович Бичун, анестезиолог-реаниматолог с 18-летним опытом, к.м.н., доцент СЗГМУ им. И. И. Мечникова. В основе всего — национальные клинические протоколы, экспертиза Антона Борисовича и его коллег.

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

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

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

Похоже на наш любимый дизайн-процесс, не так ли?

Дизайн-задача

Итак, сейчас #ALGOHELP — это офлайновый B2B-продукт для стоматологических клиник. И с этим продуктом все хорошо. Авторы видели его развитие через превращение в мобильное приложение B2C, рассчитанное на широкий круг потребителей-медиков. Например, на врачей-косметологов и школьных медсестер.

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

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

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

А вот сможет ли такое приложение выполнить главную функцию — снизить время оказания экстренной помощи — это вопрос.

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

Тогда мы задались основными сценариями и пошли проектировать.

Так выглядит алгоритм на бумаге. Целиком показать его не можем, но принцип, надеемся, понятен

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

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

Почему? Потому что на скорость и качество восприятие информации влияет примерно всё: цвет, шрифт, размер иконок, навигационные паттерны. Вторая причина — алгоритм диагностики (то есть определение, что же случилось с пациентом) «в лоб» не переносился с формата плаката А3 на экран мобильного. Нужно думать.

Один из вариантов главного экрана приложения

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

Разные интерфейсные решения одних и тех же задач

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

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

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

Всю историю ответов приложение сохраняет в верхней части экрана

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

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

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

Во время реанимации у пациента может остановиться сердце. В таких ситуациях врач должен мгновенно переключиться на другой алгоритм. Мы вставили ссылку на него в нижнюю часть экрана

В мобильное приложение мы могли добавить голосовое сопровождение. Мнения о том, будет ли это вообще удобно, можно ли будет этим пользоваться, разделились. Но проверить, безусловно, стоит

Сперва это был просто плеер с полосой прогресса. Только зачем видеть прогресс? Убрали. Потом поняли, что нажимать на каждом шаге на кнопку «Плей» — так себе решение, и сделали автоматическое воспроизведение. Только что делать человеку, если он не хочет слушать аудиоинструкции? Нажать «Стоп»? Не успеет — там всего одна-две фразы. Поэтому мы убрали обе кнопки (или одну в двух состояниях) и заменили их на «Выключить звук». А рядом поставили «Повторить заново» — для тех, кто хочет слушать аудиоинструкции.

Ищем решение для плеера

Все основные экраны и логику мы проработали достаточно, чтобы начать тестирование.

Макеты готовы к тестированию

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

Или осознать, что работы оказалось в десять раз больше, выбросить и забыть.

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

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

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

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

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

Набор из шестнадцати бумажных алгоритмов умещается в небольшой сумочке

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