Usability.Ru-Статьи-Ярослав Перевалов-Роль и место юзабилити-тестирования в процессе юзабилити-проектирования

Мотивы

Взяться за написание этой статьи меня побудили следующие обстоятельства.

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

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

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

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

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

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

Таким образом родиласть дополнительная глава, связывающая юзабилити-тестирование с общим процессом разработки UI.

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

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

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

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

Процесс разработки пользовательского интерфейса и юзабилити-тестирование

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

Таблица 1. Юзабилити-тестирование как один из методов в процессе разработки UI

Стадия	Задача	Результат
Анализ	Определение целей проектирования и критериев успешности продукта	Описание целей проектирования и определение достижимых критериев
	Анализ и юзабилити-экспертиза конкурирующих продуктов, аналогов, предыдущих версий.	Результаты сравнительного анализа по ключевым критериям, перечень недостатков, перечень эргономических требований
	Определение контекста рабочей среды и окружения	Операционная модель, Карта операционных профилей
	Определение ролей пользователей, описание целей и задач пользователей	Ролевая модель, Карта ролей пользователей
	Описание основных сценариев работы пользователей	Модель задач, основные элементы Use Case, карта Use Case
	Количественное юзабилити-тестирование аналогов и предыдущих версий	Определение количественных критериев качества
Проектирование (Синтез)	Концептуальное проектирование пользовательского интерфейса	Контентная модель, Карта навигации
	Детальное проектирование пользовательского интерфейса	Модель реализации, Функциональная модель, Визуальный проект, Бумажный/пассивный прототип, Тестовый/активный прототип, Спецификации на пользовательский интерфейс (описание характера взаимодействия, поведения системы и контролов, стилевые требования)
	Экспресс-ю-тестирование для проверки рабочих гипотез интерфейсных решений	Интерфейсные решения, подтверждённые положительными результатами ю-тестирования
Тестирование	Авторский контроль за реализацией, экспертная оценка	Перечень замечаний и необходимых доработок в UI
	Оценка потребительских качеств продукта	Определение степени достижения заданных критериев качества, Определение степени пользовательской удовлетворённости продуктом, Редизайн интерфейса (при необходимости и возможности)
	Полномасштабное качественное и количественное тестирование	Определение проблемных областей в UI (или подтверждение факта, что таких проблем нет) Определение качественных и количественных юзабилити-характеристик продукта
Внедрение и сопровождение	Сбор и анализ пользовательских замечаний и требований	Выработка стратегии развития пользовательского интерфейса в будущих версиях продукта, Устранение дефектов UI. Фиксирование потребностей в функционале
Оптимизация процесса проектирования	Унификация, стандартизация, повторное использование интерфейсных решений. Достижение консистентных свойств UI	Аккумуляция удачных и проверенных решений в руководствах по стилю оформления и по проектированию UI. Разработка / адаптация оригинальных контролов.

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

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

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

При всей важности и необходимости юзабилити-тестирования как метода проектирования UI, следует подчеркнуть, что:

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

Качественное ю-тестирование или интервью?

Влад сам говорит, что при методе «активного вмешательства» тестировщика в процесс тестирования собственно тестирование приобретает характер интервью.

Именно этот метод – структурированное интервю с пользователем на его рабочем месте, в контексте использования продукта издревле используют наёмные юзабилисты :)

Этот метод называют ещё совместным (с пользователем) сквозным инспектированием пользовательского интерфейса продукта.

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

Мысли ю-гуру по поводу ю-тестирования

Как метко подметил Влад, будучи наёмным юзабилистом, я не могу не ссылаться на авторитеты :)

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

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

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

Юзабилити-тестирование до начала программирования Купер сравнивает с «чистым исследованием, которое больше подошло бы для университетской среды».

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

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

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

А если разработчики и их шеф уже догадываются, что с юзабилити продукта не всё в порядке? Стоит ли тратить 5-10 тысяч долларов, чтобы в этом убедиться?

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

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

Брюс Тогназини в своей книге Tog on Interface утверждает, что:

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

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

Наконец, Ларри Константайн в книге Software for Use: A Practical Guide to the Models and Methods of Usage Centered Design предостерегает от злоупотреблений количественными оценками юзабилити-свойств:

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

Лари также подчёркивает недостатки юзабилити-тестирования:

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

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

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

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

Основные выводы

Целью этой статьи было вовсе не стремление показать никчёмность юзабилити-тестирования как метода разработки.

Метод этот имеет место быть весьма полезным и необходимым.

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

Перед началом любого дела никогда не помешает подумать на тему целесообразности.

Плюсы юзабилити-тестирования:

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

Минусы юзабилити-тестирования:

Юзабилити-тестирование – метод необходимый, но не достаточный. Нужно иметь полный цикл разработки UI, в котором ю-тестированию отводится вспомогательная роль контрольной проверки
Ю-тестирование может сигнализировать о наличии серьёзных проблем, но не может давать решений по их разрешению
Метод может быть неэффективным с точки зрения стоимости: для получения достоверных результатов нужна достаточно большая выборка респондентов и как минимум функциональный прототип
Респондентов из целевой группы может оказаться очень сложно найти
Условия тестирования, приближенные к боевым, может оказаться чрезвычайно сложно создать
Метод не даёт никаких гарантий: серьёзные проблемы могут быть выявлены, но могут быть и не выявлены
Результаты зависят как от условий проведения тестов, так и от структуры эксперимента, так и от интерпретации исходных данных.