Мифы про юзабилити и его тестирование

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

Миф 1: Юзабилити – это GUI

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

• функциональное (работает или нет заявленная функциональность)
• тестирование GUI (как расположены кнопочки, какого они размера и цвета)

Функциональное тестирование при таком делении кажется более важным, а тестирование GUI – дополнительной опцией, простой и не очень важной. И именно её многие называют тестированием юзабилити…

ОК, давайте договоримся: тестирование GUI и тестирование юзабилити – совсем разные вещи. Юзабилити – это свойство продукта удовлетворить потребности пользователя, и графический интерфейс – лишь одна из составляющих юзабилити.

Юзабилити продукта определяется целым комплексом факторов:

• Наличие требуемой пользователю функциональности и её работоспособность
• Простота использования продукта и скорость обучения
• Количество ошибок, которые совершают пользователи из-за непонимания.

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

Миф 2: Тестирование юзабилити – это просто

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

Для полезного и успешного проведения тестирования юзабилити, требуется достаточно большое количество знаний и навыков:

• Понимание принципов юзабилити и проектирования интерфейсов
• Большой опыт использования продуктов на схожих платформах
• Понимание бизнес-составляющей продукта: зачем он нужен? Какие задачи решает?
• Знакомство с пользователем: кто он? В каких условиях работает с продуктом? Как он это делает?

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

Миф 3: Любой человек может оценивать юзабилити продукта

Представьте, что ваш ребёнок попросил в подарок на день рожденья 5 килограмм конфет, и вы согласились с этим. Но какие конфеты он любит?

У вас есть 2 варианта, как их выбрать:

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

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

Хорошо понимая принципы юзабилити, вы можете получить полезную информацию от стороннего пользователя продукта, но сами её сгенерировать – нет!

Миф 4: Юзабилити для всех одно

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

Бухгалтеры бывают опытными и начинающими, графические редакторы используют дети и дизайнеры, антивирусы устанавливают администраторы крупных организаций и домохозяйки. Если вы попробуете удовлетворить взаимоисключающие потребности разных типов пользователей, вы не удовлетворите никого! Именно поэтому, есть MS Paint с простыми фигурками и кистями, и есть Photoshop с безграничным набором возможностей. Корпоративные антивирусы устанавливаются через доменные политики и имеют централизованный сервер управления, а домашние антивирусы имеют одну большую кнопку «защити меня». И, конечно, многие продукты имеют «расширенные настройки» для опытных пользователей, чтобы не пугать новичков.

А вы знаете все свои типы пользователей? Вы предоставляете им разные варианты продукта?

Миф 5: Заказчик знает, как сделать ему хорошо

Если продукт заказной, то многие расслабляются: я могу просто спросить клиента, как ему лучше что-то сделать, и так и будет.
Всё бы хорошо, если бы не парочка «но»:

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

Знакомиться с пользователями, исследовать их сценарии, выяснять и анализировать проблемы – важно! Но профессионалами по проектированию интерфейсов всё-таки должны быть мы с вами, а не пользователи.

Миф 6: Юзабилити не очень важно, важнее функциональность

Об этом я слышу особенно часто, но… Но как всегда, есть несколько «но»:

• Юзабилити – это и функционал в том числе. И зачастую при проведении детальных юзабилити-тестов мы приходили к необходимости убрать какой-то функционал, разработать другой и т.д. И в этих случаях это расширение функциональности несло добро в этот мир и удовлетворяло потребностям пользователей, а не просто было придумано аналитиками потому что «хорошо бы добавить».
• Если клиент не будет пользоваться продуктом (не поймёт, как; не захочет и т.д.), то до функционала он просто не дойдёт.

Любой современный продукт, добавляя новые фичи, в 99% случаев только повышает юзабилити! Это заметно не сразу, но присмотритесь: всё, что вы разрабатывали прошедшие релизы, можно было сделать и без нововведений. Но без них это было бы сложнее. Например, почтовый клиент научился сортировать письма по папкам в соответствии с правилами – раньше это можно было делать вручную. В банковскую программу добавили новый отчёт – раньше его заполняли в текстовом редакторе. В графическом редакторе новый фильтр – раньше можно было руками провести аналогичную ретушь. Почти всё, что делают ваши продукты, можно делать и без их использования, и вообще без использования ПО. Но с продуктами это становится УДОБНЕЕ, удобство выполнения пользовательских задач и есть главная цель любого продукта!

Выводы

Юзабилити – активно развивающаяся область в разработке ПО. И только развеяв перечисленные выше (и прочие, их ещё немало!) мифы, непрерывно совершенствуя себя и уделяя удобству использования должное внимание, вы сможете выпускать достойные продукты.

Узнать больше о тестировании юзабилити вы можете по нижеследующим ссылкам:

• «Как мыть слона?» — отличная вводная книжка Влада Головача по вопросам проектирования удобных продуктов.
• «Числовые методы в тестировании юзабилити» — мой обзорный доклад про тестирование юзабилити на конференции SQA Days