Риск «сделать фигню» есть в любых проектах, но именно в медицинских ставки чрезвычайно высоки: это здоровье и жизни людей. Интерфейс может как помогать врачам и пациентам, так и вводить их в заблуждение и даже повышать вероятность ошибки с непредсказуемыми последствиями. Как именно снизить риски и на что нужно обратить внимание при создании интерфейса медицинской системы — рассказываем в этой статье.
Откуда экспертиза
Все, о чем мы пишем, основано на нашем практическом опыте. В цифрах это 23 проекта по медицинской тематике и 117 интервью с врачами и пациентами.
Под медицинскими интерфейсами мы подразумеваем следующие системы:
- МИС (медицинские информационные системы).
- Экраны медицинского оборудования.
- Личные кабинеты врачей и пациентов.
- Дашборды главврачей.
- АРМ (автоматизированные рабочие места) линейного персонала.
- Мобильные приложения medTech-компаний.
Специфика, о которой пойдет речь, проявляется в первую очередь на аналитической фазе — сборе бизнес-требований и пользовательской аналитики. Но есть и сквозные аспекты, про которые нужно помнить на всех этапах.
Пациенты не любят говорить о болезни
Когда мы исследуем опыт пациентов, мы касаемся очень личных и болезненных вопросов.
- Взаимоотношение человека с собственным телом.
- Социальные установки по поводу того или иного заболевания.
- Границы ответственности за свое здоровье.
- Стигматизация отдельных медицинских тем в обществе.
На эти темы в нашем обществе не принято общаться с незнакомцами. Чем более интимную или сигматизированную область мы исследуем, тем сложнее получить релевантную информацию, и тем важнее этическая составляющая дизайна исследования.
Вопросы не должны объективировать или инвалидизировать человека. Например, вопрос: «Как вы выживаете с диабетом?» априори некорректен в своей формулировке. Человек может вообще не находиться в состоянии выживания, а прекрасно жить и иметь совершенно другой взгляд на заболевание.
Как мы решаем эту задачу
Общение с пациентами нельзя доверять менеджеру, прочитавшему книгу «Спросите маму». У нас интервью проводят профессиональные социологи, способные в рамках соблюдения этических норм выяснить у пациентов важные для продукта или системы особенности.
Врачи скептически относятся к цифровизации
Врачи – это отдельная социальная группа со своей статусной системой, условиями входа, иерархией. Группа достаточно закрытая, и это уже мешает исследовать реальное, а не задекларированное поведения врача. К новым людям (а исследователь — это, безусловно, новый человек) они относятся настороженно.
Дело усложняется негативным опытом работы с разного рода цифровыми системами. Медики взаимодействуют с неудобными программами, которые каждый год обновляются, становятся хуже, добавляют бюрократической работы и мешают основной деятельности.
Как мы решаем эту задачу
Обратная сторона закрытости сообщества — готовность проактивно и безвозмездно помогать своим. У нас сложилась база лояльных врачей (как правило, это личные знакомые), готовых поделиться своей экспертизой или порекомендовать своих открытых к общению коллег.
Сложно строить гипотезы
В обычных проектах исследователи и дизайнеры часто отталкиваются от собственного опыта, опыта знакомых, коллег, родственников. Это позволяет сформировать первичные гипотезы и быстрее погрузиться в особенности конкретного продукта.
В случае с медицинскими проектами мы часто имеем дело с совершенно новым опытом, которого у команды попросту нет. И если опыт врачей можно более-менее переносить из проекта в проект, то у пациентов он существенно отличается в зависимости от характера заболевания, стажа болезни, возраста, размера населенного пункта и других параметров.
Как мы решаем эту задачу
Методологически — закладываем эту особенность на уровне гайда для интервью. Организационно — привлекаем внешних экспертов для верификации наших предположений.
Да, методика и эксперты хороши в любой теме, но именно здесь они критически важны, чтобы избежать существенных искажений.
Опыт врача и пациента сильно различается
Этот аспект наиболее явно проявляется при создании систем, объединяющих врача и пациента. Например, в экосистемах мониторинга, когда пациент сам или с помощью приборов вносит данные в приложение, врач анализирует эту информацию на приеме, ученый использует данные при написании статьи. Разные пользователи, разные цели и разные пути.
В более простых отраслях, например, в торговле, бизнес-процессы все-таки более-менее точно накладываются на поведение клиента, и проблемы возникают лишь в отдельных точках. В медицине же мы имеем дело с радикально разными процессами, которые друг на друга не похожи и друг из друга не следуют.
В системах, где основной пользователь врач, ситуация еще сложнее. Пациент присутствует как конечный клиент, но при этом не взаимодействует с системой напрямую и никак не может на нее повлиять.
Как мы решаем эту задачу
Мы проектируем два принципиально разных интерфейса для врача и для пациента, основанных на принципиально разных сценариях. В процессе проработки сценариев неизбежно всплывают конфликты интересов, которые мы стараемся в интерфейсе разрешить.
В случае сугубо врачебных систем мы скорее находимся на стороне врача в силу сильной зарегулированности всего, что связано с медициной. Это не значит, что мы вообще не учитываем интересы пациента, мы смотрим на них через вопрос «как помочь замотивированному врачу лучше учитывать интересы пациента».
Врач хочет заниматься лечением, а не изучением программы
Обычная профессиональная система (например, CRM) рассчитана на сравнительно недорогих специалистов, которых обучают работе в этой системе. Не хочешь обучаться — профнепригоден. С врачами ситуация сложнее.
Врач сам по себе — дорогой специалист, и его ключевой навык вовсе не скорость работы за компьютером и знание той или иной программы. При этом уровень технической грамотности хорошего врача вовсе не обязан быть высоким.
Как мы решаем эту задачу
Чтобы сделать сложную функциональную и информационно насыщенную систему сравнительно простой, мы привлекаем врачей не только к тестированию прототипов, но и к экспертной оценке. Врач становится соавтором дизайна, в явном виде сообщая, какие из возможных интерфейсных решений решений в медицине общепонятны и активно используются.
Работа врача строго регламентирована
Очевидный аспект, но существенно влияющий на процесс создания интерфейса медицинской системы. Нормы, регламенты, стандарты, законы — огромное количество формализованных требований, которые должны быть отражены в интерфейсе, и на которые невозможно повлиять.
Сами по себе процессы — объемные, сложные, нелинейные. Часто мы даже имеем дело с двумя сценариями: непосредственные действия врача при работе с пациентом или его историей болезни и действия, связанные с соблюдением всех норм и требований.
В обычных проектах мы можем сказать «давайте здесь упростим, а тут поменяем бизнес-процесс». В медицинских проектах чаще всего это невозможно. В основе медицинской системы всегда лежит четкий процесс, заданный нормативными документами. С одной стороны это упрощает проектирование, оцифровывать существующий процесс всегда проще. С другой — существенно усложняет нам задачу сделать инструмент удобным.
Как мы решаем эту задачу
На этапе аналитики тратим много времени, чтобы досконально разобраться в процессах и требованиях. При проектировании смещаем фокус со сценария, заданного регламентом, на работу с отдельными экранами, микросценариями и UI, и через них упрощаем взаимодействие врача с системой. И, конечно, постоянно сверяем промежуточные результаты с экспертами-практиками.
Пользователь находится в стрессовом состоянии
Речь, конечно, не про любую медицинскую систему, но фактор стресса проявляется достаточно часто.
Применительно к пациентам — речь про состояние плохого самочувствия, затуманенного сознания, невозможности сконцентрироваться на задаче.
В случае с врачами — использование системы в экстренных ситуациях или в процессе выполнения работы, требующей соcредоточенного напряжения.
И для тех и для других свойственна боязнь совершить ошибку. Для пациента это больше технический аспект (вдруг я что-то сделаю и все сломается, а прибор дорогой, а врач не то подумает). Для врача — наказание за совершенную ошибку или невыполнение какого-то регламентного действия.
Как мы решаем эту задачу
При внутренней экспертизе интерфейса задаемся вопросом «в каком состоянии будет пользователь и как это влияет на интерфейс». Например, состояние может накладывать требования к размеру UI-элементов и шрифта, контрастности, отсутствию «интерфейсного мусора». Последнее — хоть и очевидная практика, но на деле очень сложно подчинить эстетику продукта задачам кризисного взаимодействия.
У врачей повышенные информационные требования
Система, которая оцифровывает существующий регламент, бесполезна для врача и законно воспринимается им как неизбежная бюрократия. Врачу нужно не по шагам пройти, а добыть важную информацию, которая поможет принять решение. Идеальный сценарий в упрощенном виде выглядит так.
- Вытащить из системы информацию.
- Отсортировать, убрать лишнее, сгруппировать, отфильтровать.
- Сфокусироваться на важном.
- Принять решение на основе этой информации.
Именно врачи часто описывают такое взаимодействие с системой, в других отраслях такой запрос у конечных пользователей встречается крайне редко.
Как мы решаем эту задачу
Вместе с врачами мы находим в интерфейсе точки принятия решения и определяем, какая информация здесь необходима. После этого работаем над визуализацией информации, чтобы она считывалась достаточно быстро и удобно.
Заключение
Такое внимание к аспектам проектирование медицинских систем обусловлено не только сложностью тематики, но и тем, что пока эти самые системы по качеству интерфейсов заметно отстают от того, что мы привыкли считать стандартами профессиональных систем. Надеемся, что наши наблюдения помогут и другим разработчикам исправить это досадное недоразумение.
А еще подписывайтесь на наш телеграм-канал Собака лает. Там тоже бывает интересно.