Пациент открывает личный кабинет после визита к врачу. Интерфейс загружается быстро, меню очевидно, кнопки понятны. Минуту спустя он закрывает вкладку — не найдя ни объяснения результата анализа, ни ответа на вопрос, который держал в голове всю дорогу домой.
Интересно, что этот сценарий задокументирован количественно. [Nissinen et al. 2025] опросили 2 545 пользователей пациентских порталов: 75% оценили их как лёгкие в освоении. Лишь 35% нашли в них достаточный обзор состояния здоровья. Исследование зафиксировало главное: юзабилити и полезность — статистически независимые переменные. Рост первой не влечёт роста второй.
Дизайн-система, соответствующая всем стандартам, может производить интерфейсы, в которых пользователь поймёт навигацию — и уйдёт ни с чем.
Подобный разрыв — не исключение, он устойчив. И объясняется не ошибками проектирования, а более глубокими свойствами медицинского контекста: здесь удобство необходимо, но недостаточно.
Сложность появляется сразу с трёх сторон. Первая: контекст использования медицинских интерфейсов не воспроизводится в лаборатории — стресс, прерывания и физические ограничения присутствуют одновременно, пользователь на тесте и пользователь у врача — разные люди [Hanno Digital Health Playbook]. Вторая: плохой интерфейс в здравоохранении не наказывается уходом — он наказывается ошибками; 89% медицинских ошибок связаны с дизайном интерфейса [Kiess. 2017]. Третья: данные об эффективности медицинских приложений собраны на тех, кто остался: 70% уходят за первые 100 дней, и клинические данные описывают оставшихся 30% [Kidman. 2024] (n=525 824).
Как проектировать медицинские интерфейсы, которые отвечают на вопросы, с которыми к ним приходят, — в условиях, когда контекст непредсказуем, рыночный механизм не работает, а показатели удобства не отражают показатели пользы?
Юзабилити и полезность — не одно и то же
Когда 75% пользователей оценивают продукт как удобный — это хорошая новость. Проблема в том, что она ничего не говорит об остальном.
[Nissinen et al. 2025] пошли дальше фиксации разрыва — они установили статистическую независимость двух измерений. Удовлетворённость предсказывает оба измерения (η²≈0.19), но само по себе высокое юзабилити не предсказывает высокую полезность. Портал может быть образцово удобным и при этом не отвечать ни на один вопрос, с которым пациент туда пришёл.
Авторы указывают на причину, которая лежит глубже дизайна: медицинские записи изначально не проектировались для пациента. Портал показывает то, что есть в системе, — а не то, что нужно пользователю. Это проблема серверной части и клинических процессов, которую нельзя решить инструментами интерфейса.
Nordhealth [Nord Design System] формулирует иначе: критерий качества каждого компонента — не «интуитивно ли это?», а «не прерывает ли рабочий поток?» Для пациентского портала это тот же сдвиг: не «понятно ли устроена навигация», а «находит ли пациент то, за чем пришёл». Doctolib [Oxygen] идёт дальше: маркетинговая страница клиники и интерфейс медицинского решения имеют принципиально разные стандарты качества. Акционный баннер «достаточно хорош» при неидеальной вёрстке; форма сбора анамнеза — нет.
Нужный вопрос — не «легко ли пользоваться нашим продуктом?». Нужный вопрос — «находит ли пациент то, за чем пришёл?»
Кроме того: ответственность на стороне интерфейса, не пациента
Трудности с медицинскими интерфейсами принято объяснять недостаточной грамотностью пользователей. [Paasche-Orlow & Wolf. 2007] оспаривают этот взгляд.
Медицинская грамотность, по их модели, — не личная характеристика пациента, а свойство взаимодействия между пациентом и системой. Один и тот же человек ориентируется в понятном интерфейсе и теряется в запутанном. Улучшение коммуникации на стороне интерфейса даёт больший эффект на здоровье пациента, чем программы повышения его грамотности. Ответственность находится на стороне системы.
По данным [NAAL/NCES. 2006], лишь 12% взрослых американцев обладают достаточным уровнем медицинской грамотности; 36% не справляются с базовыми медицинскими задачами. Пожилые (65+) сталкиваются с наибольшими барьерами при работе с медицинским текстом среди всех возрастных групп — при том что являются основными потребителями медицинских услуг. Дизайн, оптимизированный под «среднего пользователя», системно исключает именно ту группу, для которой ставки наиболее высоки.
NHS Design System переводит это в конкретный принцип: «один вопрос на страницу» — не про количество полей, а про количество решений. Пациент в состоянии стресса не способен принимать несколько решений подряд в одном контексте. Это клиническое требование, а не дизайн-правило. Форма с 14 полями нарушает его системно. NHS поддерживает словарь медицинских терминов с 2004 года — около трети взрослых испытывают затруднения со стандартным медицинским текстом [NAAL. 2006].
На практике: контекст использования — не лаборатория
Большинство UX-исследований фиксируют то, что пользователь говорит о своём опыте в спокойной обстановке. Медицинский пользователь работает в состоянии, которое само по себе является экспериментальной переменной.
Hanno Digital Health Playbook описывает пять слоёв контекста — сенсорный, моторный, технический, когнитивный, процедурный, — которые в медицинском интерфейсе присутствуют одновременно. Потребительский дизайн работает, как правило, с двумя-тремя из них.
Это не абстрактная классификация — она работает для любого медицинского интерфейса. Клинические системы для врача проявляют её наиболее наглядно: GE Healthcare [Ethos Design System] проектирует под конкретные физические условия: мультимодальный ввод (мышь + клавиатура + тач + голос) — для врача в перчатках; отдельная палитра освещённости — для УЗИ-кабинета и операционной, где потребительский дизайн не работает. Постоянная идентификация пациента в шапке (ФИО + дата рождения + ID) — ответ на ошибку идентификации: переключение между пациентами незаметно для интерфейса, но не для врача.
Nordhealth [Nord] проектирует для другого ритма: контурная загрузка вместо спиннера сохраняет когнитивный контекст при ожидании; боковая панель вместо модального окна — место в списке пациентов; три плотности отображения таблиц — потому что врач в хирургии и врач в поликлинике работают в разном темпе и с разным вниманием.
Процедурный слой — клинические протоколы, регламенты, порядок действий — часто невидим дизайнеру, но именно он определяет, осуществим ли предлагаемый UX-поток в реальной практике. Контекстный анализ не заменяется интервью: пять слоёв выявляются наблюдением, а не вопросами «удобно ли вам?»
Более того: ставки
Привычный аргумент: пользователи всё равно научатся, если продукт работает. Данные указывают в другую сторону.
[Kiess. 2017] проанализировал 228 задокументированных случаев медицинских ошибок, часть из которых привела к летальным исходам: 89% связаны с дизайном интерфейса, 51% — непосредственно с UX-проблемами. Ключевой контекст — вынужденное использование. Врач не выбирает МИС, пациент не выбирает интерфейс клиники. Это лишает плохой продукт рыночного сигнала о провале. Плохой интерфейс живёт годами — не потому что незаметен, а потому что у пользователя нет выбора.
[Kidman et al. 2024] задокументировали масштаб отказов: мета-анализ 18 рандомизированных контролируемых исследований (n=525 824) показывает — 70% пользователей уходят за первые 100 дней. Кривая нелинейна: крутой обрыв → плато → второй спад на 60–90-й день, когда новизна исчезла, но привычка не сформировалась. Большинство клинических данных об эффективности — о 30%, которые остались. Это смещение выборки (selection bias), искажающее всю доказательную базу цифрового здравоохранения. UX-проблемы — единственная категория причин отказа, присутствующая как устойчивый предиктор во всех изученных приложениях.
[van der Mee et al. 2024] описывают момент, когда пациент уже получил данные — но интерпретировать не смог. Числовой формат результатов анализов без визуального контекста провоцирует обращение к поисковикам в 2.3 раза чаще — и приводит к ошибочным выводам. Горизонтальная шкала с якорями опасности («при значении выше X — обратитесь к врачу») закрывает эту проблему, причём нивелирует разрыв между группами с разным уровнем грамотности.
Однако
Сделать портал полезным — ещё не решение.
[Paasche-Orlow & Wolf. 2007] указывают на ограничение, которое лежит за пределами интерфейса: люди с наиболее низкой медицинской грамотностью систематически избегают медицинской информации из любых источников — включая понятные и полезные порталы [NAAL. 2006]. Те, кому информация нужна больше всего, в портал не заходят. Нужен не лучший контент, а иная точка контакта.
Портал ограничен тем, что в нём есть. Медицинские записи создавались как клинические документы для провайдеров, а не как информация для пациента. Это инфраструктурное ограничение — оно не закрывается инструментами UX.
Наконец, массовое удержание — не всегда правильная цель. [Kidman et al. 2024] сами отмечают: даже при 70% оттоке оставшиеся 30% демонстрируют клинический эффект. Некоторые приложения проектируются для высокомотивированных пользователей с хроническими состояниями, где удержание 30% приемлемо. Метрика удержания требует контекста — она не универсальный диагностический инструмент.
На практике
Пять действий, применимых без дополнительного чтения.
Измерять полезность отдельно от удобства. На выходе из каждого ключевого сценария добавить вопрос: «Нашли ли вы то, за чем пришли?» — и отслеживать его отдельно от CSAT и SUS. Продукт, где 75% отвечают «легко» на первый вопрос и 35% на второй, — это диагноз, а не загадка.
Проверить читаемость критичных текстов. Диагнозы, инструкции, результаты анализов — прогнать через Flesch-Kincaid. Цель: уровень не выше 6-го класса. Числовые результаты анализов заменить горизонтальной шкалой с якорями опасности [van der Mee. 2024].
Провести контекстное наблюдение. Не интервью — наблюдение в реальной среде: кабинет врача, зона ожидания, дом пациента после приёма. Фиксировать прерывания, переключения, физические ограничения. Вопросы «удобно ли вам?» наблюдения не заменяют.
Отслеживать удержание на 14-й и 90-й день как отдельные диагностические точки, а не как производственную метрику. Первый отсев — проблема начального этапа (онбординга); второй спад (60–90-й день) — разрыв формирования привычки. Разные причины требуют разных вмешательств [Kidman. 2024].
Применить GROSS-протокол [Joseph & Pagani. 2024]: первую неделю аудита посвятить удалению подтверждённо ненужного, а не добавлению нового. В клинических системах, перегруженных устаревшим функционалом, это единственный путь к улучшению без добавления новой сложности поверх старой. Каждый удалённый элемент — с обоснованием и проверкой на регуляторное требование (152-ФЗ / Приказ Минздрава РФ).
Три четверти. Треть.
Три четверти пациентов считают свой портал удобным. Это хорошая новость. Плохая — в том, что эта цифра ничего не говорит о пользе. [Nissinen et al. 2025] зафиксировали: юзабилити и полезность статистически независимы — высокое юзабилити не предсказывает высокую полезность. Значит, каждая организация, оптимизировавшая NPS и SUS, могла двигаться в правильном направлении по неправильной карте.
Медицинский интерфейс — это контекст, где ставки определяются не оттоком, а ошибками; где рыночный сигнал не работает; где грамотность пациента — не его свойство, а свойство системы, с которой он взаимодействует.
Нужный вопрос — не «легко ли пользоваться нашим продуктом?». Нужный вопрос — «находит ли пациент то, за чем пришёл?»
Полный гайдлайн
Статья описывает логику. Детальный разбор — рабочий инструмент для аудита или исследования конкретного продукта.
В полном гайдлайне — паспорт аудита и граница эффективности/грамотности, инвентаризация экранов, матрица из 22 паттернов, протоколы контекстного наблюдения и юзабилити-теста с пациентами, 7 справочных инструментов и аннотированная библиография 10 источников.
Если нужно оценить продукт без пользователей:
- Паспорт аудита и граница Э/Г — что проверяется экспертно, что требует теста с пользователями
- Инвентаризация экранов с классификацией по контексту (стресс / ставки / срочность)
- Блок оценки по 22 паттернам матрицы применимости
- Реестр находок с Э/Г-классификацией и приоритетом
- Сводка для стейкхолдеров с аргументами на языке продуктового риска
Если нужно провести исследование с пациентами:
- Матрица методов: конструкт → метод → когда применять → ограничение
- Протокол контекстного наблюдения: пять слоёв, что фиксировать, N участников
- Протокол юзабилити-теста с правилами деликатного контекста
- Кодировочная рамка: USF / CTX / LIT / CON / AI — коды с поведенческими маркерами
Справочные инструменты:
- Диагностический чеклист: 5 критичных проверок за один день без участников
- Арсенал зондов для работы с пациентами вместо вопросов «почему»
- Переводной слой: теоретический конструкт → аргумент для PM