Проектирование сценариев записи на приём в мобильном приложении
Не все сценарии переживают тестирование — как я пересмотрела архитектуру приложения после UX-тестов
Контекст
Dental Care — сеть из 5 стоматологических клиник
Основой канал записи — телефон или форма обратной связи
Основой канал записи — телефон или форма обратной связи
Проблемы
— Высокий процент пропущенных визитов, потеря записей
— Зависимость от администраторов при записи
— Отсутствие удобного способа самостоятельно записаться и управлять визитом
— Трудности при выборе врача или клиники без дополнительной консультации
— Потеря пациентов после первого визита
Цель и миссия
Бизнес-цель: снизить потери из-за неявок и увеличить долю самостоятельных записей
Миссия для пользователя: cделать запись на приём быстрой, понятной и доступной без участия администратора
Задача
Моей задачей было спроектировать концепцию мобильного приложения, которое упростит процесс записи на приём.
Dental
Care
Care
Дискавери
Анализ конкурентов
Для погружения в тематику изучила прямых и косвенных конкурентов, сосредоточившись на сценариях записи, странице врача, главном экране, работе с напоминаниями и UI решениях.
Собрала скринфлоу записи на приём, управления записями и вынесла данные в сравнительную таблицу.
Вводы
Простота сценария
В большинстве приложений записаться на приём можно за 4 шага.
Фокус на ключевом действии
Чаще всего главный экран ориентирован на основную задачу — запись, без перегрузки второстепенной информацией.
Доступность важной информации
Напоминая о визите и данные о враче видны сразу на главном экране, без дополнительных действий.
Гибкость старта записи
Возможность начать запись с выбора специальности врача, клиники или услуги адаптирует процесс под пользователя.
Поиск — универсальный инструмент
В большинстве рассмотренных приложениях есть функция поиска врача. услуг, клиники.
Гипотезы
На основе анализа конкурентов и бизнес целей сформулировала UX-гипотезы, напрямую влияющие на конверсию в запись и снижение количества пропущенных визитов.
1.
Быстрый старт записи через категории
Если разместить категории специалистов на главном экране, пользователь сможет быстрее начать запись и сократить количество шагов до целевого действия.
Если разместить категории специалистов на главном экране, пользователь сможет быстрее начать запись и сократить количество шагов до целевого действия.
2.
Отображение ближайшего визита
Если показывать информацию о ближайшем визите на главном экране, пользователь будет лучше помнить о записи, что снизит количество пропущенных визитов (no-show).
Если показывать информацию о ближайшем визите на главном экране, пользователь будет лучше помнить о записи, что снизит количество пропущенных визитов (no-show).
3.
Несколько точек входа в запись
Если предложить разные способы начала записи (категории, поиск, выбор клиники), пользователь сможет выбрать наиболее удобный сценарий, что снизит количество ошибок и повысит конверсию.
Если предложить разные способы начала записи (категории, поиск, выбор клиники), пользователь сможет выбрать наиболее удобный сценарий, что снизит количество ошибок и повысит конверсию.
4.
Выбор врача через поиск
Если добавить поиск врача на главный экран и в раздел записи, пользователь быстрее находит нужного специалиста, и не перегружается лишней информацией, что сокращает время до записи и повышает конверсию.
Если добавить поиск врача на главный экран и в раздел записи, пользователь быстрее находит нужного специалиста, и не перегружается лишней информацией, что сокращает время до записи и повышает конверсию.
5.
Запись ребёнка через отдельный сценарий
Если запись ребёнка начинается с выбора детской специализации, то это снижает риск ошибки и упрощает сценарий записи для родителей.
Если запись ребёнка начинается с выбора детской специализации, то это снижает риск ошибки и упрощает сценарий записи для родителей.
6.
Выбор врача после специализации
Если после выбора специальности показывать список врачей, а не услуг, то сценарий будет соответствовать ожиданиям пользователей, что снизит количество ошибок и отказов на этапе записи.
Если после выбора специальности показывать список врачей, а не услуг, то сценарий будет соответствовать ожиданиям пользователей, что снизит количество ошибок и отказов на этапе записи.
7.
Выбор клиники — точка входа
Если сделать выбор клиники первым шагом записи при ориентации на локацию, то пользователь быстрее примет решение в сценариях, где важна география.
Если сделать выбор клиники первым шагом записи при ориентации на локацию, то пользователь быстрее примет решение в сценариях, где важна география.
8.
Управление записью
Если дать возможность легко перенести или отменить визит, это снизит количество пропущенных записей и повысит контроль пользователя над процессом.
Если дать возможность легко перенести или отменить визит, это снизит количество пропущенных записей и повысит контроль пользователя над процессом.
Проектирование
На основе сформулированных гипотез я спроектировала ключевые сценарии и архитектуру приложения. При проектировании я старалась сократить путь пользователя и учесть разные модели поведения.
Сценарий № 1: Запись через категории
Решение
На главном экране размещены категории специалистов, чтобы пользователь мог быстро начать запись.
После выбора категории попадает в список врачей с доступными слотами, где можно уточнить выбор с помощью фильтров
После выбора категории попадает в список врачей с доступными слотами, где можно уточнить выбор с помощью фильтров
Почему так
Это сокращает путь до записи и уменьшает количество шагов, соответствует привычной модели выбора: от категории к врачу
Флоу
Главная
Категории
Врачи
Дата и временя
Подтверждение
Сценарий №2: Запись через поиск
Решение
Поиск доступен на главном экране и экране записи как альтернативный вод в сценарий для пользователей с конкретным запросом (ФИО врача)
Почему так
Поиск позволяет пропустить этап выбора категории и и сразу перейти к нужному врачу, сокращая путь до записи для опытных пользователей
Флоу
Главная
Поиск
Врач
Дата и временя
Подтверждение
Сценарий № 3: Запись через клинику
Решение
Раздел «Запись» позволяет начать сценарий с выбора клиники, выступая альтернативной точкой входа для пользователей, ориентированных на локацию
Почему так
Раздел «Запись» позволяет начать сценарий с выбора клиники, выступая альтернативной точкой входа для пользователей, ориентированных на локацию
Флоу
Запись
Клиника
Специальность
Врачи
Дата и время
Подтверждение
Сценарий № 4: Отмена/перенос записи
Решение
Информация о ближайшем визите вынесена на главный экран и даёт быстрый доступ к действиям — переносу или отмене записи
Почему так
Пользователь видит запись заранее и может управлять ей в один клик, что снижает вероятность забытых визитов и позволяет заменить неявку переносом
Флоу
Главная
Напоминание о записи
Отмена / Перенос
Подтверждение
Сценарий № 5: Запись на приём ребёнка
Решение
В категориях выделена детская стоматология как отдельный вход в сценарий, после чего пользователь может выбрать или добавить ребёнка как пациента
Почему так
Запись за другого человека — отдельный пользовательский сценарий. Выделение детской специализации помогает сразу задать правильный контекст, а выбор пациента снижает риск ошибки и упрощает процесс для родителей
Флоу
Главная
Категория
Пациент
Врачи
Дата и время
Подтверждение
Результаты тестирования
Провела модерируемое UX-тестирование, в котором приняли участие 10 респондентов
Запись через категории
8/10 пользователей начинали запись через категории:
— категории работают как основной сценарий старта
— главный экран работает как точка входа
— категории работают как основной сценарий старта
— главный экран работает как точка входа
7/10 респондентов использовали фильтры, но иногда требовались уточнения
— сценарий работает, но требует дополнительных исследований
— сценарий работает, но требует дополнительных исследований
Запись через поиск
10/10 респондентов использовали поиск:
— основной быстрый сценарий
— используется для поиска врача, клиники и услуг
— основной быстрый сценарий
— используется для поиска врача, клиники и услуг
Запись через клинику
10/10 пользователей выберут клинику первым шагом, однако:
— большинство искали кинику через поиск
— раздел «Запись» не воспринимался как точка входа
— несколько человек использовали карты
— большинство искали кинику через поиск
— раздел «Запись» не воспринимался как точка входа
— несколько человек использовали карты
Отмена/перенос записи
9-10/10 пользователей успешно переносили и отменяли запись:
— сценарии управления записью понятны и не вызывают затруднений
— сценарии управления записью понятны и не вызывают затруднений
Запись на приём ребёнка
7/10 использовали категорию «Детская стоматология», но:
— часть респондентов пыталась добавить ребёнка заранее — на первом шаге записи
— некоторые искали детскую стоматологию через поиск или в категориях других специалистов
— часть респондентов пыталась добавить ребёнка заранее — на первом шаге записи
— некоторые искали детскую стоматологию через поиск или в категориях других специалистов
Выводы:
1.
Главный экран работает как старт для записи
2.
Логика записи на приём через категорию врача и специалиста понятна для респондентов как при записи себя, так и ребенка
3.
Поиск — привычный для пользователя паттерн, с его помощью искали и врача и клинику и услуги
4.
Раздел «Запись» провалился как точка входа, почти никто его не использовал для старта записи, часто воспринимался как история визитов
5.
В раздел «Запись» не идут за клиникой, её либо ищут через поиск, либо уходят в карты
Изменения после тестирования
- Пересобрала архитектуру сценариев
Отказалась от использования раздела «Запись» как точки входа, так как пользователи не воспринимали его для старта.
Информацию о клиниках перенесла на главный экран, усилив его как основную точку взаимодействия.
Информацию о клиниках перенесла на главный экран, усилив его как основную точку взаимодействия.
2. Усилила сценарий поиска
Добавила в поиск более точный текст, чтобы задать пользователю модель для поиска и снизить неопределенность
3. Добавила выбор клиники через карту
Реализовала просмотр клиник на карте с возможностью переключения между списком и картой — это позволяет пользователям выбирать локацию внутри приложения, не переходя в сторонние сервисы.
Для быстрого просмотра информации о клинике на карте, звонка, построения маршрута и записи по заданному адресу спроектировала несколько новых экранов
Для быстрого просмотра информации о клинике на карте, звонка, построения маршрута и записи по заданному адресу спроектировала несколько новых экранов
Выводы
1.
Пользователи начинают запись разными способами: через категории, поиск или выбор клиники по локации. Единой точки входа в сценарий записи не существует;
2.
Поиск воспринимается как универсальный инструмент и используется даже при наличии альтернативных путей;
3.
При выборе клиники ключевым фактором является удобство расположения, поэтому пользователи склонны обращаться к картам и внешним сервисам;
4.
Главный экран выполняет роль центра управления визитами и ключевой точки взаимодействия
5.
Проверка гипотез на раннем этапе позволила выявить неэффективный сценарий через раздел «Запись» и скорректировать архитектуру приложения
Планы по развитию:
— дополнительно протестировать фильтры;
— добавить управление профилем ребёнка через аккаунт пользователя;
— продолжить работу над разделами чата и профиля пользователя;
— усилить сценарий выбора клиники через карту.
— добавить управление профилем ребёнка через аккаунт пользователя;
— продолжить работу над разделами чата и профиля пользователя;
— усилить сценарий выбора клиники через карту.
Что не стала менять и почему
Фильтры
Во время тестов часть респондентов замечала фильтры, но использовала их нерегулярно и чаще после уточнения задач.
Так как сценарии с фильтрацией не были ключевыми в тестировании, я решила не вносить изменения на этом этапе и оставить их для дополнительной проверки.
Так как сценарии с фильтрацией не были ключевыми в тестировании, я решила не вносить изменения на этом этапе и оставить их для дополнительной проверки.
Детская стоматология
Часть пользователей ожидала возможность заранее добавить ребёнка в профиле. При этом основной сценарий записи через категорию «Детская стоматология» с добавлением ребёнка на втором шаге оказался понятным и рабочим, поэтому он был сохранён.
