DIY: Мобильное тестирование

    Когда нашу компанию пригласили выступить на конференции Mobile Developer & Business Days с темой «Особенности быстрого тестирования мобильных интерфейсов», мы согласились, не раздумывая. Уж чего-чего, а этого добра мы натестировали достаточно много. Но я вовремя представил себе картину: вот я излагаю эти самые особенности, и меня просят рассказать о каком-нибудь проекте, выразительно быстром… Вообще-то, у нас все тестирования проходили весьма быстро. Львиная доля времени уходила обычно на документооборот, согласования, рекрут. Однако отказываться от выступления было поздно. Поэтому пришлось признаться на одном из первых слайдов, что у нас все тестирования быстрые, а методику быстроты построить на том, что можно опустить – как в проведении теста, так и в анализе результатов.



    История


    Слева на картинке выше – моя бабушка, тут ей лет 25-30. Справа – телефон Моторола, который мы купили бабушке, когда ей было лет 80. Дальше, наверно, ожидается пассаж о том, насколько мобильная техника охватила все слои пользователей. Или о том, как тяжело пожилым людям пользоваться современной мобильной техникой. Это всё правда, только тяжело пришлось не бабушке, а мне.

    Свою компетенцию в пользовании телефоном бабушка добровольно ограничила звонками, пользованием его часами и зарядкой батареи. Но про батарею она иногда забывала, и у телефон сбивались часы. Разумеется, все отладочно-профилактические работы легли на меня, как на самого близкоживущего внука. Так вот, на установку времени я тратил до 10 минут. Вернее, на поиск в меню нужного пункта. Сперва я пытался включать интуицию и логику, выбирая наиболее вероятные пункты. Затем переходил к сплошному перебору, исключая разве что игры. Бабушка махала рукой – «Да ладно, черт с ним». Но я не мог разрушить имидж заботливого внука и современного человека, я боролся до конца.

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

    Не такая большая проблема, чтобы выкинуть телефон в мусорку, основную задачу он решал – можно было позвонить с дачи домой. Но при следующем выборе мобильника после такого удара по самооценке, нанесённого Моторолой, на её телефоны я бы смотрел в последнюю очередь. К слову сказать, через какое-то время Моторола сама ушла с европейского и российского рынка. Не потому ли?.. А те, кто читал Купера, вспомнят его оценку модели Razr — отличный промышленный дизайн и франкенштейн вместо прошивки.

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

    ***
    Производителей телефонов немало, разработчиков софта – легион. Есть SDK, эмуляторы, средства по автоматизации тестирования – но только функционального. Можно заставить робота «нажимать» кнопки и дергать контролы вашего софта, либо рандомом, либо по записанному сценарию. А вот инструментов для пользовательского тестирования мало. И ориентированы они преимущественно на тесты открываемых с телефона сайтов, но не на приложения и, тем паче, не на сами прошивки.

    Аппаратная часть инструментария — тоже сплошной DYI: обычные веб-камеры, самодельные держатели для них, поиск позиции, чтобы не было бликов и камера не заслоняла обзор пользователю. Вот статья в подтверждение – о том, что даже профильные специалисты вынуждены выдумать и использовать подручные средства. А вот один из немногих примеров квази-промышленного помощника, созданного специально для мобильных исследований — http://www.mrtappy.com/. И то за 295 уе вы получите ещё не изделие, а конструктор:

    What will you get in the box?



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

    Но любой разработчик понимает, что сила — в знании! Функциональный код можно написать и в блокноте, если знаешь, как писать код. Так же и в тестировании — если знаешь, на что смотреть, то продуктивная сессия тестирования возможна и в метро через плечо попутчика.

    Что тестировать?


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

    Когда тестировать?


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

    Можно начать ещё раньше – если вы никак не можете понять, что именно вы хотите дать пользователям. В процессе общения с ними ваша идея может дозреть или увянуть.

    Не ждите!


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

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

    Где найти пользователей?


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

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

    С какого боку зайти на пользователя?


    Итак, у вас есть продукт или идея продукта, пользователи и решимость предъявить продукт пользователям. С какого боку зайти?

    Вообще у пользователя три бока: желание, мнение и опыт. Юзабилити обычно заходит со стороны опыта. Желание и мнение – стезя маркетинга, причем плохой маркетинг работает только над мнением, а хороший – еще и над желанием. Почему так?

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

    Желание — можно иметь, не обладая ни опытом, ни мнением. Но желание ценно само по себе, так как именно оно превращается в деньги.

    Опыт — можно иметь, только если пользуешься продуктом. Желание не обязательно.

    Желание хоть и не обязательно, но вообще заметно легче тестировать продукт на мотивированных пользователях – они бодрее, разговорчивее, искреннее. Изъяны у них тоже имеются — мотивированные пользователи «проглотят» часть проблем, не заметив их.

    Забегая сильно вперёд, уже куда-то в зарелизные дали, можно сказать, что Успех = сильное желание + удачный опыт. Как в это уравнение добавить хотя бы одну известную величину? В нашем случае это явно не опыт, поэтому подумаем о желании.

    На тестах нередко можно заметить одну вещь: если тест проводит девушка, а респондент – мужчина, то последний склонен несколько «петушиться», преувеличивать субъективную оценку своей успешности в выполнении заданий. В данном случае работает посторонняя мотивация – не к самому продукту или не к целям, при помощи его достигаемым. Но все же человек будет увлеченно тыкать во все кнопки, стараясь поставленной цели достичь. Как применить это на практике быстрого тестирования? Очень просто, чуть-чуть перекроим ситуацию с моей бабушкой.

    Наряжаетесь в блондинку, выходите в коридор, просите первого встречного молодого человека «Ой, вы знаете, у меня не получается часы на телефоне поставить… Вы не могли бы мне помочь?» и жалостливо улыбаетесь. Готово, перед вами мотивированный пользователь с конкретной целью.

    Готовьтесь к негативу


    Хотя в реальных проектах мы фиксируем как недостатки, так и достоинства, в терапевтических целях примите совет: ищите только проблемы. Не ждите от пользователей похвал. Чем больше ругани и недоумения вы получили, тем лучше вы провели юзабилити-тестирование.
    Картинка, где разработчик наблюдает за тестированием и брызжет слюной в крике «Где вы набрали этих идиотов?» — чистая правда.



    Будьте готовы к тому, что пользователи тупые. Но вы делаете продукт для них. Возможно, вы даже рассчитываете получить с них деньги. Возможно, вы рассчитываете делать это регулярно. Поэтому будьте снисходительны. Неважно, интерфейс плохой или пользователь глуп. Важно, чтобы они нашли общий язык. Если у вас есть силы и знание, как создавать умных, платёжеспособных и жаждущих именно ваш продукт пользователей – ок, вперёд! Если нет, то дорабатывайте свой интерфейс.

    Не подсказывайте


    Хотя вам и правда могут попасться не особо сообразительные пользователи, им все равно нельзя подсказывать и давать инструкции. Ваша задача — не заставить пользователя дойти до конца и услышать его мнение (это к маркетингу). Ваша задача – понять, сможет ли пользователь самостоятельно дойти через ваш интерфейс до своей цели.

    Ставьте цель


    Цель должна жить вне интерфейса, вне продукта. При этом цель – это не «нажать последнюю кнопку на последнем шаге настройки телефона», цель «получить телефон, пригодный для решения задач в реальной жизни» — например, показывающий правильное время.

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

    Следите, чтобы после слов «вы хотите», не затесалась инструкция «…зайти в раздел «настройки», перейти в пункт «общие», затем выбрать подпункт «основные»…

    Как фиксировать результаты?


    Во-первых, что является результатом тестирования? Если говорить упрощённо, то юзабилити – это баланс между количеством шагов к цели и сложностью этих шагов. Зафиксировать количество шагов легко, а вот сложность – сложно. Хотя и говорят, что качество интерфейса измеряется в децибелах и цензурности выражений, индикатором сложности всё-таки предлагается считать время, исходя из логики «если сложно, то приходится долго думать». Соответственно, в быстром тестировании достаточно будет такой матрицы:



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

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

    * Разумеется, тут есть свои ограничения и исключения. Такая матрица плохо применима к развлекательным штукам: если я два раза нажал на экран телефона, потом полтора часа пялился в экран, а затем выключил его, это не обязательно значит, что я не смог осилить задачу и в сердцах отрубил чертов девайс. Вполне вероятно, что я смотрел фильм, а плеер был настолько удобен, что не заставлял меня подкручивать звук, выключать субтитры и заниматься прочей ерундой, не относящейся к моей задаче посмотреть подряд 3-4 серии какого-нибудь ситкома.

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

    Автор: Антон Алябьев, аналитик UIDG.

    P. S. А вот и та самая презентация, о которой шла речь в начале топика.

    UIDG
    49.71
    Company
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 17

      +2
      Готовьтесь к негативу

      Может мне показалось, но совсем же никакой конкретики.
      Похоже на вводную лекцию для гуманитариев.
        0
        Да, стоило контекст пояснить — выступление было для непрофильных специалистов, именно как ликбез
        +1
        А почему с таблицы пропали обозначения, которые есть в слайдах? Собственно, непонятно, чего много, чего мало.
          0
          Глюк какой-то. Поправили.
          +3
          Razor? Не было таких телефонов у Motorola.
          Вообще у каждого производителя своя логика. И логика Motorola мне нравится. После своих моторов я готов был разбить об стенку мамину нокию нa S40, пытаясь найти будильник.
            0
            Аналогично. Да и в свое время к моторолкам было столько всякого софта, кастомыных прошивок, патчей и прочего, что они становились практически «умными». Чего стоит только один E398 (а структура меню настроек там идентичная с с257). Вопрос мог быть в установленном языковом пакете аля во всем виновата локализация
              +1
              Да, о E398 у меня остались только хорошие воспоминания. Все хочу себе купить новый, просто в коллекцию :)
                0
                Вы не одиноки. Сам такой, и многих таких же знаю)
              0
              От этого названия произошло Razr.
              Не у производителя, а у каждого разработчика новой модели телефона. Кроме Motorola. У Motorola была единая структура меню на все модели телефона, и раз попользовавшись C350 с любой другой их трубой не нужно переучиваться. После Motorola невозможно пользоваться Nokia (говорят, там самое удобное меню — по двум телефонам в длительном пользовании и куче настроенных не заметил такого), Sony Ericsson, Samsung (последних двух я даже не знаю за что покупали люди).
              Ну а не найти Settings — Initial Setup — Time & Date это всё-таки надо стараться. Хотя нет, надо всего лишь русский язык установить.
              +1
              >качество интерфейса измеряется в децибелах и цензурности выражений

              Порвало, просто порвало!
                +1
                Так или иначе, автор статьи прав. Люди, впервые столкнувшись с мобильным телефоном фирмы Motorola, имели трудности в первоначальной настройке аппарата. Именно отсюда и пошло известное многим мнение: «У телефонов Motorola слишком сложное, запутанное и нелогичное меню». Обычная корректировка времени вводила таких в людей в легкий ступор. На мой взгляд, причина этого кроется в этаком «сохранении традиций» компании и нежелании активно дорабатывать свой интерфейс.
                Еще в то время, когда телефоны Motorola были большие и монохромные, проектировщики интерфейсов решили разделить общий пункт настроек на несколько подпунктов:
                В пункт «Личные настройки» вынесли настройки фона, различные настройки кастомизации рабочего стола и интерфейса, а в пункт «Исходные (основные) настройки» попали настройки даты, выбора языка и уровня яркости дисплея.
                Именно эта парадигма и использовалась в течении всего срока жизни мотороловских P2K/Linux/ODM платформ.
                Поэтому, пользователи, использовавшие телефоны этого производителя ранее, привыкли к такому разделению, и находили его логичным, устоявшимся. А вот новички, начав использование подобных телефонов, явно испытывали затруднения.

                Проиллюстрирую то, что рассказал выше.

                Motorola C350 (год выпуска 2003):



                Для того, чтобы изменить дату, приходилось выполнить следующий «пробег» по пунктам меню:
                «Главное Меню» -> «Параметры» -> «Другие настройки» -> «Исходная настройка» -> «Время и дата».
                Согласитесь, для новичка, да и вообще для любого пользователя это уж точно не самое очевидное и логичное размещение данной настройки. Тем более, корректировка времени в данной модели телефона использовалась особенно часто, так как на его плате банально не было батарейки для работы «внутренних» часов после снятия основного аккумулятора. Поэтому, после смены SIM-карты или полной разрядки телефона с последующим выключением — необходимо было устанавливать время и дату заново. Функция корректировки времени/даты по сети оператора была, но вот только мало какой оператор в 2003 году поддерживал такую функцию.

                Motorola ROKR E1 (год выпуска 2005):



                Здесь, как видно, путь до изменения времени сократили на один пункт:
                «Главное Меню» -> «Параметры» -> «Основные настройки» -> «Время и дата».
                Это несомненно, повлекло за собой более логичный и быстрый доступ к этой весьма часто используемой настройке. Но разделение настроек на исходные (основные) и личные, несомненно осталось. Кстати, Motorola RAZR V3, выпущенный в тот же 2005-ый год использует полностью аналогичную структуру меню и подменю.

                Следует заметить, что подобное разделение настроек использовалось в большинстве телефонов этой марки на различных платформах, вплоть до полного перехода Motorola на Android. На мой взгляд, меню надо было сделать чуточку логичнее. Например, вынести настройку времени и те настройки, которыми тестеры пользуются наиболее часто в самый верхний подпункт. Или объединить «Личные» и «Исходные» настройки. В крайнем случае, хотя бы переименовать «Исходные» в «Системные», на мой скромный взгляд, слово «Системные» наиболее четко определяет список находившихся там настроек.

                Кстати, ваш Motorola C257 не совсем Motorola. Это ODM-телефон, изготовлявшийся, если мне не изменяет память, фирмой Acer. Однако, как видно из вашей статьи, разрабатывали прошивку Acer'овцы уж точно по строгим рекомендациям Motorola.
                  +1
                  Спасибо большое за развернутый комментарий. Из него становится ясно, что проблема была в целостном дизайне продукта: если нет возможности сделать аппаратный сервис («энергонезависимые» часы), то стоило хотя бы компенсировать это интерфейсом.

                  Для тестирования целостности дизайна тоже есть вполне известный способ, хоть и не очень быстрый, но хотя бы бюджетный — раздать образцы продукта родным и знакомым и регулярно опрашивать их об успехах. Этакие дневниковые исследования.
                    +1
                    По моему меню Motorola в то время, было гораздо удобнее многих, например самсунга того же времени. Многие функции настраиваются. У меня были c350 и L7 (оба еще живы), у жены Samsung x460, потом еще подобный, модель не помню. После этого был Rizr Z3, она до сих пор считает его удобным, даже имея современный Samsung с тачскрином.
                    Я к тому что каждому свое, что одному не удобно, то другой оценит как лучшее решение.
                    Кстати у L7 время не сбывается при севшей батареи, и большинство телефонов могут синхронизировать его с оператором.
                    0
                    Спасибо за интересную статью, а бабушке за хорошего внука :)
                      0
                      Конкретики у автора очень мало, слишком расплывчатые фразы и т.д. И самое главное: не путайте бабушек с обычными юзерами и Моторола тут не при чем. У моей бабушки нокия и ситуация похожая. Вопрос касаемо бабушек должен переходить в плоскость специальных девайсов для пенсионеров: с минималистическим меню интуитивно понятным, большим шрифтом и хардкнопками, долгой автономкой и парой горячих клавиш, желательно разного цвета и т.д.
                        0
                        Так описано как раз то, что мучениям с интерфейсом подверглась не бабушка, а вполне себе типовой персонаж — продвинутый пользователь гаджетов. Про конкретику — см. выше, целевой аудиторией были разработчики, которым хотелось дать представление о том, как быстро соорудить тестирование.
                          0
                          Типовой пользователь решал задачу, которая больше таки актуальна для бабушки. Я тоже типовой пользователей, особых затруднений старые моторолки никогда не вызывали.

                      Only users with full accounts can post comments. Log in, please.