Оценка полезности и организации интерфейса мобильного приложения

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

Как было сказано выше, в исследовании опыта взаимодействия пользователя необходимо как можно точнее охарактеризовать три основных аспекта:

  • 1) профиль пользователя;
  • 2) тип интерфейса, включая характеристики аппаратной и программной составляющих (специфики устройства и информационной системы);
  • 3) контекст использования.

В итоге предполагается получение результатов следующего плана:

  • 1) понимание пользователем того, какие задачи позволяет решить информационный продукт, и оценка успешности (результативности) в достижении желательного результата;
  • 2) характеристики манеры поведения и действий в процессе работы;
  • 3) характеристика производительности (эффективности) работы, т.е. оценка затраты ресурсов (средств, усилий, времени) для достижения желаемого результата;
  • 4) характеристика юзабилити, удобства и доступности восприятия и взаимодействия с элементами интерфейса;
  • 5) характеристика общего отношения к информационному продукту (мнения и эмоции), связанные с его использованием и внешним видом.

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

  • доступность приложения: поиск приложения по запросу в соответствии с некоторой информационной потребностью; установка; запуск; вход и выход; удаление и повторный поиск;
  • способность приложения адаптироваться (гибкий макет) с учетом разных размеров экрана и ориентации устройства;
  • стабильность работы приложения: способность его функционирования, когда запущены другие приложения (учет ограниченности оперативной памяти и быстродействия процессора), варианты поведения при недостатке места (объема внутренней памяти) для установки и работы, а также характер работы при отсутствии в устройстве некоторых функций;
  • удобство и безошибочность контактного взаимодействия: характер действий при нажатии двух элементов или многократном нажатии на кнопку, достаточный размер touch-зон и др.;
  • ориентирование: отсутствие экранов без очевидной навигации, взаимосвязь навигации с функциями, количество экранов на пути к решению задачи, очевидность сценариев для пользователя и др.;
  • поведение приложения в стрессовых условиях: прерывание звонками и процессом обмена сообщениями (SMS, MMS), выключение и разрядка, потеря связи с мобильной сетью или выход из зоны Wi-Fi (отключение Интернета), начало работы с другим приложением, включение режима ожидания устройства и др.;
  • обеспечение пользователя обратной связью: визуальная индикация и четкое информирование о необходимости обратить внимание и подтвердить критическое или случайное действие (например, удаление данных или приложения), визуальное выделение активного состояния элемента и оповещение хода выполнения функции;
  • стабильность и безошибочность обновления приложения до новой версии;
  • корректность общения приложения с пользователем: отсутствие орфографических ошибок и соответствие языка.

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

Тестирование приложений может осуществляться в автоматизированном или ручном режимах.

Так, для автоматизированного тестирования Android-приложений могут использоваться следующие программные продукты:

  • — программа «Monkey» (имитирует последовательность случайных действий пользователей);
  • — программы «getevent /sendevent» (осуществляют запись последовательности действий пользователей и воспроизводят ее);
  • — программа «Robotium» (фиксируют действия соотносительно с интерфейсом, а не устройством ввода, что позволяет создать тестовый скрипт, который будет независим от характеристик элементов интерфейса, а также разрешения экрана).

Автоматизированное тестирование обладает рядом достоинств:

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

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

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

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

  • — социальные и демографические характеристики;
  • — навыки и умения работы с компьютером;
  • — мотивационно-целевая среда;
  • — рабочая среда;
  • — особенности взаимодействия с компьютером (специфические требования пользователей, необходимые информационные технологии и др.);
  • — задачи пользователей.

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

Профили предполагаемых пользователей описываются еще на этапе проектирования приложения, однако важным является внесение в состав и характеристики профилей в процессе работы. Отследить динамику изменения параметров пользователей мобильного приложения помогают сервисы, предоставляющие аналитические данные о посетителях (системы «GoogleAnalytics» или «Яндекс.Метрика (МеЫх)») и позволяющие формировать отчеты о пользователях по следующим направлениям [45]:

  • — общие сведения о сеансах работы: средняя длительность сеанса, общее число просмотров экранов, среднее число просмотров экранов за сеанс (экранов/сеанс), процент новых и вернувшихся пользователей, популярные языки и местоположения [45];
  • — сравнение состояний и эффективности версий приложения, сведения об устройствах, на которых устанавливается приложение;
  • — демографические характеристики, увлечения и интересы;
  • — сведения о географии использования, т.е. в каких странах и городах оно более популярно, а где его практически не загружают;
  • — поведенческие характеристики: соотношение новых и постоянных пользователей, заинтересованность в приложении («вовлеченность»), частота использования («периодичность»), длительность работы и др.

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

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

  • 1. «Могу ли я сделать то, что мне надо здесь и сейчас» (учитывается тип микрозадачи или контекстного действия).
  • 2. «Удобно ли мне это сделать» (учитывается контекст и дизайн интерфейса на небольшом экране мобильного устройства).

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

Проблема 1. Полезность программного продукта (usefulness) для решения оперативных задач

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

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

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

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

Для оценки полезности необходимы следующие входные данные:

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

Цели исследования на уровне полезности:

  • 1) выявление важных для пользователя функциональных возможностей в приложении определенного типа;
  • 2) выявление востребованных и невостребованных функций тестируемого приложения;
  • 3) выяснение причин расхождения логики и соответственно последовательности действий для решения задачи той, что предположена пользователем, выявлена при работе с приложением и реально организована в приложении.

Метод «Анализ задач»

Для реализации исследования привлекаются реальные пользователи, которые максимально соответствуют предполагаемым персонажам (по возможности по 5—7 представителей). Персонажи подбираются в соответствии с требуемыми им функциональными возможностями в отношении конкретного приложения или типа приложений.

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

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

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

Также пользователям может быть предложена установка конкретных приложений, например «2018» или «Ооо§1еМар8». В этом случае анализ направлен на выявление востребованности функций конкретного приложения.

Процедуры исследования включают список следующих действий.

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

Например, определить на карте свое местонахождение, найти номер маршрута общественного транспорта, на котором можно будет добраться из точки «А» в точку «Б» и др.

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

Например, предложить испытуемым несколько раз найти разные места на карте.

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

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

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

Фиксировать последовательность действий по поводу каждой задачи рекомендуется в двух направлениях.

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

Далее анализируются совпадения и расхождения на этих диаграммах на уровне логики осуществления действий, а не предсказания названия и расположения элементов интерфейса.

Например, в приложении для ориентирования на местности необходимо найти адрес и расписание работы магазина X.

Пользователь может фиксировать свои последовательности действий так:

  • — ввод названия магазина в строку поиска => получение списка учреждений => переход на страницу магазина Xс информацией;
  • — поиск магазина на карте => переход на страницу магазина Xс информацией.

Результаты и анализ результатов

После выполнения заданий испытуемыми осуществляется оценка успешности и возможности решения задач.

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

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

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

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

Переход от экрана к экрану — последовательный просмотр экранов.

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

Количественно полезность можно оценивать через следующие индикаторы:

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

В интерпретации количественных данных необходимо учитывать следующие моменты:

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

Интерпретацию количественных данных дополняют качественные индикаторы:

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

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

Проблема 2. Понятность принципов работы в условиях ограниченного времени и пространства экрана

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

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

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

Индикаторами проблемы может стать статистика (например, данные Соо§1еАпа1уйс8), которая демонстрирует, что:

  • — какие-то страницы сайта или экраны приложения практически не посещаются;
  • — какие-то ссылки или компоненты навигации не используются для перемещения между страницами / экранами.

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

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

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

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

Надежность исследования указывает на повторность получения результатов при последующих исследованиях.

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

  • 1. «Ориентированность» — возможность беспрепятственно ориентироваться в приложении в любой момент работы с учетом вынужденных прерываний.
  • 2. «Находимость» — возможность беспрепятственно найти нужную информацию, экран / страницу и др.

Метод тестирования информационной архитектуры

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

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

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

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

Процедуры исследования включают следующие действия.

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

Возможно два пути воссоздания структуры:

схема без учета дизайна интерфейса. В данном случае осуществляется анализ структурной схемы и названий активных элементов. Для этой цели могут использоваться специализированные сервисы типа «Тгее]аск» или «к^е^оот». Можно воссоздать навигационную структуру в таблице при помощи программы Мюго-80ЙЕхе1, а после импортировать ее в сервис «Тгее]аск».

Например, часть навигационной структуры приложения «2018» выглядит, как показано в табл. 2.4.

Таблица 2.4. Часть структуры приложения «2GIS»

Главное

меню

Кнопка «Назад»

Кнопка

«Назад»

Кнопка

«Назад»

Кнопка

«Назад»

Фирмы

  • — Поесть
  • — Бары, клубы
  • — Гостинцы
  • — Аптеки
  • — Банкоматы
  • — Банки
  • — АЗС
  • — Автосервис
  • — Таски
  • — Фильтровать
  • — На карте
  • (перечень всех фирм по каждому направлению с заголовком)

Уточнить

условия

Переход к нужному объекту

(Аптека № 9)

На карте

Навигация по карте

Карта

Навигация на карте(поиск и щелчок по объекту)

Переход по адресу к информации объекта

Переход к информации нужной организации

  • — Навигация по карте
  • — Маршрут проезда сюда/отсюда
  • — Позвонить
  • — Отправить e-mail
  • — Написать отзыв
  • — Дополнительная информация
  • — Перейти к аналогичным организациям и др.

Окончание табл. 2.4

Главное

меню

Кнопка «Назад»

Кнопка

«Назад»

Кнопка

«Назад»

Кнопка

«Назад»

Как

прое

хать

— Укажите начальную точку

  • — Мое местоположение
  • — Указать на карте

Из избранного

Схема

проезда и

маршруты

Укажите конечную точку

  • — Мое местоположение
  • — Указать на

карте

Из избранного

Избран

ное

Список особо отмеченных пользователем мест

Сервис «Тгее]аск» позволяет представить пользователям «дерево» исследуемого программного продукта с учетом вложенности категорий, а также позволяет раскрывать и сворачивать категории. Пользователь видит структуру в программе в следующем виде (рис. 2.12).;

Вид информационной структуры в программе «Тгееіаск»

Рис. 2.12. Вид информационной структуры в программе «Тгееіаск»

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

Например, согласно предложенной схеме задача может звучать так:

Найти адрес и режим работы аптеки № 9. В табл. 2.4 помечен правильный путь следования.

4. При лабораторном тестировании после решения задачи проводится беседа с пользователем.

Результаты и анализ результатов

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

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

  • — скорость, т.е. как быстро участники нашли правильный ответ без необходимости возврата вверх/вниз по дереву;
  • — сколько участников (относительно общего количества) достигли верного результата без необходимости возвратов вверх/вниз по дереву;
  • — сколько участников (относительно общего количества) не достигли верного результата;
  • — средний процент (от общего количества) участников, которые попали в нужное место назначения во всех задачах.

Визуализация результатов переходов может выглядеть, как на рис. 2.13 (результаты вымышлены и используется схема перехода по данным табл. 2.4).

15 участников 15 участников

на карте

О Верный переход О Ошибочный переход О Относительно ошибочный переход О Верное конечное решение

Рис. 2.13. Визуализация переходов по дереву участников теста (для одной задачи)

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

В интерпретации результатов надо учитывать следующие моменты:

  • — прямым указанием на обеспечение естественной «находимо-сты» (суть навигационного элемента и то, куда он ведет, однозначно понятны пользователю определенного уровня подготовки) является высокая доля (от 70 до 90%) тех испытуемых, которые нашли верный путь без необходимости возвратов (дополнительных перемещений по дереву);
  • — доля участников, которые нашли правильный путь, но перемещались по дереву вверх/вниз, т.е. просматривали структуру, ха-

растеризует «ориентированность». Хорошим результатом при этом считается 85—100% числа испытуемых. Средний результат (около 50%) свидетельствует о затруднениях в понимании сути навигационных элементов для большинства испытуемых, что сигнализирует о наличии проблем в ориентировании;

  • — большая вариативность путей (когда пользователи прошли везде, чтобы найти ответ) и отсутствие явного преобладания числа участников на верных путях при первом проходе свидетельствует о неочевидной структуре для данного типа пользователей;
  • — при наличии нескольких верных вариантов решения надо обратить внимание на тот, который нашли большинство испытуемых. Он, возможно, показался наиболее очевидным, а остальные не совсем понятными;
  • — анализ неверных путей (т.е. тех, которые, по мнению участников, являются верными для решения указанной задачи, но на самом деле ошибочны) должен быть направлен на выявление причин, которые дали пользователю возможность считать, что это верный путь. Например, возможно названия каких-то узлов двусмысленно или неочевидно;
  • — анализ времени, которое затрачивается на поиск правильного пути, может подсказать то, насколько легка задача для понимания и решения. Если большинство участников (80—90%) достаточно много времени затратили на поиски верного решения (20—30 с), то это может свидетельствовать о сложности, непонятности или неадекватности задачи. Если при этом было получено мало верных решений (20—30%), то можно считать, что данная задача практически не решаема при наличии такой структуры;
  • — анализ первых кликов, т.е. то, что участники нажимают в первый раз, а не после возврата, позволяет понять то, насколько уместны для пользователей и адекватны задаче названия категорий. Однако при этом надо учитывать первые клики в контексте правильных решений.

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

 
< Пред   СОДЕРЖАНИЕ     След >