Что нужно учесть перед тестированием профессиональных интерфейсов

Показываем на примере медицинской системы.

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

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

Итак, что же важно?

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

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

Для одного из проектов нам нужно было понять, врачи какой специализации могут назначить пациенту вести дневник давления: только кардиолог или участковый терапевт тоже это делает? Важно ли для будущей системы, чтобы у врача был опыт работы с суточным мониторингом давления и умение анализировать расшифровки СМАД? А подойдет ли в качестве респондента ординатор?

Если мы не разберемся в должностных обязанностях и привлечем не тех респондентов, наши выводы и рекомендации рискуют оказаться нерелевантными. Так что нам и проекту в целом еще повезет, если заказчик вовремя заметит ошибки. А вот если пропустит, кто-то получит неверные данные и их основе будет принимать решения.

И наоборот: чем глубже мы погрузимся в тему, тем релевантнее будут выводы и советы. Тщательно собранные знания позволяют выходить за рамки банального UI-аудита, давать рекомендации по процессам или в целом по продукту. И иногда такой подход приводит к неожиданным выводам: например, что проблема заключается не в UX. Парадокс.

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

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

Искать респондентов и разговаривать с ними удобнее не через организации (для нас — поликлиники, больницы), а индивидуально. Хотя у последнего есть исключение — команда исследуемого продукта уже может с кем-то сотрудничать.

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

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

Кто-то из нас раньше работал с BPM-системами и понимает, чем занимается бизнес-аналитик, а кто-то работал в администрации и разбирается в тендерных площадках. И этот опыт помогает. Но такое бывает редко. Люди с медицинским образованием в IT — исключение. Что делать? Опять же, разобраться в теме.

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

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

Подготовка — это не просто знакомство с темой, но и способ завоевать доверие врача, когда ты сам не врач.

Во время интервью пользователи часто просят готовые решения: сделайте табы, добавьте кнопку, объедините разделы. Если речь идет о массовом продукте, мы относимся к таким предложениям с недоверием — нередко люди просто делятся фантазиями. Наша же цель — зафиксировать задачи, зачем именно нужна та или иная функция или кнопка. Как это будет использоваться? Зачем, почему? Придумать решение для задачи — работа дизайнеров. Они, кстати, не любят, когда ее отбирают непрофессионалы!

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

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

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

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

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

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

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

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

Так или иначе, финальное решение при любых разночтениях остается за заказчиком. Наша задача — собрать информацию, чтобы снизить неопределенность.

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

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

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

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

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

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

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

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

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

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