Очень многие тестировщики, с которыми я обсуждала вопросы юзабилити, имеют об этом понятии очень смутное представление. Давайте развеем основные мифы про юзабилити и его тестирование:
В восприятии многих тестировщиков есть 2 взаимоисключающих вида тестирования:
Функциональное тестирование при таком делении кажется более важным, а тестирование GUI – дополнительной опцией, простой и не очень важной. И именно её многие называют тестированием юзабилити…
ОК, давайте договоримся: тестирование GUI и тестирование юзабилити – совсем разные вещи. Юзабилити – это свойство продукта удовлетворить потребности пользователя, и графический интерфейс – лишь одна из составляющих юзабилити.
Юзабилити продукта определяется целым комплексом факторов:
А значит, для достижения высокого юзабилити, менять цвет кнопочек недостаточно, и удобство использования включает в себя и функциональную составляющую, и GUI, и справку, и даже поддержку пользователей.
Как бы не так! Именно те, кто считают тестирование юзабилити простым, и проводят его без применения требуемых техник, дискредитируют понятие тестирования юзабилити как такового.
Для полезного и успешного проведения тестирования юзабилити, требуется достаточно большое количество знаний и навыков:
При этом, нельзя просто применить эти знания и сказать: здесь надо поменять вот это, а тут вот то. Любые догадки и пресуппозиции в тестировании юзабилити должны проверяться на пользователях. На настоящих пользователях! И тут мы как раз переходим к следующему мифу:
Представьте, что ваш ребёнок попросил в подарок на день рожденья 5 килограмм конфет, и вы согласились с этим. Но какие конфеты он любит?
У вас есть 2 варианта, как их выбрать:
Конечно, во втором случае есть шанс, что вы угадаете, но он катастрофически маленький!
То же самое в тестировании юзабилити: вы каждый день тестируете продукт, вы разбираетесь значительно лучше в технологиях и программах, у вас значительно выше компьютерная грамотность, чем у среднестатистического пользователя (если вы только не пишете софт для других айтишников). Внимание, вопрос: как вы можете оценить, что удобно бухгалтеру, впервые запустившему вашу программу, если вы не бухгалтер, и запускали её для тестирования примерно 632 тысячи раз?
Хорошо понимая принципы юзабилити, вы можете получить полезную информацию от стороннего пользователя продукта, но сами её сгенерировать – нет!
Допустим, вы лучше узнали кого-то из своих пользователей, и тщательно прорабатываете продукт, чтобы удовлетворять его ожидания. Но в реальной жизни очень редко бывает, что продуктом пользуется только один тип пользователей!
Бухгалтеры бывают опытными и начинающими, графические редакторы используют дети и дизайнеры, антивирусы устанавливают администраторы крупных организаций и домохозяйки. Если вы попробуете удовлетворить взаимоисключающие потребности разных типов пользователей, вы не удовлетворите никого! Именно поэтому, есть MS Paint с простыми фигурками и кистями, и есть Photoshop с безграничным набором возможностей. Корпоративные антивирусы устанавливаются через доменные политики и имеют централизованный сервер управления, а домашние антивирусы имеют одну большую кнопку «защити меня». И, конечно, многие продукты имеют «расширенные настройки» для опытных пользователей, чтобы не пугать новичков.
А вы знаете все свои типы пользователей? Вы предоставляете им разные варианты продукта?
Если продукт заказной, то многие расслабляются: я могу просто спросить клиента, как ему лучше что-то сделать, и так и будет.
Всё бы хорошо, если бы не парочка «но»:
Знакомиться с пользователями, исследовать их сценарии, выяснять и анализировать проблемы – важно! Но профессионалами по проектированию интерфейсов всё-таки должны быть мы с вами, а не пользователи.
Об этом я слышу особенно часто, но… Но как всегда, есть несколько «но»:
Любой современный продукт, добавляя новые фичи, в 99% случаев только повышает юзабилити! Это заметно не сразу, но присмотритесь: всё, что вы разрабатывали прошедшие релизы, можно было сделать и без нововведений. Но без них это было бы сложнее. Например, почтовый клиент научился сортировать письма по папкам в соответствии с правилами – раньше это можно было делать вручную. В банковскую программу добавили новый отчёт – раньше его заполняли в текстовом редакторе. В графическом редакторе новый фильтр – раньше можно было руками провести аналогичную ретушь. Почти всё, что делают ваши продукты, можно делать и без их использования, и вообще без использования ПО. Но с продуктами это становится УДОБНЕЕ, удобство выполнения пользовательских задач и есть главная цель любого продукта!
Юзабилити – активно развивающаяся область в разработке ПО. И только развеяв перечисленные выше (и прочие, их ещё немало!) мифы, непрерывно совершенствуя себя и уделяя удобству использования должное внимание, вы сможете выпускать достойные продукты.
Узнать больше о тестировании юзабилити вы можете по нижеследующим ссылкам:
Миф 1: Юзабилити – это GUI
В восприятии многих тестировщиков есть 2 взаимоисключающих вида тестирования:
- функциональное (работает или нет заявленная функциональность)
- тестирование GUI (как расположены кнопочки, какого они размера и цвета)
Функциональное тестирование при таком делении кажется более важным, а тестирование GUI – дополнительной опцией, простой и не очень важной. И именно её многие называют тестированием юзабилити…
ОК, давайте договоримся: тестирование GUI и тестирование юзабилити – совсем разные вещи. Юзабилити – это свойство продукта удовлетворить потребности пользователя, и графический интерфейс – лишь одна из составляющих юзабилити.
Юзабилити продукта определяется целым комплексом факторов:
- Наличие требуемой пользователю функциональности и её работоспособность
- Простота использования продукта и скорость обучения
- Количество ошибок, которые совершают пользователи из-за непонимания.
А значит, для достижения высокого юзабилити, менять цвет кнопочек недостаточно, и удобство использования включает в себя и функциональную составляющую, и GUI, и справку, и даже поддержку пользователей.
Миф 2: Тестирование юзабилити – это просто
Как бы не так! Именно те, кто считают тестирование юзабилити простым, и проводят его без применения требуемых техник, дискредитируют понятие тестирования юзабилити как такового.
Для полезного и успешного проведения тестирования юзабилити, требуется достаточно большое количество знаний и навыков:
- Понимание принципов юзабилити и проектирования интерфейсов
- Большой опыт использования продуктов на схожих платформах
- Понимание бизнес-составляющей продукта: зачем он нужен? Какие задачи решает?
- Знакомство с пользователем: кто он? В каких условиях работает с продуктом? Как он это делает?
При этом, нельзя просто применить эти знания и сказать: здесь надо поменять вот это, а тут вот то. Любые догадки и пресуппозиции в тестировании юзабилити должны проверяться на пользователях. На настоящих пользователях! И тут мы как раз переходим к следующему мифу:
Миф 3: Любой человек может оценивать юзабилити продукта
Представьте, что ваш ребёнок попросил в подарок на день рожденья 5 килограмм конфет, и вы согласились с этим. Но какие конфеты он любит?
У вас есть 2 варианта, как их выбрать:
- Дать попробовать разные конфеты ребёнку, чтобы он выбрал сам
- Попробовать самостоятельно, выбрать самые вкусные на ваш взгляд, и купить 5 кг таких конфет.
Конечно, во втором случае есть шанс, что вы угадаете, но он катастрофически маленький!
То же самое в тестировании юзабилити: вы каждый день тестируете продукт, вы разбираетесь значительно лучше в технологиях и программах, у вас значительно выше компьютерная грамотность, чем у среднестатистического пользователя (если вы только не пишете софт для других айтишников). Внимание, вопрос: как вы можете оценить, что удобно бухгалтеру, впервые запустившему вашу программу, если вы не бухгалтер, и запускали её для тестирования примерно 632 тысячи раз?
Хорошо понимая принципы юзабилити, вы можете получить полезную информацию от стороннего пользователя продукта, но сами её сгенерировать – нет!
Миф 4: Юзабилити для всех одно
Допустим, вы лучше узнали кого-то из своих пользователей, и тщательно прорабатываете продукт, чтобы удовлетворять его ожидания. Но в реальной жизни очень редко бывает, что продуктом пользуется только один тип пользователей!
Бухгалтеры бывают опытными и начинающими, графические редакторы используют дети и дизайнеры, антивирусы устанавливают администраторы крупных организаций и домохозяйки. Если вы попробуете удовлетворить взаимоисключающие потребности разных типов пользователей, вы не удовлетворите никого! Именно поэтому, есть MS Paint с простыми фигурками и кистями, и есть Photoshop с безграничным набором возможностей. Корпоративные антивирусы устанавливаются через доменные политики и имеют централизованный сервер управления, а домашние антивирусы имеют одну большую кнопку «защити меня». И, конечно, многие продукты имеют «расширенные настройки» для опытных пользователей, чтобы не пугать новичков.
А вы знаете все свои типы пользователей? Вы предоставляете им разные варианты продукта?
Миф 5: Заказчик знает, как сделать ему хорошо
Если продукт заказной, то многие расслабляются: я могу просто спросить клиента, как ему лучше что-то сделать, и так и будет.
Всё бы хорошо, если бы не парочка «но»:
- Клиент ничего не знает о проектировании интерфейсов и зачастую предлагает абсолютно нелогичные идеи!
- Клиент не всегда хорошо понимает, какие есть варианты реализации, и придумывает что-то слишком сложное.
- Запрос за запросом, выполненные в соответствии с пожеланиями клиента, превращают ваш продукт в стёганое одеяло, потерявшее свою консистентность и общий уникальный стиль.
Знакомиться с пользователями, исследовать их сценарии, выяснять и анализировать проблемы – важно! Но профессионалами по проектированию интерфейсов всё-таки должны быть мы с вами, а не пользователи.
Миф 6: Юзабилити не очень важно, важнее функциональность
Об этом я слышу особенно часто, но… Но как всегда, есть несколько «но»:
- Юзабилити – это и функционал в том числе. И зачастую при проведении детальных юзабилити-тестов мы приходили к необходимости убрать какой-то функционал, разработать другой и т.д. И в этих случаях это расширение функциональности несло добро в этот мир и удовлетворяло потребностям пользователей, а не просто было придумано аналитиками потому что «хорошо бы добавить».
- Если клиент не будет пользоваться продуктом (не поймёт, как; не захочет и т.д.), то до функционала он просто не дойдёт.
Любой современный продукт, добавляя новые фичи, в 99% случаев только повышает юзабилити! Это заметно не сразу, но присмотритесь: всё, что вы разрабатывали прошедшие релизы, можно было сделать и без нововведений. Но без них это было бы сложнее. Например, почтовый клиент научился сортировать письма по папкам в соответствии с правилами – раньше это можно было делать вручную. В банковскую программу добавили новый отчёт – раньше его заполняли в текстовом редакторе. В графическом редакторе новый фильтр – раньше можно было руками провести аналогичную ретушь. Почти всё, что делают ваши продукты, можно делать и без их использования, и вообще без использования ПО. Но с продуктами это становится УДОБНЕЕ, удобство выполнения пользовательских задач и есть главная цель любого продукта!
Выводы
Юзабилити – активно развивающаяся область в разработке ПО. И только развеяв перечисленные выше (и прочие, их ещё немало!) мифы, непрерывно совершенствуя себя и уделяя удобству использования должное внимание, вы сможете выпускать достойные продукты.
Узнать больше о тестировании юзабилити вы можете по нижеследующим ссылкам:
- «Как мыть слона?» — отличная вводная книжка Влада Головача по вопросам проектирования удобных продуктов.
- «Числовые методы в тестировании юзабилити» — мой обзорный доклад про тестирование юзабилити на конференции SQA Days