Кейс из России: Проектирование интерфейса диспетчерского ПО для такси-сервиса01.02.2016 19:38

Так уж сложилось, хорошие интерфейсы с продуманными сценариями и красивым оформлением — прерогатива массовых сервисов. Например, информационных или развлекательных.

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

Мы столкнулись с такими проблемами, когда взялись за разработку диспетчерской системы такси для компании Blaq. Вот как выглядят системы большинства таксопарков:

У крупных игроков ситуация такая же. Вот, к примеру, чем приходится пользоваться диспетчерам «Яндекс.Такси»:

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

Приступаем к работе

Выслушав клиента, обозначили требования:

Обучение оператора — не более двух недель

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

Формирование заказа — не более 1 минуты

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

Полноэкранный режим и мониторы от 21'

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

Концепция

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

Разделение по ролям

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

Всплывающие панели

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

Карта

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

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

Что же получилось

Края экрана и бесконечные кнопки

Чтобы закрыть окно или вернуться на уровень назад, достаточно, не прицеливаясь, отвести мышку к краю экрана. По закону Фиттса, это увеличивает скорость реакции на такие кнопки в несколько раз. Если учесть, что человек нажимает на нее 200–300 раз в день, 5 дней в неделю — экономия существенная.

То же самое с кнопкой набора номера и приема звонка. Их области клика увеличены до края экрана.

Пропорции карты

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

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

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

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

Задержка создана, чтобы не отвлекать этим экраном при простом переключении языков или копировании текста.

Цветовое кодирование

У каждого раздела свой цвет. Не читая заголовки, оператор может понять, в каком разделе он сейчас. Даже с помощью периферического зрения.

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

Защита от ошибок

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

Чтобы сократить количество ошибок, связанных с человеческим фактором, мы применили две стратегии:

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

Неслучайные комбинации. Например, чтобы отправить заказ на обработку водителям, оператор нажимает комбинацию клавиш Ctrl+Enter. Случайно нажать их практически невозможно.

Резюме

Задачу уложиться по времени оформления заказа в 1 минуту выполнили. В общем случае заказ оформляется в несколько раз быстрее.

В течение месяца после запуска диспетчерский центр клиента перешел на новое ПО и успешно на нем работает.

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