Проведение юзабилити-тестирований или опыт набитых шишек



    Небольшой сборник советов и выводов о проведении юзабилити-тестирований.

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




    Тестирование знакомых и коллег


    Из плюсов первые строчки хит-парада занимают экономия времени, денег и сил на поиски респондентов.

    А теперь про минусы и подводные камни.

    Знакомые


    Знакомые могут быть настолько хорошими, что, в попытках сберечь ваше самолюбие, напрочь завалят результаты тестирования.

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

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

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

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

    Коллеги


    С хорошими коллегами ситуация может быть такой же, как и ситуация с хорошими знакомыми.

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

    Что делать


    когда время поджимает и протестировать все же нужно?

    «Хороших» просите не стесняться и критиковать все недочеты, так как любая критика в этом деле только на благо.

    Пугливых предупреждайте, что тестируете не его способности, а результаты своей работы. Если что-то не получилось, то это не он дурак, а ты не учел.

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



    Мужская и женская аудитория


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

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

    Мужчинам лучше подходит более законченный вариант прототипа со всеми выпадающими и всплывающими окошками.



    Постановка близких пользователю задач


    Про то, что для тестирования набирают «свою» целевую аудиторию уже было сказано и до меня. Скажу немного про задачи.

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

    Вывод


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

    Не надо просить многодетную мать искать колеса для байка, если только она не является байкером, в свободное от материнства время.

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



    Тестирование пяти


    «Чтобы выявить ключевые проблемы на сайте, вам будет достаточно протестировать пять пользователей» (с) Якоб Нильсен.

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

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



    Присутствие более одного интервьюера на тестировании


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

    С одной стороны, разработчику очень полезно наблюдать, как люди пользуются продуктом, так сказать, в боевых условиях.

    С другой стороны, некоторым пользователям тяжело сосредоточиться на задаче, когда на него пристально смотрят 2 и больше пары глаз.

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



    Слишком разговорчивый пользователь


    Бывает и так. Ему нравится ваш продукт, он мегалоялен. Он фонтанирует кучей идей, иногда очень даже неплохих, как сделать продукт еще круче.

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

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

    Например


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



    Вопросы в лоб


    «Вы не нажали на эту кнопку! Вы что, ее НЕ УВИДЕЛИ!!!» и глаза при этом такие большие-большие, а там бегущая строка: «Ну пользователи, ну тупыыыыые!».

    В тот момент, когда вы так явно негодуете по поводу тупости пользователя, этот самый пользователь замыкается в себе и все, он в домике.

    Выводов, почему он не нажал эту злополучную кнопку, ноль.

    Мелко? Затерялась среди текста и мигающего баннера или не понятно ее назначение?

    Когда нужно решить задачу относительно работы элемента, а она не решается с первого раза, попросите его решить задачу еще раз, любым удобным для него способом. Если опять мимо, можно попросить попробовать еще раз, может даже еще раз, пока он не увидит эту злополучную кнопку (если увидит), но тут уже попахивает провалом.

    И спокойно, без нервов. Никоим образом не намекая, что ваш 3-х летний сын вчера с первого раза выполнил эту задачу.

    Вот собственно все, что хотелось рассказать. Плодотворной работы всем!
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 5
    • 0
      А вот как тестировать прототип на пользователях сервиса, если ты делаешь рефакторинг? Если они уже привыкли к старому расположению элементов, к старой логике, а ты по факту предлагаешь совершенно более новый прогрессивный продукт
      • 0
        Тестируйте его на новых пользователях и небольшой части старых. Если новые пользователи с нуля разберутся быстрее, чем на предыдущем тестировании, значит рефакторинг удался. А старые пользователи покажут насколько быстро они смогут перестроиться.
        • 0
          а стоит ли тестировать на пользователях конкурентских сервисов?
          • +1
            Не очень понял вопроса. Новые пользователи для вашего сервиса, вполне могли пользоваться аналогом или конкурентом. Вы же продаете им СВОЙ способ решения определенной задачи. Они ваш способ и будут оценивать.
      • 0
        Я думаю полезно тестировать всех возможных пользователей целевой аудитории, для надежности, в том числе и конкурентских)

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.