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

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

Разобраться в должностных обязанностях

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

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

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

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

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

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

Найти «проводника»

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

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

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

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

Протестировали дизайн на анестезиологе-реаниматологе. Спросили: вы понимаете, что здесь изображено? Он правильно назвал все показатели. Значит, нам удалось соблюсти отраслевой стандарт

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

Стать своим, пусть это и невозможно

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

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

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

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

Доверять

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

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

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

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

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

В проекте Algohelp мы действительно работали с четкими алгоритмами — их создал заказчик, и дизайнеры даже не замахивались на какие-то изменения

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

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

У вашего близкого давление 145 на 90 — это много или нормально? А бывает ли единое нормальное значение или оно для каждого индивидуально?

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

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

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

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

Не ломайте

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

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

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

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

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

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

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

Итого

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

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

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