Ценная информация в нужное время: определение идеального уровня точности дизайна для пользовательского тестирования

В Intercom один из принципов разработки продуктов: мыслить масштабно, начинать с малого, учиться быстро.

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

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

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

Слова имеют значение

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

Определите проблему

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

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

Таким образом, чтобы определить правильную точность проектирования, вам необходимо определить, какую из следующих проблем вы пытаетесь решить:

• Концепции тестирования: имеет ли эта идея ценность?
• Дизайн системы тестирования: могут ли пользователи сформировать «достаточно хорошее» представление об этой системе?
• Тестирование удобства использования: могут ли люди использовать этот продукт?

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

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

«На ранних стадиях вас не интересует, как они будут с ней взаимодействовать. Вас интересует, будет ли это ценно для них».

Концепции тестирования: имеет ли эта идея ценность?

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

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

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

Быстрые текстовые описания, раскадровки, макеты целевых страниц, диаграммы в Google Slides или каракули в стиле доски — все это законные варианты. Сохраняйте простоту и целенаправленность, размывая ненужные тексты и используя очевидные графические заполнители.

Дизайн системы тестирования: могут ли пользователи сформировать «достаточно хорошее» представление об этой системе?

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

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

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

Тестирование удобства использования: могут ли люди использовать этот продукт?

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

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

В итоге

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

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

Хотите узнать больше о работе с нашей командой? Узнайте о наших ценностях, о том, как мы работаем, и о наших открытых ролях здесь.