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

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

В закладки
Аудио

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

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

Предыстория

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

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

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

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

Шаг 1. Выясняем боль пользователей

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

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

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

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

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

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

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

Шаг 2. Разбираемся в пользовательских привычках

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

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

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

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

Шаг 3. Узнаем технические нюансы

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

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

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

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

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

Шаг 4. Формулируем пользовательские сценарии

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

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

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

Шаг 5. Проектируем зоны внимания

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

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

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

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

Шаг 6. Избавляемся от лишнего

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

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

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

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

Шаг 7. Адаптируем к сенсорному экрану

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

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

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

Алексей Нибо
арт-директор digital-агентства «Атвинта»

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

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

Результат

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

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

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Digital-агентство Атвинта", "author_type": "self", "tags": [], "comments": 8, "likes": 22, "favorites": 61, "is_advertisement": false, "subsite_label": "design", "id": 108060, "is_wide": false, "is_ugc": true, "date": "Thu, 20 Feb 2020 10:20:33 +0300", "is_special": false }
0
8 комментариев
Популярные
По порядку
Написать комментарий...
4

"Перелом мизинца задней левой ноги"
Это точно приложение для врачей, а не для ветеринаров? 

Ответить
0

Нашли пасхалку :)

Ответить
0

для врачей-ветеринаров же.

Ответить
1

... и получился сайт =/

Ответить
1

какого размера должен быть планшет, чтобы читать этот текст

Ответить
0

Вот тут есть кнопочка на этот случай видимо

Ответить
0

хуейс

Ответить
0

Более перспективно, чтобы Гугл или Яндекс, имея поисковики, создали приложение-врач. Имел обращения к врачам, 90%, результат ноль.

Ответить

Прямой эфир