"Не слушайте пользователей" и ещё четыре мифа о юзабилити-тестированиях
В некоторых практиках слепо копируются лабораторные исследования, в других — используются в корне неверные методы интерпретации. Есть и такие, где стремятся полностью обезличить участников процесса.
В этой статье мы бы хотели развенчать несколько мифов о юзабилити, доказав их несостоятельность на примере собственных исследований.
Миф первый: не слушайте пользователей
Угадайте, кому принадлежит это высказывание? Якобу Нильсену, одному из первых исследователей удобства интерфейсов для пользователей. Так появилось первое правило юзабилити. Разумеется, обратная связь, ставшая результатом реального взаимодействия с продуктом, играет в нашем деле решающую роль. Но это не значит, что специалистам по юзабилити не надо разговаривать с людьми. Главное — делать это вовремя. В той же самой статье Нильсен указывает на лучшее время для общения с респондентами:
"Когда следует собирать данные о предпочтениях пользователей? Только после того, как те смогли испытать дизайн в действии и поняли, помогает ли он справляться с задачами или, наоборот, мешает".
Что же можно узнать из интервью, чего нельзя увидеть, наблюдая за пользователями? Приведу пример из своей практики. Я тестировал сервис Request icon ("Запроси иконку, поделись в соцсетях и попроси друзей проголосовать. Как только идея наберет нужное число голосов, мы бесплатно нарисуем иконку.")
Исследование показало, что:
- пользователи легко справлялись со всеми задачами
- им нравился новый современный дизайн
Всё было бы прекрасно, если бы не одно "но": завершив все задачи, участники интересовались: "для чего вообще нужен этот интерфейс?" Услышав один и тот же вопрос от нескольких человек, я почувствовал, как у меня зашевелились волосы на голове. После я написал об этом пост: история о том, как мы потеряли 47% аудитории.
Вывод: когда все задачи выполнены, не мешает поговорить с самими пользователями. Есть как минимум 47 причин не отказываться от этой возможности.
Миф второй: сто мнений лучше, чем пять
Человек, который сказал, что сотня людей — это лучше, чем пять, никогда не бывал в метро в час пик. Суть этого мифа можно описать так: "автоматизированные тесты с участием большого числа людей лучше, чем живое общение с несколькими респондентами". Автоматизированные тесты — хороший инструмент, но сравнивать его с другими методами по принципу "хуже-лучше" некорректно.
Во-первых, для правильной интерпретации больших объёмов данных нужны глубокие знания и опыт.
Предположим, у меня яичная ферма, и я узнаю, что 10% яиц оказались разбитыми. Как мне поступить?
а) вырастить дополнительно несколько несушек, чтобы восполнить нехватку яиц
б) сосредоточиться на безопасности уже существующих кур и их яиц, чтобы сократить потери
в) уволить бездельника-кузена
Большие данные кажутся более убедительными, но нет гарантии, что мы сможем их правильно интерпретировать. Напротив, личной беседы с одним-единственным пользователем достаточно, чтобы пошатнуть мой внутренний мир, заставить меня усомниться во всех своих суждениях и, таким образом, сделать меня более объективным.
Я не призываю вас опрашивать всех кур на ферме (3−4 вполне достаточно), я лишь хочу показать, что результаты автоматизированных тестов интерпретируются гораздо шире, чем результаты прямого диалога с пользователем.
Во-вторых, внимательный собеседник узнает из обсуждения много такого, чего нельзя узнать никаким другим образом.
Вывод: автоматизированные тесты и интервью лицом к лицу с пользователями решают разные задачи. Не стоит сравнивать их по принципу "что лучше" — используйте их в связке.
Миф третий: не меняйте сценарий
Человека, разорвавшего свои записи за две минуты до презентации, мы называем смелым. О режиссере, режущем сценарий во время съёмок, говорим: у него своё видение. Но стоит кому-то посягнуть на сценарий уже запущенного юзабилити-тестирования, все скажут: "Что за хрень?"
Почему UX-специалисты так боятся корректировать сценарий в процессе исследования? Считается, что это нарушит объективность результатов. Для получения логичных выводов об интерфейсе нужно, чтобы пять человек делали ровно одно и то же.
И хотя я понимаю, как важно получить максимально объективный результат, я не согласен с тем, что слова в сценарии должны быть неизменны, как эпитафия на мраморной плите. В одном из своих исследований я наблюдал, как люди с удивительным постоянством игнорировали одну из кнопок, появляющуюся ещё в самом начале интерфейса. Если бы я не добавил в анкету вопрос: "Заметили ли вы эту кнопку перед выполнением задачи?", то никогда бы не догадался о реальной причине столь странного поведения испытуемых.
Ещё один аргумент в пользу неизменного сценария состоит в том, что с ним гораздо комфортнее: пользователям кажется, что исследователи знают, что делают. Последним тоже кажется, что они знают, что делают. Что тут сказать? Правда важнее, чем комфорт UX-специалиста.
Вывод: иметь под рукой четкий сценарий очень удобно, но не стоит бояться добавить в него что-либо в ходе тестирования — достаточно убедиться, что корректировки не помешают процессу идти своим чередом.
Миф четвёртый: не разговаривайте с испытуемыми во время тестирования
Стандартная юзабилити-лаборатория: стул, стол, компьютер и пользователь, выполняющий задачи. Камеры и сенсоры следят за движениями глаз, выражением лица, положением тела. Других людей в комнате нет. Подобные условия создаются с единственной целью — исключить влияние экспериментатора на участника, оставив последнего один на один с продуктом.
По той или иной причине разные авторы настаивают на необходимости создавать подобные условия всякий раз, когда тестируется продукт, — даже во время менее формальных интервью в скайпе. "Не разговаривайте с пользователями — только слушайте". С тем, что исследователь должен больше слушать, чем говорить, я согласен. Но он не должен обращаться с испытуемыми как полковник Страйкер с Росомахой!
Даже если вы храните полное молчание, находитесь в другой комнате или где-то ещё, люди всё равно чувствуют, что за ними наблюдают. Вам даже не надо ничего делать — роль экспериментатора ваша по умолчанию. Существование экспериментатора располагает к тому, чтобы:
- участники тестирования восприняли вас как лицо, наделенное властью, и старались "угодить" вам своими ответами и действиями, таким образом искажая реальную картину
- боясь показаться глупыми, они отказывались признавать наличие в интерфейсе ошибок
- они вели себя не так, как вели бы в обычных условиях использования продукта (на работе, дома)
Вот почему надо быть более дружелюбным. Я люблю перед началом тестирования перекинуться с участником парой фраз. Несколько шуток (желательно смешных), пара вопросов на тему, не имеющую отношения к тестированию, спокойный голос — и вот человек уже с большей охотой делится с вами своими мыслями. Так вы получите ценную информацию о продукте, узнаете то, что более строгий исследователь потерял бы из-за закрытости пользователя.
Вывод: не болтайте попусту, но постарайтесь создать максимально непринуждённую обстановку во время тестирования.
Миф пятый: здравого смысла недостаточно
Юзабилити — это вопрос, по которому у каждого — начиная с вашего босса и заканчивая безработным кузеном — всегда есть своё мнение. Это не значит, что в этой области нет настоящих профессионалов. Специалист по юзабилити должен быть знаком с целым рядом дисциплин:
- социальная психология
- поведенческая психология
- основы дизайна
- управление данными
- должен иметь коммуникационные навыки
- и много практического опыта
Подобный специалист довольно дорого стоит, и многие компании нашли такой выход: они просто поручают обязанности юзабилиста кому-то из команды. И если у этого человека есть здравый смысл, оно того стоит.
Если вашей компании не по карману эксперт, но вам жизненно необходимо протестировать продукт, почему бы не пойти по этому пути и не стать тем самым человеком из команды?
Есть фундаментальный дизайн-принцип, согласно которому 80% аудитории будут использовать 20% функционала продукта, его "ядро". Определите его и придумайте несколько задач в рамках этого ядра. Теперь понаблюдайте за тем, как люди их выполняют. Не подсказывайте, наберитесь терпения и ждите, пока человек сам не попросит помочь. Так вы увидите реальные проблемы и получите от исследования гораздо большую пользу, чем если будете придерживаться чьего-либо субъективного мнения.
Вывод: опытный профессионал принесет пользу любому делу, но для начала его функции можно поручить сотруднику со здравым смыслом.
"Люди с зачатками здравого смысла / Полные идиоты"
Заключение
Мифы о юзабилити-тестированиях, описанные в этой статье, так или иначе связаны с попытками ослабить влияние человеческого фактора, сделать исследования и сервисы оценки юзабилити максимально обезличенными. С одной стороны, в этом есть смысл — в реальной жизни между продуктом и пользователем нет третьего лица. Представьте, что каждый раз, когда вы принимаете душ, кто-то с блокнотом в руках заглядывает к вам и спрашивает "Как водичка?".
Однако зачастую попытки спрятать экспериментатора приводят к противоположному результату: люди начинают вести себя неестественно. Лучший способ избавиться от фигуры исследователя — наблюдать за пользователями в их "естественной среде обитания", в рамках программы полномасштабной слежки, но я сомневаюсь, что юзабилисты доберутся до этого ресурса первыми.
Что же делать? Создать дружелюбную доверительную атмосферу во время исследования. Не исключать влияние человеческого фактора, но использовать его в свою пользу. Не делать вид, будто вас нет. По крайней мере тогда, когда мы говорим об исследованиях вне стен лаборатории, например, сессиях в скайпе. Но кто может сказать, как этот подход будет работать в лаборатории?
Кстати, вот рассказ об одном из моих первых юзабилити-тестирований: Drag-and-drop против клика: соперники или друзья?
Я не единственный, кто использует в своей работе нестандартные подходы: знакомьтесь, Иван, основатель Icons8, и его метод слепого найма сотрудников.
Оригинал: https://icons8.com/articles/dont-listen-to-users-and-4-other-myths-about-usability-testing/
Автор: Андрей Бурмистр начал свою работу в Icons8 с должности юзабилиста — он проводил тесты и опросы пользователей. Почувствовав острую потребность поделиться своими открытиями с коллегами, стал рассказывать поучительные или забавные (чаще поучительно-забавные) истории в корпоративном блоге.