В 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 в нынешнем виде. Несмотря на вышеперечисленные трудности, можно выделить два основных вектора. В бекенде борьбу между красотой и утилитарностью выигрывает утилитарность. Этот выбор диктуется общими эксплуатационными требованиями к интерфейсам большинства энтерпрайз-ПО. В фронтенде упор на портальные технологии и работу с мобильными приложениями, тут мы имеем диктат дизайна и эргономичности. И тут, конечно, необходимо обернуть свой продукт в достойную его упаковку, руководствуясь не только соображениями практичности, но и обращаясь к трендам, о которых так много говорят зарубежные разработчики и дизайнеры интерфейсов: геймификации пользовательских задач, индивидуализации оформления или использованию технологии “тач-скрин”.
Кто наши новые пользователи
Мы более 10 лет занимаемся разработкой, внедрением и поддержкой информационных систем для бизнеса: биллинг, PRM-, CRM-, BPM-системы и многое другое. Всё это отнюдь не “коробочные” решения. Для внедрения системы необходимо изучить IT-инфраструктуру клиента и интегрировать с ней свой продукт. Иногда это подразумевает сборку мини-ЦОДа на территории клиента. Плюс обучение сотрудников. Естественно, такие системы не могут стоить дешево, и нашими клиентами всегда были в основном крупные или преуспевающие средние компании. Выпустить облачную PRM-систему мы решили в расчете на новый сегмент потенциальных клиентов: SMB — small-medium business.
Такие компании часто страдают от несовершенства готовых IT-решений и низкого качества их техподдержки. Нам хотелось предоставить им простой (по сравнению с системами, которые мы адаптируем под требования конкретного бизнеса), но надежный продукт, который при этом был бы им по карману. Так было принято решение о внедрении модели SaaS, когда само ПО размещается в нашем Дата-центре, провайдер SaaS услуг ведет обслуживание, мы как вендор занимаемся его развитием и обновлением, а клиентам предоставляем доступ через веб-интерфейс.
Первым делом — функциональность
Для тех, кто хоть раз имел дело с ПО, обеспечивающим сложные бизнес-процессы с предоставлением больших объемов информации, не секрет, что его интерфейс — не поле для дизайнерских экспериментов. Конечно, техника не стоит на месте, растет разрешение мониторов, даже на недорогих ноутбуках появляется функция “тач-скрин”, и у дизайнеров и разработчиков велик соблазн не отставать от трендов. Никому не хочется в глазах пользователей выглядеть как динозавр, вызывая интерфейсом своего продукта ностальгические воспоминания о 95-й “винде”. Тем не менее, любые, даже чисто декоративные изменения в ПО для бизнеса должны вноситься очень аккуратно. Успех продуктов в области автоматизации зависит от того, насколько они упрощают работу с большим объемом информации и ускоряют рутинные действия. Даже изменение цветовой схемы или оформления иконок может вызывать дезориентацию пользователя и будет стоит ему секунд рабочего времени. А в бизнесе, как известно, время — деньги.
Особенности энтерпрайз-приложений — плотная упаковка данных на каждом экране и таблицы как основная форма их представления. Творческой фантазии разгуляться негде. История знает примеры, когда стремление сделать дизайн свежее, а таблицы не такими громоздкими, приводило к провалу обновленной версии и многочисленным жалобам клиентов. Это то, что стоит держать в уме, вне зависимости от того, работает ваше ПО в облаке или на клиентских серверах.
Что можно сделать, чтобы облегчить восприятие данных такой плотности и работу с ними? Во-первых, внимательно изучить структуру данных и убрать избыточное. Например, объединить ячейки, содержимое которых пользователи считывают как относящееся к одному смысловому блоку. Во-вторых, ввести возможность сортировать и фильтровать данные таблиц и отображать их в соответствии с заданными параметрами. В PRMSaaS пользователь по сути может самостоятельно структурировать данные с помощью гибкой системы настроек отображаемых параметров. В-третьих, с умом использовать цвет и закономерности его восприятия. Сдержанная цветовая схема не вызывает сенсорной перегрузки даже у человека, работающего в системе полный рабочий день. На этом сдержанном фоне четко выделяется визуальная сигнализация о важных для пользователя событиях — ошибках, незаполненных полях, новых сообщениях. Не оригинально, зато функционально.
Технические возможности малого бизнеса
Нам также предстояло понять, в каких условиях будет функционировать система. И тут в игру вступили особенности национальной экономики, в народе кратко формулируемые “Москва — не Россия”. Разница в IT-обеспечении компаний в столице и бескрайней российской провинции была заметна и раньше. Экономическая ситуация последних лет этот разрыв только увеличила. В итоге, думая о технических возможностях нашего потенциального пользователя, мы должны были себе одновременно представлять людей с новенькими макбуками и менеджеров на удаленных торговых точках где-нибудь в Уфе, Самаре или Новосибирске, работающих вообще неизвестно на чем (Уфа, Самара, Новосибирск — не обижайтесь).
Поскольку мы не могли себе позволить, чтобы работа с сервисом замедлялась даже на самом плохом пользовательском оборудовании или как в одном из проектов железо на местах не позволяло запустить ни один современный браузер.
Что это значило для нас? Во-первых, мы должны минимизировать нагрузку на железо пользователя: все трудоемкие операции переносятся на бэкенд (“тонкий” интерфейс). Компьютер пользователя нельзя нагружать лишн��ми скриптами. Нельзя использовать эффекты, требующие значительного аппаратного ускорения.
Расчет должен быть на то, что часть пользователей будет работать с нашим сервисом на 15”-экранах или с разрешением экрана ниже FullHD. Значит, нам придется экономно использовать пространство и минимизировать визуальный шум.
Алгоритм тестирования
Здесь нам не пришлось ничего изобретать. У нас уже была схема тестирования интерфейсов информационных систем и изучения пользовательского опыта, проверенная при разработке и внедрении других продуктов Forward. Кроме того, часть этапов в этом случае мы могли пропустить, потому что речь шла об адаптации интерфейсов уже существующей PRM-системы.
Целиком алгоритм выглядит так:
- Изучение пользовательского опыта по выполнению таких же задач в старой информационной системе или без средств автоматизации.
- Подготовка типовых сценариев работы пользователей, выделение на основании этих сценариев ролей или групп пользователей.
Эти два шага в случае с PRMSaaS были уже выполнены, ведь у нас была информация о поведении пользователей и их возможных ролях, собранная за время работы с не-облачной PRM.
- Оценка нагрузки на систему с учетом длительности непрерывной работы пользователей в сервисе, масштабирование числа пользователей на будущее. На этом этапе проводится автоматизированное нагрузочное тестирование, например, для сравнения граничных допустимых значений времени ожидания и реального поведения сервиса.
- Разделение прав пользователей и удаление из интерфейса избыточной части функционала для данной конкретной роли.
- Итерационная подготовка прототипов интерфейса с минимально необходимым для каждой роли функционалом, разработка черновых вариантов рабочих интерфейсов.
- Тестовая эксплуатация на ограниченном количестве пользователей.
- Изучение результатов тестирования и проверке корректности работы пользователей.
- Исправления багов, оптимизация фронт- и бэкенда по результатам нагрузочного и пользовательского тестирования.
То же самое повторяется для каждого функционального блока или процесса, реализованного в сервисе.
Вместо заключения
Из таких предпосылок и процессов родился интерфейс PRMSaaS в нынешнем виде. Несмотря на вышеперечисленные трудности, можно выделить два основных вектора. В бекенде борьбу между красотой и утилитарностью выигрывает утилитарность. Этот выбор диктуется общими эксплуатационными требованиями к интерфейсам большинства энтерпрайз-ПО. В фронтенде упор на портальные технологии и работу с мобильными приложениями, тут мы имеем диктат дизайна и эргономичности. И тут, конечно, необходимо обернуть свой продукт в достойную его упаковку, руководствуясь не только соображениями практичности, но и обращаясь к трендам, о которых так много говорят зарубежные разработчики и дизайнеры интерфейсов: геймификации пользовательских задач, индивидуализации оформления или использованию технологии “тач-скрин”.
