Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 20333 сообщений
Cообщения с меткой

планирование - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Планирование юзабилити-тестирования. Часть 2

Четверг, 18 Августа 2016 г. 19:37 (ссылка)





Привет, Хабр, с вами снова Наталия Спрогис, руководитель направления UX-исследований в Mail.Ru Group! Это вторая часть статьи о планировании юзабилити-тестирования. В первой я рассказывала о формулировке целей и гипотез, выборе метода тестирования и инструментов фиксации данных, а также об организационных моментах для исследователя. Эта часть посвящена составлению протокола (сценария) тестирования: продумыванию того, какие задания вы дадите респонденту, какие вопросы будете задавать, какие опросники предложите заполнить.



Протокол любого юзабилити-тестирования состоит из следующих частей:




  • Инструктаж/брифинг (приветствие, описание мероприятия, подписание документов)

  • Вводное интервью (проверка скрининга, небольшое интервью об использовании продукта, контексте и сценариях)

  • Работа с продуктом (задания тестирования)

  • Сбор итоговых впечатлений от продукта на основании опыта тестирования



Инструктаж/брифинг







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




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

  • Описать процесс. Расскажите, что за мероприятие ждёт респондента, сколько времени оно займёт, из каких частей оно состоит, что вы будете делать. Обязательно обратите внимание респондента на то, что его вклад поможет улучшить продукт и что вы не тестируете способности человека. Если вы ведёте видеозапись, предупредите об этом респондента и успокойте его, что данные не появятся в Сети. Я говорю примерно следующее:

    «Мы находимся в офисе компании Mail.Ru Group. Сегодня мы поговорим о проекте ХХХ. Это займёт около часа. Сначала мы немного побеседуем, потом я попрошу вас что-то попробовать сделать в самом проекте, а после мы обсудим ваши впечатления. Мы будем вести видеозапись того, что происходит в комнате и на экране компьютера. Запись нужна исключительно для анализа, в интернете вы себя не увидите. Мы проводим исследование, чтобы сделать проект ХХХ лучше, понять, что в нём нужно исправить и в какую сторону ему развиваться. Поэтому очень прошу вас открыто высказывать любые комментарии, и положительные, и отрицательные. Не бойтесь нас обидеть. Если при изучении проекта у вас что-то не получится, относитесь к этому спокойно. Значит, мы с вами нашли проблему, которую команде проекта нужно исправить. Самое главное — помните: мы не тестируем вас, это вы тестируете продукт. Если вы готовы, предлагаю начинать».

  • Подписать документы. Как правило, это согласие на обработку персональных данных, а иногда — соглашение о неразглашении информации о тестировании. Для тестов с несовершеннолетними необходимо согласие родителей на участие ребёнка в исследовании. Обычно мы высылаем его родителям заранее и просим принести его с собой. Обязательно объясните, зачем вы просите подписать документы, и дайте время изучить их. В России люди с опаской относятся к любым бумагам, которые требуется подписать.

  • Настроить оборудование. Если вы используете айтрекинг, биометрическое оборудование или просто ведёте видеозапись, самое время всё это включить. Предупредите респондента, когда начнёте запись.



Вводное интервью







Оно решает следующие задачи:




  • Проверить рекрутинг. На всякий случай всегда начинайте с этого — даже если вы доверяете агентству или человеку, который нашёл респондента. Не раз уже на тесте мы выясняли, что респондент неправильно понял вопросы и на самом деле пользуется продуктом не совсем так, как нам нужно. Старайтесь отойти от формальности и не задавать вопросы из скринингового опросника: человек может уже знать, что отвечать на них.

  • Сценарии и контекст использования продукта. Даже если у вас мало времени на тест, не пропускайте этот пункт. Хотя бы в целом узнайте у респондента, какие задачи он решает при помощи продукта, пользуется ли аналогичными проектами, в каких условиях взаимодействует с ними и с каких устройств. Знание особенностей использования продукта поможет вам лучше понимать причины поведения респондента. А если вы применяете гибкий сценарий — то и формулировать подходящие задания. Если хватает времени, попросите респондента показать, что и как он обычно делает. Это бывает источником дальнейших вопросов и инсайтов.

  • Ожидания и отношения. Начало тестирования — хорошее время узнать, что респондент знает о продукте, как относится к нему и чего от него ожидает. После теста вы сможете сравнить ожидания с итоговым впечатлением.



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



Работа с продуктом, составление заданий







Какие бывают задания



Давайте представим, что вы хотите протестировать интернет-магазин. У вас есть важные сценарии (поиск и выбор товара, процесс оформления заказа), известные проблемы (частые ошибки в форме оплаты) и даже гипотеза, что дизайнер что-то намудрил с фильтром по цене. Как же сформулировать задания?



Сфокусированные задания. Очевидным кажется сделать примерно такое задание:



«Выберите посудомоечную машину шириной 45 сантиметров с функцией „луч на полу“ стоимостью не более 30 тысяч рублей».



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




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

  • Отсутствие вовлечения. Подобные задания пользователи часто выполняют механически. Увидев первый товар, подходящий под критерии, они останавливаются. Возможно, в жизни респондент никогда не выбирал посудомойки и ему всё равно, что такое «луч на полу». Чем больше задание походит на ситуацию из реальной жизни, чем больше в нём понятного пользователю контекста, тем выше шансы вовлечь респондента, который представит, что на самом деле выбирает товар. А вовлечённый пользователь лучше «проживает интерфейс», оставляет больше комментариев, повышаются его шансы найти проблемы и дать полезные знания о поведении и особенностях аудитории.

  • Суженный спектр инсайтов. В реальной жизни пользователь бы, возможно, подбирал товар совсем не так. Например, вообще не пользуясь фильтрами (а тут вы на них указали). Или искал бы товар по критериям, которых нет на сайте. Давая жёсткие, сфокусированные задания, вы не узнаете о реальном контексте использования продукта, не найдёте сценариев, которые команда проекта, возможно, не предусмотрела, не соберёте данные о потребностях в контенте и функционале.



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



«Через час к вам придут гости. Найдите, что можно испечь за это время. У вас в холодильнике есть всё для бисквита, а также немножко слив. Но, к сожалению, нет сливочного масла».



Подобный подход можно использовать и с интернет-магазином. Например: «Представьте, что вы выбираете подарок сестре. У неё недавно сломался фен, и она была бы рада получить новый. Вам нужно уложиться в 7 тысяч рублей». Важно, чтобы респондент действительно выбрал реального человека, которому будет «покупаться» подарок (если нет сестры, предложите другого родственника или подругу). Ключевое для подобных заданий — реальность и понятность контекста. Легко представить, что ты выбираешь подарок родным, куда труднее — что ты «бухгалтер, составляющий годовой отчёт».



Яркий пример такого подхода — «метод Болливуда», который придумала индийский UX-эксперт Апала Лахири Чаван (Apala Lahiri Chavan). Она утверждает, что индусам, как и многим азиатам, сложно открыто высказывать своё мнение об интерфейсе. Зато, представляя себя героями вымышленных драматических ситуаций (как в любимых ими фильмах), они раскрываются и начинают живо участвовать в тестировании. Поэтому задания для индусов должны выглядеть примерно так:



«Представьте, что ваша любимая юная племянница собирается замуж. И тут вы узнаёте, что будущий муж — мошенник, да ещё и женатый! Вам нужно срочно купить два билета на рейс до Бангалора для себя и жены обманщика, чтобы расстроить свадьбу и спасти семью от позора. Торопитесь!»



Задания с опорой на опыт респондентов. Напомним: для успешного тестирования респонденты должны соответствовать аудитории проекта. Поэтому для проверки интернет-магазина бытовой техники мы рекрутируем тех, кто недавно выбирал технику или выбирает её сейчас. Именно этим мы будем пользоваться, составляя задания с опорой на опыт респондентов. Есть два варианта использования такого подхода:




  • Параметры респондентов. В этом случае вы адаптируете фиксированные задания под респондентов. Например, для случая с магазином бытовой техники и задачи на работу с фильтрами уточняете у человека, что именно он недавно приобрёл. Узнаёте критерии (цена, функции и т. д.) и предлагаете повторить «покупку» на вашем сайте.

  • Сценарии респондентов. Задания полностью формируются с опорой на опыт участников. Чтобы понять, какие сценарии проверить, модератор выясняет, как именно человек решал задачу в жизни, и предлагает сделать это на сайте. Например, покупатель долго сравнивал между собой несколько моделей перед выбором. Даже если на сайте нет подходящей функции, предложите респонденту сравнить товары, чтобы понять, на какие параметры он станет опираться. Возможно, вы получите идеи, как должна выглядеть функция сравнения, а также адаптируете под этот сценарий страницу товара.



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



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



Задания без заданий. Иногда лучше вообще не предлагать пользователям задания на работу с проектом, а посмотреть, с чего они сами начнут знакомство с продуктом. Дайте респонденту вводную: «Представьте, что вы решили попробовать этот продукт. Я оставлю вас на несколько минут. Делайте то, что вы стали бы делать в реальной жизни. Я не даю вам никаких заданий».



Важно, чтобы модератор при этом выходил из комнаты. В противном случае у пользователя появляется соблазн сразу же что-то спросить, уточнить: «А надо ли регистрироваться? А как вот это сделать?» и т. д.



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



Ещё одна область применения свободных заданий — контентные проекты. Если вы хотите понять, как читают ваши статьи, где надолго задерживаются, что пропускают, на какие элементы на странице обращают внимание и пр., то просто оставьте респондента на несколько минут наедине с проектом. Только без модератора, смотрящего через плечо, пользователь расслабится и будет читать текст так же, как обычно, в реальной жизни. Так мы тестируем проекты Новости Mail.Ru, Леди Mail.Ru и др. Этот подход позволил выделить разные модели поведения на сайте, разные паттерны чтения статей и понять, какие типы материалов стоит оформлять по-другому.



Составляем хорошие задания



Первое задание — простое. Начинайте тестирование с ознакомительных и несложных заданий. Респондент должен освоиться с форматом тестирования, особенно если вы используете метод «мысли вслух»: на первом задании человеку нужно привыкнуть к необходимости озвучивать свои мысли и чувства. Не стоит сразу вываливать на него всю боль и страдания интерфейса.



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



Следите за терминологией. Не используйте непонятные слова и обозначения. Это кажется очевидным, но мы часто, привыкнув к каким-то терминам, забываем, что их мало кто знает за пределами IT-тусовки. Например, при тестировании нового функционала тредов (цепочек писем) в Почте Mail.Ru нам пришлось достаточно сложно. Ведь у пользователей, незнакомых с подобным функционалом, просто нет в голове термина, который бы обозначал треды. В итоге мы никак их не называли. Мы просто показывали респондентам ящик с подключёнными цепочками и обсуждали эту новую возможность. В рамках обсуждения давали пользователям самим подобрать слово для обозначения тредов. Это помогло нам позже использовать наиболее понятные тексты в обучающих промоматериалах. Следите не только за заданиями, но и за вопросами модератора, особенно за теми, которые приходят от команды во время тестирования. Не стоит, например, использовать слово «тулбар» при обсуждении функций: оно не всем знакомо. Ещё несколько лет назад даже слово «браузер» знали далеко не все пользователи. То, как именно лучше сформулировать задания, зависит от аудитории тестирования. Не стоит кидаться и в обратную крайность, объясняя все термины подряд. Например, опытным игрокам не надо растолковывать, что такое «баф», «фраг», «респаун» и пр.



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



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



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



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



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



Оценивайте полезность задания. Подумайте, действительно ли оно соответствует вашим гипотезам. Например, вы хотите проверить функцию подписки на новости на сайте. Задание «Подпишитесь на новостную рассылку» позволит проверить только то, смогут ли найти рассылку те, кто будет её искать. Однако мы понимаем, что люди редко приходят на сайт, чтобы подписаться на новости. Задание не относится к реальной жизни. Вам же нужно понять, замечают ли возможность подписки те, кто выполняет совсем другие задачи. Проверять это можно разными способами — в зависимости от реализации функции. Если человек занимался заданиями, в которых ему на глаза могла попасть возможность подписки, спросите его, есть ли она на сайте. Только обязательно уточните, где он видел эту возможность или как она реализована, чтобы удостовериться, что респондент не просто с вами соглашается. Если предложение подписки встроено в процесс регистрации или оформления заказа, посмотрите, воспользуется ли им респондент, а после задания обсудите это. Очень мало шансов, что в лабораторных условиях люди реально подпишутся на рассылки, но можно проверить, обратил ли человек внимание на такую возможность, чего он ожидает от рассылки и т. п.



Сбор итоговых впечатлений







Цель заключительной фазы тестирования — собрать впечатления от работы с продуктом, понять, что понравилось пользователю, а что его расстроило, оценить субъективную удовлетворённость. Как правило, в этой части теста используется сочетание интервью с модератором и заполнения формальных опросников.



Интервью с модератором



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




  • Социальная желательность. Обращайтесь с результатами интервью очень аккуратно. Если во время теста вы часто слышите импульсивные комментарии под влиянием проблем, то в финальном интервью вовсю расцветает социальная желательность. Одним кажется, что, говоря о проблемах в продукте, они признаются в собственной некомпетентности. Другие просто не хотят расстраивать приятного в общении модератора. Очень часто респонденты (особенно женщины), которые промучились весь тест, говорят, что всё, в принципе, нормально. Отрицательные отзывы также могут быть продиктованы социальной желательностью: если респондент уверен, что цель теста — найти недостатки, он старательно пытается их отыскать.

  • Цитаты и приоритеты. Несмотря на то что все слова участников теста в финальном интервью часто нужно делить на два, а то и на десять, это не значит, что они бесполезны. По тому, как именно респонденты подытоживают впечатления, вы можете сделать вывод о приоритетах. Продукт — «полный отстой»? Что именно повлияло на это? Какую из многих проблем респондент запомнил больше всего и считает самой раздражающей? Однако делайте скидку на то, что лучше всего запоминается последнее задание. Также очень полезно отслеживать, какими прилагательными описывают продукт респонденты в разговоре, с чем сравнивают свой опыт.

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

  • Отношение к «хотелкам». Скорее всего, помимо своих впечатлений, респонденты будут также высказывать пожелания и идеи. Ваша задача — понять, какая проблема стоит за предложениями. Потому что решения, которые предложат пользователи, с высокой вероятностью вам не подойдут. Ведь участники тестирования — не дизайнеры, они не в курсе особенностей и ограничений разработки. Тем не менее за любым подобным запросом стоит потребность, которую вы должны зафиксировать. Если респондент говорит, что ему вот здесь непременно нужна большая зелёная кнопка, обязательно спросите — а зачем?



Мера удовлетворённости



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



Составление хорошего опросника — это отдельная и очень большая тема. Тут важны и формулировки, и шкалы, и многое другое. Поэтому хорошим подспорьем могут стать готовые и проверенные опросники. Они уже отточены и многократно протестированы. Проблема только в том, что почти у всех этих анкет нет официальных переводов на русский. Естественно, вы можете перевести их самостоятельно, но с методологической точки зрения переводы нужно протестировать, чтобы проверить корректность формулировок. Тем не менее анкеты могут стать ориентиром при составлении собственных опросников.



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





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




  • System Usability Scale (SUS) и Post-Study System Usability Questionnaire (PSSUQ). Два классических и популярных опросника, созданных более 20 лет назад. Оба состоят из утверждений. Респонденты должны указать степень согласия с ними. Все эти утверждения с разных сторон характеризуют юзабилити продукта. Например: «Я легко мог найти нужную информацию», «Разные возможности системы легко доступны» и т. д.

  • Microsoft Desirability Toolkit. Опросник, который часто помогает нам на тестах. Пользователю предоставляется набор прилагательных, из которых он выбирает те, что, на его взгляд, могут характеризовать продукт. В итоге вы получаете облако слов — характеристик вашего проекта. Часто эта методика приносит очень интересные результаты.

  • Game Experience Questionnaire. К играм нельзя применять классические юзабилити-опросники: вовлечённость в игровой процесс гораздо важнее, чем понятность интерфейсов. Поэтому для игр нужно всегда составлять особые опросники или пользоваться GEQ. Опросник содержит несколько модулей: базовый модуль, внутриигровой блок, постопросник и опросник социальных возможностей игры.



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



Заключение



Хорошее планирование позволит вам провести исследование, точно отвечающее целям заказчика и максимально полезное для проектной команды. Также грамотный план сокращает время подготовки отчёта. Однако, как бы хорошо вы ни подготовились, обязательно проведите пилотный тест на ком-нибудь из коллег или знакомых. Это позволит избежать казусов с неправильно настроенным оборудованием, покажет, укладываетесь ли вы в тайминг, понятны ли тексты заданий и нет ли опечаток в опросах.
Original source: habrahabr.ru.

https://habrahabr.ru/post/308054/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как планировать и оценивать проекты в Agile?

Понедельник, 15 Августа 2016 г. 12:50 (ссылка)

Несколько лет назад Тренер Luxoft Agile Practice — Вячеслав Москаленко столкнулся с проблемой, что многие Скрам-команды не оценивают все истории в Бэклоге Продукта. А зря, ведь оценка дает нам прозрачную картину реального прогресса и возможность управлять ожиданиями наших заказчиков, не дожидаясь финишной прямой нашего проекта, когда уже поздно что-то менять.



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



Когда я в первый раз провел игру-раскраску на одном из мастер-классов местной ПМ-тусовки, даже не ожидал, что достаточно консервативные менеджеры проведут так весело время и получат объяснение „Что такое относительный стори поинт? В чем его ценность?“. С тех пор я провел эту игру на многих тренингах и нескольких конференциях, включая SECR-2015 и Agile Days Russia 2016».






Цель



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



Время



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




  • 15 минут – оценка

  • 35 минут – завершить закрашивание (длительность итерации = 1 минута)

  • 10 минут – обсуждение



Подготовка:




  • Разбить группу на команды из 3-5 человек

  • Команды должны сидеть за столом

  • Один чистый лист флип-чарт бумаги на команду

  • Один флип-чарт маркер на одного участника



Инструкции



Оценка



1. Для каждой группы подготовить одинаковые флип-чарты с пустыми фигурками. См. пример ниже



image


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



image


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



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



Выполнение



1. Длина одной итерации не больше минуты.



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



3. Запускаем первую итерацию:



image


4. Ведущий принимает работу. Засчитываем только идеально закрашенные фигуры, либо сегменты (только если была предварительная разбивка). Команда считает Velocity.



5. Частично сделанная работа переоценивается в стори-поинтах в сторону уменьшения, но разница не добавляется в суммарную скорость (т.е. скорость показывает только принятую работу). У меня часто спрашивают «почему»? Я понимаю, что обидно терять поинты, когда история в конце спринта закончена на 90% (поинты пройдут как-бы мимо команды). Вопрос только в том чего хочет команда, показать высокую скорость или завысить ожидания заказчика? Возможно в этой незаконченной истории действительно осталось 10% работ. Но вдруг, доделывая эти 10%, вы обнаруживаете дефект, на решение которого вы потратите еще +50% вашего времени. А заказчикам то уже показали высокую скорость? Именно поэтому сообщество скрам-практиков не рекомендует включать в скорость (Velocity) любые недоделанные истории.



6. Команда пересчитывает сумму оставшихся стори-поинтов на флип-чарте и прогнозирует срок выполнения проекта по формуле.



Время выполнения = Сумма стори-поинтов\Velocity


Скорее всего срок выполнения будет отличаться от изначально запланированного



7. Повторяем шаги 1-6 до выполнения проекта по закраске:



image


8. Команда празднует завершение проекта.



image


Обсуждение



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



2. Если команды не заработали очков после первой итерации. Обсудите почему важно в конце итерации иметь готовый инкремент? Почему наполовину готовый инкремент не показывает прогресс? Почему наполовину готовый инкремент может дать большие погрешности в подсчете прогноза выполнения проекта?



3. Продемонстрируйте как нарисовать Release Burn-Down Chart, используя данные из таблицы.



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



5. Собрать и зафиксировать обратную связь от участников. Что они узнали нового? Чему научились? Что из упражнения можно пробовать в реальной жизни?



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



7. Исследуйте ценность разделения больших задач\историй (фигур) и как команды улучшались между итерациями.



Спасибо за внимание!



P.S. 29-31 августа Вячеслав проводит сертифицированный тренинг Professional Scrum Master в Москве.
Original source: habrahabr.ru.

https://habrahabr.ru/post/307760/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
sovet7ya

Планирование в бизнесе. Для чего оно?

Воскресенье, 14 Августа 2016 г. 20:43 (ссылка)

trains-96-1 (310x214, 12Kb)


Планирование в бизнесе. Для чего оно?



Многим бизнесменам «планёрка» считается пустой тратой времени. Просто лишняя и никому ненужная работа. А у маркетологов так вообще нет никакой тяги к планированию.



И всё же, планирование – это ключик к процветающему бизнесу. Вот и ответ на вопрос.



Человек так создан, что ещё в раннем детстве он начинал что-то планировать. К примеру, малыш хочет с верхней полки достать игрушку. Что он делает сначала? Мысленно планирует расстояние до полки, потом тянет стул, потом думает, двумя руками или одной лучше достанется игрушка.



Планирование в бизнесе – это не только достижение цели, но и своего рода обучение.



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



Правило всех маркетологов гласит так: « Планирование бизнеса не должно замещать действие».



Что это значит? Планирование в работе не должно быть чисто теоретическим, но и практическим. И понятное дело, что оно не должно проходить раз в год и откладываться далеко и надолго.



Мероприятие планёрки на работе позволяет всем сотрудникам видеть свои действия, как на бумаге, так и в действительности. Что надо сделать? Что предстоит сделать? Где поторопиться? А что может и подождать.



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





  1. Сколько стоит реклама?





  2. Сколько товара продано?





  3. Сколько товара на складе?





  4. Сколько надо иметь товара в запасе?





  5. Сколько средств на счёте?





  6. Будет ли готов новый товар к праздникам?





И многое, многое другое.



А если плана нет, то, как можно всё узнать и контролировать? Без него можно просто всё потерять и потерпеть колоссальные убытки. План, на него должны ссылаться, он должен всё время использоваться, маркетологи обязаны его улучшать и вносить новые и новые поправки. В иных сферах бизнеса, план – это документ. И этот документ есть у каждого в виде копии. И если его нет, то каждый сотрудник работает «по-своему», а не во благо фирме.



План – он побуждает сотрудников думать о будущем фирмы. А в иных сферах, он даже побуждает создавать будущее фирмы.



План представляет собой подробные этапы процесса. И он включает в себя:





  1. Исследование ситуации на рынке;





  2. Анализ рынка;





  3. Разработка стратегии;





  4. Документирование цели, стратегии и программы;





  5. Практика. Реализация. Оценка полученного. Контроль.





Итак, отвечая на вопрос: «Что такое план?», можно сказать так:



Планирование – это исследование рынка, анализ исследований; разработка целей и плана достижения этих целей; подсчёт ресурсов и возможностей.



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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Планирование юзабилити-тестирования. Часть 1

Четверг, 11 Августа 2016 г. 16:29 (ссылка)





Привет, Хабр! Это Наталия Спрогис из UX-лаборатории Mail.Ru Group. Сегодня я расскажу о планировании и подготовке такого вида исследований, как юзабилити-тестирование. Статья рассчитана в первую очередь на неопытных исследователей и тех, кто собирается впервые проводить юзабилити-тестирование.



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



Точно ли нужно тестирование?



Для начала вы должны быть уверены, что на данном этапе проекту нужно именно юзабилити-тестирование. Поэтому уточняйте реальные цели обращения к вам проектной команды. Юзабилити-тестирования не всемогущи, и уже на старте нужно понимать, что подобное исследование реально может принести продукту. Сразу подготовьте проектную команду к тому, на какие вопросы вы сможете дать ответы, а на какие нет. У нас бывали случаи, когда мы либо предлагали заказчикам другой метод (например, сейчас лучше подойдут глубинные интервью или дневниковые исследования) или даже вообще рекомендовали отказаться от исследования, а вместо этого сделать сплит-тест.



Например, мы никогда не беремся в качественных исследованиях проверять «привлекательность» какой-то функции или варианта дизайна. Мы можем собрать с пользователей отзывы, но слишком велик риск, что на их ответы повлияет социальная желательность. Люди всегда склонны сказать, что стали бы пользоваться даже тем, чем пользоваться не будут. Да и маленький размер выборки не позволяет доверять таким ответам. Так, например, у нас был неудачный опыт тестирования игровых лендингов. Когда лендинг, который выбирали как наиболее привлекательный на тесте, при A/B тестировании отработал гораздо хуже.



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



Основа для составления сценария юзабилити-теста



Планирование тестирования начинается не с составления текста заданий, а с детальной проработки целей и вопросов исследования совместно с проектной командой. Основной для составления плана являются:




  • Важные сценарии. Это те пользовательские сценарии (или задачи, или юзкейсы), которые влияют на бизнес или связаны с целью тестирования. Даже если команда подозревает проблемы в конкретных местах, часто стоит проверить основные кейсы. При этом важными для теста могут считаться следующие сценарии:




    • наиболее частотные (например, отправка сообщения в мессенджере);

    • влияющие на бизнес-цели (например, работа с платежной формой);

    • связанные с обновлением (те, которые затронул редизайн или внедрение нового функционала).





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




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




  • Гипотезы. Это то, во что преобразуются известные проблемы и вопросы команды. Хорошо, если заказчик приходит к вам с готовыми гипотезами. Например, «Наши клиенты платят только с телефона с комиссией. Возможно, пользователи не видят выбора более выгодного способа оплаты». Если же гипотез нет, а есть только желание проверить проект абстрактно «на юзабилити», то ваша задача эти гипотезы сформулировать.



Подумайте совместно с проектной командой о тех местах, где пользователи ведут себя не так, как ожидается (если такая информация есть). Выясните, нет ли элементов дизайна, над которыми много спорили, и они могут оказаться проблемными. А также сделайте собственный аудит продукта в поисках потенциальных сложностей для пользователей, которые важно проверить на тесте. Все это поможет вам составить список тех элементов (заданий, вопросов, проверок), которые должны войти в итоговый сценарий.



Метод сбора данных







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




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




  • Think Aloud (Мысли вслух). Долгое время этот метод использовался в юзабилити-тестированиях чаще всего. Якоб Нильсен в свое время называл его главным инструментом оценки юзабилити. Суть его в том, что вы просите респондента озвучивать все мысли, которые возникают у него при работе с интерфейсом и комментировать все свои действия. Это выглядит примерно так: «Сейчас я собираюсь добавить этот товар в корзину. А где же кнопка? А, вот она. Ой, я забыл посмотреть, какой там был цвет». Метод помогает вам понимать, почему пользователь ведет себя тем или иным образом, и какие эмоции вызывает у него текущее взаимодействие. Он дешев и прост, с ним справится даже неопытный исследователь. Однако у него есть свои недостатки. Во-первых, для людей не слишком естественно все время «думать вслух». Они будут часто замолкать, и вам придется им постоянно напоминать о том, что надо продолжать говорить. Во-вторых, задания при таком методе выполняются несколько дольше, чем в реальной жизни. Кроме того, часть респондентов начинает более вдумчиво пользоваться продуктом. Проговаривая причины своих действий, они стараются действовать более рационально, да и просто не хотят выглядеть идиотами. И вы можете не поймать какие-то интуитивные моменты поведения.




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




  • Retrospective think aloud (Ретроспектива). Это комбинация первых двух методов. Пользователь сначала выполняет все задания без вмешательства, а потом перед ним проигрывается видеозапись его работы, и он комментирует свое поведение и отвечает на вопросы модератора. Главный недостаток метода — сильное увеличение времени тестирования. Однако бывают случаи, когда он оптимален. Например, один раз перед нами встала задача протестировать несколько видов мобов (игровых монстров) в одной RPG-игре. Естественно, мы не могли ни отвлекать респондентов вопросами, ни заставлять их комментировать свои действия во время боя. Это бы сделало невозможным игру, где нужна концентрация для победы. С другой стороны, вспомнить после серии схваток, заметил ли он загоревшуюся красным секиру у первой крысы, пользователь вряд ли смог бы. Поэтому в этом тесте мы воспользовались RTA. С каждым пользователем мы пересматривали их бои и обсуждали, какие эффекты монстров они заметили, и как их поняли.



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



Метрики







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



Какие бывают метрики



Все мы, конечно, помним, что по ISO 9241-11 основными характеристиками юзабилити являются эффективность, продуктивность и удовлетворенность. Для разных проектов могут быть актуальны разные метрики, но все они, так или иначе, завязаны на эти три характеристики. Я напишу о наиболее часто используемых показателях:




  • Успешность выполнения заданий. Можно использовать бинарный код: справился, не справился с заданием. Мы чаще придерживаемся подхода Нильсена и выделяем три вида оценок успешности:




    • справился с заданием практически без проблем — 100%;

    • столкнулся с проблемами, но выполнил задание самостоятельно — 50%;

    • не справился с заданием — 0%.



    То есть, если из 12 респондентов 4 справились с заданием легко, 6 с проблемами, а 2 потерпели фиаско, то средняя успешность по этому заданию будет 58%. Иногда вы будете сталкиваться с ситуацией, когда в среднюю группу попадают очень разные по степени «проблемности» респонденты. Например, один респондент мог мучиться над каждым полем формы, а второй лишь немного ошибиться в самом конце. Вы можете давать оценку на собственное усмотрение, в зависимости от того, что произошло на тесте. Например, 25%, если респондент только начал выполнять задание или 80%, если допустил незначительную ошибку. Однако, чтобы избежать слишком большой субъективности, продумайте шкалы оценок заранее, а не решайте для каждого респондента после теста. Также вам стоит подумать, что делать с ошибками. Например, вы дали задание, купить билеты в кино на проекте Кино Mail.Ru. Один из респондентов случайно купил билет не на завтра, а на сегодня, и не заметил этого. Он уверен, что справился с заданием и действительно имеет билет на руках. Однако его ошибка настолько критична, что приведет к тому, что он не попадет в кино, поэтому я бы поставила «0%», несмотря на то, что билет куплен. Процент успешности — это очень простая и наглядная метрика. И я рекомендую ее использовать, если у ваших заданий есть четкие цели. Взгляд на график успешности по заданиям позволяет быстро понять, где самые проблемные места интерфейса.




  • Время выполнения заданий. Эта метрика показательна только в сравнении. Как вы поймете, плохо или хорошо то, что пользователь выполняет задачу за 30 секунд? А вот то, что время сократилось по сравнению с предыдущей версией дизайна, уже хорошо. Или то, что регистрация на нашем проекте занимает меньше времени, чем у конкурентов. Есть интерфейсы, где сокращение времени на выполнение задач критично. Например, рабочий интерфейс сотрудника колл-центра. Однако не для всех задач эта метрика в принципе применима. Возьмем, к примеру, задачу подбора товара в интернет-магазине. Пользователи должны быстро находить фильтры и другие элементы интерфейса, связанные с поиском товаров, но сам процесс выбора будет занимать у них разное время. И это совершенно нормально. Женщины при выборе туфель бывают готовы отсмотреть 20 страниц выдачи. И это необязательно значит, что на первых страницах не было подходящих товаров или что они не видят фильтры. Часто им просто хочется увидеть все варианты.




  • Частотность проблем. Любой отчет о юзабилити-тестировании содержит список проблем, с которыми столкнулись респонденты. То, сколько респондентов столкнулось с проблемой, является показателем частотности данной проблемы в рамках теста. Данную метрику можно применять только в том случае, если ваши пользователи выполняли абсолютно одинаковые задания. Если же в тесте были вариации или задания были не четко сформулированы, а составлены на основании интервью, то посчитать частотность будет сложно. Нужно будет считать не только столкнувшихся, но и оценивать то, сколько респондентов могло бы столкнуться с проблемой (выполняли схожую задачу, заходили в тот же раздел). Тем не менее, это достаточно полезная характеристика для команды, позволяющая понять, какие проблемы стоит исправлять в первую очередь.




  • Субъективная удовлетворенность. Это субъективная оценка пользователем удобства/комфорта работы с системой. Выявляется она при помощи различных опросников, которые респонденты заполняют в процессе или после тестирования. Есть стандартные опросники. Например, System Usability Scale (SUS), Post-Study Usability Questionnaire (PSSUQ) или Game Experience Questionnaire (GEQ) для игр. Или вы можете составить собственный опросник. Подробнее о способах оценки удовлетворенности во второй части статьи.



Это далеко не единственные возможные метрики. Вот, например, список из 10 UX-метрик, которые выделяет Джеф Сауро. Но для вашего продукта метрики могут быть другими. Например, с какого уровня респонденты разбираются в правилах игры, сколько ошибок допускают при заполнении длинных форм и прочее.



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




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




  • Отсутствие вмешательств. Любое общение с модератором может, как повлиять на метрики эффективности, если модератор невольно подскажет что-то респонденту, так и увеличивает время выполнения задания.




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




  • Критерии успешности. Заранее продумайте, какое именно поведение вы считаете успешным для данного задания. Допустимо ли, например, что при подборе товара в интернет магазине респондент не пользовался фильтрами.



Трактовка метрик



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



Джеф Сауро, эксперт по статистике в UX-исследованиях, советует представлять метрики не средними значениями, а всегда считать доверительные интервалы. Это гораздо правильнее, особенно если в результатах респондентов присутствует разброс. Для этого можно воспользоваться его бесплатными онлайн-калькуляторами: для успешностей и для времени выполнения заданий. Также не обойтись без статистической обработки и при сравнении результатов.



Когда нужны метрики



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




  • Доказать. Часто, особенно в крупных компаниях, необходимость внесения в продукт изменений необходимо доказать. Цифры наглядны, понятны и привычны для лиц, принимающих решения. Поэтому когда вы показываете, что 10 из 12 респондентов не смогли оплатить товар, или что регистрация в системе в среднем занимает в два раза больше, чем у конкурентов, это придает результатам исследования больший вес.




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




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




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



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



Способ фиксации данных







Казалось бы, чем плох блокнотик и ручка или просто открытый документ Word? В современном Agile мире разработки UX-исследователи должны стараться максимально быстро выдавать команде результаты своих наблюдений. Чтобы оптимизировать время на анализ, хорошо заранее заготовить шаблон для ввода ваших заметок в процессе теста. Мы пробовали делать это в специализированном ПО (например, Noldus Observer или Morae Manager), но на практике наиболее гибкими и универсальными оказались таблицы. Заранее разметьте в таблице вопросы, которые точно планируете задавать, места под ввод проблем, обнаруженных в различных заданиях, а также гипотезы (вы будете помечать, подтвердилась она или нет на каждом респонденте). Наши таблички выглядят подобным образом:












































Респондент 1 Респондент 2 Респондент 3 Респондент 4
Задание 1
Заметил ли функцию А?
В каком месте искал возможность Б?
Проблемы и наблюдения по заданию
Вы также можете воспользоваться:




  • Usability Test Data Logger от Userfocus. Кастомизируемый шаблон Excel для ввода наблюдений по каждому респонденту. Есть встроенный таймер для измерения времени выполнения заданий и автоматически генерируемые графики времени и успешности.




  • Rainbow Spreadsheet от Томера Шерона из Google. Наглядная таблица для совместной работы исследователя и команды. По ссылке статья с описанием метода, там же есть ссылка на Google-таблицу с шаблоном.



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



Подготовка к тестированию



Помимо метода, метрик и непосредственно протокола тестирования, вам необходимо определиться со следующим:




  • Формат общения с модератором. Модератор может находиться в одной комнате с участником тестирования, в этом случае ему будет легко вовремя задавать вопросы. Однако присутствие модератора может влиять на респондента. Он может начать задавать вопросы модератору, провоцируя того явно или неявно подсказать ему. По возможности, мы стараемся хотя бы на часть теста оставлять респондента наедине с продуктом. Так его поведение становится более раскованным и естественным. А чтобы не бегать туда-сюда, если что-то пойдет не так, вы можете оставить включенным любой мессенджер с аудиосвязью, чтобы модератор имел возможность связаться с респондентом из наблюдательной комнаты.




  • Способ постановки заданий. Задания может озвучивать модератор. Но в этом случае, несмотря на единый протокол тестирования, каждый раз текст задания может произноситься немного по-разному. Особенно это актуально, если тест ведет несколько модераторов. Иногда, даже небольшие различия в формулировках могут поставить респондентов в разные начальные условия. Чтобы избежать этой проблемы, можно либо «надрессировать» модераторов всегда читать тексты задания, либо выдавать задания респондентам на листочках или на экране. Различие формулировок не проблема для вас, если вы используете гибкий сценарий, при котором задания формулируются в процессе теста, на основании интервью с модератором.



    Кроме того, интересным может быть вариант использования средств продукта для постановки заданий. Так, например, при тестировании ICQ задания респонденты получали через окно чата с модератором, а при тестировании Почты Mail.Ru они приходили в письмах. Такой способ постановки заданий был максимально естественен для этих проектов, а еще мы многократно обкатывали базовые сценарии переписки.




  • Создание естественного контекста. Даже если мы говорим о лабораторных исследованиях, подумайте, как вы можете приблизить использование продукта на тесте к реальным условиям. Например, если вы тестируете мобильные устройства, как респонденты будут держать их? Для хорошего изображения на видеозаписи лучше, когда телефон или планшет фиксированы на стенде или лежат на столе. Однако это не дает понять, все ли зоны доступны и удобны для нажатия. Ведь телефоны часто держат одной рукой, а с планшетами лежат на диване. Также стоит подумать об обстановке, в которой будет использоваться продукт: есть ли отвлечения, шумно ли, хороший ли интернет. Все это можно пытаться имитировать в лаборатории.




  • План теста для заказчика. Это также важный этап подготовки, так как он вовлекает проектную команду. Вы можете не посвящать заказчика во все методологические особенности теста (как будете общаться с респондентом, фиксировать данные и прочее). Но обязательно покажите ему, какие будут задания, и что вы на них собираетесь проверять. Возможно, вы не учли какие-то особенности проекта, а может быть, у команды проекта появятся какие-то дополнительные идеи и гипотезы. У нас обычно получается подобная табличка:










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

    • Находят ли правильную категорию

    • Заметность фильтров

    • Есть ли сложности с фильтром по цене

    • Достаточность фильтров

    • И т.д.


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



Заключение



Конечно, вы можете просто «дать попользоваться продуктом» своему другу и наблюдать за тем, какие сложности у него возникнут. Но грамотно составленный сценарий позволит вам не упустить важные проблемы и не натолкнуть случайно респондента на нужные вам ответы. Ведь юзабилити-тестирование — это упрощенный эксперимент, а у любого эксперимента важна предварительная подготовка. В следующей части статьи я расскажу о составлении протокола тестирования: с чего начать тест, какие вопросы задать респонденту, как сформулировать задания и как собрать итоговые впечатления.
Original source: habrahabr.ru.

https://habrahabr.ru/post/307556/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Планирование юзабилити-тестирования. Часть 1

Четверг, 11 Августа 2016 г. 16:29 (ссылка)

Привет, Хабр! Это Наталия Спрогис из UX-лаборатории Mail.Ru Group. Сегодня я расскажу о планировании и подготовке такого вида исследований, как юзабилити-тестирование. Статья рассчитана в первую очередь на неопытных исследователей и тех, кто собирается впервые проводить юзабилити-тестирование.







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



Точно ли нужно тестирование?



Для начала вы должны быть уверены, что на данном этапе проекту нужно именно юзабилити-тестирование. Поэтому уточняйте реальные цели обращения к вам проектной команды. Юзабилити-тестирования не всемогущи, и уже на старте нужно понимать, что подобное исследование реально может принести продукту. Сразу подготовьте проектную команду к тому, на какие вопросы вы сможете дать ответы, а на какие нет. У нас бывали случаи, когда мы либо предлагали заказчикам другой метод (например, сейчас лучше подойдут глубинные интервью или дневниковые исследования) или даже вообще рекомендовали отказаться от исследования, а вместо этого сделать сплит-тест.



Например, мы никогда не беремся в качественных исследованиях проверять «привлекательность» какой-то функции или варианта дизайна. Мы можем собрать с пользователей отзывы, но слишком велик риск, что на их ответы повлияет социальная желательность. Люди всегда склонны сказать, что стали бы пользоваться даже тем, чем пользоваться не будут. Да и маленький размер выборки не позволяет доверять таким ответам. Так, например, у нас был неудачный опыт тестирования игровых лендингов. Когда лендинг, который выбирали как наиболее привлекательный на тесте, при A/B тестировании отработал гораздо хуже.



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



Основа для составления сценария юзабилити-теста



Планирование тестирования начинается не с составления текста заданий, а с детальной проработки целей и вопросов исследования совместно с проектной командой. Основной для составления плана являются:




  • Важные сценарии. Это те пользовательские сценарии (или задачи, или юзкейсы), которые влияют на бизнес или связаны с целью тестирования. Даже если команда подозревает проблемы в конкретных местах, часто стоит проверить основные кейсы. При этом важными для теста могут считаться следующие сценарии:




    • наиболее частотные (например, отправка сообщения в мессенджере);

    • влияющие на бизнес-цели (например, работа с платежной формой);

    • связанные с обновлением (те, которые затронул редизайн или внедрение нового функционала).





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




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




  • Гипотезы. Это то, во что преобразуются известные проблемы и вопросы команды. Хорошо, если заказчик приходит к вам с готовыми гипотезами. Например, «Наши клиенты платят только с телефона с комиссией. Возможно, пользователи не видят выбора более выгодного способа оплаты». Если же гипотез нет, а есть только желание проверить проект абстрактно «на юзабилити», то ваша задача эти гипотезы сформулировать.



Подумайте совместно с проектной командой о тех местах, где пользователи ведут себя не так, как ожидается (если такая информация есть). Выясните, нет ли элементов дизайна, над которыми много спорили, и они могут оказаться проблемными. А также сделайте собственный аудит продукта в поисках потенциальных сложностей для пользователей, которые важно проверить на тесте. Все это поможет вам составить список тех элементов (заданий, вопросов, проверок), которые должны войти в итоговый сценарий.



Метод сбора данных







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




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




  • Think Aloud (Мысли вслух). Долгое время этот метод использовался в юзабилити-тестированиях чаще всего. Якоб Нильсен в свое время называл его главным инструментом оценки юзабилити. Суть его в том, что вы просите респондента озвучивать все мысли, которые возникают у него при работе с интерфейсом и комментировать все свои действия. Это выглядит примерно так: «Сейчас я собираюсь добавить этот товар в корзину. А где же кнопка? А, вот она. Ой, я забыл посмотреть, какой там был цвет». Метод помогает вам понимать, почему пользователь ведет себя тем или иным образом, и какие эмоции вызывает у него текущее взаимодействие. Он дешев и прост, с ним справится даже неопытный исследователь. Однако у него есть свои недостатки. Во-первых, для людей не слишком естественно все время «думать вслух». Они будут часто замолкать, и вам придется им постоянно напоминать о том, что надо продолжать говорить. Во-вторых, задания при таком методе выполняются несколько дольше, чем в реальной жизни. Кроме того, часть респондентов начинает более вдумчиво пользоваться продуктом. Проговаривая причины своих действий, они стараются действовать более рационально, да и просто не хотят выглядеть идиотами. И вы можете не поймать какие-то интуитивные моменты поведения.




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




  • Retrospective think aloud (Ретроспектива). Это комбинация первых двух методов. Пользователь сначала выполняет все задания без вмешательства, а потом перед ним проигрывается видеозапись его работы, и он комментирует свое поведение и отвечает на вопросы модератора. Главный недостаток метода — сильное увеличение времени тестирования. Однако бывают случаи, когда он оптимален. Например, один раз перед нами встала задача протестировать несколько видов мобов (игровых монстров) в одной RPG-игре. Естественно, мы не могли ни отвлекать респондентов вопросами, ни заставлять их комментировать свои действия во время боя. Это бы сделало невозможным игру, где нужна концентрация для победы. С другой стороны, вспомнить после серии схваток, заметил ли он загоревшуюся красным секиру у первой крысы, пользователь вряд ли смог бы. Поэтому в этом тесте мы воспользовались RTA. С каждым пользователем мы пересматривали их бои и обсуждали, какие эффекты монстров они заметили, и как их поняли.



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



Метрики







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



Какие бывают метрики



Все мы, конечно, помним, что по ISO 9241-11 основными характеристиками юзабилити являются эффективность, продуктивность и удовлетворенность. Для разных проектов могут быть актуальны разные метрики, но все они, так или иначе, завязаны на эти три характеристики. Я напишу о наиболее часто используемых показателях:




  • Успешность выполнения заданий. Можно использовать бинарный код: справился, не справился с заданием. Мы чаще придерживаемся подхода Нильсена и выделяем три вида оценок успешности:




    • справился с заданием практически без проблем — 100%;

    • столкнулся с проблемами, но выполнил задание самостоятельно — 50%;

    • не справился с заданием — 0%.



    То есть, если из 12 респондентов 4 справились с заданием легко, 6 с проблемами, а 2 потерпели фиаско, то средняя успешность по этому заданию будет 58%. Иногда вы будете сталкиваться с ситуацией, когда в среднюю группу попадают очень разные по степени «проблемности» респонденты. Например, один респондент мог мучиться над каждым полем формы, а второй лишь немного ошибиться в самом конце. Вы можете давать оценку на собственное усмотрение, в зависимости от того, что произошло на тесте. Например, 25%, если респондент только начал выполнять задание или 80%, если допустил незначительную ошибку. Однако, чтобы избежать слишком большой субъективности, продумайте шкалы оценок заранее, а не решайте для каждого респондента после теста. Также вам стоит подумать, что делать с ошибками. Например, вы дали задание, купить билеты в кино на проекте Кино Mail.Ru. Один из респондентов случайно купил билет не на завтра, а на сегодня, и не заметил этого. Он уверен, что справился с заданием и действительно имеет билет на руках. Однако его ошибка настолько критична, что приведет к тому, что он не попадет в кино, поэтому я бы поставила «0%», несмотря на то, что билет куплен. Процент успешности — это очень простая и наглядная метрика. И я рекомендую ее использовать, если у ваших заданий есть четкие цели. Взгляд на график успешности по заданиям позволяет быстро понять, где самые проблемные места интерфейса.




  • Время выполнения заданий. Эта метрика показательна только в сравнении. Как вы поймете, плохо или хорошо то, что пользователь выполняет задачу за 30 секунд? А вот то, что время сократилось по сравнению с предыдущей версией дизайна, уже хорошо. Или то, что регистрация на нашем проекте занимает меньше времени, чем у конкурентов. Есть интерфейсы, где сокращение времени на выполнение задач критично. Например, рабочий интерфейс сотрудника колл-центра. Однако не для всех задач эта метрика в принципе применима. Возьмем, к примеру, задачу подбора товара в интернет-магазине. Пользователи должны быстро находить фильтры и другие элементы интерфейса, связанные с поиском товаров, но сам процесс выбора будет занимать у них разное время. И это совершенно нормально. Женщины при выборе туфель бывают готовы отсмотреть 20 страниц выдачи. И это необязательно значит, что на первых страницах не было подходящих товаров или что они не видят фильтры. Часто им просто хочется увидеть все варианты.




  • Частотность проблем. Любой отчет о юзабилити-тестировании содержит список проблем, с которыми столкнулись респонденты. То, сколько респондентов столкнулось с проблемой, является показателем частотности данной проблемы в рамках теста. Данную метрику можно применять только в том случае, если ваши пользователи выполняли абсолютно одинаковые задания. Если же в тесте были вариации или задания были не четко сформулированы, а составлены на основании интервью, то посчитать частотность будет сложно. Нужно будет считать не только столкнувшихся, но и оценивать то, сколько респондентов могло бы столкнуться с проблемой (выполняли схожую задачу, заходили в тот же раздел). Тем не менее, это достаточно полезная характеристика для команды, позволяющая понять, какие проблемы стоит исправлять в первую очередь.




  • Субъективная удовлетворенность. Это субъективная оценка пользователем удобства/комфорта работы с системой. Выявляется она при помощи различных опросников, которые респонденты заполняют в процессе или после тестирования. Есть стандартные опросники. Например, System Usability Scale (SUS), Post-Study Usability Questionnaire (PSSUQ) или Game Experience Questionnaire (GEQ) для игр. Или вы можете составить собственный опросник. Подробнее о способах оценки удовлетворенности во второй части статьи.



Это далеко не единственные возможные метрики. Вот, например, список из 10 UX-метрик, которые выделяет Джеф Сауро. Но для вашего продукта метрики могут быть другими. Например, с какого уровня респонденты разбираются в правилах игры, сколько ошибок допускают при заполнении длинных форм и прочее.



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




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




  • Отсутствие вмешательств. Любое общение с модератором может, как повлиять на метрики эффективности, если модератор невольно подскажет что-то респонденту, так и увеличивает время выполнения задания.




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




  • Критерии успешности. Заранее продумайте, какое именно поведение вы считаете успешным для данного задания. Допустимо ли, например, что при подборе товара в интернет магазине респондент не пользовался фильтрами.



Трактовка метрик



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



Джеф Сауро, эксперт по статистике в UX-исследованиях, советует представлять метрики не средними значениями, а всегда считать доверительные интервалы. Это гораздо правильнее, особенно если в результатах респондентов присутствует разброс. Для этого можно воспользоваться его бесплатными онлайн-калькуляторами: для успешностей и для времени выполнения заданий. Также не обойтись без статистической обработки и при сравнении результатов.



Когда нужны метрики



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




  • Доказать. Часто, особенно в крупных компаниях, необходимость внесения в продукт изменений необходимо доказать. Цифры наглядны, понятны и привычны для лиц, принимающих решения. Поэтому когда вы показываете, что 10 из 12 респондентов не смогли оплатить товар, или что регистрация в системе в среднем занимает в два раза больше, чем у конкурентов, это придает результатам исследования больший вес.




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




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




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



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



Способ фиксации данных







Казалось бы, чем плох блокнотик и ручка или просто открытый документ Word? В современном Agile мире разработки UX-исследователи должны стараться максимально быстро выдавать команде результаты своих наблюдений. Чтобы оптимизировать время на анализ, хорошо заранее заготовить шаблон для ввода ваших заметок в процессе теста. Мы пробовали делать это в специализированном ПО (например, Noldus Observer или Morae Manager), но на практике наиболее гибкими и универсальными оказались таблицы. Заранее разметьте в таблице вопросы, которые точно планируете задавать, места под ввод проблем, обнаруженных в различных заданиях, а также гипотезы (вы будете помечать, подтвердилась она или нет на каждом респонденте). Наши таблички выглядят подобным образом:












































Респондент 1 Респондент 2 Респондент 3 Респондент 4
Задание 1
Заметил ли функцию А?
В каком месте искал возможность Б?
Проблемы и наблюдения по заданию
Вы также можете воспользоваться:




  • Usability Test Data Logger от Userfocus. Кастомизируемый шаблон Excel для ввода наблюдений по каждому респонденту. Есть встроенный таймер для измерения времени выполнения заданий и автоматически генерируемые графики времени и успешности.




  • Rainbow Spreadsheet от Томера Шерона из Google. Наглядная таблица для совместной работы исследователя и команды. По ссылке статья с описанием метода, там же есть ссылка на Google-таблицу с шаблоном.



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



Подготовка к тестированию



Помимо метода, метрик и непосредственно протокола тестирования, вам необходимо определиться со следующим:




  • Формат общения с модератором. Модератор может находиться в одной комнате с участником тестирования, в этом случае ему будет легко вовремя задавать вопросы. Однако присутствие модератора может влиять на респондента. Он может начать задавать вопросы модератору, провоцируя того явно или неявно подсказать ему. По возможности, мы стараемся хотя бы на часть теста оставлять респондента наедине с продуктом. Так его поведение становится более раскованным и естественным. А чтобы не бегать туда-сюда, если что-то пойдет не так, вы можете оставить включенным любой мессенджер с аудиосвязью, чтобы модератор имел возможность связаться с респондентом из наблюдательной комнаты.




  • Способ постановки заданий. Задания может озвучивать модератор. Но в этом случае, несмотря на единый протокол тестирования, каждый раз текст задания может произноситься немного по-разному. Особенно это актуально, если тест ведет несколько модераторов. Иногда, даже небольшие различия в формулировках могут поставить респондентов в разные начальные условия. Чтобы избежать этой проблемы, можно либо «надрессировать» модераторов всегда читать тексты задания, либо выдавать задания респондентам на листочках или на экране. Различие формулировок не проблема для вас, если вы используете гибкий сценарий, при котором задания формулируются в процессе теста, на основании интервью с модератором.



    Кроме того, интересным может быть вариант использования средств продукта для постановки заданий. Так, например, при тестировании ICQ задания респонденты получали через окно чата с модератором, а при тестировании Почты Mail.Ru они приходили в письмах. Такой способ постановки заданий был максимально естественен для этих проектов, а еще мы многократно обкатывали базовые сценарии переписки.




  • Создание естественного контекста. Даже если мы говорим о лабораторных исследованиях, подумайте, как вы можете приблизить использование продукта на тесте к реальным условиям. Например, если вы тестируете мобильные устройства, как респонденты будут держать их? Для хорошего изображения на видеозаписи лучше, когда телефон или планшет фиксированы на стенде или лежат на столе. Однако это не дает понять, все ли зоны доступны и удобны для нажатия. Ведь телефоны часто держат одной рукой, а с планшетами лежат на диване. Также стоит подумать об обстановке, в которой будет использоваться продукт: есть ли отвлечения, шумно ли, хороший ли интернет. Все это можно пытаться имитировать в лаборатории.




  • План теста для заказчика. Это также важный этап подготовки, так как он вовлекает проектную команду. Вы можете не посвящать заказчика во все методологические особенности теста (как будете общаться с респондентом, фиксировать данные и прочее). Но обязательно покажите ему, какие будут задания, и что вы на них собираетесь проверять. Возможно, вы не учли какие-то особенности проекта, а может быть, у команды проекта появятся какие-то дополнительные идеи и гипотезы. У нас обычно получается подобная табличка:










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

    • Находят ли правильную категорию

    • Заметность фильтров

    • Есть ли сложности с фильтром по цене

    • Достаточность фильтров

    • И т.д.


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



Заключение



Конечно, вы можете просто «дать попользоваться продуктом» своему другу и наблюдать за тем, какие сложности у него возникнут. Но грамотно составленный сценарий позволит вам не упустить важные проблемы и не натолкнуть случайно респондента на нужные вам ответы. Ведь юзабилити-тестирование — это упрощенный эксперимент, а у любого эксперимента важна предварительная подготовка. В следующей части статьи я расскажу о составлении протокола тестирования: с чего начать тест, какие вопросы задать респонденту, как сформулировать задания и как собрать итоговые впечатления.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307556/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
justvitek

Советы от Дэна Кеннеди по планированию времени

Понедельник, 01 Августа 2016 г. 15:55 (ссылка)


10 советов от Дэна Кеннеди по планированию времени



Техника №1. Приручение телефона




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



Техника №2. Минимум деловых встреч



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



Техника №3. Абсолютная пунктуальность



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



Техника №4. Составление списков



Не существует системы планирования времени, которая не опиралась бы на составление списков дел. Все помнить НЕВОЗМОЖНО. Если вы «свободная натура», вам, вероятно, кажется, что списки сдавливают вас, как трусы на размер меньше. Но на самом деле списки освобождают: чем больше мелочей вы запишете, тем меньше вам придется держать в голове. И тогда ваш мозг готов заняться действительно важной работой.



Техника №5. Всё – на службу своим целям



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



Техника №6. Каталог событий



Берете 90 папок, каждая тридцатка – это месяц: текущий и два следующих. И рассовываете по ним письма, факсы, материалы в соответствии с тем днем, когда вы собираетесь встречаться с этими клиентами и заниматься этими делами. Да, я знаю, что есть много компьютерных программ, которые делают то же самое, и если вы хотите пойти по этому пути – бога ради. Мне удобнее так. Но какой бы вы ни выбрали вариант, бумажный или цифровой, каталог событий – это исключительно полезная техника.



Техника №7. Времяблоки



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



Техника №8. Минимум внеплановой деятельности



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



Техника №9. Польза от «обрезков»



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



Техника №10. Подальше от потока



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



4208855_PTBAxDtFdIc (604x483, 81Kb)

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Elena_52

Без заголовка

Воскресенье, 31 Июля 2016 г. 17:21 (ссылка)

Это цитата сообщения Капочка_Капа Оригинальное сообщение

КАК СПЛАНИРОВАТЬ ШКАФ МЕЧТЫ.




Хранение вещей в небольших, да и в любых пространствах - вопрос весьма актуальный, а удобное хранение - вдвойне актуальная проблема.



Итак, как спланировать шкаф мечты? Для начала его нужно нарисовать, а это, как оказывается, самое сложное.







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



Основные шаги по грамотной организации и хранению вещей в шкафах вашего дома:



Шаг 1. Понять где будет стоять шкаф, для каких целей он предназначается и какие вещи там будут храниться.



Шкафы можно разделить по такому принципу:

Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Sveta-N

Кенозерье - 2016. Техническая сторона

Среда, 13 Июля 2016 г. 20:57 (ссылка)


Транспорт



Как же добраться до Кенозерского национального парка? Поначалу это кажется простой идеей, но когда вы начинаете докапываться до деталей, может оказаться не всё так просто. 



Чтобы доехать из Москвы до Каргополя, откуда мы начали своё путешествие, необходимо купить билет на поезд до Няндомы. Любой поезд, идущий до Архангельска, вам подойдет. В пути 17 часов. На маршруте ходят очень старенькие поезда, даже без биотуалетов (о кондиционерах речи вообще не идет). Так что будьте готовы к этому. 



Когда вы выйдете в Няндоме, у вас будет несколько способов добраться до Каргополя (до него 80 км). Во-первых, это автобусы, но вы должно точно узнать их расписание, чтобы не застрять на вокзале надолго, а потом понять, что их вовсе не будет. То расписание, которое прислали нам из Кенпарка, было отчасти правильное, отчасти, потому что наш автобус был только в 19 вечера, а мы приехали туда в 5 утра, рассчитывая уехать на 6 или 10-часовом. Второй вариант - это такси. Скорее всего под поезд приедут таксисты и будут набирать несколько человек в машину. Мы уехали именно на таком, нам обошлось оно в 1000 рублей на двоих (незапланированные расходы, ага). А так до Каргополя такси будет стоить 1500 где-то. Третий вариант - автостоп, но, как мне показалось, там маленький трафик...с другой стороны, я не профи в этих делах :)



Итак, мы осматриваем Каргополь и планируем двигаться дальше - в село Морщихинская, это центр Каргопольского сектора Кенпарка. Благо здесь с расписанием все оказывается в порядке. Автобус ходит раз в два дня два раза в день, примерно. Причем это тот же самый ПАЗик, что ходит до Няндомы :) стоимость проезда - 108 рублей. Дорога представляет собой то бетонные плиты, то хорошо укатанную грунтовку.



Передвижения по нацпарку.



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



В Плесецкой части парка вы сможете взять в прокат велосипеды (если у вас с собой будет ключ 13) и покататься по окрестностям.



Выбраться из Плесецкой части парка можно следующим образом: на автобусе, тоже ходит два раза в день через день, можно попробовать автостоп - благо там постоянно туда-обратно кто-то ездит, можно попробовать связаться с кем-то из туристов на машине через визит-центр и сесть к нему, а ещё можно заказать такси из Плесецка. Такси из Плесецка стоит 3500 рублей (да, это тоже отъедает руку по локоть, но у нас был поезд вечером и вписаться под вечер ни к кому не удалось), там порядка 180 км в одну сторону.



Билеты на поезд из Плесецка также были куплены заранее.



Проживание



В Каргополе жили на частном секторе вместе с хозяйкой, бронировали жилье через турбюро "Лаче". Далее мы бронировали турстоянки по нашему маршруту непосредственно по телефону секторов Кенпарка. Это надо сделать обязательно и обязательно позвонить им подтвердиться. Далее мы жили один день в домике, два дня в палатках.



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



Питание



На территории Кенпарка поесть негде, только если вы не большая организованная компания (больше 5 человек), которая заранее заказывает себе обеды. Есть чаепития, входящие в экскурсии на Плесецкой стороне, и это очень хорошие чаепития.  Кафе есть в Каргополе - там мы обедали "У егеря". Само по себе дорого, зато ланч очень недорогой и сытный, из пяти блюд.



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



Связь



Обязательно купите себе карточку Мегафона! Ибо в этих местах царствует именно он, а без связи вы никак не сможете узнать, приедет за вами лодка или не приедет. Нас чуть таким образом не оставили ночевать в Горбачихе, но спасибо местным, которые нам помогли, когда дали позвонить инспекторам.



Тропы и стоянки



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



Ещё Кенпарк порадовал нас оборудованными пешеходными тропами. Вот тропы, которые мы прошли: Транскенозерская тропа (31 км), Тропа Раздумий (2 км), Тропа Муравейников (3,5 км), Тропа Предков (10 км туда-обратно). Есть ещё несколько троп, до которых мы не добрались. На всех тропах есть информационные щиты, столбики, указывающие направления, в обход луж проложены мостики, а над болотами построены гати. В этом смысле всё чётко.



Насекомые



Вот этих товарищей было достаточно много: комары, оводы, мошка. Мы брали с собой рефтамид, и то он спасал не всегда, в итоге, я вернулась с чешущимися ногами и спиной. Москилл и Москитол - не берите, вообще не помогает :(



Что делать?



В Каргополе вы можете походить по городу, музеям, посетить центр ремёсел "Берегиня", поездить/походить по окрестностям и осмотреть деревянные церкви



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



1735259_IMG_4180 (700x525, 228Kb)



1735259_IMG_4424 (700x466, 276Kb)



1735259_IMG_4641 (700x466, 265Kb)



 

Метки:   Комментарии (4)КомментироватьВ цитатник или сообщество
lenov_ru

Real City Gangster v 1.7 » Клуб пользователей планшетов на ANDROID / Lenovo IdeaTab A2109 8GB / Samsung Galaxy Tab 2 7.0 / Asus Transformer TF700T / NVIDIA Tegra 3

Вторник, 14 Июня 2016 г. 19:29 (ссылка)
lenov.ru/games/25371-real-c...-v-17.html


Real City Gangster - экшен от третьего лица в котором главный герой, только что освободившись из исправительного учреждения, приезжает в Город Ангелов и решает стать самым крутым гангстером.

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<планирование - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda