Казалось бы, ответ на вопрос “Стоит ли тестировать новый дизайн?” очевиден. Но все не так однозначно. Бывают ситуации, когда без тестирования можно обойтись, сэкономив время и другие ресурсы.
Тестирование и исследования делают дизайн лучше. Вы могли убедиться в этом на собственном опыте, запуская тесты перед тем, как приступить к следующей итерации, или работая с исследователями над созданием новой функции.
Возможно, вы прибегали к исследованиям, чтобы повысить удобство использования, исправить недочеты и определить, какие изменения следует внести в рамках следующего спринта. Исследования пользователей действительно помогают дизайнерам принимать более эффективные и обоснованные решения.
Но у нас есть секрет. Иногда... в них нет необходимости.
Это не значит, что вы должны начинать каждый проект вслепую, но бывают случаи, когда вам не нужно расставлять все точки над "i".
Как всегда, важно правильно расставить приоритеты. Вы знаете, что время на тестирование ограничено. Вам нужно оценить, что необходимо протестировать прямо сейчас, что может подождать, а с чем можно двигаться вперед без тестирования.
Во-первых, вот когда тестирование обязательно
Давайте поговорим о тех ситуациях, когда без тестирования совершенно точно не обойтись. Без вопросов. Никаких отговорок. Это нужно сделать.
Если вы изучаете абсолютно новую концепцию, вы должны ее протестировать. Не стоит тратить время и ресурсы на движение по пути, который не сработает, а без похожих примеров вы не сможете принять взвешенное решение. Не идите с закрытыми глазами. Тестируйте.
“Если вы изучаете абсолютно новую концепцию, вы должны ее протестировать.”
Но тестируйте так, чтобы это было максимально эффективно и не отнимало много ресурсов. Один из вариантов — немодерируемое тестирование концепции и юзабилити.
Если речь не об инновациях, возвращаемся к главному вопросу. В каких случаях тестирование необходимо, а когда можно руководствоваться своими предположениями и пропустить его?
7 вопросов, которые нужно задать
При участии дизайнеров и исследователей мы разработали фреймворк из 7 вопросов, которые помогут определить, нужно ли вам тестирование, или вы можете спокойно двигаться вперед и уверенно принимать дальнейшие решения.
1. Вопрос об основном сценарии
Является ли эта функция частью основного сценария опыта взаимодействия?
Ответ: ТЕСТИРУЙТЕ! Всякий раз, когда новая функция является неотъемлемой частью опыта взаимодействия пользователя с вашим продуктом, стоит вложить средства в тестирование концепции и юзабилити.
2. Успех запуска
Будет ли способность пользователя выполнить это конкретное действие определять успех запуска?
Ответ: ТЕСТИРУЙТЕ! Всегда тестируйте, если действие напрямую связано с успехом. Интуиции недостаточно, если вы хотите, чтобы запуск был успешным и прибыльным.
3. Сложность для пользователя
Та ли это область, в которой, как мы предполагаем, у пользователей могут возникнуть трудности?
Ответ: ТЕСТИРУЙТЕ! Если функция затрагивает важную болевую точку и может поставить пользователей в тупик, лучше перестраховаться, чем потом жалеть. Проведите тестирование, чтобы определить, действительно ли вы решили их проблемы, или новая функция создает дополнительные трудности.
4. Влияние на выполнение задачи
Изменит ли это способ выполнения задач текущими клиентами? Повлияет ли на то, как клиенты действуют сейчас?
Ответ: ТЕСТИРУЙТЕ! Новое не всегда лучше. Тестирование помогает определить, сделали ли вы жизнь пользователей проще, а также понять как эффективнее всего познакомить клиентов с нововведениями. Если какая-то функция окажется слишком сложной, возможно, стоит поработать над ней дополнительно. Необходимо вложить средства в продуманный процесс онбординга, чтобы пользователи, привыкшие к предыдущей версии продукта, смогли адаптироваться к новым условиям.
5. Лучшие практики
Существуют ли в этой области лучшие практики? Например, знаете ли вы, что зеленая кнопка сигнализирует об успехе, а красная — останавливает пользователей от продолжения работы?
Ответ: НЕ ТЕСТИРУЙТЕ! Если существует устоявшаяся лучшая практика, в тестировании нет необходимости. Вы можете быть уверены, что ваши пользователи легко разберутся в новых функциях.
6. Предпочтения пользователей
Кому-то нравится шоколад, а кому-то ваниль. Кому-то нравится голубой цвет, а кому-то розовый. Людям всегда будут нравиться разные вещи, и вы никогда не сможете угодить абсолютно всем. Является ли то, что вы хотите протестировать, просто вопросом предпочтений?
Ответ: НЕ ТЕСТИРУЙТЕ! Предпочтения пользователя относительно того, что красивее, а что нет, не являются достаточно весомым основанием для тестирования. Какими бы ни были полученные результаты, они вряд ли повлияют на итоговую прибыль.
7. Неоправданные усилия
Сколько усилий на самом деле потребует тестирование? Есть ли у вас необходимое для его проведения время?
Ответ: ТЕСТИРУЙТЕ... НО НЕ ВСЁ. Если идея тестирования кажется пугающей, отступите на шаг назад. Взгляните на свой проект. Не каждая деталь критически важна. Некоторые из них попадают в категорию требующих тестирования, в то время как другие — можно пропустить. Например, в Sprig мы сейчас переделываем нашу страницу вопросов. Для полного тестирования потребовалось бы создать сложный прототип, но в этом нет необходимости. Вместо этого мы выборочно протестируем наиболее важные части страницы.
