#2. UX таблиц, с которыми работают. ч2 Добавление и поиск данных

Михаил Греков
Дизайн-кабак
10 min readFeb 20, 2019

--

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

Предисловие

Девиз серии статей про UX таблиц, с которыми работают, сформулирован так:

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

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

Писать на эту тему я себе позволил, потому что с 2007 года работаю с системами, в которых таблица — основной рабочий инструмент. Это были и web-системы, и инсталлируемые, и мобильные (начиная с windows mobile).

Существуют 5 крупных видов работы с таблицами:

  • просмотр данных — было в части 1,
  • внесение данных — в этой статье,
  • поиск данных — в этой статье,
  • управление данными — будет в части 3,
  • экспорт данных — будет в части 3.

Ещё в четвёртой части я расскажу о работе с таблицами на мобильных устройствах.

Чтобы ничего не пропустить — приходите в мой Телеграм-канал @proudobstvo.

Работа 2 — внесение данных

Работа в части внесения данных может быть двух типов:

  • Скоростная: колл-центр, МФЦ, Почта РФ, операционистки в банках и т.д.
  • Размеренная: CRM, Task-трекеры и любые другие системы, в которых скорость внесения данных не влияет на объём данных, которые будут внесены за день. Например, даже если таблица не оптимизирована для скоростного ввода, я успею внести в неё 10 записей, а больше мне и не требовалось никогда.

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

Если предполагается размеренная работа, то можно “сэкономить” и не делать скоростные функции — никто за них спасибо не скажет и вау-эффекта они не вызовут.

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

Оказалось, что если адаптировать таблицу для ввода данных на 100% с клавиатуры, то вносить данные можно гораздо быстрее, чем с использованием мышки. В итоге, мы сделали таблицу и форму ввода заказа, с которыми можно работать без мышки: табуляция и горячие клавиши были нашими основными помощниками.

Итак, как же можно помочь пользователю добавлять данные быстрее:

Горячие клавиши

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

В Яндекс.Почте можно написать, нажав w или c.

Сами горячие клавиши зависят от среды, в которой работает продукт — они не должны перебивать привычные горячие клавиши среды (windows, браузер).

Например, создание новой заметки в Evernote Desktop — это “ctrl+N”, но в Google Crome эти клавиши открывают новое окно. Поэтому для браузерного приложения Evernote комбинация”ctrl+N” уже не работает.

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

Создать копию

Если данные в таблице достаточно однородны, то скорость и удобство добавления новых записей можно повысить, используя опцию “Создать копию” или “Создать на основе”.

Создать копию — добавляется запись-копия в таблицу (возможно, при этом в ключевое поле добавляется текст “копия”)

Создать на основе — показывается форма добавления, которая предзаполнена данными из той записи, на основе которой создана.

Новые записи без перезагрузки

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

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

Многопоточность

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

О чём речь:

Добавляет оператор Ирина новую заявку, а в это время ей звонит другой клиент и его заявку тоже надо зафиксировать. Что делает обычно Ирина: берёт листочек и записывает на нём параметры второго заказа. Битва Автоматизация vs Бумага проиграна.

Но если для оператора Ирины сделать кнопку “Добавить ещё”, которая открывает вторую форму добавления, не закрывая при этом первую, то Ирина добавит новую заявку сразу в электронном виде без всякой бумажки. Например, “Добавить ещё” открывает новую вкладку браузера с формой добавления.

Одна за другой

Когда пользователю необходимо внести сразу несколько записей, то удобно делать это без возврата к таблице. То есть в классическом варианте работает так:

  1. Нажал “Добавить”,
  2. Открылась страница/форма добавления,
  3. Сохранил,
  4. Страница закрылась,
  5. Открылась таблица.
  6. Нажал снова “Добавить”.

Но когда есть кнопка “Сохранить и добавить” (или чек-бокс “Добавлять после закрытия”), то можно избежать постоянного возврата к таблице. После нажатия такой кнопки сразу открывается страница/форма добавления следующей записи.

Добавление под поиск

В некоторых системах бывает удобно добавлять новые записи, учитывая поисковый фильтр. Например, в системе управления задачами найти задачи по проекту “Сайт города Н”, для исполнителя “Иванов И.” и нажать “Добавить”. В форму добавления будет сразу вписан проект “Сайт города Н” и исполнитель “Иванов И.” — удобно.

Такой кейс работает, например, в Jira.

Импорт новых записей из файла

Заполняешь файл (например, Excel) определённого шаблона и грузишь его в систему. Файл разбирается, записи создаются.

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

Добавление записей из файла актуально для систем, автоматизирующих те области, которые ранее автоматизировали с помощью Excel. Например, удобно если в CRM можно из Excel загрузить список контрагентов.

При импорте важно визуализировать итоги импорта: загружено столько из стольки. Не загружены такие-то строки по таким-то причинам.

Работа 3Поиск данных

Какой бывает поиск

Начну с того, что можно выделить следующие виды поиска:

  • Поиск по ключевому слову.
  • Поиск по наиболее популярным параметрам.
  • Поиск по столбцу таблицы.
  • Расширенный поиск.
  • Сохранённые поисковые запросы.

Какие виды поиска использовать — зависит от проекта.

Я бы рекомендовал в бизнесовых системах использовать как некий умолчательный базис: поиск + расширенный поиск. Это привычный паттерн для активных пользователей почтовых веб-сервисов (Гугл, Яндекс).

Поиск → Расширенный поиск в gmail.

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

Поиск по ключевому слову или фразу

Это невероятно мощный и достаточно сложный инструмент.
Сложный он, потому что может потребоваться:

Учитывать морфологию, исправлять опечатки

Какое-то время назад пользователи не были избалованы морфологией и исправлением опечаток, но сейчас некоторые системы одинаково хорошо ищут и по слову “контрАгент” и по слову “контрОгент”. Во втором случае оплошность пользователя просто будет исправлена.

Искать везде, где пользователь ожидает

Пользователь ожидает, что поиск осуществляется и в связанных таблицах/справочниках. Например, есть контрагент “Ивушка”, у которого есть сотрудники “Петров” и “Васечкин”. Сотрудники — справочник сотрудников, Контрагент — справочник контрагентов. Заходя в Контрагенты и вводя в поиск “Петров” пользователь ожидает, что найдутся и компания “Петровский причал” и компания “Ивушка”, в которой работает Петров.

Предлагать итоги на лету

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

Пользователь вводит слово “Петр”, а ему ниже поля поиска уже показаны возможные варианты. Это классный инструмент, который экономит время на поиск.

Только делать такой инструмент необходимо разумно: например, подбирать варианты не сразу, а после 3-х символов и паузы при вводе.

Выделять искомый фрагмент

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

Ещё важно — поиск по ключевому слову/фразе должен срабатывать по нажатию Enter.

Поиск по наиболее популярным параметрам

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

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

Поиск по столбцу таблицы

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

Основной плюс — многие табличные движки его поддерживают “из коробки” и можно сэкономить на предоставлении функций поиска.

Минусы наблюдаются при поиске по числовым полям и датам: ищет по совпадению, а для дат и чисел важнее поиск по интервалу (от … до …).

Расширенный поиск

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

Но есть порой группы пользователей, которым нужен расширенные поиск: руководители и те, кто ищет информацию по запросу из вне (call-centre, секретари и так далее).

Расширенный поиск хорош в связке с сохранёнными поисковыми запросами.

Сохранённые поисковые запросы

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

Количество в сохранённых запросах

Обогащение сохранённых поисковых запросов информацией о количестве записей, которые в настоящее время удовлетворяют запросу может быть очень полезным. Например, руководитель делает себе сохранённые запросы по таблице Задачи: Со срывом, Важное, От шефа. Ему будет удобнее видеть их в режиме: Со срывом (0), Важное (4), От шефа(5).

Как с почтовиком, который показывает количество непрочитанных в папках.

Количество найденных

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

Показывать количество после поиска — это обязательно.

Показывать количество ДО поиска — порой удобно.

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

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

Вечный поиск

Очень многие пользователи начинают свой день (или придя с обеда) с вопроса: “Так, а на чём же я тут закончил!?”.

Для большинства рабочих систем актуально, чтобы система не сбрасывала поисковые настройки. Иными словами — выполненный поиск является вечным. Конечно, итоги поиска не вечные, а только параметры поиска.

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

Если вы научились не сбрасывать поиск, то важно, чтобы пользователь понимал, что включены критерии поиска. Можно вывести надпись, добавить значки в зону поиска и так далее (это уже детали).

Например, в Excel фильтр является “вечным” — фильтруешь записи и они остаются с фильтром даже после закрытия/открытия файла. Но видно крайне плохо, что записи отфильтрованы и часто пользователи начинают суетиться и искать пропавшие записи. Я так тоже искал в Excel частенько потерянные записи, не заметив, что поиск включен.

Легко сбросить

Должно быть легко сбросить поисковый фильтр. Не нужен фильтр — отключай его одним нажатием, а не очищай каждый параметр.

Поиск по свойствам из списка

Частая боль поиска — поиск по свойству из списка. Например, у записи есть свойство: Цвет, который выбирается из списка: Красный, Белый, Синий, Жёлтый, Фиолетовый.

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

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

На этом вторая часть заканчивается. Спасибо за внимание 👏!

Чтобы ничего не пропустить, заходите на 🔥 в Telegram-канал @proudobstvo — про UX, продуктовую разработку и саморазвитие.

--

--

Михаил Греков
Дизайн-кабак

Head of products BI AnalyticWorkspace.ru, основатель itkadr.ru, автор телеграм-каналов Про удобство t.me/proudobstvo и Продуктовошная t.me/suda_smotri