Проблемы графического интерфейса пользователя в ECM-системах и пути их решения

В предыдущей статье (Пользователи и их взаимодействие с системой и друг с другом) уже упоминалось о существовании проблем с графическим интерфейсом пользователя в ECM-системах (далее — интерфейс). Конечно, ECM — это не единственный класс систем, имеющих проблемы с GUI, с подобными явлениями сталкиваются и системы классов ERP, CRM, системы бухгалтерского учета, налоговой отчётности и многие другие.

Пожалуй, громче всех о проблеме с интерфейсами в крупных системах заявили ещё 3 года назад специалисты компании Usability Lab в своём вебинаре «Почему пользователи ненавидят СЭД». Тогда информация, поданная в свойственной Usability Lab игривой манере, встретила бурный отклик в профессиональной среде. Однако, проходит время, конфликты сглаживаются, и даже самые острые проблемы находят свои решения.

Сложность архитектуры

Проблема

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

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

Неудивительно, что при разработке сложность архитектуры и функционального состава ECM-системы начинает «просвечивать», загромождая экраны пользователей разнообразными элементами управления. Так, например, при создании нового экземпляра сущности может запрашиваться множество полей ввода данных, существующих одновременно на одной странице или на разных её закладках и странным образом сгруппированных друг с другом. Попытки увязать сразу несколько разных сущностей на одной, как правило, главной странице приводят к тому, что уже при входе новичок испытывает по отношению к системе, в которой ему нужно работать, чувство, близкое к тому, что ощущал посетитель готического храма: страх и неуверенность в своих силах.

Решение

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

●   Не показывать пользователям системную информацию: скрывать системные коды со страниц и окон, при возникновении ошибок давать пользователям инструкцию по её устранению, словом, прятать всё то, что связано с внутренним устройством системы, так, чтобы эта информация была доступна только специалистам.

●   При проектировании интерфейсов думать о контексте возникновения того или иного его элемента в системе. Например, представить себе, о чём думает пользователь во время создания новой записи: о типе ли её жизненного цикла и идентификационном номере или всё же о том, частью какого бизнес-процесса является эта запись, к каким изменениям на предприятии она приводит, кому нужно знать о её появлении и почему?

Словом, при разработке ECM-системы очень важно понимать, что для пользователя система — это инструмент, как, например, станок, и пользователю важно не столько то, как устроен этот станок, нежели то, сможет ли он с помощью этого оборудования решить поставленную задачу.

Стремление к унификации экземпляров систем

Проблема

ECM-системы — это, в первую очередь, программный продукт, а одной из основных черт программных продуктов, в отличие  от продуктов материального свойства, является лёгкость воспроизведения копий (фактически производитель вкладывает средства только в создание одного экземпляра, а копирование не стоит ничего). Отсюда становится понятным стремление вендоров ECM-систем создавать максимально унифицированные продукты. Однако, чем сложнее решение, тем, как правило, меньше у него шансов одинаково хорошо подходить всем потребителям, поскольку, в частности, в случае ECM-систем, бизнес-процессы в одной организации могут проходить диаметрально противоположно ровно тем же самым бизнес-процессам на другом предприятии. Вследствие попыток создать универсальное решение и как результат необходимости обработки всего разнообразия возможных ситуаций, могут появиться усложнения как в архитектуре системы, так и в интерфейсе её пользователей. 

Решение

На мой взгляд, к решению этой проблемы вендору можно подойти с двух сторон:

●   не создавать максимально унифицированные продукты,

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

В первом случае, вендору нужно максимально чётко определиться с тем, организации с какими именно бизнес-процессами попадают в целевую аудиторию системы (например, только государственные организации с сильным вертикальными взаимодействиями и другими известными характеристиками бизнес-процессов). Соответственно, разрабатывать систему нужно будет, постоянно помня о том, для кого она делается, какие ситуации могут произойти (а значит, какие ситуации пользователи должны уметь обрабатывать с помощью графического интерфейса), а какие события настолько маловероятно в бизнес-процессах, что их можно отбросить. Главные риски такого подхода состоят в следующем:

●   в случае изменения бизнес-процессов, система в один момент перестанет соответствовать им,

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

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

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

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

Завышенные требования к пользователям

Проблема

Интерфейсные проблемы ECM-систем могут появляться также и по причине завышения требований к их конечным пользователям. Следствием таких завышенных ожиданий может являться, например, отсутствие валидации значений в полях непосредственно при их вводе (т. е. от пользователя ожидается абсолютно верный ввод всех значений в нужном формате), а также, например, неоправданно сложное именование полей или отсутствие возможности отмены или отката транзакции при вводе ошибочных данных.

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

Решение

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

Подводя итоги

Конечно, приведённый здесь список проблем с интерфейсами в ECM-системах, не полон, однако, я попыталась дать понять, что у всякой проблемы есть своя причина: будь то стремление снизить стоимость разработки или ошибочно высокие требования к пользователям. И при решении всякой проблемы очень важно помнить о настоящей причине её возникновения: чинить крышу, а не подставлять под место протечки ведро побольше.

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