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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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