Тестирование ux-прототипов как необходимое звено разработки продукта

Posted on by riasevastopol

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

  • одностраничный сайт, либо мультистраничный с достаточным числом меню и экранов, благодаря которым пользователь делает собственные задачи;
  • реалистичный и подробный прототип либо схематичный, существующий в виде наброска на бумаге;
  • интерактивный (кликабельный) либо статичный (действия компьютера имитирует человек).

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

Просматривайте кроме этого: Оптимизация дизайна для стремительного тестирования прототипов

Для чего тестировать прототип?

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

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

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

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

Просматривайте кроме этого: Способ «минимально жизнеспособного продукта»

Интерактивные и статичные прототипы

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

Интерактивные (кликабельные) прототипы

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

Статичные прототипы

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

1. «Колдун страны Оз»

Способ назван в честь популярной книги Фрэнка Баума (Frank Baum). В произведении, как вы не забывайте, колдуном был простой человек. В опыте «колдун» (роль которого играется дизайнер, прекрасно привычный с прототипом) удаленно осуществляет контроль экран участника, пребывав в второй комнате. Ни один из кликов пользователя в действительности ничего не означает. В то время, когда человек совершает воздействие, «колдун» за стенкой решает, что должно случиться дальше, и вносит трансформации в экран пользователя.

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

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

2. Бумажный прототип компьютера

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

3. «Захваченная» мышь (Steal-the-Mouse)

Версия «Колдуна страны Оз», где «колдун» сидит в той же комнате, что и пользователь (роль «колдуна» может сыграть ведущий). Прототип демонстрируется пользователю на экране компьютера. Когда участник совершает клик, ведущий требует его отвернуться, а сам вносит трансформации на экране.

После этого человек продолжает работу с прототипом.

Рекомендации

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

2. Ведущий обязан удерживаться от объяснения и комментариев дизайна пользователю.

Дабы выяснить самый подходящий вам прототип, ответьте на вопросы:

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

В случае если большая часть ответов утвердительные, то попытайтесь кликабельный вариант, в случае если — нет, то подойдет и статичный.

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

Прототип может иметь высокую либо низкую точность по всем либо некоторым перечисленным компонентам. Ниже растолковано, в чем выражена высокая и низкая точность этих элементов:

Правильный прототип

Неточный прототип

Интерактивность

Кликабельные ссылки и меню

Их большое количество. Большая часть из них кликабельны.

Нет. Интерактивные элементы не трудятся.

Непроизвольный отклик на действия пользователя

Да, ссылки в прототипе необходимы для работы при помощи инструмента прототипирования

Отсутствует. Экраны сменяются человеком, играющим роль компьютера

Внешний вид

Реалистичная визуальная иерархия, размер элементов экрана и приоритет экрана

Да, вся графика и макет выглядят как в готовом продукте (кроме того в случае если прототип реализован на бумаге).

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

иерархия и Контент навигации

Контент

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

Нет, в прототипе представлено только краткое содержание материалов и плейсхолдеры вместо изображений.

Просматривайте кроме этого: Проектирование пользовательского опыта: стратегия task flows

Преимущества точных прототипов

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

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

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

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

2. В случае если прототип близок к финальному виду совокупности в плане интерактивности либо ее визуальной стороны, вы сможете протестировать рабочие процессы (workflow), конкретные компоненты интерфейса пользователя (к примеру, мега-меню, раскрывающиеся меню), такие графические элементы, как affordance («очевидности» в дизайне), иерархию страниц, читаемость шрифта, уровень качества изображений а также степень вовлечения (engagement).

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

В итоге поведение пользователей перестает быть стопроцентно естественным.

4. Правильные в плане интерактивности прототипы освобождают от необходимости имитировать работу совокупности и позволяют сосредоточиться на ходе опыта.

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

Просматривайте кроме этого: Кейс от Mozilla: тестируйте бумажные макеты, дабы сэкономить деньги и время

Преимущества прототипов низкой точности 1. Меньше времени на подготовку статичного прототипа, больше времени на работу над дизайном до начала опытов

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

2. Несложнее корректировать дизайн на протяжении опыта

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

3. Неточные прототипы не давятна пользователей

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

4. Дизайнеры относятся к прототипам без лишнего трепета

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

5. Инвесторы и другие заинтересованные стороны не докучают вам

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

Просматривайте кроме этого: Как совершить «бережный» мобильный юзабилити-тест?

Сотрудничество с пользователем на протяжении опробований любого прототипа

При тестировании прототипа ведущий, в большинстве случаев, общается с участниками значительно больше, чем при опробованиях готовой совокупности. В основном, это происходит по следующим обстоятельствам:

  • ведущему нужно растолковать природу прототипа (но не то, как трудится дизайн);
  • время от времени ведущему нужно растолковать текущее состояние совокупности (к примеру, «Эта страница пока не работает») либо задать вопрос «Что, как вы ожидали, должно было случиться?»;
  • не редкость, что ведущему нужно узнать, по какой причине участник опыта приостановил работу: по причине того, что ожидает отклика либо по причине того, что считает, что он выполнил задачу.

Кроме того не обращая внимания на то, что ведущему приходится иногда взаимодействовать с участником тестирования, его главная цель — нормально следить за человеком, трудящимся с дизайном, а не говорить с ним.

Рекомендации

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

  • сообщить: «Данный элемент не работает»;
  • задать вопрос: «Что, как вы ожидали, должно было случиться?»;
  • попросить пользователя щелкнуть по следующему элементу.

К примеру: «Вы надавили на ссылку «компактные машины». К сожалению, мы еще не подготовили соответствующий экран. Попытайтесь выбрать категорию «среднеразмерные машины».

По окончании того, как пользователь выберет данный пункт, старайтесь сказать как возможно меньше, оставайтесь бесстрастным.

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

Просматривайте кроме этого: Секрет действенного лендинга кроется в его прототипе

Неточности «компьютера» искажают эти

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

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

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

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

Просматривайте кроме этого: Секреты юзабилити: из-за чего пользователи винят себя в неточностях дизайнеров?

Заключение

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

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

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

Высоких вам конверсий!

По данным: nngroup.com Image source Stefano Bertolotti

Случайные статьи:

UX исследования на всех этапах разработки продукта


Подборка похожих статей:

riasevastopol

More Posts