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