Как работать с референсами в продукте
Когда говорим о референсах, то первое, что приходит на ум: behance, dribbble, pinterest. Эти площадки на слуху, но содержат больше визуальных решений. В продукте у дизайнера достаточно ограничений как по визуалу (готовая палитра, стилистика, компоненты), так и с технической стороны (архитектура бэка, используемая библиотека).
Допустим, вам поступает задача сделать страницу с отображением заявок и их статусов. Если пойти по прямому пути и зайти на известные ресурсы, то по запросу «request» выдача вряд ли подойдет для решения задачи.
Рефы под задачу
Тогда декомпозируем задачу, разбиваем страницу на элементы: карточка заявки, фильтры, header, панель заявки. Элементы определяем исходя из требований к системе. Для примера возьмем фильтр. Задача стала более очерченной: сделать фильтр для списка заявок. Только что установили дополнительное ограничение. А если теперь его расширим? Будем искать референсы по фильтрам.
При таком подходе нам уже не столь важна сфера, больше важен опыт взаимодействия, принципы формирования, расположения, количество элементов фильтрации и разнообразные фичи. Фильтры можно искать и на известных ресурсах, но лучше искать в уже существующих системах и проектах, попробовать с ними взаимодействовать, записать скринкасты, зафиксировать скринами, выделить интересные моменты.
Смотрим на другие системы
Если посмотреть на сервисы Ozon, М.видео, Яндекс.маркет, то увидим фильтры в левой панели. Если посмотреть на Lamoda, STREET BEAT, то фильтры размещены сверху основной выдачи. Можем выделить критерий: расположение (это важный момент, что в процессе просмотра референсов можем определять критерии и классифицировать). Возникают вопросы: почему одни выбирают расположение сверху, а другие сбоку, как принять решение для задачи?
В очередной раз широкую задачу сузили до точки «расположение фильтров» и расширили ее до «референсы расположения фильтров и исследования». Дальше можно пойти разными путями, но попробуем найти ответы в сети, так как известные агентства публикуют небольшие куски из платных исследований. Про расположение фильтров выделила бы эти статьи:
- Pancil&Paper. UX Pattern Analysis: Enterprise Filtering
- Baymard Institute. Filter UI Design: A Horizontal Toolbar Can Outperform the Traditional Sidebar
Выводы из исследований
По изученным материалам других агентств по фильтрам можно выделить следующее:
- боковую панель фильтров хорошо использовать, когда параметров фильтрации много, в ней открыто показаны значения параметров фильтрации;
- верхние фильтры интуитивно понятнее пользователю, но есть проблемы с их адаптивностью, применяются, когда параметров фильтрации немного;
- интересное наблюдение, что пользователи думают, что сортировка — это параметр фильтрации, из-за чего меньше проблем возникает, когда она расположена рядом со строкой фильтрации.
Определение общей концепции
На скрине виден контекст применения фильтров. Изначально была гипотеза, что фильтры нужно размещать сбоку, возможно в скрытой панели для удобства адаптации под небольшие разрешения. В системе много табличных данных, пользователям сложно сформулировать точный запрос для фильтрации сразу, это не «купить белые кроссовки 43 размера известного бренда».
Нужно фильтровать данные постепенно. В этом случае лучше применять фильтры, в которых сразу видим все параметры фильтрации, а значения могут быть скрыты. В итоге решение приняли в пользу горизонтального фильтра, чтобы отдать больше места под таблицу, были всегда видны основные параметры фильтрации.
Поля фильтрации
Теперь можно вернуться ко всем собранным референсам и оценить их по параметру «визуал». Сперва нужно выделить критерии, по которым будем их оценивать: в системе под фильтры немного места, они должны спокойно читаться, не создавать лишний шум. Под них лучше всего подходил вариант фильтров Notion и фильтров, которые были представлены в статье Pencil&Paper.
Определяем параметры фильтрации, но для каждого параметра тип поля будет свой: select, multiselect, slider, period. И тут снова прибегаем к нашим референсам. Когда под каждый тип ищем практики, анализируем их по взаимодействию и функционалу, отбираем те варианты, которые лучше подходят под задачу.
При использовании точечных референсов нужно уточнять ограничения в системе. Например, в ходе обсуждения с разработчиками функционала и способов реализации мы пришли к выводу, что нам будет удобно представление multiselect подобно Notion, так как сможем использовать существующие компоненты, что снизит нагрузку на разработку, тестирование.
Итоги
Подведем итоги по поиску референсов для задачи «фильтры для страницы заявок»: подбирали референсы 8 раз, применили метод double diamond 10 раз. Наша небольшая задача про фильтры превратилась в целое исследование с многочисленными поисками референсов только для того, чтобы создать для платформы то решение, которое бы отвечало ее техническим требованиям и решало задачи пользователей.
Подборка референсов для продукта — совсем другая история, отличающаяся от подборки для презентации, постера, промо-сайта и т.д. Она включает в себя не только визуальный посыл, но и анализ на состав данных, наличие функций, сценариев взаимодействия и реакции элемента на действия пользователя.
Дизайнерам необходимо смотреть на это в комплексе, проводить постоянные эксперименты и фиксировать их результаты, тогда при решении рабочих задач у вас будет бэкграунд опыта взаимодействия, будет первичное понимание возможностей реализации, но подбирать референсы и предлагать множество разных решений под задачу все равно придется, так как решением пользуетесь не конкретно вы, а пользователи определенного продукта или сервиса, у которых свой бэкграунд.
P.S. Пишу для канала Явно.дизайн заметки по продуктовому дизайну, процессам в командных проектах, обсуждаем проблемы дизайна. Подписывайтесь и участвуйте в наших активностях t.me/yavnodesign
