Продумал поиск по разным типам данных, чтобы пользователи могли быстрее искать заказы

Контекст

Необходимо было улучшить интерфейс страницы с заказами для бэк-офиса онлайн-магазина.

Ключевая функция страницы — поиск. Искать можно по следующим полям: номер заказа, дата и время создания заказа, ID клиента, имя клиента, электронная почта клиента, телефон клиента, город клиента, адрес клиента, комментарий к адресу клиента, состав заказа, сумма заказа, способ оплаты, примененная скидка, промокод, ID даркстора, статус доставки, дата и время доставки, ID курьера, рейтинг курьера.

Часть этих полей не отображается в таблице, но поиск их учитывает.

Проблема

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

Задача

Продумать функцию настройки поиска по разным типам данных (то есть, чтобы было можно искать только по сумме или только по ID клиента и т.д.). Тем самым сократить время поиска нужного заказа.

Результат

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

Процесс

Понимание задачи

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

Что делаем?

Добавляем возможность искать заказы по разным типам данных

Какую проблему этим решаем?

Сокращаем время поиска нужного заказа

Пользовательская задача

Ускорить работу сотрудников, сделать её результативнее, сократить время на рутину

Бизнес-задача

Увеличить количество обрабатываемых заказов в единицу времени

Аудитория

  • логист курьерской службы

  • менеджер закупок

  • сотрудник финансового отдела

  • служба поддержки

  • маркетологи

  • аналитики

Критерии успеха

  1. Сокращение времени, затраченного на поиск нужного заказа

  2. Увеличение количества обрабатываемых заказов в единицу времени

Вот, как выглядела таблица изначально.

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

Анализ похожих решений

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

Так я пришёл к трём возможным вариантам решения:

  • Добавить выбор типа данных к полю поиска

  • Внедрить поиск непосредственно в столбцы таблицы

  • Сделать поисковое поле для каждого столбца вне таблицы

Выбранное решение

Проанализировав подобные интерфейсы и немного подумав, я решил, что наиболее оптимальным будет подход «аля Notion», когда при нажатии на заголовок столбца открывается поиск/фильтр по нему. Такое решение позволяет не перегрузить интерфейс кучей полей и кнопок, сохраняет внимание на данных, и ключевое — позволяет одновременно искать не по одному типу данных, а по нескольким. Например, дата заказа и ID клиента.

Исходное поле поиска оставил глобальным, по всем данным таблицы. Его можно комбинировать с полями в столбцах и дополнительно искать по тем данным, которые не отражены в таблице.

Прототип для тестирования

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

Что ещё было сделано

На самом деле я решил пойти дальше и сделать немного больше, чем требовала задача:

  • Пересобрал интерфейс на компонентах, изначально это был просто фрейм с фреймами и группами внутри.

  • Добавил состояния некоторым элементам, не связанным с задачей. Дотюнил кнопочки, ховеры там всякие и т.п.

  • Сумму заказа отобразил в таблице моноширинным шрифтом, чтобы улучшить считываемость разрядов.

  • Добавил цветовое кодирование для статусов, чтобы лучше отличать одни заказы от других.

  • Показал скроллбар и количество отображаемых в таблице заказов с возможностью его регулировать.

© 2025 Николай Ткаченко

© 2025 Николай Ткаченко

© 2025 Николай Ткаченко