Сделать лучше, чем у конкурентов. Как мы тестировали новый дизайн сайта и приложений с точки зрения likability (Михаил Правдин)

Михаил Правдин, UX Research Lead, Авито

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

Как пример, предположим, у нас есть несколько вариантов иконок навигации, и мы хотим понять, какой из вариантов нравится клиентам больше. Иконки, которые ты видишь сверху: дизайн 1 слева, дизайн второй справа. И мы спрашиваем: «Дизайн и внешний вид какого приложения вам нравится больше?»

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

Side-by-side-тесты очень хорошо подходят, когда нужно понять, как я сказал, какой дизайн больше нравится. Это могут быть иллюстрации, могут быть интерфейсные дизайны, могут быть иконки, могут быть любые картиночки. Также подходит, когда нужно понять, как они воспринимают дизайн, то есть спросить, какой дизайн больше кажется современным, второй момент — с чем ассоциируется дизайн, и третий — какой дизайн связывает какие-то… Здесь повтор, наверное. Напоминает что-то, что мы ожидаем. Это как раз про ассоциации. 

Нельзя использовать side-by-side-тесты, как нам кажется, для вопросов, когда мы хотим проверять удобство сценария, потому что это уже UX-юзабилити. Здесь side-by-side-тест подходит, как нам кажется плохо. Проверить находимость элементов — это, в принципе, тоже UX-тесты. Оценивать понятность и желанность, востребованность. Вот эти три момента на side-by-side-тестах мы стараемся не проверять, для этого подходит либо модерируемое, либо немодерируемое обычное тестирование. В принципе, для таких задач можно использовать «Яндекс.Взгляд» или Fastuna, но не SbS-тесты на «Яндекс.Толоке».

Давай еще несколько примеров посмотрим, чтобы закрепить тему с side-by-side, какие тесты мы запускали на side-by-side. Например, когда мы выясняли, куда нам лучше расположить иконочки с сердечками, добавление в избранное. Левый и правый вариант — какой больше нравится? Или когда мы пытались понять, как лучше описать характеристики: в две колонки или сразу после… Как это слева назвать? После типа характеристик. Или когда мы пытались понять, какая иконка больше ассоциируется у пользователей с чатом, с поддержкой, левая или правая.

Также есть несколько примеров от «Яндекса», они на последней конференции рассказывали. У них был кейс, когда они выбирали для своей операционной системы наиболее привлекательные обои, которые добавить в пул предустановленных картинок, чтобы не добавлять все. Здесь мы видим в верхней строчке победителей.

Или вот тоже «Яндекс» рассказывал, они с помощью side-by-side-тестирования выясняли, какую обложку на боевики поставить. Как лучше отобразить стикеры, как лучше нарисовать стикеры для мессенджера. Как лучше отображать, опять же, именно с точки зрения визуала, рецепты, которые выдает «Алиса». Ну и так далее.

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

Мы тут side-by-side не используем как единственный метод, результаты получили — и всё. Конечно же, в тех примерах, которые я показывал, например даже с сердечками, здесь можно еще запустить после этого A/B-тест и посмотреть, где чаще используют. То есть для нас side-by-side-тест — это как еще один метод в дополнение к A/B, если A/B занято или если мы хотим до A/B несколько дизайнов. Ты же на A/B не запустишь сразу 50 и даже 5 тестов. А на side-by-side можно, это гораздо дешевле.

Один тест в среднем стоит 10 долларов и длится 2 часа, поэтому это гораздо быстрее и дешевле, чем пускать на A/B, во многих случаях. Поэтому важно отметить, что у нас side-by-side в дополнение. Или когда нет возможности запустить A/B, мы используем side-by-side-тесты.

Вроде бы уложился в 5–7 минут. Это про side-by-side. Я здесь делаю паузу, чтобы, может, ты какие-то комментарии сказала.

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

SbS-тесты суперпросты в запуске. Вот у тебя есть два варианта, ты сомневаешься, как я говорил, какая иконка лучше подходит для чата с поддержкой. И ты эти две иконки швырнул в тест, фактически загрузил, как ты загружаешь любые картинки куда-то, и через 2 часа у тебя результаты. Ты на них посмотрел, такой: ага, вот эту 63% понимают, а вот эту — 37%, значит, выбираем вот эту иконку. И всё. Не мучаешься, не страдаешь, не споришь с дизайнером, что часто бывает в продуктовых командах, потому что у каждого свое мнение: тебе больше нравится человечек, мне больше нравится это.

Теперь про проверку дизайна наших новых главных страничек и приложения.

У нас в маркетинге постоянно проводят опросы аудитории, и мы знаем из этих опросов, что, например, если мы говорим про «Авито Авто», сравниваем с Drom, сравниваем с Auto.ru, то наш сайт ассоциируется у пользователей с более старым, несовременным. Так часто сравнивают, например, с Киркоровым, при этом Auto.ru сравнивают с… Когда маркетинг проводит исследования, они ассоциативные такие штуки используют, механики. Вот мы как Киркоров, а Auto.ru как такой проверенный автодилер. С точки зрения именно восприятия сервиса пользователями мы гораздо более олдскульные и несовременные.

Поэтому мы здесь, разрабатывая дизайн наших новых страничек… Не так. Разрабатывая обновленный дизайн сайта и приложения, мы думаем на тему: «О’кей, а как нам сделать его либо на уровне, либо лучше, чем наш старый дизайн?» Точнее, не так. «Лучше, чем наш старый дизайн, и на уровне или лучше, чем дизайны конкурентов».

То есть мы сами, рисуя макеты нового дизайна сайта (который на втором месте находится), глядя на эти макеты, думаем, что «о’кей, это классный дизайн, он на уровне или даже лучше конкурентов, мы можем его отдавать в разработку». Но при этом мы понимаем, что это наше мнение, а мнение пользователей здесь может отличаться. И мы поставили перед собой задачу: перед тем как отдавать эти макеты, эти дизайны веб и мобилки в разработку, нам как раз было бы здорово, опять же, с помощью тех же side-by-side-тестов быстро проверить, а так ли это, действительно ли пользователям он нравится больше, чем старый «Авито», и действительно ли он лучше или на уровне, если сравнивать с конкурентами.

Опять же, ты можешь сделать это через A/B-тест. Но через A/B-тесты не только «нравится или не нравится» будешь проверять, там ты кучу других метрик… Но, скорее всего, отдельно эту метрику ты никак не поверишь, потому что A/B-тесты — это поведенческие метрики. Поэтому решить эту задачу с A/B-тестами сложно. А с side-by-side, как нам показалось, в принципе, возможно.

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

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

Дальше. Тяжело показать только один экран. Особенно если мы говорим про мобильную версию. Ты не можешь просто отрезать экран и вот так показать, потому что много дизайна скрыто еще ниже. Если мы говорим про старую версию, где главная страница — это выдача, то здесь похожий дизайн. А если мы говорим, например, про новую или про Auto.ru, то здесь снизу кроется куча элементов дизайна, которые тоже влияют, как нам кажется, на восприятие.

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

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

Что в связи с этими сложностями мы решили сделать. Мы решили, что запустим два варианта тестирования. Первый вариант — это попарное, side-by-side, которое мы видели с вами. А второй вариант — это монадические тесты.

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

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

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

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

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

Вот, в принципе, у нас получилось таких четыре запущенных теста. Это классический side-by-side как контрольный. Это в низком разрешении, на другом языке side-by-side-тесты. И отдельно монадические тесты, которые мы проводили на «Толоке» и отдельно на втором сервисе — Fastuna.

Для чего вот это? Как я говорил выше, мы считаем, что на «Толоке» сидит более профессиональная аудитория, и ее результаты могут отличаться от результатов, если мы берем в среднем наших пользователей. На Fastuna в этом плане аудитория более чистая. Поэтому мы решили вот такие два теста запустить и сравнить их между собой, будут ли они отличаться, чтобы понять, действительно там более профессиональная или нет, или результаты будут одинаковыми.

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

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

Здесь по графикам еще переделаю, чтобы это было читабельно. Но на мобильной версии мы получили, что на Fastuna и с точки зрения likeability, и с точки зрения функциональности, и с точки зрения дизайна мы получили абсолютно одинаковый результат. То есть статистически различий нет никаких. На «Толоке» мы практически везде получили, что наше текущее мобильное приложение лучше по дизайну, чем у конкурентов. С web картинка ровно наоборот: нет статистически различий в «Толоке», а на Fastuna мы получили, что практически везде Drom лучше всех — и нашего нового, и Auto.ru, и нашего старого.

На Fastuna не было статистически значимых отличий в мобилках, а на «Толоке» — в web. Это плохо, потому что это значит, что люди воспринимают всё в среднем одинаково. Несмотря даже на такие большие выборки, как я тебе говорил, по 400 человек, нет разницы. А это значит, что то, что мы хоть пощупать и найти, — люди, пользователи для себя не видят большой разницы. То есть мы нашу задачу здесь, получается, решить не можем.

Результаты «Толоки» и Fastuna в отдельных местах сильно расходятся, что тоже плохо. Значит, все-таки аудитории разные. Но проводить постоянно тесты на Fastuna мы не можем — там сильно дороже. Стоимость от «Толоки» отличается буквально, наверное, в 100 раз на самом деле. Поэтому мы планировали тестирование в основном с помощью аудитории «Толоки» проводить, а не Fastuna, и в тесте увидели, что результаты отличаются. Получается, для нас использовать сервис «Толока» невозможно, а Fastuna — слишком дорого.

На эксперимент на самом деле потратили довольно много времени и средств. Как я сказал, на Fastuna раз в 100 дороже, чем на «Толоке». На «Толоке» 10 долларов, а на Fastuna… Не в 100, а в 50. На Fastuna 1 300 наши тесты стоили.

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

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

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

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

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

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

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