Обсудить проект

СМИ о нас 8 минут Источник: HABR.COM

Интерфейс для облачных сервисов в сегменте B2B: между красотой и утилитарностью

Как проектировался интерфейс облачного решения для работы с партнерами: чем требования B2B-пользователя отличаются от привычных потребительских сценариев.

В 2017 году, уже имея многолетний опыт в разработке информационных систем для бизнеса, мы, компания Forward Telecom, выпустили на рынок первое облачное решение для автоматизации взаимоотношений с партнерами — PRMSaaS. Система построена на базе существующих продуктов компании. Однако смена целевой аудитории и способа доступа к системе заставила нас заново думать, о чем будет болеть голова конечных пользователей при взаимодействии с ее интерфейсом. Рассказываем, какие требования мы сформулировали для энтерпрайз-ПО в облаке и как добились соответствия им.

Кто наши новые пользователи

Мы более 10 лет занимаемся разработкой, внедрением и поддержкой информационных систем для бизнеса: биллинг, PRM-, CRM-, BPM-системы и многое другое. Все это отнюдь не “коробочные” решения. Для внедрения системы необходимо изучить IT-инфраструктуру клиента и интегрировать с ней свой продукт. Иногда это подразумевает сборку мини-ЦОДа на территории клиента. Плюс обучение сотрудников. Естественно, такие системы не могут стоить дешево, и нашими клиентами всегда были в основном крупные или преуспевающие средние компании. Выпустить облачную PRM-систему мы решили в расчете на новый сегмент потенциальных клиентов: SMB — small-medium business.

Такие компании часто страдают от несовершенства готовых IT-решений и низкого качества их техподдержки. Нам хотелось предоставить им простой (по сравнению с системами, которые мы адаптируем под требования конкретного бизнеса), но надежный продукт, который при этом был бы им по карману. Так было принято решение о внедрении модели SaaS, когда само ПО размещается в нашем Дата-центре, провайдер SaaS услуг ведет обслуживание, мы как вендор занимаемся его развитием и обновлением, а клиентам предоставляем доступ через веб-интерфейс.

Первым делом — функциональность

Для тех, кто хоть раз имел дело с ПО, обеспечивающим сложные бизнес-процессы с предоставлением больших объемов информации, не секрет, что его интерфейс — не поле для дизайнерских экспериментов. Конечно, техника не стоит на месте, растет разрешение мониторов, даже на недорогих ноутбуках появляется функция “тач-скрин”, и у дизайнеров и разработчиков велик соблазн не отставать от трендов. Никому не хочется в глазах пользователей выглядеть как динозавр, вызывая интерфейсом своего продукта ностальгические воспоминания о 95-й “винде”. Тем не менее, любые, даже чисто декоративные изменения в ПО для бизнеса должны вноситься очень аккуратно. Успех продуктов в области автоматизации зависит от того, насколько они упрощают работу с большим объемом информации и ускоряют рутинные действия. Даже изменение цветовой схемы или оформления иконок может вызывать дезориентацию пользователя и будет стоит ему секунд рабочего времени. А в бизнесе, как известно, время — деньги.

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

Что можно сделать, чтобы облегчить восприятие данных такой плотности и работу с ними? Во-первых, внимательно изучить структуру данных и убрать избыточное. Например, объединить ячейки, содержимое которых пользователи считывают как относящееся к одному смысловому блоку. Во-вторых, ввести возможность сортировать и фильтровать данные таблиц и отображать их в соответствии с заданными параметрами. В PRMSaaS пользователь по сути может самостоятельно структурировать данные с помощью гибкой системы настроек отображаемых параметров. В-третьих, с умом использовать цвет и закономерности его восприятия. Сдержанная цветовая схема не вызывает сенсорной перегрузки даже у человека, работающего в системе полный рабочий день. На этом сдержанном фоне четко выделяется визуальная сигнализация о важных для пользователя событиях — ошибках, незаполненных полях, новых сообщениях. Не оригинально, зато функционально.

Технические возможности малого бизнеса

Нам также предстояло понять, в каких условиях будет функционировать система. И тут в игру вступили особенности национальной экономики, в народе кратко формулируемые “Москва — не Россия”. Разница в IT-обеспечении компаний в столице и бескрайней российской провинции была заметна и раньше. Экономическая ситуация последних лет этот разрыв только увеличила. В итоге, думая о технических возможностях нашего потенциального пользователя, мы должны были себе одновременно представлять людей с новенькими макбуками и менеджеров на удаленных торговых точках где-нибудь в Уфе, Самаре или Новосибирске, работающих вообще неизвестно на чем (Уфа, Самара, Новосибирск — не обижайтесь).

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

Что это значило для нас? Во-первых, мы должны минимизировать нагрузку на железо пользователя: все трудоемкие операции переносятся на бэкенд (“тонкий” интерфейс). Компьютер пользователя нельзя нагружать лишними скриптами. Нельзя использовать эффекты, требующие значительного аппаратного ускорения.

Расчет должен быть на то, что часть пользователей будет работать с нашим сервисом на 15”-экранах или с разрешением экрана ниже FullHD. Значит, нам придется экономно использовать пространство и минимизировать визуальный шум.

Алгоритм тестирования

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

Целиком алгоритм выглядит так:

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

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

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

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

Вместо заключения

Из таких предпосылок и процессов родился интерфейс PRMSaaS в нынешнем виде. Несмотря на вышеперечисленные трудности, можно выделить два основных вектора. В бекенде борьбу между красотой и утилитарностью выигрывает утилитарность. Этот выбор диктуется общими эксплуатационными требованиями к интерфейсам большинства энтерпрайз-ПО. В фронтенде упор на портальные технологии и работу с мобильными приложениями, тут мы имеем диктат дизайна и эргономичности. И тут, конечно, необходимо обернуть свой продукт в достойную его упаковку, руководствуясь не только соображениями практичности, но и обращаясь к трендам, о которых так много говорят зарубежные разработчики и дизайнеры интерфейсов: геймификации пользовательских задач, индивидуализации оформления или использованию технологии “тач-скрин”.

Обсудить проект

Первым с вами поговорит архитектор платформы: оценит сроки и состав решения под вашу задачу.

Если форма не отправляется, напишите на info@fw-t.ru или позвоните +7 (495) 960-62-78.

Настройки cookie

Необходимые cookie и статистика посещений работают всегда. Запись сессий и реклама включаются только с вашего согласия. Изменить выбор можно в любой момент по ссылке «Настройки cookie» внизу каждой страницы.

Необходимые

Всегда включены

Работа страниц, отправка заявок, защита формы от ботов и хранение выбора в этом окне. Отключить нельзя.

Сайт Forward, Яндекс SmartCaptcha · законный интересСостав cookie
CookieНазначениеСрок
fw_consentХранит выбор в этом окне и версию текста согласия12 месяцев

Статистика

Всегда включена

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

Яндекс Метрика · ООО «Яндекс» · законный интересСостав cookie
CookieНазначениеСрок
_ym_uidИдентификатор посетителя1 год
_ym_dДата первого визита1 год
_ym_isadПроверка блокировщика рекламы2 дня

Запись сессий

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

Яндекс Метрика · ООО «Яндекс» · по согласиюСостав cookie
CookieНазначениеСрок
_ym_visorcЗапись сессий Вебвизора30 минут

Реклама

Показ рекламы Forward в Яндекс Директ тем, кто уже был на сайте.

Яндекс Метрика, Яндекс Директ · ООО «Яндекс» · по согласиюСостав cookie
CookieНазначениеСрок
_ym_uidСегменты посетителей для показа рекламы1 год

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