Интерфейс приложения с инструкциями для медиков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Ситуация на сегодняшний день сложнее, чем я ожидал: алгоритмы требуют приличной переработки для телефонного интерфейса. Диагностический алгоритм прям сильно меняется, лечебные в меньшей степени, но тоже прилично. За этим будет согласование с профессорами и прочие проверки самой логики алгоритмов. То есть почти все сначала.»

Другие кейсы