Вы написали и просмотрели копию своей домашней страницы. И ты доволен этим.
Но имеет ли это смысл для пользователей? Есть только один способ узнать это, и это сделать это перед этими людьми.
Пришло время поговорить о тестировании.
Зачем проверять свою копию?
Для меня этот вопрос во многом похож на вопрос «Зачем тестировать потоки или макеты страниц?»
Тем не менее, у меня мало клиентов, которые тестируют макеты страниц, не говоря уже о копировании. Я думаю, возможно, что принятие общепринятых макетов страниц убеждает владельцев сайтов, что им не нужно тестировать. Если этот макет целевой страницы работает для [назовите вашего крупнейшего конкурента], то, конечно, он будет работать для вас … или так будет продолжено.
Даже если бы это было так (и я не верю, что это так), язык, который вы используете для передачи своей новой концепции или услуги, будет отличаться от ваших конкурентов (мы надеемся!).
Да, это может иметь смысл для вас, всех в вашем офисе, вашего делового партнера, вашего жизненного партнера и вашего любимого бигля. Но эти люди слишком близки к игре, чтобы объективно увидеть ваш текст.
Вы должны проверить это.
Что проверять когда
Если вы создали новый словарь для своего продукта или услуги — особенно если продукт вводит новую концепцию, о которой вам нужно будет обучать пользователей — тестирование ключевой терминологии в то же время, когда вы тестируете каркас сайта, является идеальным.
Возможно, вы уже тестировали свои надписи IA в рамках каркасного теста, так почему бы не проверить текст ключа одновременно? Вы можете проверить:
- Ваш слоган или предложение о продаже
- поток заголовков шагов в вашей копии «Как это работает»
- призывы к действию и ярлыки кнопок
- названия, которые вы дали уровням оплаты вашего продукта
- и так далее.
Конечно, вы также можете проверить терминологию на своих маркетинговых или рекламных страницах, а также в самом приложении, если это то, что вы продаете.
Если вы уже прошли каркасное тестирование до того, как подготовили черновик своей копии, вы можете попробовать протестировать ключевые термины и концепции на выложенных страницах, но это далеко не идеально.
Каркасы позволяют тестировать базовый макет страницы, поэтому они являются лучшим местом для тестирования ключевой терминологии. Но если вы добавите только ключевую терминологию на выложенную страницу, она будет выглядеть незаконченной и может привести пользователей в замешательство.
И если вы решите пойти дальше и протестировать полную копию, вы никогда не узнаете, получили ли пользователи (или не получили) сообщение из-за самой терминологии, или как оно использовалось в предложениях, или из-за других аспектов. дизайна страницы.
Давайте посмотрим, как это может сбить с толку через пару примеров.
Контрольный пример 1: копировать в каркас
Не так давно мне пришлось протестировать ключевую терминологию, перечисленную выше, в рамках пользовательского тестирования каркасов. Продукт представлял собой транзакционный сервис на основе социальных сетей. Целевую аудиторию можно охарактеризовать как массовый рынок: увлеченный покупками, но не технологически подкованный.
Мы разработали словарь для этого продукта и использовали его, чтобы объяснить, что это за концепция и как она работает, примерно в 60 словах на главной странице.
Кроме того, нам нужно было разработать убедительный заголовок, содержащий CTA и кнопку CTA, которая имела бы смысл для пользователей.
Мы подготовили этот контент, поместили его без каркаса в каркасы и провели с ними личное тестирование.
Результаты были неоценимыми: спросив пользователей, что они понимают об услуге, посмотрев на домашнюю страницу, мы:
- были в состоянии определить ключевую терминологию, которая была необходима для понимания службы — и сократить остальное
- Выявлены возможности связать ключевые слова с информационными страницами, которые в полной мере исследовали концепции, что уменьшило количество слов на домашней странице, не рискуя запутать тех, кто их не получил.
- были в состоянии отточить терминологию, чтобы отразить собственный язык пользователей и их ожидания. Например, вместо того, чтобы называть картинку «картинки», мы обнаружили, что можем лучше соответствовать ожиданиям пользователей, называя картинки «иллюстрацией». К счастью, это также повысило восприятие пользователем качества продукции. Выиграть!
Контрольный пример 2: скопируйте на выложенную страницу
В проекте с дизайнерским агентством мы буквально не могли помешать этим увлеченным типам дизайнеров создавать визуальные элементы страницы. У нас было два разных макета страниц для тестирования, а также устоявшийся словарный запас, который мы настроили так, чтобы он обращался к более широкой аудитории. Таким образом, мы поместили словарь в два макета и передали их пользователям.
Результаты не были действительно полезны. Как и следовало ожидать, некоторые пользователи предпочитали одну страницу другой, но мы не могли сказать, было ли это из-за макетов или того, что сообщалось в каждой.
Мы обнаружили, что пользователи пропускают определенные опции в интерфейсе, некоторые из которых используют наш измененный словарь бренда. С точки зрения UX, мы не могли сказать, было ли это потому что:
- цвета не позволили этим параметрам выделиться
- на странице были отвлекающие моменты
- терминология не передавала то, что мы хотели.
Мы обнаружили, что ожидания пользователей в отношении терминологии не были отражены в том, что мы им показываем, но мы не знали, маскировали ли визуальные элементы или усиливали эти эффекты.
Из этого теста было трудно понять, куда идти. У нас было множество предложений по разработке терминологии для лучшего соответствия пользователям, но в некоторых случаях они противоречили друг другу, они не соответствовали бренду, и тест не выявил приоритетных элементов, которые, если мы их правильно поняли, будет иметь большое значение для понимания пользователей.
Как вы будете тестировать?
Как показывают эти случаи, базовые правила UX-тестирования применяются к копированию и тестированию вокаба.
Если вы хотите:
- используйте как можно меньше слов
- общаться как можно больше
- как можно быстрее
- как можно большему количеству ваших целевых пользователей
… проверить свою копию в ваших каркасах.
Это означает, что вам нужно будет разрабатывать свою копию при разработке пользовательского интерфейса, а не после этого, но в моих книгах это просто хорошая практика UX (независимо от того, как мало людей это делают). Это также дает вам лучший шанс связаться с целевыми пользователями сразу. И это ваша главная цель, не так ли?
Вы когда-нибудь проверяли свою копию? Как вы будете проверять это в следующий раз? Расскажите нам, как вы делаете это в комментариях.