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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

______________________________________________________________________________

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

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