Когда нашу компанию пригласили выступить на конференции Мобильные разработчики и деловые дни С темой «Особенности быстрого тестирования мобильных интерфейсов» мы согласились без колебаний.
Ну, мы протестировали довольно много подобных вещей.
Но я во времени представил картину: вот я представляю эти самые возможности, а меня просят рассказать о каком-то впечатляюще быстром проекте.
На самом деле все наше тестирование проходило очень быстро.
Львиная доля времени обычно уходила на оформление документов, согласования и подбор персонала.
Однако отказываться от выступления было уже поздно.
Поэтому мне пришлось на одном из первых слайдов признать, что все наше тестирование быстрое, и методика скорости должна основываться на том, что можно опустить — как при проведении теста, так и при анализе результатов.
История
Слева на фото выше моя бабушка, здесь ей 25-30 лет. Справа — телефон Motorola, который мы купили моей бабушке, когда ей было около 80. Далее нас, вероятно, ожидает отрывок о том, как мобильные технологии достигли всех слоев пользователей.Или о том, как пожилым людям сложно пользоваться современными мобильными технологиями.
Это все так, но тяжело было не бабушке, а мне.
Бабушка добровольно ограничила свои возможности в пользовании телефоном звонками, пользованием часами и зарядкой аккумулятора.
Но иногда она забывала про батарейку, и часы телефона сбивались.
Разумеется, вся работа по отладке и обслуживанию легла на меня, как на самого близкого из ныне живущих внуков.
Итак, на установку времени я потратил до 10 минут. А точнее, для поиска нужного пункта в меню.
Сначала я пытался использовать интуицию и логику, выбирая наиболее вероятные точки.
Дальше перешёл к полному поиску, возможно за исключением игр.
Бабушка махнула рукой – «Да ладно, черт с ним».
Но я не смог разрушить имидж заботливого внука и современного человека, я боролся до конца.
Что показательно, одна и та же картина повторялась при каждой последующей необходимости установки времени.
При добавлении в сценарий еще одного внука (у моей бабушки их восемь) результат не улучшился.
Выбросить телефон в мусорку – не такая уж большая проблема; это решило главную проблему – можно было позвонить домой со своей дачи.
Но в следующий раз, когда я выберу мобильный телефон после такого удара по самооценке, нанесенного Motorola, я бы посмотрел на ее телефоны в последнюю очередь.
Кстати, через какое-то время сама Motorola покинула европейский и российский рынки.
Вот почему?.
И те, кто читал Купера, помнят его оценку модели Razr - отличный индустриальный дизайн и Франкенштейн вместо прошивки.
Если бы разработчики потратили день-два на тестирование меню на телефоне моей бабушки, возможно, переставив несколько строк кода, они бы заслужили репутацию обычного телефона и приобрели лояльного клиента.
Но увы.
*** Производителей телефонов много, а разработчиков программного обеспечения — легион.
Есть SDK, эмуляторы, инструменты автоматизации тестирования — но только функциональные.
Вы можете заставить робота «нажимать» кнопки и использовать элементы управления вашим программным обеспечением как в случайном порядке, так и в соответствии с записанным сценарием.
Но инструментов для пользовательского тестирования мало.
И ориентированы они в первую очередь на тестирование сайтов, открываемых с телефона, а не на приложения и тем более не на сами прошивки.
Аппаратная часть набора инструментов тоже полностью DYI: обычные веб-камеры, самодельные держатели для них, поиск положения, чтобы не было бликов и камера не закрывала обзор пользователю.
Здесь статья в подтверждение - что даже профильные специалисты вынуждены изобретать и использовать подручные средства.
А вот один из немногих примеров квазипромышленного помощника, созданного специально для мобильных исследований — http://www.mrtappy.com/ .
И тогда за 295 евро вы получите не товар, а конструктор: Что вы получите в коробке? 
Даже наш западный коллега сказал, что это неоправданно дорого, хотя в целом стоимость исследования юзабилити на Западе выше.
Но любой разработчик понимает, что сила в знаниях! Функциональный код можно написать в блокноте, если вы умеете писать код. То же самое и в тестировании — если знаешь, на что обращать внимание, то продуктивное тестирование возможно в метро через плечо попутчика.
Что тестировать?
Все.Если у вас недостаточно времени, проверьте все, в чем сомневаетесь.
И на всякий случай то, в чем вы больше всего уверены.
Уверенность порождает слепоту и приводит к досадным упущениям.
Когда тестировать?
Как только вы поймете, что именно вы хотите дать пользователям.Возможно, заодно вы узнаете, хотят ли они его получить.
Можно начать и раньше — если просто не можете понять, что именно вы хотите дать пользователям.
В процессе общения с ними ваша идея может созреть или угаснуть.
Не жди!
Не ждите релиза, дизайна или одобрения заинтересованных сторон.Во-первых, зачастую ни релиз, ни дизайн не меняют пользовательский опыт настолько, что результаты бета-тестирования становятся недействительными.
Однажды мы ждали релиз от заказчика около полугода.
Продукт уже был в магазине приложений, собирая негативные отзывы, но добро нам не дали.
Когда его дали, мы увидели, что в продукте практически ничего не изменилось.
Во-вторых, наверняка можно придумать подходящий метод тестирования для любого этапа проекта.
Бумажный прототип выдержит все.
Даже если он мало дает, он немного и заберет.
Где я могу найти пользователей?
Если вы работаете в офисном центре, ищите их в коридоре.Если у вас есть собственное здание, привлеките коллег, не участвующих в проекте.
Если все работают над одним и тем же проектом, обратитесь к семье и друзьям.
Этот метод не поможет, если целевая аудитория должна обладать определенными навыками.
Например, приложение для менеджера по поставкам табачных изделий запутает рядового пользователя деловой терминологией.
Хотя можно сделать это в качестве краш-теста — с хорошим бизнес-приложением неподготовленный пользователь сможет хотя бы строить гипотезы о его предназначении.
С плохой стороны он вообще ничего не поймет.
С какой стороны я должен получить доступ к пользователю?
Итак, у вас есть продукт или идея продукта, пользователи и решимость представить продукт пользователям.С какой стороны мне зайти? В общем, у пользователя есть три стороны: желание, мнение и опыт. Юзабилити обычно зависит от опыта.
Желание и мнение — это путь маркетинга, а плохой маркетинг работает только на мнении, а хороший маркетинг тоже работает на желании.
Почему это? Мнение о продукте - вы можете получить его, не используя продукт и не желая его.
То есть оно может быть необоснованным, немотивированным и ненадежным.
Трудно выделить обоснованные, мотивированные и достоверные мнения, да и мы не телепаты.
Желание - вы можете иметь это, не имея ни опыта, ни мнения.
Но желание ценно само по себе, поскольку именно оно превращается в деньги.
Опыт - вы можете получить его только в том случае, если используете продукт. Желание не обязательно.
Хоть желание и не обязательно, но протестировать продукт на мотивированных пользователях, как правило, гораздо проще — они веселее, разговорчивее и искренние.
Есть у них и недостатки — мотивированные пользователи «проглотят» некоторые проблемы, не заметив их.
Забегая вперед, уже где-то за пределами релиза, можно сказать, что Успех = сильное желание + успешный опыт. Как добавить в это уравнение хотя бы одну известную величину? В нашем случае это явно не опыт, поэтому подумаем о желании.
Во время тестов часто можно заметить одну вещь: если тест проводит девушка, а респондентом является мужчина, то последний склонен вести себя несколько «дерзко» и преувеличивать субъективную оценку своих успехов в выполнении заданий.
В этом случае работает посторонняя мотивация — не на сам продукт или не на цели, достигнутые с его помощью.
Но все равно человек будет с энтузиазмом тыкать на все кнопки, пытаясь добиться своей цели.
Как применить это на практике для быстрого тестирования? Все очень просто, давайте немного изменим ситуацию с моей бабушкой.
Оденьтесь блондинкой, выйдите в коридор, спросите первого встречного молодого человека: «Ой, ты знаешь, я не могу настроить часы на телефоне.
Не мог бы ты мне помочьЭ» и жалостливо улыбнуться.
Готово, у вас есть мотивированный пользователь с конкретной целью.
Будьте готовы к негативу
Хотя в реальных проектах мы фиксируем как недостатки, так и преимущества, в терапевтических целях прислушайтесь к совету: ищите только проблемы.Не ждите похвалы от пользователей.
Чем больше оскорблений и недоумений вы получили, тем лучше ваше юзабилити-тестирование.
Фотография разработчика, наблюдающего за тестированием и пускающего слюни, кричащего «Откуда вы взяли этих идиотовЭ» - чистая правда.
Будьте готовы к тому, что пользователи тупы.
Но вы делаете для них продукт. Вы даже можете рассчитывать на получение от них денег.
Возможно, вы рассчитываете делать это регулярно.
Так что будьте снисходительны.
Неважно, плохой интерфейс или глупый пользователь.
Важно, чтобы они нашли общий язык.
Если у вас есть силы и знания, как создать умных, платежеспособных и жаждущих пользователей для вашего продукта – ок, вперед! Если нет, то улучшите свой интерфейс.
Не давай мне никаких намеков
Хотя действительно вы можете встретить не особо умных пользователей, но давать им какие-либо подсказки или инструкции все равно не следует. Ваша задача не заставить пользователя дойти до конца и услышать его мнение (это для маркетинга).Ваша задача — понять, сможет ли пользователь самостоятельно достичь своей цели через ваш интерфейс.
Поставить цель
Цель должна жить вне интерфейса, вне продукта.При этом цель не в том, чтобы «на последнем этапе настройки телефона нажать последнюю кнопку», а в том, чтобы «получить телефон, пригодный для решения задач в реальной жизни» — например, показывающий правильное время.
.
Если у вас нет времени придумывать правдоподобные истории (о бабушке и настройке часов), вы можете остаться в интерфейсе.
Просто сформулируйте задачи со словами «Предположим, вы хотите изменить время на телефоне».
Если пользователь принимал предположение, что он чего-то хочет, он тем самым входил в игру и начинал изображать хоть какого-то мотивированного человека.
Убедитесь, что после слов «вы хотите» нет инструкции «…зайдите в раздел «настройки», перейдите к пункту «общие», затем выберите подпункт «основные»…
Как зафиксировать результаты?
Во-первых, каков результат тестирования? Проще говоря, юзабилити — это баланс между количеством шагов к цели и сложностью этих шагов.Зафиксировать количество шагов легко, а вот сложность — сложно.
Хоть и говорят, что качество интерфейса измеряется в децибелах и цензуре выражений, всё же предлагается считать время показателем сложности, исходя из логики «если сложно, то надо долго думать».
».
Соответственно, при быстром тестировании будет достаточно следующей матрицы: 
Как видите, здесь есть даже своего рода диагностика, которая сообщает, с каким типом проблемы столкнулся пользователь.
Записывать эти значения можно прямо головой, ручкой в блокноте, веб- или экшн-камерой (ее можно спрятать в волосах блондинки, которая просит молодого человека помочь ей с телефоном).
Если вы сможете написать простой логгер, сохраняющий количество кликов (нажатий, тапов, свайпов и других движений пользователя) и длительность сеанса, то у вас получится примитивный, но автоматизированный измеритель юзабилити*.
* Конечно, здесь есть ограничения и исключения.
Эта матрица плохо применима к развлекательным вещам: если я дважды коснулся экрана телефона, затем полтора часа смотрел на экран, а затем выключил его, это не обязательно означает, что я не смог выполнить задачу.
и отключил проклятое устройство в моем сердце.
Вполне вероятно, что я смотрел фильм, и плеер был настолько удобен, что не заставлял меня включать звук, отключать субтитры и делать прочую ерунду, не связанную с моей задачей просмотра 3-4 серий.
ситкома подряд. На этом все, будем рады ответить на вопросы в комментариях.
Спасибо за внимание! Автор: Антон Алябьев, аналитик UIDG. P.S. А вот та самая презентация, о которой говорилось в начале темы.
Теги: #сделай сам #интерфейсы #юзабилити-тестирование #мобильное тестирование #быстрое тестирование
-
Бериллий
19 Oct, 24 -
Искренняя Радость Большого Человека
19 Oct, 24 -
Viewdle Поднял Раунд
19 Oct, 24 -
Вышел Spb Shell 3D
19 Oct, 24 -
Оставьте Космос В Покое!!! Я Серьезно!!!
19 Oct, 24
