Все мы не раз сталкивались с понятием целевой аудитории. В последнее время это словосочетание все чаще используется в качестве одной из характеристик организации, товара или услуги. И действительно, в любом бизнесе действует простая и очевидная схема: для любого продукта есть свой пользователь. Несомненно, это правило затрагивает и ПО. В этой статье я предлагаю обсудить довольно сложный вопрос: чем знание целевой аудитории поможет при оценке степени несоответствия заложенных ожиданий реальным по отношению к тестируемому продукту?
Прежде всего разберемся, что же такое целевая аудитория (в дальнейшем – ЦА). В соответствии с определением из Британского бизнес-словаря, целевая аудитория (англ. target audience) – это группа людей или сегмент рынка, для которого предназначен продукт, услуга, веб-сайт, реклама, телевизионная или радио программа и т. д.
Если не вникать в суть вопроса, то может показаться, что ЦА – это некая общность потенциальных потребителей или покупателей продукта. На практике все обстоит далеко не так просто, и подтверждение тому – огромное количество несостоявшихся проектов, владельцы которых при запуске ожидали увидеть ажиотажный спрос на свое детище. Причиной провала во многих случаях являлась в том числе не соответствующая реальности оценка ЦА.
Для чего нам нужно знать целевую аудиторию проекта?
Знать и понимать ЦА важно на каждом этапе разработки программы. Может ли разработчик приложения-мессенджера, к примеру, не учесть, что продуктом могут воспользоваться слабовидящие пользователи, для которых нужны специальные возможности? Запросто!
При проектировании сайта важно не только добиться привлекательного оформления страниц, но и обеспечить пользователю простое и понятное выполнение пользовательских действий (например, сделать процесс поиска товара легким и очевидным). На этом этапе тщательное изучение ЦА является обязательным. Оно необходимо для того, чтобы понять, почему пользователь не выполняет ожидаемых от него действий и не реализует цель нахождения на сайте (или использования продукта).
Но в тот момент, когда речь заходит о тестировании, информация о ЦА нередко отступает на задний план. Тестировщики обсуждают функциональное и нагрузочное тестирование, тестирование безопасности и требований, проверяют массу показателей состояния продукта, но почему-то не учитывают особенности взаимодействия пользователя с программой – его поведенческие привычки, компьютерную грамотность, обучаемость и, наконец, его ожидания от работы с ПО или продуктом. Не стоит обвинять в этом тестировщиков: не они решают, какие именно требования ставятся перед проектом. Но вот решение задачи по корректировке заявленных целей и проведению необходимых проверок с учетом знания ЦА – в их компетенции.
Для формирования психологического портрета представителя ЦА применяются классические методики: опросы, сбор данных от фокус-групп, ведение статистики, интервьюирование посетителей аналогичных по наполнению сайтов. При этом умение поставить себя на место пользователя – это важное качество для тестировщика.
Одной из классических проблем написания ПО является приверженность разработчиков привычной им логике того или иного языка программирования, которая часто непонятна конечному пользователю (если речь не идет об узкоспециализированном ПО, рассчитанном на конкретную аудиторию, обладающую особыми знаниями). Проблема усугубляется в том случае, если и тестировщики не учитывают, что результат работы (как и удовлетворенность от использования продукта) может зависеть от возраста, знаний, уровня образования и прочих характеристик пользователя.
В ряде случаев пользователь нуждается в подробном описании вариантов действий – что именно, в каком месте и в какой последовательности он должен сделать для того, чтобы получить нужный результат. Если вместо этого он увидит простое описание параметров (пусть даже подробное), цель может стать недостижимой. Недаром на форумах мы встречаем так много вопросов, связанных с, казалось бы, простейшими функциями приложений.
Пример.
Важный аспект работы сервисов, связанных с онлайн-платежами, – корректная обработка ошибок и выдача внятных уведомлений пользователям. К сожалению, это правило соблюдается не всегда. Так, на сайте авиакомпании «Победа» при оплате билета сервис не сообщает о статусе произведенного платежа. На этом ресурсе также невозможно быстро получить информацию о максимальном размере и весе багажа, хотя компания имеет жесткие ограничения на эти параметры.
Проблемы клиента на этом не заканчиваются: поиска на странице (как и глобального поиска) не существует, а все блоки информации спрятаны под «плашками». Каждую такую «плашку» нужно разворачивать – только тогда появляется возможность прочитать содержимое каждого из блоков или воспользоваться клавишами ctrl+f в браузере.
Тестирование с ориентацией на ЦА
Возможно, у вас создалось впечатление, что для успешного тестирования продукта необходимо провести огромную исследовательскую работу, потратив не один день для выделения ЦА? К счастью, все не так страшно, как кажется на первый взгляд. На практике нам достаточно определить, кому именно нужен конкретный продукт, а далее проделать три последовательных шага. Рассмотрим этот алгоритм на конкретном примере.
Шаг 1. Определяем ЦА продукта.
Рассмотрим на примере создания приложения по обучению экстремальному спорту, которое подойдет как для начинающих, так и для продвинутых спортсменов.
Цель приложения – обучение новым трюкам, обеспечение возможности общения между людьми с общими интересами.
Архитектура приложения – блоки трюков с разделением по видам спорта, лента новостей, видеозапись трюка, чат, личная страница, поиск.
Приложение рассчитано на социально активных мужчин и женщин возрастом от 14 до 40 лет, проживающих в Европе, Америке и Азии и имеющих средний или высокий уровень доходов.
Итак, у нас есть общее понимание нашей ЦА, но достаточно ли этого для тестирования продукта? К примеру, предприниматель Валера (33 года, живет в городе Зеленогорск, каждые выходные ездит на рыбалку) подходит под все критерии нашей ЦА, но на самом деле не является потенциальным пользователем приложения. Очевидно, мы не можем провести достоверное тестирование, ориентируясь только на общие параметры. Вжиться в роль абстрактного «мужчины или женщины от 14 до 40 лет» невозможно – для дальнейшего исследования нам нужно конкретизировать несколько персонажей.
Шаг 2. Выявляем ролевые персонажи.
Проанализировав информацию мы можем создать 3-4 основных персонажа, для каждого из которых составим сценарий использования приложения. Персонаж обычно описывается как конкретный человек, являющийся типичным представителем определенного сегмента ЦА со своими потребностями, особенностями, привычками, мотивами и прочими характеристиками, влияющими на его поведение.
Примеры разработанных персонажей:
ОПИСАНИЕ ОСНОВНОГО ПЕРСОНАЖА
ОПИСАНИЕ ДОПОЛНИТЕЛЬНОГО ПЕРСОНАЖА 1
ОПИСАНИЕ ДОПОЛНИТЕЛЬНОГО ПЕРСОНАЖА 2
Шаг 3. Определяем ключевые решаемые сценарии.
Пользовательские сценарии представляют собой «протоколы» взаимодействия пользователей с системой. Мы определяем задачи пользователя внутри системы, его действия, направленные на решение этих задач, а также контекст, в котором эти задачи выполняются.
Пример.
Проектировочные сценарии являются базовым описанием взаимодействия, исходя из которого проектировщик и дизайнер придумывают интерфейс, а тестировщик создает задания на тестирование продукта пользователями.
Каким образом применить знания ЦА и персонажей в тестировании?
Портрет ЦА и ролевые персонажи чаще всего применяются при тестировании юзабилити. Юзабилити-тестирование – это проверка удобства интерфейса продукта для конечных пользователей. Юзабилити-тестирование показывает, насколько продукт соответствует ожиданиям пользователей, выявляет проблемные места в интерфейсе и дает возможность взглянуть на продукт иначе, глазами пользователей.
Конечно, проведение юзабилити-тестирования допускается на разных этапах процесса, но оптимальный вариант – внедрять его на начальных стадиях создания интерфейса, еще до его реализации в программном коде. Чем раньше мы исключим ошибки в интерфейсе и сделаем его по-настоящему удобным – тем легче, быстрее и дешевле станет весь процесс разработки ПО. Юзабилити-тестирование можно проводить как на реальных пользователях продукта, выбранных из нашей ЦА, так и на ролевых персонажах.
Тестирование реальными пользователями
При таком способе создаются сессии тестирования – каждая сессия проводится с конкретным пользователем в индивидуальном порядке и длится около часа. За это время человек выполняет несколько типовых пользовательских задач, которые заранее определяются специалистом совместно с заказчиком. Сделать это не так трудно: понимая цель разработки нашего приложения и его архитектуру, а также определив ЦА, мы легко можем наметить действия нашего пользователя при использовании.
Например, для приложения, посвященного обучению экстремальному спорту, могут быть намечены следующие задачи:
- найти определенный вид спорта и зарегистрироваться в качестве спортсмена;
- найти конкретный трюк и ознакомиться с техникой его исполнения;
- найти уже существующий видеосюжет трюка и добавить свой ролик;
- найти ближайшее к дому или работе место для выполнения трюка;
- найти ближайшее по месту или времени спортивное мероприятие.
После выполнения пользователем этих задач мы оцениваем результаты и анализируем, с какими именно трудностями он столкнулся. Этот процесс нередко выявляет неожиданные проблемы, о которых мы даже не думали, ведь уровень квалификации пользователей может быть совершенно различным.
Пример.
По клику на картинку откроется полная версия.
Тестирование при помощи ролевых персонажей
Производится в том случае, когда у нас нет возможности задействовать реальных пользователях. Итак, мы знаем проблемные шаги в приложении, у нас есть набор гипотез, которые нам нужно проверить.
Теперь самое время провести тестирование, для подготовки к которому нам потребуются:
- описание персонажей для тестирования (примеры приведены выше);
- список заданий для тестирования;
- оценочные листы к списку заданий.
Задания позволят пройти по нужным сценариям и увидеть, каким образом наши персонажи будут работать с продуктом. Формирование заданий из сценариев не вызывает трудностей: например, если есть сценарий «заказ услуги», то будет и задание «заказать эту услугу». Нам нужно определить конечную цель сценария и посмотреть, как она будет достигнута. И помните – если реальный путь расходится с ожидаемым, то кто-то не очень хорошо знает своих пользователей.
В оценочных листах мы отмечаем следующие критерии:
- Выполнил ли задачу персонаж?
- Смог ли он достигнуть нужного результата?
- Сложности, с которыми он столкнулся (например, по шкале от 1 до 5, где 1 – это недостижение цели при наличии множества сложностей, а 5 – достижение цели без всяких проблем).
- Затраченное время (отмечаем, пройден ли сценарий за предполагаемое время, или прохождение потребовало больше времени).
После тестирования нужно собрать разрозненные оценки и понять, в каких местах пользователь не понимает заложенную логику (в силу ее запутанности или неочевидности), а в каких – просто допускает свойственные всем ошибки.
Пример.
Нередко камнем преткновения становится запрос на регистрацию. Многие проекты сразу требуют регистрации. Но пользователь в начале работы еще не уверен, нужно ли ему это. Прежде чем предлагать заполнить регистрационную форму или заплатить за контент, необходимо предоставить клиенту информацию о функциях программы или предложить демо-версию продукта.
Очень часто после юзабилити-тестирования приходит понимание, что разработчики и пользователи говорят и мыслят на разных языках. В этом случае новаторские идеи, заложенные в интерфейс продукта, остаются непонятыми или непринятыми целевой аудиторией. Но только ли в юзабилити-тестировании нужно знать свою целевую аудиторию и ориентироваться на нее?
Функциональное тестирование с учетом ЦА
Помимо указанных способов, есть возможность измерить показатели производительности и оценить предпочтения пользователей. Производительность определяется успехом выполнения задания, ошибками, временем выполнения и т.п. Информацию о предпочтениях мы получаем из отчетов пользователей о комфорте при использовании сайта и общей удовлетворенности процессом работы. Как ни странно, оценка предпочтения далеко не всегда соответствует уровню производительности.
В результате проведения одного исследования было обнаружено, что примерно у 70% пользователей показатели производительности и оценки предпочтений согласованы между собой: эти клиенты либо успешно выполняют задания и им нравится сайт, либо не выполняют задание и не одобряют интерфейс сайта. Следовательно, для многих людей (около 30%) эти показатели не совпадают: они успешно выполняют задания, но сайт им не нравится, или же неудачно выполняют поставленные перед ними задачи, но сам по себе сайт их устраивает.
Это парадоксальное, на первый взгляд, явление имеет немало причин. Часто люди считают, что они сами, а не сайт, виноваты в возникающих проблемах. Наиболее тактичные пользователи боятся оскорбить чувства владельцев, поставив сайту низкую оценку. Наконец, многие просто не замечают проблем и думают, что у них все получается, хотя на самом деле это не так.
Но если проблемы с сайтами и их проектированием, как правило, очевидны, то сложные интерфейсы требуют особого нетривиального подхода. Только тогда тестировщики могут выявить проблему и инициировать ее исправление до обнаружения пользователями.
Пример.
Во время тестирования бэкапов на разные носители был выявлен баг: не работала выгрузка на тейпы (пленочные кассеты). Разработчики решили не исправлять ошибку, так как из отдела маркетинга поступила информация, что «в 2008 году объем продаж тейпов упал почти до нуля». Баг ушел в релиз, и уже скоро до 80% клиентов указали на данную ошибку. Оказалось, что срок использования тейпов достигает 25 лет, в этом заключается их преимущество перед другими носителями. Для исправления ошибки пришлось провести большую работу: был запущен опрос по всем особенностям окружения, собрана статистика, найдена возможность связаться с админами и получить информацию по используемым ПК, размерам и производителям HDD, предпочтениям в использовании файлов. После тщательного анализа и проработки полученной информации новая стратегия тестирования принципиально отличалась от первоначальной.
Пример.
При тестировании ПО для создания договоров по управлению домами был задан вопрос аналитику: «Сколько может быть учтено домов»? По мнению специалиста, количество могло варьироваться от 10 до 1000. Тестировщик провел проверку 5000 домов и получил положительный результат. Релиз вышел, и очень скоро оказалось, что количество домов может достигать 100 000! Для такого объема проверка не проводилась, что повлекло за собой возникновение ошибок.
Вывод
Часто разработчики, уверенные в корректной работе функционала проекта, сталкиваются с ситуацией, когда процесс коммуникации пользователей с продуктом идет совсем не так, как задумывалось. Пользователи заявляют, что программа плохо решает поставленные перед ней задачи. В этом случае необходимо проверять проблемные ситуации на респондентах из ЦА. Аналитика поможет локализовать ошибки внутри продукта, сценарии – выявить контекст затруднений, а привлечение ролевых персонажей – найти реальные проблемы приложения. Своего пользователя нужно знать в лицо!
И последнее. При работе над любым продуктом вопрос определения ЦА необходимо всегда ставить на первое место. Это позволит в худшем случае минимизировать потери от оттока конечных пользователей, в лучшем – сделать продукт удобным для потребителя и финансово успешным для заказчика.
