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

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

Методы уменьшения затрат
Методы уменьшения затрат в сфере юзабилити были предложены Якобом Нильсеном и Джаредом Споулом около 20-ти лет назад. Говорят, что “наиболее достоверные результаты получаются при тестировании не более 5 человек и при проведении большого количества мини тестов». Основная идея здесь заключается в том, что качественные исследования являются менее дорогими, чем количественные, и к тому же быстрее, дешевле и рентабельней. Как сказал Я. Нильсен: “Нет необходимости измерять удобство пользования продуктом, чтобы улучшить его … Если вы видите, что несколько человек затрудняются при использовании одного и того же элемента дизайна, Вам не нужно знать, у скольких еще пользователей возникнет подобная проблема”. Например, в одном из тестов, который мы проводили в прошлом году, мы наблюдали 2-х пользователей не справившихся с одной и той же задачей. В данном случае, мы даже не стали смотреть, как с этой задачей справятся другие пользователи, а просто изменили дизайн и продолжили тестирование с новым дизайном. Следующие 3 пользователя успешно справились с задачей, которая вызвала затруднения у предыдущих пользователей.

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

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

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

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

Девид Чиснелла считает, что юзабилити тестирование – это скорее формирующий инструмент, чем, как многие обычно думают, обобщающий. Он утверждает, что юзабилити-тестирование должно применяться “везде и всегда, когда перед пользователями встает какая-либо задача…”. Юзабилити-тестирование является мощным инструментом для юзабилити специалистов, но как мне кажется, лабораторные исследования все таки имеют некоторые погрешности ввиду того, что проводятся в незнакомой для тестируемых обстановке. Мы также должны учитывать, что продукты, которые удачно используются в повседневной жизни, не всегда подходят для тестирования в лабораторных условиях. По этой причине я всегда стараюсь проводить тестирования с пользователями на их рабочем месте.

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

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

Примерно 10 лет назад я начала интересоваться пользовательскими историями об опыте взаимодействия с продуктом. Эти истории помогают нам понять потребности и действия пользователя. В них отражается не только оценка пользователем продукта, но его переживания, впечатления, эмоции. Как мы получаем пользовательские истории? От пользователей, конечно! Вы можете спросить тестируемых об их личном пользовательском опыте во время интервью, проведения тестов и т.д.. Пользовательские истории очень хорошо могут вписаться в процессы исследования пользовательского поведения.

Как и почему Agile Software может изменить положение?
Agile Software процессы различаются, но в целом они имеют и в общие характеристики, например:

• потенциальные покупатели продукта вносят свой вклад в процесс разработки продукта
• быстрая интеграция
• получение результатов в кратчайшие сроки

UCD / UX дизайнеры, как правило, работают не только с пользователями. Для них также очень важно изучать новые направления развития в дизайне и в исследованиях пользовательского поведения. Таким образом, при Agile разработке всегда смешиваются анализ, проектирование, разработка и взаимодействие на протяжении всего процесса разработки продукта, а это означает, что юзабилити специалисты должны будут обязательно адаптироваться к этой новой модели.

Пока есть люди, которые считают, что UX и Agile разработка не в ладах друг с другом. Мне же кажется, что в данном случае перед нами открывается чудесная возможность привлечь внимание общества к этой проблеме. Сколько раз вы находили то, что желали бы иметь пользователи, но Вам говорили, что введение этих обновлений возможно только в следующей версии продукта.

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

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

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

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

Перевод Анастасии Рязановой