Сайт для участников клинических исследований почему-то не привлекал участников клинических испытаний. Мы выяснили, что с ним не так.

Заказчик

Очередной кейс, в котором мы не можем назвать компанию-заказчика (и вовсе не потому, что подписали NDA). Жаль, потому что как раз в этом случае название очень даже важно — оно было и осталось серьезной проблемой.

Сейчас попробуем рассказать так, чтоб все стало понятно.

Проблема

У заказчика есть платформа для всех, кто связан с клиническими исследованиями: участников, врачей, спонсоров.

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

Теоретически.

На практике сайтом пользовались неохотно.

На него не приходили. А если приходили, то не регистрировались. А если регистрировались, то не находили врачей/пациентов, не общались с ним в чате, не договаривались об исследованиях.

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

Название

Самое время сказать, что платформа называлась… допустим, «МедДок».

Да, это выдуманное название. Но оно полностью соответствует реальному. И с ним что-то не так ровно настолько же.

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

Забегая вперед, скажем, что во время тестирования только один пользователь (и тот — сотрудник «МедДока») нашел сайт с первой попытки и без подсказок.

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

Процесс

Как обычно, вначале мы протестировали интерфейс сами. Наши дизайнеры задокументировали все найденные UX- и UI-ошибки и недостатки и все удачные решения.

Это важная часть UX-аудита, но не главная. Главная — пользовательское тестирование

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

Цели пользователей

Мы выделили четыре типа пользователей этого портала, которые преследуют четыре разные цели:

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

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

Как проходит тестирование

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

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

Успешность каждого шага оценивали в процентах:

• справился с заданием практически без проблем — 100%;
• столкнулся с проблемами, но выполнил задание самостоятельно — 50%;
• не справился с заданием — 0%.

Результаты тестирования

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

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

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

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

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

Критичная проблема личного кабинета: в нем не сохраняются исследования. И множество UX- и UI-недочетов помельче.

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

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

Неудача

А теперь о том, почему этот кейс — провальный.

Выглядит как отлично сделанная работа. Она и была сделана на отлично. Но есть одно «но», из-за которого этот кейс — провальный.

Заказчик хотел другого.

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

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

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

Ну, кстати, какое-то количество багов мы действительно задокументировали — чего ж не зафиксировать, если все равно нашли.

Но UX-тестирование — оно вообще не про баги и не про продуктовые решения. Оно про взаимодействие пользователя с интерфейсом.

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

Результат

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

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

UX-исследование не спасет проект, если заказчик не готов к изменениям