UXPUB 🇺🇦 Дизайн-спільнота

Cover image for Улучшение юзабилити выбора нескольких элементов из длинного списка
Редакція
Редакція

Опубліковано • Оновлено

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

#ux

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

Существующие решения

Когда вы будете искать варианты выбора нескольких элементов для интерфейса, вы найдете следующие решения: предоставление пользователям выпадающего меню или отображение элементов в поле ввода в виде кнопок. Как в этом примере. Скролл и поиск в длинном списке Скролл и поиск в длинном списке Или вы можете предоставить список с флажками, скрытый в выпадающем списке. Или два списка, и вы перемещаете выбранные элементы из левого списка в правый. Как здесь. Гибридный двойной список с фильтром от doejo Гибридный двойной список с фильтром от doejo В нашей системе уже был компонент Select2, который был похож на первый пример. Наши разработчики использовали его в нескольких областях, в том числе в процессе создания списка, который состоит из нескольких этапов. На первом этапе мы просим провайдеров выбрать 4-6 соответствующих тегов из очень длинного списка.

Проблема с поиском в списке с несколькими выделяемыми элементами

Список, который мы показываем нашим провайдерам, очень длинный. Он содержит около 300 позиций, и с большинством из них они не знакомы. Из записей экрана пользователей я узнала, что 1) пользователи прокручивали список всего несколько раз, а затем отказались от прокрутки всего списка 2) начали искать нужный элемент. Multi-select pill box является хорошим решением, когда пользователи знакомы с содержимым списка, и знают, что ищут. Они могут легко найти элемент, выполнив поиск или просто прокрутив соответствующую часть списка. В случае, если содержание списка им не знакомо, возникает несколько проблем. Прокрутка длинного списка и чтение каждого элемента чрезвычайно утомительна. Никто этого не делает. Особенно, когда список не отсортирован в алфавитном порядке. Тогда в 50% случаев поиск не дает каких-либо результатов. Либо потому, что пользователи используют фразу или порядок слов, отличный от того, что в списке, либо контент просто отсутствует. После нескольких проб и ошибок они сдаются и работают дальше без выбора наиболее релевантных тегов. Я слышала от нашей команды по контролю качества контента, что общее качество выбранных тегов было очень низким, очень общим и не достаточным. Требовалось много дополнительных исследований и временных затрат, чтобы помочь провайдерам и улучшить качество контента и рейтинг их листинга.

Первая идея по улучшению

Я серьезно рассматривала вариант гибридного двойного списка с фильтром, поскольку варианты отображаются (проще читать) слева, а выбор в списке справа. Но насколько это удобно для работы на смартфоне? В первую очередь мы проектируем с учетом мобильного опыта, даже для наших провайдеров, и это решение не подходит. Что еще? Давайте отобразим все варианты в виде облака тегов как, например, делает Foursquare с «предпочтениями». Выберите свои предпочтения на Foursquare Выберите свои предпочтения на Foursquare С этим улучшением мы надеялись, что будет легче найти соответствующие теги и выбрать их. Мы знали, что список тегов слишком длинный и неструктурированный, но это был первый маленький шаг вперед. Состояние до – просмотрите на размер скроллбара Состояние после – показаны все элементы Это было исключительно изменением интерфейса, никаких данных или сортировки в бэкэнде не было затронуто. Как вы можете видеть на примере, «Категории» не упорядочены по алфавиту, что меня немного беспокоило. Будет ли это достаточно хорошо? Прежде чем показать это решение нашим клиентам, я дала обе версии коллегам, с заданием выбрать 6 элементов (которые я взяла из реальной жизни) и засекла время, которое потребовалось им, чтобы выбрать требуемые элементы. Я специально дала им список тегов, как поставщик пытался их искать, а не как они расположены в списке. В старой версии дизайна 3 коллеги из 5 бросили выполнять задачу, 2 из них закончили ее более, чем за минуту. В новой версии все они выполнили задачу в течение минуты, используя для поиска сочетание клавиш Ctrl + F. Это был хороший результат.

Что мы узнали из этого теста

Я открыла половине наших провайдеров функцию облака тегов примерно на месяц (из-за низкого трафика), но, к сожалению, не было никаких реальных улучшений в 1) выборе более релевантных тегов ни в 2) скорости нахождения этих тегов. Я должна была понять, что просто предоставить пользователю варианты было недостаточно, особенно когда они даже не отсортированы. Для этого требуется гораздо больше фокуса и умственного напряжения, так как взгляд должен прыгать туда-сюда, вверх и вниз среди тегов, а не просто следовать паттерну.

Итерация: следующий шаг немного больше

Поскольку моя вера в то, что стоит предоставить пользователям варианты, не изменилась, мне пришлось наводить порядок и добавить паттерн. Это потребовало некоторых изменений в инфраструктуре. Стоило ли этим заниматься? Чтобы сделать список немного меньше, я повторно использовала созданный ранее, но неиспользуемый дизайн информационной архитектуры, который сформировал группы тегов, основываясь на сходстве и релевантности. Это сэкономило нам несколько дней работы, и я сразу же перешла к проведению итерации со своим разработчиком. Мы создали группы разумного размера с очень жирным заголовком (так что пользователи могут быстро сканировать их, а затем просматривать фактический список, если они сочтут его релевантным) и очень хорошо организованные списки в столбцах одинакового размера, которые быстро изменяли ширину в процентах, но сохраняли направление чтения сверху-вниз. Сначала я создала столбцы с display: flex; который упорядочивал элементы списка слева-направо, а не сверху-вниз. Магическим решением было column-count: 2; Это было победой само по себе! (Кликните JSFiddle для иллюстрации). Эти два списка были даже длиннее, чем с тегами, поэтому мы решили выделить эти поля на свою собственную страницу, вместо того чтобы перетащить их в форму с 4-5 другими элементами. Это дало нам возможность более внимательно следить за новой функцией и ее использованием.

Анализируя результат

Открыв половине наших поставщиков сгруппированный и открытый список тегов вместо multi-select pill box, я просмотрела записи экрана, чтобы увидеть, насколько хорошо это решение было принято пользователями. Мое решение оказалось правильным. Люди прокручивали весь список, но только 1,93% из них застряли на этой странице. Я хотела получить некоторые данные о количестве выбранных тэгов (я хотела видеть четкое улучшение) и количестве времени, которое потребовалось для завершения шагов (я хотела видеть уменьшение времени). К сожалению, используемый нами экспериментальный инструмент разработан для измерения изменений в воронке конверсии клиентов и вовсе не оптимизирован для измерения изменений юзабилити формы в области администрирования.

Поэтому мне пришлось собирать и анализировать данные вручную.

Сначала я определила списки, созданные в контрольной группе, и группе обработки. Для контрольной группы (V0) я выяснила секунды, затраченные на каждый список для перехода от этапа 1 к этапу 2 (этап 1 содержал multi-select pill boxes) и количество выбранных тегов. Группа обработки (V1) на 2 этапе имела выбор тегов, поэтому для них мне пришлось выяснить, сколько секунд потребовалось пользователям для перехода от этапа 1 к этапу 3, а также количество выбранных тегов. Я добавила их в Google Sheet, чтобы начать анализ, и быстро вывела СРЕДНЕЕ число. И результат был неожиданным: [caption id="attachment_43088" align="aligncenter" width="1264"] Образец набора данных, с которым я работал[/caption] В среднем 10000 секунд??? Почти на 3 часа дольше в группе обработки? Так не должно быть. Я не бизнес-аналитик, но я припоминаю что-то из колледжа о статистике и удалении резко выделяющихся значений из наборов данных. Поэтому вы не видите влияния (в данном случае) поставщиков, которые оставили процесс на целый день, а затем возвратились к нему. Итак, каков наилучший способ убрать выбивающиеся значения, с которым Google Sheets могут легко справиться? После некоторых исследований я решила использовать функцию TRIMMEAN, которая вычисляет среднее значение набора данных, исключая некоторую долю данных с верхнего и нижнего концов набора. В расчете я исключила верхние и нижние 20%, чтобы получить более реальную картину использования списков.

И результат был удивительным!

Завершение 2 этапов в экспериментальной группе было на 33% быстрее, чем один этап в контрольной группе, и в новой версии списка было выбрано еще четыре тега. Какое замечательное улучшение!

В заключение

Дизайн контекстуален. Так, выбрать свою страну из списка в 195 стран может быть простой задачей, даже, если какое-то время вам придется листать список. Когда дело доходит до незнакомых предметов, лучше визуально открывать предметы, а не скрывать их. Еще лучше организовывать их логически: создать группы с выразительными заголовками и позволить пользователям увеличивать масштаб до интересующих их групп. При меньшей когнитивной нагрузке завершение задачи занимает меньше времени и оставляет пользователю больше энергии на прохождение всего процесса. Спасибо Mário Silva.


Перевод статьи Zina Szőgyényi

Найстарші коментарі (0)