Войти в систему
Войти с помощью соц. сетей:
Тестирование юзабилити, как правило, наиболее продуманная и понятная форма тестирования на этапе исследования продукта, используемая уже много лет. Конечно, сегодня инструменты стали намного эффективнее, и команды проводят такие тесты гораздо чаще, чем раньше, но и в целом это не самый сложный вид деятельности. Главное отличие от тестирования юзабилити в прошлом — его проведение на этапе исследования — с использованием прототипов, а не готовых продуктов — а не в конце процесса, когда исправления и коррекции сопряжены со значительными непродуктивными тратами, а то и с чем-то похуже.
Если ваша компания достаточно велика и в ней есть собственная группа исследователей пользователей, во что бы то ни стало добейтесь, чтобы эти люди как можно больше времени работали на вашу команду. Даже если этого времени будет не очень много, такие специалисты обычно представляют собой потрясающий ресурс для менеджера продукта; и если вы сможете подружиться с кем-то из них, то получите отличное подспорье.
Если компания располагает средствами для привлечения сторонних сервисов, можно воспользоваться для тестирования своих идей и продуктов услугами одной из множества фирм, специализирующихся на исследовании пользователей. Однако из-за цены, взимаемой большинством из них, скорее всего, вы не сможете себе позволить такой подход к тестированию юзабилити в нужном объеме. Дело в том, что если вы похожи на большинство компаний, то у вас не слишком много ресурсов и еще меньше денег. Но это ни в коем случае не должно помешать вам работать в этом важнейшем направлении.
А теперь я расскажу, как проводить тестирование юзабилити идеи или нового продукта самостоятельно. Нет, это не позволит вам достичь эффективности специально обученного и подготовленного исследователя, по крайней мере поначалу, и, скорее всего, понадобится провести не одну серию тестов, чтобы в нем поднатореть, но в большинстве случаев вы сможете практически с самого начала самостоятельно выявлять самые серьезные проблемные области продукта, а это, безусловно, очень и очень важно.
В отличных книгах подробно описывается, как проводить неофициальное тестирование юзабилити, но я не стану пересказывать их содержание, а обращу ваше внимание на ряд наиболее существенных моментов.
Прежде всего нужно собрать группу объектов исследования. Если у вас есть особая команда исследователей пользователей, то подбирать людей и планировать тесты будут они; и это огромное подспорье. Но если вам приходится делать все самим, в вашем распоряжении есть несколько вариантов:
Юзабилити-тестирование обычно проводится с применением пользовательского прототипа высокой детализации. Собрать полезные сведения о юзабилити можно и с помощью пользовательского прототипа средней детализации, но для изучения ценности, которое обычно проводится сразу после этого теста, все равно понадобится более реалистичный продукт (о причинах этого я расскажу чуть позже).
В большинстве случаев в тестировании юзабилити и (или) ценности участвуют продакт, дизайнер продукта и один из инженеров-программистов команды (из тех, кому нравится посещать такие мероприятия). Я стараюсь привлекать наших разработчиков по очереди. Как я уже упоминал, в присутствии инженера-программиста нередко возникает некое волшебство, поэтому я стараюсь по возможности всегда привлекать таких специалистов. Если в тестировании вам помогает сторонняя компания по исследованию пользователей, управляет тестом обычно она, но ваши продакт-менеджер и дизайнер обязательно должны присутствовать на каждом тесте.
Следует заранее определить набор задач для тестирования. Обычно тут все просто. Если вы разрабатываете, скажем, приложение для будильника на мобильном устройстве, то пользователям придется устанавливать будильник, находить и нажимать кнопку повтора и так далее. Встречаются и менее очевидные задачи, но при тестировании юзабилити нужно сосредоточиться на основных, то есть на тех, которые будут выполняться чаще всего.
Некоторые до сих пор считают, что продакт-менеджер и дизайнер продукта слишком к нему привязаны, поэтому не способны объективно провести тестирование юзабилити; что полученный результат может глубоко ранить их чувства; что они будут слышать только то, что хотят услышать. Такое препятствие устраняется двумя способами: во-первых, путем обучения продакт-менеджеров и дизайнеров поведению в ходе тестирования; во-вторых, как можно более ранним и быстрым проведением тестов, прежде чем создатели продукта влюбятся в свои детища. Хороший продакт знает, что поначалу любой продукт «неправильный», ведь никто не способен сделать все правильно с первого раза. И ему известно, что знания, полученные благодаря этим тестам, — самый скорый и верный путь к успеху в разработке.
Следите за тем, чтобы юзабилити-тест проводил один человек, а записи вел другой. Очень полезно потом все обсудить и убедиться, что оба видели одно и то же и пришли к одинаковым выводам, для этого и нужен второй участник с вашей стороны.
В формальных средах для проведения тестирования обычно организуются помещения с двусторонними зеркалами или специальные видеомониторы с камерами, которые показывают и экран, и лицо пользователя. Прекрасно — иметь такое оборудование, но я даже не могу сосчитать, сколько прототипов мы протестировали за крошечным столиком в Starbucks — таким крошечным, что больше трех-четырех стульев за ним не помещалось. Во многих отношениях кафе даже предпочтительнее отлично оборудованной лаборатории: в неформальной обстановке пользователь не чувствует себя подопытным кроликом.
Еще одна превосходная среда для тестирования — офис потребителя. На реализацию такого подхода может уйти много времени, но даже полчаса, проведенные «в среде обитания» пользователя, расскажут вам о нем очень много полезного. Здесь ваши потребители хозяева, поэтому они намного разговорчивее. В офисе всегда найдется множество подсказок, как еще можно использовать тестируемый продукт. Многое можно узнать при виде офисной обстановки. Насколько большие мониторы? Как быстро работает компьютер и подключение к сети? Как люди общаются с коллегами при решении рабочих задач?
Сегодня в нашем распоряжении имеются инструменты для проведения данного типа тестирования удаленно, и я приветствую это двумя руками. Однако не забывайте, что они предназначены для тестирования юзабилити, а не ценности; вторые тесты обычно проводятся сразу после первых. Иными словами, я рассматриваю удаленное тестирование юзабилити как дополнение, а не замену обычному.
Итак, прототип готов, участники тестирования отобраны, задачи и вопросы сформулированы, теперь воспользуйтесь приведенными ниже советами и методиками для проведения теста.
Первым делом узнайте, что потребители думают о проблеме в настоящий момент. Вы же, конечно, помните, какие ключевые вопросы задаются в рамках методики «Интервью с клиентом»; нам нужно узнать, действительно ли пользователь или клиент столкнулся с той проблемой, которую мы выделили, как он решает ее сегодня и что нужно для того, чтобы убедить его использовать наш продукт.
В начале теста юзабилити обязательно сообщите участникам, что это всего лишь прототип, сырая идея, а не настоящий продукт, и объясните, что они не обидят вас откровенным как позитивным, так и негативным отзывом. Вы тестируете на прототипе идеи, а не пользователей, и они не могут пройти или провалить тест — это грозит только вашему прототипу.
Прежде чем приступить к выполнению своих задач, посмотрите, могут ли пользователи по начальной (посадочной) странице прототипа определить, что вы, собственно, пытаетесь сделать, и особенно то, что, с их точки зрения, может быть ценным или привлекательным. Как только люди приступят к выполнению задания, контекст посетителя-новичка исчезнет, так что не упускайте такую отличную возможность. Увидите: для преодоления разрыва между ожиданиями пользователя и тем, что продукт предлагает ему на самом деле, невероятно важны начальные (посадочные) страницы.
В ходе тестирования нужно делать все от вас зависящее, чтобы удерживать участников в режиме использования и не давать им перейти к критике. Важно определить, могут ли пользователи, применяя ваш прототип, легко выполнять необходимые им задачи, а не то, считают ли они тот или иной элемент страницы недостаточно привлекательным или что, по их мнению, на ней нужно что-то переместить или изменить. Иногда люди, не слишком поднаторевшие в тестировании, задают пользователям неправильные вопросы: «Какие три элемента на странице вы изменили бы?» Меня подобные вещи не очень интересуют — разве что если этот человек по стечению обстоятельств еще и дизайнер продукта. Если бы пользователи знали, чего они на самом деле хотят, создавать программное обеспечение было бы намного проще. Так что обращайте внимание на то, что они делают, а не на то, что говорят.
Для успешного тестирования очень важно сохранять олимпийское спокойствие. Видя, что у человека что-то не получается, у большинства из нас возникает естественное желание прийти на помощь. Вы должны всеми силами подавлять его в себе. Ваша задача — превратиться в нелюдима, не готового поддерживать приятную беседу. Станьте максимально молчаливым; тишина — лучший помощник тестировщика.
В ходе тестирования стоит ожидать развития событий по трем основным сценариям: 1) пользователь справился с задачей без малейших проблем и посторонней помощи; 2) пользователь немного помучился и поворчал, но выполнил нужную задачу; 3) он так измучился и расстроился, что в конце концов сдался, но так и не сделал того, что хотел. Конечно, иногда люди сдаются очень быстро, и вам, возможно, придется уговаривать их продолжить попытки. Но если дело доходит до момента, когда, судя по поведению пользователя, он точно откажется от вашего продукта и перейдет к конкуренту, можно сделать пометку, что пользователь сдался.
Тестировщику нужно стараться не помогать и не задавать участнику тестирования наводящие вопросы. Но если вы видите, что пользователь в сотый раз прокручивает страницу вверх-вниз, явно что-то разыскивая, спросите его, что он ищет, так как эта информация может оказаться очень полезной. Некоторые тестировщики даже просят пользователей в ходе теста постоянно рассказывать, о чем они думают, но, по-моему, это настраивает людей на критику, а такое поведение для нас нежелательно.
Повторяйте за собеседником как попугай, так как это полезно во многих ситуациях и помогает не давать пользователю наводок. Если участник тестирования ничего не говорит, а у вас уже нет сил молчать, опишите ему, что он делает: «Я вижу, вы ищете этот список справа». Человек обязательно расскажет вам, что он пытается сделать, что хочет найти и все остальное. Если же он задаст прямой вопрос, вместо ответа-подсказки можно просто повторить его слова. Например, пользователь спрашивает: «А если кликнуть тут, будет новая запись?» — а вы отвечаете: «Вам интересно, нужно ли кликнуть здесь, чтобы получить новую запись?» Как правило, пользователи «покупаются» на такой прием, потому что люди обычно хотят ответить на заданный им вопрос: «Ну да, думаю, так и будет». А еще попугайничанье помогает избегать наводящих оценочных суждений. Если у вас возникло непреодолимое желание похвалить участника тестирования, лучше скажите: «Ну вот, вы создали новую запись». И наконец, по-попугайски повторяя ключевые моменты, вы помогаете коллеге, который ведет записи, оставляя ему на это больше времени.
Вы пытаетесь разобраться, как целевые пользователи подходят к осмыслению тестируемой проблемы, и выявить в своем прототипе слабые места, в которых модель, представленная данным софтом, не согласуется с ходом рассуждений и действий пользователя. В этом случае она нелогична. К счастью, заметив это на этапе тестирования, мы можем без особого труда все исправить, что нередко становится решающим фактором в успехе будущего продукта.
Вы также скоро обнаружите, что очень многое можно узнать по жестам и тону участников тестирования. Обычно бывает очевидно, нравятся или не нравятся людям ваши идеи. Если пользователям по душе то, с чем они столкнулись, они почти всегда просят вас им сообщить, как только продукт выйдет на рынок. А если ваше детище им очень понравилось, то постараются заполучить его и раньше.
Цель тестирования прототипа — как можно лучше понять своих пользователей и клиентов и, конечно же, выявить в прототипе слабые места, чтобы как можно раньше их устранить. Например, это могут быть проблемы со спецификациями, потоком, графическим дизайном или ментальной моделью работы продукта. Выявив их, сразу же исправьте.
Тест не должен быть одинаковым для всех участников тестирования прототипа. Такая установка базировалась бы на непонимании роли этого вида качественного тестирования. Проводя тест, мы не пытаемся что-либо доказать, а хотим быстро получить ценную информацию.
После каждого тестирования или каждой серии тестов кто-нибудь, обычно продакт-менеджер или дизайнер, составляет резюме полученных результатов и рассылает их по электронной почте членам продуктовой команды. Не нужно составлять эти отчеты долго, они не должны быть длинными. Их редко дочитывают до конца, и они устаревают раньше, чем люди их получат. Ведь к этому моменту прототип, как правило, уже ушел далеко вперед по сравнению с тем, каким был на момент проведения теста. Такие отчеты не стоят потраченных сил и времени.
Войти с помощью соц. сетей: