Специфика проектирования медицинских интерфейсов

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

Специфика проектирования медицинских интерфейсов

Откуда экспертиза

Все, о чем мы пишем, основано на нашем практическом опыте. В цифрах это 23 проекта по медицинской тематике и 117 интервью с врачами и пациентами.

Под медицинскими интерфейсами мы подразумеваем следующие системы:

  • МИС (медицинские информационные системы).
  • Экраны медицинского оборудования.
  • Личные кабинеты врачей и пациентов.
  • Дашборды главврачей.
  • АРМ (автоматизированные рабочие места) линейного персонала.
  • Мобильные приложения medTech-компаний.

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

Пациенты не любят говорить о болезни

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

  • Взаимоотношение человека с собственным телом.
  • Социальные установки по поводу того или иного заболевания.
  • Границы ответственности за свое здоровье.
  • Стигматизация отдельных медицинских тем в обществе.

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

Количественные данные из внешних источников тоже используем, но их недостаточно.
Количественные данные из внешних источников тоже используем, но их недостаточно.

Вопросы не должны объективировать или инвалидизировать человека. Например, вопрос: «Как вы выживаете с диабетом?» априори некорректен в своей формулировке. Человек может вообще не находиться в состоянии выживания, а прекрасно жить и иметь совершенно другой взгляд на заболевание.

Как мы решаем эту задачу

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

Врачи скептически относятся к цифровизации

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

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

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

Как мы решаем эту задачу

Обратная сторона закрытости сообщества — готовность проактивно и безвозмездно помогать своим. У нас сложилась база лояльных врачей (как правило, это личные знакомые), готовых поделиться своей экспертизой или порекомендовать своих открытых к общению коллег.

Сложно строить гипотезы

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

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

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

Как мы решаем эту задачу

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

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

Опыт врача и пациента сильно различается

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

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

Личный кабинет врача и мобильное приложение пациента — два разных интерфейса, объединенных общими данными.
Личный кабинет врача и мобильное приложение пациента — два разных интерфейса, объединенных общими данными.

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

Как мы решаем эту задачу

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

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

Врач хочет заниматься лечением, а не изучением программы

Обычная профессиональная система (например, CRM) рассчитана на сравнительно недорогих специалистов, которых обучают работе в этой системе. Не хочешь обучаться — профнепригоден. С врачами ситуация сложнее.

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

Дерево — не самое современное и удобное UI-решение, но это настолько привычный врачам паттерн, что они настояли именно на нем.
Дерево — не самое современное и удобное UI-решение, но это настолько привычный врачам паттерн, что они настояли именно на нем.

Как мы решаем эту задачу

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

Работа врача строго регламентирована

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

Сами по себе процессы — объемные, сложные, нелинейные. Часто мы даже имеем дело с двумя сценариями: непосредственные действия врача при работе с пациентом или его историей болезни и действия, связанные с соблюдением всех норм и требований.

Система автоматически считает расходные материалы, исходя из назначений. Это экономит уйму времени и избавляет от лишней бумажной работы.
Система автоматически считает расходные материалы, исходя из назначений. Это экономит уйму времени и избавляет от лишней бумажной работы.

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

Как мы решаем эту задачу

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

Пользователь находится в стрессовом состоянии

Речь, конечно, не про любую медицинскую систему, но фактор стресса проявляется достаточно часто.

Применительно к пациентам — речь про состояние плохого самочувствия, затуманенного сознания, невозможности сконцентрироваться на задаче.

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

Для врача-стоматолога диагностика состояния пациента, внезапно потерявшего сознание, — нетипичная стрессовая ситуация.
Для врача-стоматолога диагностика состояния пациента, внезапно потерявшего сознание, — нетипичная стрессовая ситуация.

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

Как мы решаем эту задачу

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

У врачей повышенные информационные требования

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

  • Вытащить из системы информацию.
  • Отсортировать, убрать лишнее, сгруппировать, отфильтровать.
  • Сфокусироваться на важном.
  • Принять решение на основе этой информации.

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

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

Как мы решаем эту задачу

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

Заключение

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

______________________________________________________________________________

Подписывайтесь на Telegram-канал.

Оригинал статьи опубликован на нашем сайте.

5656
34 комментария

Комментарий недоступен

9
Ответить

Ну неправда. Удобно? - Да. Наглядно? - Да. Минималистично? - Да.
В 2010 всё это выглядело бы сильно не так.

7
Ответить

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

Ответить

Очень интересно.

1
Ответить

Интересная статья. Спасибо

1
Ответить

Насчёт стрессового состояния… такие картинки даны и описание шока (сам врач) - никогда бы не копался в приложении когда у пациента шок
Будет намного легче, если врач после оказания помощи - просто выберет какой вид шока был, клинику и анализы
Нужно приложение которое показывает динамику и анамнез больного, а не ставит диагноз

1
Ответить

Это картинки из вполне конкретного кейса, когда заказчик хотел оцифровать уже существующие (и работающие) бумажные шпаргалки. Если коротко, то наша визуализация помогла заказчику осознать печальную мысль, что «в лоб» протоколы не перекладываются на мобильное приложение. Вот тут по ссылке вся история целиком: https://www.sobakapav.ru/portfolio/algohelp


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

Ответить