Я хотела бы рассказать о том, как эффективно спланировать процесс юзабилити-тестирования и получить качественную обратную связь. Этот материал затрагивает деятельность UX-дизайнеров и будет полезным для продакт-оунеров, продакт- и проджект-менеджеров, а также всех, кто тесно связан с разработкой программного продукта.
Юзабилити-тестирование это метод оценки интерфейса со стороны удобства и эффективности его использования. Чтобы получить ее, нужно привлечь представителей целевой аудитории программного продукта.
Зачастую юзабилити-тестирование проводится в два этапа: прохождение пользователем N-го количества задач (количественные или качественные тесты), а также беседа, заполнение опросников или глубинные интервью с пользователем (качественное исследование).
Как правило, его стоит проводить, когда уже сформирован интерфейс в виде бумажного или цифрового прототипа либо готовый программный продукт, и вы хотите понять, какие проблемы возникают в работе и насколько продукт соответствует ожиданиям пользователей.
Процесс тестирования занимает в среднем от месяца до трех. Это зависит от множества факторов: наличия разных типов продукта, сложности сценариев и наличия их альтернатив, количества пользовательских ролей.
В проведении юзабилити-тестирования выделим следующие этапы:
- определение цели;
- создание плана тестирования;
- определение количества исследователей;
- определение целевой аудитории;
- получение пользовательского согласия;
- организация доступа;
- проведение наблюдения;
- анализ.
Определение цели
В каждом исследовании должна быть цель. Вы должны точно понимать, какую информацию хотите получить. Важно для себя ответить на следующие вопросы:
- Что для вас в исследовании будет важным? Какие роли пользователей или их конкретные задачи стремитесь протестировать?
- Что надеетесь зафиксировать в заметках? К примеру, хотите использовать видеосъемку, а в протоколах помечать интересные моменты с привязкой к видео для быстрого поиска и обработки обратной связи.
- Планируете ли изучить рабочее пространство пользователей? Есть случаи, когда оно влияет на организацию интерфейса.
- Есть ли необходимость в фото- или видеосъемке в процессе наблюдения за пользователем? Возможно, какие-то сценарии проще записать на видео. Например, при проектировании мониторинговой системы скважин необходимо понять, с какими устройствами передачи данных взаимодействует Service Supervisor и какое количество мониторов он использует.
- Какие метрики будут использованы в тестировании? Количественные и/или качественные? Это зависит от того, что вам в исследовании интересно и что проверяете. Если работаете над приложением, предназначенным для рабочего процесса пользователя, вряд ли вас будет интересовать степень его вовлеченности. Вы, очень вероятно, будете заинтересованы в скорости прохождения сценариев, количестве пользовательских ошибок, выполненных сценариев и степени удовлетворенности пользователя.
Создание плана тестирования
Для формирования плана тестирования нужно прежде всего определить:
- Какой продукт или продукты планируете изучить? Например, закрытая Product Experience Management веб-платформа, обеспечивающая управление всей информацией о товаре/изделии.
- Что будет предметом тестирования? К примеру, та же веб-платформа или кликабельный адаптивный прототип ее новой версии.
- Какие типы устройств будут использованы? Например, персональный компьютер (ПК), планшет и мобильный телефон.
- Какие роли и функции пользователей будут протестированы? Допустим, роль: PDM-администратор. Функции/задачи: создание шаблона для товара или изделия, проверка шаблона товара, утверждение шаблона.
Если есть несколько продуктов, такие как мобильное web- и desktop-приложение, и вы хотите протестировать каждый из них, то лучше делать это в разное время. Так получите более точные отзывы и избежите смешанных чувств от тестирования всех продуктов сразу.
Для наблюдения я, как правило, готовлю документ для каждого пользователя дорожную карту, которая рассказывает, что и как делать и на какие вопросы отвечать. Документ называется UX testing plan & script и состоит из таких элементов:
- вступление;
- погружение пользователя в контекст решаемых задач;
- описание задач и список шагов с возможностью занесения комментариев по каждому из них;
- список вопросов к каждой задаче;
- заключительный раунд вопросов.
Не пытайтесь выявить все проблемы юзабилити в большом продукте сразу. Гораздо эффективнее раздробить сценарии на отдельные небольшие исследования по ролям с определенной целью в каждом из них.
Обычно при формировании задач провожу их декомпозицию. Что это такое? Я заменяю решение одной задачи на серию мелких простых и связанных между собой подзадач с конкретной целью в каждой.
Давайте рассмотрим пример. Сценарий задачи Как пользователь я могу забронировать понравившийся отель на самом деле состоит из ряда мелких подзадач:
- Как пользователь я могу найти отель. Узнаем, как пользователь ищет отели, и проверяем целесообразность выбранных критериев поиска и его алгоритма.
- Как пользователь я могу получить информацию об отели. Узнаем, хватает ли информации в наших данных.
- Как пользователь я могу забронировать отель. Проверяем целесообразность выбранного алгоритма, узнаем, все ли шаги понятны пользователю, можно ли ускорить процедуру бронирования и так далее.
Если задаться целью, можно разложить информацию об отеле на составляющие и декомпозировать подзадачу на ряд других.
Сценарии задач должны быть конкретными и отражать реальные потребности целевой аудитории. Не просите потребителя купить мясо, если он вегетарианец.
Не стоит забывать, что задачи для качественных и количественных методов разные. Давайте рассмотрим примеры задач для каждого из них.
Задача для качественных исследований: найдите на сайте отчет за первый квартал 2019 года.
Задачи для количественных исследований:
А. Используя глобальный поиск на сайте, найдите отчет за первый квартал 2019 года.
В. Используя раздел Reports на сайте, найдите отчет за первый квартал 2019 года.
В качественных исследованиях мы поймем пользовательское предпочтение user-flow, а в количественных разъясним, все ли шаги конкретного user-flow понятны пользователю. Качественные и количественные исследования должны дополнять друг друга, а не противопоставляться.
Как может выглядеть задача, связанная с авторизацией на сервере.
Пример сценария: клиент попросил вас подготовить отчет, и вы хотите начать с поиска информации в рамках сайта www.sample.com.
Задача: пожалуйста, войдите в систему, используя свой логин и пароль.
Шаги:
- Открыть браузер.
- Ввести в адресную строку www.sample.com.
- Ввести электронную почту в поле Email.
- Ввести символы в поле Password.
- Нажать кнопку Вход.
Альтернативные шаги:
- Открыть браузер.
- Ввести в адресную строку www.sample.com.
- Нажать ссылку Забыли пароль.
- Ввести свою электронную почту.
- Открыть почтовый клиент.
- Найти письмо от сервера об авторизации.
- Перейти по ссылке.
- Ввести новый пароль.
- Повторить пароль.
- Нажать кнопку Сменить пароль.
Если вы проводите количественные исследования и замеряете, например, время прохождения сценария, количество ошибок в одном сценарии, прошел/не прошел пользователь сценарий, а также уровень удовлетворенности пользователя все замеры производите исключительно на production-сервере, с реальной пользовательской нагрузкой, с реальными данными и работающими сервисами, с их валидацией и запросами к реальным базам данных.
Стоит заранее прогнать выполнение сценариев на пробной аудитории, чтобы удостовериться в актуальности тайминга сессии и понимании пользователем всех инструкций. Обычно я закладываю в бюджет обкатку сценариев с тремя пробными пользователями.
Определение количества исследователей
Для качественного проведения наблюдения необходимо иметь следующие роли:
- Интервьюер проводит юзабилити-тестирование, используя UX testing plan & script. Часто такая роль достается самому проектировщику интерфейса.
- Наблюдатель уточняет детали и углубляется в них по мере протекания тестирования. В данной роли могут выступить продакт-оунер, эксперты предметной области или проектировщики интерфейса.
- Модератор должен придерживаться тайминга и следить за тем, чтобы все сценарии были воспроизведены пользователем. С этим хорошо справляются проджект- и продакт-менеджеры, скрам-мастеры. Еще приглашают на эту роль проектировщика интерфейсов.
Нередко проектировщики интерфейса являются интервьюерами и неосознанно продавливают свои решения во время тестирования. Это обусловлено тем, что тяжело оставаться беспристрастным, если ты очень близок к программному продукту. Что же делать в таких ситуациях?
В первую очередь вы должны любить задачу, над которой работаете, а не ее решение. Только так сможете эволюционировать в проектировании интерфейса конкретной задачи. Далее привлеките три независимых мнения в лице интервьюера, наблюдателя и модератора, которые помогут в спорных моментах разъяснить ситуацию суммарно верно.
Однако не всегда есть возможность вовлечь троих исследователей для каждого сеанса тестирования. Часто функции, перечисленные выше, возлагаются на одного интервьюера, что делает процесс исследования для него тяжелым испытанием.
Если вы проводите тестирование один, лучше всего проводить не более трех тестирований в день с максимальной продолжительностью сеанса 1,5 часа. Если же тестирование выходит за рамки указанного времени, разбейте его на две части.
Определение целевой аудитории
При работе над ПО из узкой предметной области демографических показателей обычно недостаточно. Здесь важно разобраться в ролях и их функциях.
Например, вы работаете над финансовым продуктом и планируете изучить деятельность брокера в рамках создания CLO (collateralized loan obligation) бизнеса на американском рынке. В данном случае нужно понять алгоритмы взаимодействия инвест-банкира с другими финансовыми ролями.
Определиться с целевой аудиторией помогут предварительные опросники. Их создают как в бесплатных сервисах, например Google Forms, так и в платных SurveyMonkey, Typeform и других.
Расспросите кандидатов об их роде деятельности, территориальной принадлежности, на какие функции приложения они подписаны, если подписка существует вообще. Спросите, как часто и для чего они используют продукт. Если их цели по использованию сервиса совпадают с целями исследования это ваши люди.
Сопоставив план тестирования и предварительный опросник, вы сможете правильно выбрать потенциальных кандидатов для исследования.
Правила создания таких опросников очень просты:
- Точно формулируйте вопросы. Как правило, люди понимают одни и те же фразы по-разному. Используя недостаточно точные формулировки, мы не можем быть уверены, что пользователь правильно понял вопрос.
- Не спрашивайте у респондентов то, что вам заранее известно. Например, его имя, возраст или должность.
- Используйте закрытые вопросы везде, где есть возможность. Пользователям гораздо проще выбрать вариант ответа, чем писать свой.
- Убедитесь, что вы включили все подходящие варианты ответов для закрытых вопросов, в том числе Другое или Свой вариант на случай, если ни один из предложенных пользователю не подходит.
- Всегда задавайте нумерацию вопросам.
- Показывайте суммарное количество вопросов и прогресс-бар, заранее ориентируя человека, где он находится и сколько ответов ему предстоит дать.
Можно использовать дихотомические вопросы (да/нет ответы), чтобы определить, на какой следующий вопрос будет отвечать респондент. Это несложно делается, к примеру, с помощью Google Forms.
Задавайте вопросы с градацией, если хотите измерить степень суждения. В основном для этого применяют шкалу Ликерта либо скользящую шкалу. Рекомендую использовать шкалу Ликерта, так как она более удобна для восприятия респондентом. Поскольку во скользящей шкале варианты ответа записаны цифрами и респонденту приходится определять значение оценок самостоятельно.
В случае скользящей шкалы варианты 6-9 принадлежат категории частично согласен, однако нет возможности понять, чем они отличаются. Здесь стоит избегать большого количества ответов без надобности.
Если хотите узнать, согласен или не согласен пользователь с чем-то, используйте четное количество оценок. Если же вас интересует также нейтралитет применяйте нечетное количество оценок.
Выборка пользователей зависит от многих факторов:
- вероятности появления ошибки у определенного процента респондентов;
- однородности в выборке пользователя каждой роли;
- наличия альтернативных путей прохождения сценариев;
- степени сложности выполнения сценариев.
Давайте поговорим о вероятности возникновения ошибки у пользователя. Если у всех юзеров возникает одна и та же ошибка, то для тестирования вам понадобится всего лишь один пользователь, который с вероятностью 100% обнаружит эту проблему.
Другая история получается, если только половина участников сталкивается с определенной проблемой. Тогда нужно как минимум три человека для ее выявления. Однако есть вероятность, что у всех троих проблема не будет проявляться. Придется продолжать тестировать, пока пользователь не обнаружит проблему.
На сегодня есть калькуляторы для вычисления количества пользователей. Они базируются на средней вероятности обнаружения ошибки в одном исследовании. Однако проблема в том, что разные исследователи получают разные показатели этой вероятности. К примеру, Якоб Нильсен в свое время получил значение, равное p=0.31, в то же время исследования Спула и Шредера приводят к результату p=0.16.
Выбор вероятности это всегда большой риск. Вы можете полагаться на свои исследования и провести расчет своей вероятности или использовать значения p=0.31 для простых сценариев и p=0.16 для сложных и разнообразных, полагаясь на исследования других.
При анализе различных исследований вытекает один бесспорный факт чем больше пользователей вы протестируете, тем более точные получите результаты. Но что делать, когда вы ограничены количеством конечных пользователей?
До сих пор в мире спорят о том, какое же минимальное количество участников подходит для тестирования. По мнению Якоба Нильсена, это 5 человек, а по мнению Лауры Фолкнер 10.
Я рекомендую начинать с 5-10 тестирований одного прототипа для проверки гипотез в качественных исследованиях и 10-20 тестирований для количественных. Если ошибки начинают повторяться, это свидетельствует о том, что выборка пользователей однородная. Также допускается использовать метод итеративных изменений RITE, когда правки вносятся в интерфейс по мере обнаружения проблем. Проводится тестирование одного пользователя.
Если группа исследователей уверена, что понимает суть обнаруженных проблем, то она принимает решение исправлять их или нет. Если же нет, она продолжает тестировать текущий интерфейс, пока суть не будет ясна. После внесения правок тестирование начинается заново. Обычно подход RITE требует 5-6 итераций.
Если же мы говорим о поиске новых идей для развития продукта или нахождения закономерностей поведения, то большая выборка здесь крайне необходима.
Получение пользовательского согласия
Перед началом теста необходимо получить разрешение на участие пользователя в конкретном исследовании. Важно прописать абсолютно все условия, по которым оно будет проводиться (примеры условий ниже). Это будет хорошей страховкой на предмет использования всех данных, которые вы получите в процессе исследования.
Я стараюсь делать в своих наблюдениях видео- и аудиозаписи. Это позволяет максимально точно зафиксировать все ответы и реакцию пользователя на выполнение задач. Как организатор тестирования вы должны всегда уведомлять человека об осуществлении записи в письменной или электронной форме.
Между тем в нескольких случаях у меня был отказ со стороны пользователей на применение каких-либо записей и приходилось документировать сессию вручную.
Пример:
Я даю свое согласие (название компании) на участие в пользовательском тестировании с использованием ноутбука/веб-сайта. Я проинформирован(а) и понимаю свою роль в проведении исследования. Во время сеанса меня попросят найти информацию или выполнить задачи, используя сайт-прототип, и попросят заполнить анкету после тестирования. Сеанс будет снят, но только для целей записи моих ответов (записи голоса) и для проверки моего поведения (видео), например, что я нажимаю и где на веб-сайте. Мое лицо будет видно интервьюеру и исследователям во время физического присутствия, но не будет присутствовать на видео.
Я понимаю, что информация, которую я предоставляю, предназначена только для исследовательских целей, и что мое имя и контактные данные не будут использоваться для каких-либо других целей и не будут переданы третьим лицам.
Я понимаю, что участие является добровольным, и согласен немедленно задать любые вопросы, которые у меня могут возникнуть.
Я понимаю, что вся информация об исследуемом приложении конфиденциальна и обязуюсь не разглашать людям, которые не являются сотрудниками компании.
У меня было достаточно времени для принятия решения, участвовать ли в этом исследовании.
Я понимаю, что могу принять решение отказаться от участия или прекратить участие в любое время.
В такой шаблон обязательно нужно добавить информацию, как долго будет сохраняться полученная информация от респондента, а также его персональные данные (дает ли он согласие на то, чтобы компания контактировала с ним после проведения опроса, а если да, то для каких целей).
В такой шаблон смело добавляйте: дату и время, адрес проведения тестирования, к примеру, ссылку на виртуальную встречу или физический адрес помещения.
На мой взгляд, получать согласие пользователя нужно всегда, однако есть редкие случаи, когда его можно заменить соответствующим информационным знаком. Например, если необходимо посчитать статистику вошедших и вышедших мужчин и женщин из магазина, можем поместить знак о наблюдении у входа.
Организация доступа
Организуйте доступ к нужному ПО, установите оборудование для записи сеанса. Наблюдение должно проходить в естественной среде для пользователя. Анализ рабочего пространства важен, а в конкретных случаях крайне необходим.
К примеру, вы можете провести наблюдение за работой электромонтера на электрической распределительной подстанции, так как повторить рабочие условия в лаборатории будет нецелесообразно и сложно. В ходе исследования вы поймете, какие факторы и как влияют на работу инженера: типы устройств, ПО и его индивидуальная настройка, сезонность, температура, свет, организация рабочего пространства и так далее.
Так в одном из исследований мы выявили, что электромонтер не мог выполнять свою работу на планшете летом, поскольку температура в помещении доходила до 50 градусов и планшет периодически отключался. При работе на открытом воздухе на устройство попадал луч солнца и давал блики, что также мешало выполнению задач. Разрешить ситуацию помогло использование специализированных промышленных планшетов с матовым дисплеем и защитным чехлом, предназначенных для работы при высоких температурах.
В результате анализа реального рабочего пространства вы сможете проверить, подходит ли выбранные тип и конфигурация оборудования в данном контексте или нет.
Бывают случаи, когда нет возможности провести наблюдения в естественной среде, например, из-за сложного получения доступа в периметр или его отсутствия совсем. Тогда убедитесь, что конфигурация оборудования, настройки ПО, а также обстановка максимально похожи на рабочее пространство человека.
Проведение наблюдения
Важный момент во время всего процесса тестирования наблюдение за пользователем. Существует множество причин, для чего это может понадобиться, но выделим две основные:
- Некоторые действия сложно описать. Если я спрошу, как вы катаетесь на велосипеде, вы наверняка не вспомните, с какой стороны подходите к велосипеду, какой ногой отталкиваетесь от поверхности, чтобы взгромоздиться на него и так далее. Вам проще взять его и продемонстрировать умения.
- Некоторые описания могут конфликтовать с реальным поведением. На вопрос, как часто проверяете почту, люди обычно отвечают, что делают это на рабочем месте раз в полчаса. Однако, если вы бежите по коридору и коллега просит вас ответить на письмо, отправленное двумя минутами ранее, ваша рука потянется за телефоном и вы неосознанно проверите почту. Но этот факт вспомните не сразу, и это нормально. Дело в том, что пользователи не помнят или не знают детали своих действий, которые могут быть важными для исследователей.
Наблюдение за человеком позволяет выявить его реальное поведение и получить максимальное понимание ситуации, в которой он оказывается.
Перед началом наблюдения важно объяснить пользователю, какая цель исследования, как оно будет проходить и какая его роль. Важно объяснить, что в процессе тестирования мы не будем проверять его способности, а лишь протестируем прототип системы, чтобы понять, что стоит улучшить.
Во время выполнения задач попросите участников комментировать свои действия и делиться мыслями вслух. Это позволит точнее понять их действия. Не кивайте, если респондент дает правильный ответ и тем более не демонстрируйте отчаяние, если он не справляется с задачей.
Не используйте профессиональные термины в беседе, так как пользователь может не понять, что такое, к примеру, кастомные контролы, нативный алерт или мегаменю. Слушайте, что он говорит, и употребляйте понятные слова и объяснения.
Избегайте наводящих вопросов. В них содержатся подсказки, и вы можете неосознанно влиять на результаты. Уточните все детали, если человек не понял задачу сразу.
Не спешите сразу делать выводы или записывать за пользователем. Важно уточнять, что он имеет в виду, и верифицировать с ним свои мысли, чтобы точнее зафиксировать ответ.
Видео-, аудиозапись для фиксации ответа не исключает личного протоколирования сессии на случай, если записи потеряются или сотрутся.
Делайте заметки с помощью предварительно подготовленной структуры. В UX testing plan & script обычно использую колонку для записи пользовательских комментариев к каждому шагу сценария. Во время выполнения задач делаю небольшие заметки в виде прошел/не прошел сценарий, возникали/не возникали сложности. Эти заметки можно привязать к соответствующим моментам видео, и вы сможете легко вернуться к ним позже.
Просмотрите заметки сразу после наблюдения. Убедитесь, что вы можете разобрать свой почерк, дополните наблюдения, если не успели это сделать.
Если во время тестирования человек отвлекается на исследователя с блокнотом, то в беседе могут возникнуть сложности. Исходя из своего опыта, скажу, что большинство пользователей сбивает с мысли то, что исследователь сразу записывает его ответы во время интервью. Если имеете соглашение на запись используйте диктофон на телефоне, например в личной беседе. Через пару минут человек прекращает обращать внимание на телефон, начинает погружаться в вопросы, а в конце сессии и вовсе забывает о нем. После интервью сделайте небольшой набросок ответов на бумаге.
Что еще очень важно. Не пытайтесь провести тестирование, если пользователь выбран ошибочно и не является частью целевой аудитории. Например, однажды в предварительном опроснике респондент отметил, что имеет подписку на модуль, который я исследовала. Но в начале тестирования выяснилось, что он им никогда не пользовался и не планирует.
Лучшим решением в данной ситуации был откат на этап определения целевой аудитории и выбор другого человека. Также предварительно стоит доработать неточности в опроснике.
Анализ
Во время анализа обращайте внимания на ситуации, когда пользователь:
- понимает задачу, но не может выполнить ее в намеченный срок;
- понимает цель задачи, но вынужден перепробовать несколько вариантов для ее достижения;
- не достигает цели задачи и досрочно прекращает выполнение сценария;
- выполняет задачу, но не ту, которая была поставлена;
- выражает удивление или удовольствие;
- выражает разочарование и замешательство;
- говорит, что ему что-то непонятно или неправильно реализовано;
- предлагает внести изменения в интерфейс.
Не пренебрегайте одиночными случаями, когда участник не прошел сценарий. Разберитесь, что в его опыте было по-другому и какие причины могли привести к такому результату. Возможно, вы нашли ошибку, которая встречается у малого процента пользователей.
Проведите анализ всех пометок, что осуществлялись в протоколах. Если проводились видео- и аудиозаписи, стоит сделать их транскрибацию. Это позволит в дальнейшем быстро находить нужные цитаты людей, определять облака слов для составления диаграммы сродства определение количества тех, у кого возникли одни и те же проблемы.
Используя метод RBT, а также диаграмму сродства, вы сможете выявить похожие проблемы, сильные стороны интерфейса и общие предложения пользователей.
Метод RBT состоит из следующих показателей:
- Rose то, что работает хорошо или что-то положительное; зеленая карточка.
- Bud область возможностей или идей, которые еще предстоит изучить; синяя карточка.
- Thorn что-то не работает или что-то негативное; красная карточка.
Составление диаграммы сродства процесс группирования по значимым признакам наблюдений и выводов исследования, на которые проектировщики интерфейсов опираются во время разработки продукта.
Как это делается? Мы анализируем первую задачу одного пользователя и фиксируем конкретные замечания и цитаты на стикерах. На каждом стикере написаны имена участников. Размещаем их на стене или доске. Далее следующий пользователь вносит свои данные. После нескольких тестов появляются общие вопросы и проблемы.
Затем содержимое записок объединяют в группы по родственному признаку, а потом из групп формируют темы. Множество красных стикеров в одной категории будет указывать на то, что у нескольких человек возникли одни и те же проблемы.
Задайте рейтинг найденным проблемам (Thorn) по шкале:
- Критическая ошибка. Не работает какая-то кнопка, если это не исправить, пользователи не смогут завершить сценарий. Например, человек ищет отели на сайте-агрегаторе, но не может залогиниться или не отображается результат.
- Серьезная ошибка. Пользователи будут расстроены, если мы не исправим ошибку. Также есть вероятность, что они сдадутся и не пройдут сценарий. Например, выдача в поиске на сайте бронирования отелей занимает 10 секунд. Многие юзеры не заходят ждать и уйдут на другие ресурсы.
- Минорная ошибка. Пользователи будут раздражены, но это не помешает им завершить сценарий. Например, ожидание отображения результатов сократится до 5 секунд. Это продолжит раздражать, но человек, скорее всего, останется на сайте, так как он уже потратил свое время и не пойдет искать другой сайт, несмотря на то, что ожидание результатов на нем может быть немного меньшим.
Этот рейтинг поможет определиться с приоритетами в работе над поиском и валидации решений найденных проблем.
В процессе анализа также будьте готовы получить интересные факты, которые не были связаны с тестирующими сценариями. Например, при тестировании сценария создание чата в Microsoft Teams веб-версии вы поймете, что у пользователя несколько разных рабочих аккаунтов. Ему приходится быть авторизованным в системе под разными аккаунтами в разных вкладках браузера. Сделать такое в desktop-версии невозможно, соответственно, вы получите новый инсайт о том, как пользователи с разными учетными записями решают эту задачу, используя ваш продукт.
При анализе обратной связи стоит задуматься над такими вопросами:
- Что или сколько бизнес приобретет, если прислушается к пользователю и внедрит изменения? К примеру, возможность расширения горизонтов бизнеса или лидерство в конкурентной среде.
- Какой процент недовольных пользователей готов уйти от заказчика, если не будет услышан? Сколько денег при этом потеряет бизнес?
Когда все продумано, нужно презентовать результаты исследования заказчику. Вы предлагаете ему варианты улучшения и объясняете последствия, если все оставить так, как есть. Далее он уже решает, есть ли ресурсы на доработку и целесообразно ли это.
Заключение
С четкой целью исследования, правильными задачами, тщательно сформулированными вопросами вы сможете в полной мере собрать интересные советы и критику в адрес продукта, а также приоритизировать план задач по его улучшению.
Анализ и обнаружение ошибок это всегда субъективный процесс. Те результаты, к которым придете, это исключительно ваше понимание ситуации. Поэтому чем разнообразней будете подбирать команду исследователей, тем разностороннее истолкуете суть проблемы.
Однако не стоит забывать, что, решая проблемы, вы снова столкнетесь с необходимостью их протестировать. По сути это бесконечный процесс. Но такой подход позволит убедиться на практике, сработало ваше решение или нет.
