О месте юзабилити-тестирований
Не секрет, что «юзабилити-тестирование» — весьма «раскрученное» понятие. Более того, часто термин «юзабилити» употребляется именно в значении «юзабилити-тестирование». При этом сложился ряд представлений о «юзабилити-тестировании» которые я, рискуя попасть под град критических стрел, хочу оспорить или, по крайней мере, подкорректировать.
Вот основные из них. «Юзабилити-тестирование» — это:
- Отдельная, весьма важная услуга, предлагаемая юзабилити-компаниями и одиночными специалистами;
- Если не обязательный, то крайне желательный начальный этап ЛЮБОГО проекта по переработке интерфейса;
- Основной и часто единственный способ гарантировать качество работ по разработке/переработке интерфейса;
- Максимально достоверный прием для оценки качества интерфейса — как на разных этапах его создания, так и при завершении разработки.
Выскажу свое мнение по каждому утверждению.
Юзабилити-тестирование как отдельная услуга
Под услугой я понимаю определенную деятельность, результат которой имеет самостоятельную ценность для клиента. При этом реализовываться услуга может с помощью различных инструментов, в зависимости от конкретных условий.
Так вот. Тестирование — это не услуга, это инструмент. «Проектирование интерфейса», например — услуга, «аудит интерфейса» — тоже услуга. В нашем случае, как правило, говоря о «тестировании», имеют в виду именно аудит.
Поясню. В качестве результата аудита клиент получает, как минимум, информацию о качестве своего интерфейсного решения, обработанную и структурированную, удобную для восприятия. Для этого требуется 3 этапа работы:
- Понять, какие требования предъявляются к интерфейсу. Фактически, провести этап исследований. Некоторые «профессионалы», к сожалению, опускают эту часть работы, предлагая «оценить» интерфейс сразу, исходя их эмпирических соображений: «посмотрел — нашел ошибки». Но это ущербный подход. Так можно обнаружить в основном микродизайнерские проблемы (неуклюжую компоновку экранных элементов, неоптимальное использование контролов и т.д.). Оценить же соответствие интерфейса сценариям работы пользователей, контексту, бизнес-требованиям можно, лишь собрав предварительно соответствующие данные. Даже с продуктами, рассчитанными на широкую аудиторию, где, казалось бы, все уже давно ясно «и тебе, и мне», этот этап необходим, пусть и в усеченном виде. Структурированные требования много полезней в работе, нежели общие представления, которые «вертятся» в голове. Что уж говорить об узкоспециализированных продуктах: там без сбора и фиксации требований просто нельзя.
В качестве инструментов на этом этапе могут применяться интервью, анкетирования, полевые наблюдения, фокус-группы и т.д. - Изучить текущую реализацию интерфейса. Вот здесь наиболее популярным и действенным инструментом и является юзабилити-тестирование. Но при этом также можно (и нужно) использовать и другие инструменты: экспертную оценку, например, или анализ логов. Причем иногда вместе, а иногда – вместо тестирования.
А само тестирование, если копать дальше, может проводиться с использованием множества разных методик: Observation, Thinking Aloud, Co-Discovery и т.п. - Подготовить отчет с перечнем проблем интерфейса, рекомендациями по их исправлению.Для создания такого отчета необходимы и собранные требования (что на самом деле нужно?), и результаты оценки интерфейса (как оно реализовано?). Отсюда мы сможем сделать вывод, что не так, и к чему нам следует стремиться.
Отчет может создаваться также с помощью различных инструментов: тут и статистическая обработка информации, и аналитика, и визуализация данных.
Каждый из этих этапов, а уж тем более инструменты, с помощью которых они выполняются, не представляют самостоятельной ценности для клиента (за редкими исключениями), а конечные этапы просто невозможны без начальных. Ценен лишь результат их последовательной реализации.
Несомненно, «юзабилити-тестирование» — очень полезная и важная штука.
Юзабилити-тестирование как необходимый начальный этап перепроектирования
Имея перед собой цель оптимизировать интерфейс, мы должны понять, что именно и в каком направлении нам нужно в нем менять. И здесь тестирование, вроде бы, незаменимая вещь. Но, оказывается, не всегда.
В ряде проектов еще на начальных этапах работы становится очевидным, что переделка интерфейса будет весьма значительной, на уровне концепции. В этом случае тестировать существующую версию бессмысленно. Ведь в ходе тестирования мы не сможем «выскочить» за рамки существующей концепции, мы найдем проблемы лишь в ее рамках. А что нам толку от этих проблем, если концепция будет изменена? Это лишь пустая трата ресурсов.
Тестировать интерфейс оправданно в том случае, если последующие переделки не затронут его концептуально.
Юзабилити-тестирование как основная гарантия конечного качества
Один из подходов к проектированию/перепроектированию интерфейсов: осознаем способ реализации основных функций системы — тестируем — оптимизируем — (и так по кругу). В случае, когда перепроектируем существующую версию — начинаем с тестирования сразу. В этом случае тестирование гарантирует нам максимальное качество конечных решений.
Спору нет, итеративное тестирование — вещь нужная, позволяющая не свернуть с нужного пути и максимально «вылизать» решение в ходе его разработки. Но в озвученном подходе есть проблема: тестируя и оптимизируя, мы почти всегда улучшаем существующую концепцию интерфейса, однако за ее пределы выйти при этом очень сложно. Возможно, эта концепция и есть наилучшая в условиях существующих ограничений, но весьма вероятно, что нет. Тогда, «вылизывая» решение с помощью тестирований, мы достигаем локального максимума качества, в то время как изменение концепции на другую поможет достичь нам глобального максимума.
Проиллюстрирую идею картинкой:
Цифрами 1-2-3-4 показаны локальные максимумы качества в рамках разных концепций.
Очевидно, что глобально максимального качества мы достигнем с помощью 3-й концепции. И достигнем мы его, благодаря двум условиям: выбору правильной концепции, и оптимизации решений в ее рамках, в том числе, и с помощью «юзабилити-тестирования» — как одного из инструментов, применяемого при проектировании.
Весь вопрос лишь в том, как выбрать эту самую, правильную.
Я пока знаю только один путь: на начальном этапе работ собрать необходимое количество данных, должным образом их проанализировать, интерпретировать, и сделать верные выводы. Иными словами, качественные исследования в проекте, которые служат для синтеза решений, не менее важны, чем качественная валидация и оптимизация промежуточных (и конечных) результатов. Не менее важным является и сам процесс синтеза интерфейсных решений, проектирование, но это настолько очевидно, что не буду заострять на этом внимание.
«Юзабилити-тестирование» — важное, но недостаточное условие качества конечного результата. Лишь полноценный цикл может гарантировать нужный результат. При этом я прекрасно осознаю, что для разных проектов и сам цикл, и важность его этапов может быть разной: где-то, например, критичнее более глубоко исследовать, где-то — тестировать. А где-то (о, ужас!) тестирование практически не даст результатов.
Юзабилити-тестирование как главный способ оценки качества
В ряде проектируемых систем максимальная эффективность работы достигается только в случае приобретения и закрепления пользователями ряда навыков, при этом кривая обучения весьма полога (навыки вырабатываются медленно). И на эту пологость идут сознательно: «мгновенная эффективность» работы важнее скорости обучения. Бывают крайние случаи, когда ради эффективности действия в ситуации, которая может вообще никогда не случиться, навыки приобретаются долго, и требуют множество ресурсов.
Пример: отработка нештатных ситуаций в отраслях с высокой ценой ошибки — атомная энергетика, авиация и т.д.
В этом случае тестирование «свежесделанного» интерфейса не даст нам необходимой обратной связи. Мы сможем оценить качества, связанные со скоростью взаимодействия с системой, но значительная часть интерфейсных решений будет закладываться в расчете на то, что у пользователей сформирован ряд навыков (пусть даже «вдолблен» в них). И «свежие» пользователи в этом случае нам не указ. А «бывалых» у новых продуктов вовсе нет.
Получается, с помощью юзабилити-тестирования в ходе (или по завершении) работы для оценки нам доступна только часть качеств. А чтобы оценить остальные, необходимо тестировать в процессе не только СОЗДАНИЯ, но и последующего ИСПОЛЬЗОВАНИЯ продукта, причем этот процесс может растянуться на месяцы и годы.
«Юзабилити-тестирование» — прекрасный способ оценки качества интерфейса, но он не всегда объективен.
Многие из тезисов, упомянутых мною, достаточно поверхностны, или, более того, сознательно упрощены. Их, конечно же, можно расширить, но я не хочу этого делать в рамках этой статьи.
Главное, на что я стремлюсь обратить внимание:
«Юзабилити-тестирование» — очень полезный и востребованный инструмент, который может (и должен) применяться практически на всех этапах работы и при оказании большинства услуг. Но сам по себе он не является панацеей, его применение по-настоящему эффективно только в общем цикле и при правильном позиционировании среди других видов работ.