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