Именно этими артефактами решает заняться Олег. Он создает таблицу — словарь, куда вносит непонятные слова и предполагает их смысл. Словарь предметной области “Клинические исследования” Он также предполагает, что основные сущности в предметной области — это лаборант, препарат и само клиническое исследование. Возможно, есть что-то еще. Олег набрасывает схему связей между сущностями. Схема связей сущностей предметной…
Существует много разных причин для тестирования опыта, например:
Ваша причина тестирования будет определять ваши цели исследования , Ваши цели исследования, в свою очередь, определят, как вы анализируете свой пользовательский тест. Я обсуждаю это далее в своей статье об установлении целей исследования и предположениях при сопоставлении пользовательских исследований.
Поскольку причина конечного пользовательского теста влияет на ваш анализ, для каждого пользовательского теста потребуется глубокое погружение. В этой статье я собираюсь сосредоточиться исключительно на тестировании проблем юзабилити.
У вас может быть конкретная причина подозревать проблемы юзабилити (например, на основе аналитики, отзывов клиентов или недавнего редизайна). Или вы можете просто захотеть провести открытое исследование пользовательского опыта. Какой бы ни была ваша мотивация для тестирования, вы будете ограничены в том, сколько времени вы можете потратить на тестирование всего.
При подготовке к пользовательскому тесту у вас уже должно быть общее представление о задачах, которые обычно выполняют ваши пользователи. , Вы можете узнать, что это за задачи, с помощью других исследований (например, наблюдения, дневниковые опросы, пользовательские интервью, пользовательские тесты). В этой статье я предполагаю, что вы заранее знаете задачи.
Как только мы узнаем, какие задачи мы хотим проверить, мы доберемся до развилки на дороге:
В любом случае, вы захотите перечислите возможные задачи в вашем плане тестирования. Таким образом, если вы выберете опцию (1), вы можете попросить участников вернуться к заданию, даже если оно не является частью их процесса. Иногда, даже если вы выберете вариант (2), вам может понадобиться сохранить сценарии достаточно общими (например, «представьте, что вы хотите купить новый телефон по месячному тарифу», не указывая, какой телефон или какой план). В любом случае наличие списка задач означает, что даже если ваши участники не выполнят все задачи естественным образом, вы можете попросить их сделать это ради теста.
Здесь может быть полезен анализ иерархических задач. Вы хотите отделить задачи, относящиеся к опыту (например, поиск продукта в магазине), от реальных задач, которые нужны вашим пользователям (например, приобрести продукт, который им нужен). Важно, чтобы вы понимали покрытие вашего пользовательского теста, чтобы знать, какие части опыта не были протестированы.
Открытый пользовательский тест имеет одно ключевое преимущество: ваши участники исследования с большей вероятностью будет вести себя «естественно», используя интерфейс, как обычно. Но чем более открыт ваш план тестирования, тем выше вероятность того, что вы столкнетесь с этими проблемами:
С другой стороны, проведение пользовательского теста на основе сценариев может привести к «неестественному» поведению, которое может означать:
Важно помнить об этих соображениях при написании вашего плана тестирования. Задачи, которые вы освещаете (и то, как вы их освещаете), влияют на записки, которые вы записываете, и, в конечном счете, на ваш анализ.
Пользовательское тестирование — один из тех случаев, когда расшифровка стенограммы не так полезна. а также структурированные заметки. Хотя, если вы делаете заметки, вы все равно должны попытаться отловить то, что участники говорят дословно.
Если вы используете стенограмму, у вас может возникнуть соблазн использовать стороннюю службу транскрипции. Для пользовательского теста это может быть проблематично, потому что писцы вряд ли будут включать наблюдения. Это могут быть простые наблюдения, например, о том, на какой странице / разделе / экране находится пользователь, или о взаимодействии, например о том, какие пользователи нажимают или нажимают (или не нажимают или не нажимают).
На этом снимке экрана мы видим пример заметок о юзабилити-тестировании, записанных с помощью нашего Evolve Research App. Вместо стенограммы вы делаете заметки по соответствующей задаче в руководстве по моду. В этом примере заметки предназначены для юзабилити-тестирования сайта проката автомобилей. Это эффективно, потому что процесс найма автомобиля следует за коротким и последовательным процессом.
Другой подход состоит в том, чтобы делать заметки, основанные на том, на каком экране находится пользователь. Это может быть полезно для приложения или веб-сайта, где определенная задача может охватывать несколько экранов, особенно если несколько задач могут ссылаться на один и тот же экран.
Примечание. Важно проявлять гибкость. Возможно, вы структурировали свои заметки вокруг задач, но обнаружили, что участники переходят назад и вперед между экранами. Это затруднило бы давать рекомендации для каждого экрана. С другой стороны, вы можете структурировать свои заметки по экрану, но обнаружите, что проблемы юзабилити связаны с задачей, а не с возможностями экрана.
В любом случае преимущество получения структурированных заметок заключается в том, что что это значительно упрощает ваш анализ.
Самый быстрый (и самый эффективный) подход обычно состоит в том, чтобы структурировать ваш анализ так же, как вы структурировали заметки. Поэтому, если заметки структурированы вокруг задач, вы должны создать карту соответствия для каждой задачи. Если примечания относятся к экрану (или странице), у вас должна быть карта сходства для каждого экрана.
На этом снимке экрана мы можем видеть необходимость гибкого подхода к нашему анализу. У каждого участника есть примечания к «Задаче 1: Найти машину на прокат», но эта задача была разбита на 2 страницы: поиск и результаты поиска. В этом случае было более эффективно разделить анализ на каждый экран, чтобы упростить выявление трендов между участниками. Это также полезно, потому что мы, вероятно, хотим сообщать о проблемах юзабилити для каждого экрана.
Самая важная вещь, которую нужно иметь в виду, — не делайте свое отображение соответствия на основа участника . Вместо этого вы должны просматривать каждое задание / экран один за другим среди участников. Если вы просматриваете каждого участника один за другим, заметки одного участника больше не будут заметны, если вы посмотрите на этот же раздел для следующего участника.
Первым шагом в поиске проблем с юзабилити является группировка заметок очень широко. На скриншоте выше есть комментарии от нескольких участников о фильтрах. Если вы обнаружите, что в одной теме слишком много заметок, вы можете рассмотреть их дальнейшее разделение.
Ваш первый проход анализа должен включать в себя объединение всех связанных заметок. Поэтому, если есть комментарии или замечания по поводу фильтров, все они входят в одну тему.
Примечание. Некоторые проблемы или замечания могут применяться только к одному участнику. Мы имеем дело с небольшими размерами выборки. Этот один участник может представлять значительную часть вашей пользовательской базы. Вы должны использовать свое суждение о значимости проблемы, основываясь на том, КАК она влияет на опыт участника.
Завершите каждое задание, экран или раздел для каждого участника, прежде чем переходить к следующему часть анализа. Фактически, это может помочь оставить некоторое время между первым проходом анализа и поиском результатов. Лично я обнаружил, что хороший ночной сон помогает мне лучше подойти к анализу. Но не ждите слишком долго между группировкой заметок по темам и выявлением результатов исследований! Человеческая память хрупка. Вы можете обнаружить, что вам нужно тратить больше времени на просмотр своих тем, если вы слишком долго ждете, чтобы завершить анализ.
Именно с этого начинается значение глубокого анализа. войдите. У вас может возникнуть соблазн просто делать заметки о проблемах юзабилити во время просмотра теста (или записи). И этот подход быстрого анализа хорош, если вы тестируете небольшое количество задач с очень небольшим количеством участников. Но даже в этом случае вы можете упустить более общую картину.
Как только у вас будет обзор опыта по каждой задаче, самое время начать делать выводы. В моей статье о методах анализа пользовательских интервью я упомянул, что нам нужно найти баланс между строгостью и скоростью. Мы имеем дело с размерами выборки, которые слишком малы, чтобы делать уверенные прогнозы на основе количества участников, которые испытывают проблемы с юзабилити. Вместо этого нам нужно объединить доказательства из нескольких исследований и наше суждение, чтобы прийти к подходящим выводам.
Например: если фильтры на странице легко пропустить, мы можем рекомендовать изменить дизайн так, чтобы пользователи более вероятно, чтобы найти их. Но предположим, что большинство пользователей легко могут найти то, что ищут, даже если они не могут найти фильтры. В этом случае мы должны подумать о потенциальных последствиях, которые могут сделать одну часть дизайна более визуально заметной (например, это может нарушить визуальную иерархию страницы и фактически усложнить ее использование).
При работе с При небольших размерах выборки большинство наших идей (и рекомендаций) будут основаны на предположениях. Вместо проведения рандомизированных контролируемых испытаний для каждого изменения конструкции мы можем просто выполнить итерацию быстро. Используя быструю итерацию, мы можем выяснить, не было ли предыдущее изменение дизайна нежелательным результатом в будущих тестах юзабилити.
Очевидно, что подход быстрого анализа, основанный на предположениях, не будет работать в каждом сценарии. Вы должны быть намного более строгими, если вы работаете с опасными материалами, опасным оборудованием, здравоохранением или любой другой областью, которая непосредственно влияет на благополучие других.
Для некоторых результатов исследования вы можете составить рекомендацию на месте. Для других вам может потребоваться некоторое время подумать об этом, прежде чем вы сможете решить, что делать. Однако на этом этапе анализа вы не должны давать подробные рекомендации по проектированию, если они не являются невероятно очевидными. Лучше держать ваши рекомендации на высоком уровне — в рассматриваются оценки, а не проекты, которые окончательно необходимо изменить.
Стоит пройтись по каждому из выводов и написать рекомендации или обзор ваших рекомендаций на месте ранее. Также может быть стоит отметить серьезность вывода и масштаб рекомендации. Особенно, если вы находитесь в гибкой среде, возможно, стоит придумать мелкие исправления для особо важной проблемы.
В мире UX нам постоянно приходится балансировать между тщательностью исследований и разработкой продуктов. скорость. Пока вы решаете, исправить проблему юзабилити или нет, у вас есть пользователи, которые испытывают эту проблему. С другой стороны, вы не хотите пропустить проблему, потому что вы не смогли провести надлежащий анализ — или, что еще хуже, проведите поверхностный анализ и дадите плохую рекомендацию, которая вызовет больше проблем в будущем.
Метод, который мы использовали Предлагаю пытается достичь этого баланса. Вот краткое изложение:
С помощью этого подхода вы можете добавить некоторую строгость в свой анализ юзабилити, продолжая двигаться в быстром темпе. Это будет не так быстро, как делать быстрые суждения, пока вы будете делать заметки, но оно будет более надежным.
Хотите использовать Evolve для анализа ваших юзабилити-тестов? Недавно мы добавили руководство по использованию Evolve для юзабилити-тестов.
Заключительная часть нашей серии статей о том, как анализировать ю-тесты В прошлой статье мы писали, что на юзабилити-тестировании приоритетнее записывать действия респондента, а мнение и комментарии — по возможности. Вы можете вести записи во время тестирования и/или после по видеозаписи. Выбирайте наиболее удобный и эффективный для вас формат сбора данных. Собирать их вы можете на стикерах, бумаге,…