Кейс о дизайне планшетного приложения: снять скептицизм и расположить пользователей к продукту

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

Команда digital-агентства «Атвинта» рассказывает на примере планшетного приложения для участковых врачей, как разработать интерфейс продукта, который будет востребован.

К нам обратилась компания-разработчик, которая совместно с КОМИАЦ решила создать планшетную версию МИС для участковых врачей — тех, которые ездят к пациентам на дом.

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

Программа, на основе которой нужно разработать интерфейс приложения, выглядит так:

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

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

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

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

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

По итогам модерационной сессии были определены функции будущего приложения:

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

При проектировании пользовательских сценариев первым делом разобрались в привычной последовательности действий врачей на работе:

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

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

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

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

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

Функции приложения по способу хранения и передачи информации:

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

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

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

С поправкой на необходимость разделить получение информации из информационной системы больниц и передачу данных обратно мы составили такой сценарий приложения:

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

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

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

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

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

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

На этапе аналитики мы выяснили, какая информация хранится в МИС и чем из этого пользуются врачи ежедневно. Данных оказалось очень много, и мы задались вопросом: «А действительно ли вся информация, хранимая в МИС, нужна врачам, когда они направляются к пациенту на дом?».

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

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

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

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

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

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

Получился интерфейс, который учитывает пожелания, привычки и рабочие паттерны врачей. Продукт реализован и запущен в ряде больниц области.

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

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

Полный кейс.