Когда нашу компанию пригласили выступить на конференции Mobile Developer & Business Days с темой «Особенности быстрого тестирования мобильных интерфейсов», мы согласились, не раздумывая. Уж чего-чего, а этого добра мы натестировали достаточно много. Но я вовремя представил себе картину: вот я излагаю эти самые особенности, и меня просят рассказать о каком-нибудь проекте, выразительно быстром… Вообще-то, у нас все тестирования проходили весьма быстро. Львиная доля времени уходила обычно на документооборот, согласования, рекрут. Однако отказываться от выступления было поздно. Поэтому пришлось признаться на одном из первых слайдов, что у нас все тестирования быстрые, а методику быстроты построить на том, что можно опустить – как в проведении теста, так и в анализе результатов.
История
Слева на картинке выше – моя бабушка, тут ей лет 25-30. Справа – телефон Моторола, который мы купили бабушке, когда ей было лет 80. Дальше, наверно, ожидается пассаж о том, насколько мобильная техника охватила все слои пользователей. Или о том, как тяжело пожилым людям пользоваться современной мобильной техникой. Это всё правда, только тяжело пришлось не бабушке, а мне.
Свою компетенцию в пользовании телефоном бабушка добровольно ограничила звонками, пользованием его часами и зарядкой батареи. Но про батарею она иногда забывала, и у телефон сбивались часы. Разумеется, все отладочно-профилактические работы легли на меня, как на самого близкоживущего внука. Так вот, на установку времени я тратил до 10 минут. Вернее, на поиск в меню нужного пункта. Сперва я пытался включать интуицию и логику, выбирая наиболее вероятные пункты. Затем переходил к сплошному перебору, исключая разве что игры. Бабушка махала рукой – «Да ладно, черт с ним». Но я не мог разрушить имидж заботливого внука и современного человека, я боролся до конца.
Что показательно, такая же картина повторялась при каждой следующей необходимости установить время. При добавлении в сценарий ещё одного внука (у моей бабушки их восемь) результат не улучшался.
Не такая большая проблема, чтобы выкинуть телефон в мусорку, основную задачу он решал – можно было позвонить с дачи домой. Но при следующем выборе мобильника после такого удара по самооценке, нанесённого Моторолой, на её телефоны я бы смотрел в последнюю очередь. К слову сказать, через какое-то время Моторола сама ушла с европейского и российского рынка. Не потому ли?.. А те, кто читал Купера, вспомнят его оценку модели Razor – отличный промышленный дизайн и франкенштейн вместо прошивки.
Если бы разработчики потратили день или два на тестирование меню телефона моей бабушки, то, возможно, путем перестановки нескольких строк кода они бы заслужили для него бы репутацию нормального телефона и получили бы лояльного покупателя. Но увы.
***
Производителей телефонов немало, разработчиков софта – легион. Есть SDK, эмуляторы, средства по автоматизации тестирования – но только функционального. Можно заставить робота «нажимать» кнопки и дергать контролы вашего софта, либо рандомом, либо по записанному сценарию. А вот инструментов для пользовательского тестирования мало. И ориентированы они преимущественно на тесты открываемых с телефона сайтов, но не на приложения и, тем паче, не на сами прошивки.
Аппаратная часть инструментария — тоже сплошной DYI: обычные веб-камеры, самодельные держатели для них, поиск позиции, чтобы не было бликов и камера не заслоняла обзор пользователю. Вот статья в подтверждение – о том, что даже профильные специалисты вынуждены выдумать и использовать подручные средства. А вот один из немногих примеров квази-промышленного помощника, созданного специально для мобильных исследований — http://www.mrtappy.com/. И то за 295 уе вы получите ещё не изделие, а конструктор:
What will you get in the box?
Даже наш западный коллега сказал, что это неоправданно дорого, хотя в целом стоимость юзабилити-исследований на Западе выше.
Но любой разработчик понимает, что сила — в знании! Функциональный код можно написать и в блокноте, если знаешь, как писать код. Так же и в тестировании — если знаешь, на что смотреть, то продуктивная сессия тестирования возможна и в метро через плечо попутчика.
Что тестировать?
Всё. Если времени не хватает, то тестируйте всё, в чём сомневаетесь. И на всякий случай то, в чём вы больше всего уверены. Уверенность порождает слепоту и приводит к досадным упущениям.
Когда тестировать?
Как только вы поняли, что именно хотите дать пользователям. Возможно, заодно узнаете, хотят ли они это получить.
Можно начать ещё раньше – если вы никак не можете понять, что именно вы хотите дать пользователям. В процессе общения с ними ваша идея может дозреть или увянуть.
Не ждите!
Не ждите релиза, дизайна или одобрения стейкхолдеров. Во-первых, часто ни релиз, ни дизайн не меняют пользовательский опыт настолько, чтобы обесценить результаты тестов на бета-версии. Мы как-то ждали от заказчика релиз где-то с полгода. Продукт уже висел в аппсторе, собирал негативные отзывы, но нам не давали отмашки. Когда её дали, мы увидели, что в продукте не изменилось практически ничего.
Во-вторых, наверняка для любой стадии проекта можно придумать пригодный метод тестирования. Бумажный прототип стерпит всё. Даже если он мало что даст, он и отнимет немного.
Где найти пользователей?
Если вы работаете в каком-нибудь офисном центре, то ищите их в коридоре. Если у вас свое здание, используйте коллег, не участвующих в проекте. Если все работают над одним проектом, обратитесь к родственникам и знакомым.
Такой способ не поможет, если целевая аудитория должна обладать специфическими навыками. Например, приложение для менеджера по поставке табачной продукции поставит среднестатистического пользователя в тупик деловой терминологией. Хотя в качестве крэш-теста можно пойти и на это – по хорошему бизнес-приложению неподготовленный пользователь сможет хотя высказать гипотезы о его назначении. По плохому – не поймет вообще ничего.
С какого боку зайти на пользователя?
Итак, у вас есть продукт или идея продукта, пользователи и решимость предъявить продукт пользователям. С какого боку зайти?
Вообще у пользователя три бока: желание, мнение и опыт. Юзабилити обычно заходит со стороны опыта. Желание и мнение – стезя маркетинга, причем плохой маркетинг работает только над мнением, а хороший – еще и над желанием. Почему так?
Мнение о продукте — можно иметь, не пользуясь продуктом и не желая его. То есть оно может быть необосовано, немотивировано, недостоверно. Вычленять обоснованные, мотивированные и достоверные мнения – сложно, а мы не телепаты.
Желание — можно иметь, не обладая ни опытом, ни мнением. Но желание ценно само по себе, так как именно оно превращается в деньги.
Опыт — можно иметь, только если пользуешься продуктом. Желание не обязательно.
Желание хоть и не обязательно, но вообще заметно легче тестировать продукт на мотивированных пользователях – они бодрее, разговорчивее, искреннее. Изъяны у них тоже имеются — мотивированные пользователи «проглотят» часть проблем, не заметив их.
Забегая сильно вперёд, уже куда-то в зарелизные дали, можно сказать, что Успех = сильное желание + удачный опыт. Как в это уравнение добавить хотя бы одну известную величину? В нашем случае это явно не опыт, поэтому подумаем о желании.
На тестах нередко можно заметить одну вещь: если тест проводит девушка, а респондент – мужчина, то последний склонен несколько «петушиться», преувеличивать субъективную оценку своей успешности в выполнении заданий. В данном случае работает посторонняя мотивация – не к самому продукту или не к целям, при помощи его достигаемым. Но все же человек будет увлеченно тыкать во все кнопки, стараясь поставленной цели достичь. Как применить это на практике быстрого тестирования? Очень просто, чуть-чуть перекроим ситуацию с моей бабушкой.
Наряжаетесь в блондинку, выходите в коридор, просите первого встречного молодого человека «Ой, вы знаете, у меня не получается часы на телефоне поставить… Вы не могли бы мне помочь?» и жалостливо улыбаетесь. Готово, перед вами мотивированный пользователь с конкретной целью.
Готовьтесь к негативу
Хотя в реальных проектах мы фиксируем как недостатки, так и достоинства, в терапевтических целях примите совет: ищите только проблемы. Не ждите от пользователей похвал. Чем больше ругани и недоумения вы получили, тем лучше вы провели юзабилити-тестирование.
Картинка, где разработчик наблюдает за тестированием и брызжет слюной в крике «Где вы набрали этих идиотов?» — чистая правда.
Будьте готовы к тому, что пользователи тупые. Но вы делаете продукт для них. Возможно, вы даже рассчитываете получить с них деньги. Возможно, вы рассчитываете делать это регулярно. Поэтому будьте снисходительны. Неважно, интерфейс плохой или пользователь глуп. Важно, чтобы они нашли общий язык. Если у вас есть силы и знание, как создавать умных, платёжеспособных и жаждущих именно ваш продукт пользователей – ок, вперёд! Если нет, то дорабатывайте свой интерфейс.
Не подсказывайте
Хотя вам и правда могут попасться не особо сообразительные пользователи, им все равно нельзя подсказывать и давать инструкции. Ваша задача — не заставить пользователя дойти до конца и услышать его мнение (это к маркетингу). Ваша задача – понять, сможет ли пользователь самостоятельно дойти через ваш интерфейс до своей цели.
Ставьте цель
Цель должна жить вне интерфейса, вне продукта. При этом цель – это не «нажать последнюю кнопку на последнем шаге настройки телефона», цель «получить телефон, пригодный для решения задач в реальной жизни» — например, показывающий правильное время.
Если нет времени сочинять правдоподобные сюжеты (про бабушку и установку часов), можно оставаться в пределах интерфейса. Только формулируйте задачи словами «Предположим, вы хотите изменить время на телефоне». Если пользователь принял предположение, что он чего-то хочет, тем самым он вступил в игру и начал изображать хоть сколь-нибудь мотивированного человека.
Следите, чтобы после слов «вы хотите», не затесалась инструкция «…зайти в раздел «настройки», перейти в пункт «общие», затем выбрать подпункт «основные»…
Как фиксировать результаты?
Во-первых, что является результатом тестирования? Если говорить упрощённо, то юзабилити – это баланс между количеством шагов к цели и сложностью этих шагов. Зафиксировать количество шагов легко, а вот сложность – сложно. Хотя и говорят, что качество интерфейса измеряется в децибелах и цензурности выражений, индикатором сложности всё-таки предлагается считать время, исходя из логики «если сложно, то приходится долго думать». Соответственно, в быстром тестировании достаточно будет такой матрицы:
Как видите, здесь имеется даже некая диагностика, говорящая о том, какого типа проблемы повстречались пользователю.
Фиксировать эти величины можно непосредственно головой, ручкой в блокноте, веб- или экшн-камерой (её можно спрятать в шевелюре блондинки, которая просит молодого человека помочь ей с телефоном). Если вы в состоянии написать простенький логгер, который сохранит количество нажатий (щелчков, тапов, свайпов и других движений пользователя) и длительность сеанса, то вы получите примитивный, но автоматизированный измеритель юзабилити*.
* Разумеется, тут есть свои ограничения и исключения. Такая матрица плохо применима к развлекательным штукам: если я два раза нажал на экран телефона, потом полтора часа пялился в экран, а затем выключил его, это не обязательно значит, что я не смог осилить задачу и в сердцах отрубил чертов девайс. Вполне вероятно, что я смотрел фильм, а плеер был настолько удобен, что не заставлял меня подкручивать звук, выключать субтитры и заниматься прочей ерундой, не относящейся к моей задаче посмотреть подряд 3-4 серии какого-нибудь ситкома.
На этом, пожалуй все, будем рады ответить на вопросы в комментариях. Спасибо за внимание!
Автор: Антон Алябьев, аналитик UIDG.
P. S. А вот и та самая презентация, о которой шла речь в начале топика.
Автор: UiDesignGroup
