UX-исследование ДБО: наш опыт, ошибки и открытия

Привет. Я Денис Элиановский, дизайн-директор в JTC и руководитель в Opium Pro. Мы работаем в очень узких сегментах рынка IT, связанных с финансами и документооборотом. Вы точно ещё не слышали об этих компаниях и сегодня мало что о них узнаете, ведь эта статья про UX-исследования.

Я занимаюсь дизайном последние 12 лет (из них 8 — именно дизайном сложных интерфейсов) и хочу рассказать, как мы у себя проводили юзабилити-тестирование приложения ДБО. А ещё о том, какие ошибки совершили и какие сделали из этого выводы. В процессе порекомендую пару книг. Все картинки кликабельны.

Что такое ДБО? Расшифровывается как Дистанционное Банковское Обслуживание. Ещё эти приложения называют онлайн-банками. Наверняка у всех вас уже есть такое в телефоне. Вот мы одни из тех, кто такие приложения дизайнит и разрабатывает.

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

Кому удобнее смотреть видео, тут запись выступления

Если вы попросите уложить описание UX-исследований в 23 слова, используя три запятые, одно тире и один дефис, то UX-исследование — это быстрое полезное действие, которое можно сделать ещё на ранних этапах разработки, и тем самым избежать ошибок, которые бы вышли в продакшен. А ведь выход банковского приложения в продакшен — это не только огромный стресс, но и огромная трата денег. UX-исследования позволяют вам проверить своё приложение на реальных пользователях задолго до того, как вы начнёте выгружать камазы с деньгами в карманы разработчиков и маркетологов.

Конечно, каждый дизайнер (каждый хороший дизайнер) тестирует своё приложение до релиза. Но обычно это делается «в домашних условиях». То есть тестируется на своих родных и близких, и очень редко это как-то систематизируется. В этой статье мне хочется донести, что в больших и сложных приложениях тестирование дизайна должно быть регламентировано и встроено в сам процесс дизайна.

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

Ещё исследования можно поделить на поведенческие и отношенческие. Когда мы проводим поведенческие тестирования, то следим за тем, что человек делает с нашим приложением. В отношенческих же важно, что человек говорит про наше приложение.

Процесс создания дизайна хорошо отражается графиком Дэмиена Ньюмана.

И поскольку выше я говорил, что дизайн и тестирование должны быть единым целым, то график отражает как процесс создания дизайна, так и его тестирование. Из этого графика можно сделать два вывода. 1) Дизайн и его тестирование — процесс нелинейный. 2) И еще это процесс итерационный. Это же очевидно при первом взгляде на график, не правда ли?

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

Называя процесс итерационным, я имею в виду то, что нельзя провести тестирование один раз и на этом остановиться. Тестирование нужно проводить регулярно. Именно тогда в нём есть смысл. Особенно учитывая то, что дизайн в процессе тоже сильно меняется.

1. Usability-тест начинается с выдвижения гипотезы.Что такое гипотеза? Это наше предположение, как конкретный человек будет пользоваться нашим приложением. То есть по какому сценарию он пойдёт. Выдвигая гипотезу, мы изучаем постановку от аналитиков, стараемся учесть наш личный опыт использования подобных приложений (если он есть), составляем User Story Map. На основании User Story Map создаётся кликабельный прототип приложения.
2. Составляем опросник. Важно, чтобы он был небольшим. Если тестировать людей подолгу, они просто начнут уставать. Идеально, если на одну сессию с одним человеком уйдёт 10–15 минут, максимум 20 (после этого для удержания внимания респондента возможно придётся прибегать к крайним мерам: брать в заложники его родных, одурманивать, апеллировать к чести и богу). Чтобы уложиться в нужное время, нам обычно хватает 5–7 вопросов-сценариев.Вопросы должны быть открытыми, это важно. То есть это те вопросы, на которые нельзя просто ответить «да» или «нет», мы должны спровоцировать человека поделиться с нами чем-то, открыть нам душу.
3. Собираем группу людей. Она также должна быть небольшой (5–7 человек). Ведь мы проводим качественные тесты, что предполагает использование небольших выборок. Набирать людей можно тоже по-разному. Интервью мы можем назначать заранее и некоторым людям даже немного приплачивать за это, а можем выходить «в поля» и искать подходящих людей в кафе и прочих общественных местах.

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

Давайте для закрепления ещё раз повторим, что нужно для подготовки.

На картинке ниже представлено несколько возможных вариантов визуализации данного процесса.

Самый левый скрин — это то, как можно подручными средствами сделать User Story Map. Для этого достаточно просто использовать бумажные стикеры. Соединяя их ниточками, мы показываем предположения относительно того, как пользователь будет ходить по приложению.

Второй вариант — User Story Map, нарисованная в Miro. По сути те же самые бумажки, только перенесены в электронный вид для удобства.

И третий скрин — кликабельный прототип в Figma.

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

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

Пример:

Этот график составил Якоб Нильсен еще в 1990-х годах. Уже тогда UX-исследования проводились.

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

Более эффективно делать маленькие выборки, но делать это часто.

Сначала хотел посоветовать книжку Якоба, но вообще она уже старая. Есть кое-что получше. Автор продолжает заниматься UX-исследованиями, и вот его сайт, там много статей: nngroup.com

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

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

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

И третье. По результатам тестов мы спрашиваем «Считаете ли Вы, что справились с задачей?». Причем на этот вопрос отвечает не только респондент, но и человек, который тестирует. Почему мы это делаем, я расскажу ниже.

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

Слева — список вопросов-историй, дальше идут столбики по каждому из опрашиваемых. Если стоит 1 — значит, что и испытуемый, и тестировщик посчитали задачу выполненной. Если 0,5 — значит, кто-то один считает, что задача не выполнена. Если 0 — оба согласны, что задача не выполнена. По этим данным можно понять, какие сценарии у нас сильные, какие слабые.

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

Мы тестировали наше мобильное приложение ДБО для физических лиц. В общей сложности на момент создания этого отчёта прошло две итерации тестов, в каждой из которых было протестировано по 6 человек. Всего 7 женщин, 5 мужчин в возрасте от 20 до 50 лет.

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

Благодаря просьбе нашего клиента, во второй сессии в выборку было включено больше людей в возрасте 40+. И именно в этой аудитории было выявлено больше всего ошибок. Они чаще всего где-то запинались, где-то останавливались, и им приходилось задавать больше всего вопросов.

Итоги теста с точки зрения «справились / не справились»:

Получилось, что тестируемые справились с 93% задач. При этом сами они считали, что справились только с 83%. Эта разница в 10% — те моменты, когда человек прошёл по нужному сценарию, наш тестировщик видит, что он с задачей справился, но респондент в результатах не уверен. И это тоже проблемы, над которыми нужно работать. Ведь мы понимаем, что в таких моментах приложение не даёт человеку нужного фидбека и это необходимо исправить. В среднем на одну сессию ушло 12 минут. Неплохой результат, с учётом того, что мы ориентировались на 10-15 минут.

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

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

В чём проблема? На экране две кнопки «оплатить», ни одну из них человек не заметил. Это было в 3 случаях из 6.

Ещё проблема. Раздел аналитики, который мы посчитали очень полезным, к сожалению, пользователи не сочли таковым. Он только сбивал людей с толку.

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

Второй экран — экран оплаты/переводов:

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

Третий экран — экран с продуктами банка:

Все люди, которых мы тестировали (ок, почти все), отметили, что этот экран полезный. Они знали, где его вызвать, они часто им пользовались. Здесь проблему мы создали сами себе, поместив вызов этого экрана в левое верхнее бургер-меню. На видео мы заметили, что, когда человек пытается нажать эту кнопку, многие перехватывают телефон, и это не всем удобно.

Сейчас телефоны стали большие, могут выпасть, и мы решили, что это для нас проблема, мы будем с этим работать. Кстати, угадайте, почему автор статьи ходит с разбитым телефоном?

На следующих картинках представлен существенно изменившийся дизайн второй итерации.

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

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

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

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

Ещё некоторые наблюдения и выводы, которые мы сделали в ходе тестирования.

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

Ещё есть люди с плохим зрением. Все об этом знают, и все об этом забывают (имею в виду дизайнеров). Как можно помочь людям с плохим зрением? Во-первых, можно увеличивать объекты в дизайне. Во-вторых, можно увеличивать контрастность в дизайне. И есть ещё один менее очевидный момент: можно отделять информацию, увеличивать расстояние между блоками, что тоже поможет людям лучше читать интерфейсы.

По самым скромным оценкам, которые можно найти в Википедии, левшей у нас 10%, а людей с плохим зрением — 13%. По нескромным — левшей где-то 15%, а людей с плохим зрением — 30%.

А ещё у некоторых девушек есть длинные ногти. Такие девушки тоже по-другому пользуются телефоном. Им тяжело нажимать что-то в правом нижнем углу, потому что вместо нажатия подушечкой пальца они упираются ногтем, в связи с чем им тоже приходится как-то перехватываться. Здесь официальная статистика отсутствует, но могу предположить, что время от времени до 50% взрослого населения планеты могут оказаться в такой ситуации.

Помимо освещённых выше Usability-тестов, есть много разных способов тестировать UX. Среди них:

• Eyetracking
• A/B-тесты
• Онлайн-опросы
• Глубинные интервью

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

Для тех, кто хочет в этом закопаться, советую книгу Даниеля Канимана «Thinking, Fast and Slow» (Думай медленно, решай быстро). Она ничего не расскажет вам про тесты, но даст хорошую почву для размышлений, показав, как на один и тот же вопрос одни и те же люди могут отвечать по-разному.

Помогла ли тебе эта статья приблизиться к тому, чтобы начать тестировать интерфейсы самому? Что оказалось полезным (если что-то всё-таки оказалось), а что неуместным?

Спасибо всем, кто помогал провести исследование и подготовить доклад

Проведение UX-исследования:

Команда JTC — бизнес-анализ, дизайн, UX-исследование

Денис Красильников — дизайн

Антон Казаков — UX-исследование

Екатерина Кашковская — UX-исследование

Дмитрий Добродеев — UX-исследование

Ирина Пономарёва — съёмки и монтаж

Подготовка доклада:

Команда JTC — формирование доклада

Максим Блохин — дизайн

Ирина Пономарёва — съёмки и монтаж

Надежда Молодцова — съёмки

Татьяна Китаева — редактура

#дизайн_интерфейсов #uxисследования #ux #банки #приложения #мобильные_приложения #ui #тестирование #design #designthinking