Система электронного документооборота

К сожалению, нас попросили не раскрывать названия компаний, для которых мы выполнили это проект.

Так что писать этот кейс было нелегко. Ведь в этой истории три компании, не считая «Собаки»:

Два автора и редактор сошли с ума, пытаясь объяснить, кто на ком стоял (это и с названиями-то непросто!), а дизайнеры плакали, рисуя брендонейтральные варианты наших прототипов.

Потом мы отпоили контентную группу молоком, а дизайнеров валерьянкой и решили дать компаниям-заказчикам кодовые имена.

Итак, первая компания — назовем ее, действительно, «Полуэкт» — разрабатывает корпоративные информационные системы (ERP, системы документооборота, системы управления персоналом).

С этим разработчиком мы уже сотрудничали двумя годами раньше — спроектировали прототип интерфейса системы ERP-Полуэкт.

А теперь «Полуэкту» заказал новую систему электронного документооборота крупный российский пивоваренный концерн — назовем его ООО «Пивоваренная компания „Исаев“». А международную группу пивоваренных компаний, в которую входит «Исаев», соответственно, Stierlitz.Group.

«Полуэкт» разработал для «Исаева» новую систему электронного документооброта (СЭД). Запустил α-версию, и тут же выяснилось, что пользователи осваивают ее с трудом. Еще не все функции системы доступны — а уже запросто можно запутаться в формах, кнопках, закладках и списках.

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

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

Выяснили, что больше всего пользователям жмут:

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

«Исаев» не мог предоставить полный доступ к системе из соображений безопасности, «Полуэкт» — из-за технических проблем. У нас был ровно один день с TeamViewer, за который мы посмотрели и зафиксировали все, что успели, — а потом могли только запрашивать скриншоты.

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

Боковое меню в СЭД было организовано по принципу «Что у меня там за бумажки?» (входящие, исходящие, черновики…). Но пользователь не любоваться на исходящие документы пришел, у него есть конкретные цели: согласовать это, найти то, служебную записку дописать и послать Петрову.

Мы решили организовать меню по принципу «Что мне надо сделать?» — и расположили его пункты в соответствии с основными сценариями использования. Если у системы появятся новые возможности — можно дополнить меню новыми функциями, тоже группируя их посценарно.

Документы, к которым пользователь имеет прямое отношение. Они выводятся списком карточек и разложены по папкам: в старом интерфейсе — «Входящие», «Исходящие», «Избранное», «Черновики», в новом — «Согласовать», «Подписать», «Исполнить», «Отслеживать» и т. п.

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

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

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

В старом интерфейсе указывался только автор документа.

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

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

В старом интерфейсе пользователям было очень сложно найти нужный документ. Особенно если задача, как это часто бывает, не очень внятная, вроде «документ, который пришел где-то месяц назад; кажется, от Петрова». Фильтры поиска не очень-то помогали: непонятные названия, неочевидная логика (чем, например, «Период» отличается от «Дат активности»?).

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

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

Блок фильтров не занимает много места на экране, но его можно развернуть, если понадобится. Примененные фильтры отображаются на экране, а те, что не используются, — скрыты.

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

Иногда пользователь ищет коллегу по должности или по нечетким вводным вроде «начальник Петрова», «Иванов из отдела Марии Павловны».

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

По мере работы мы составляли карту предметной области, где описывали все сценарии и сущности, которые надо отрисовать. Проверяя требования, мы использовали этот документ как чек-лист. Вот так выглядела карта предметной области для раздела «Адресная книга».

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

Штатную информацию (списки подчиненных у сотрудников-руководителей, иерархия подразделения и т. п.) вынесли в отдельный раздел.

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

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

Использовали цвета из гайдлайна компании и оттеночные к ним. Дополнительный цвет — красный (для негативных состояний элементов: оповещений, незаполненных полей и т. п.). Он не предусмотрен гайдлайном, но гармонично сочетается с фирменными цветами по цветовому кругу.

Предложили несколько вариантов дизайна.

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

Кроме того, заказчику может понадобиться что-то добавить в интерфейс (а если тот, как было с СЭД, в α-версии — дополнения точно будут). Поэтому нужно дать заказчику детали конструктора, из которого собран интерфейс, чтобы при необходимости он мог доделать его сам.

Обе задачи решает UI-kit, каталог элементов интерфейса. Мы сверстали его на Bootstrap в двух вариантах (в цветах разработчика и в цветах производителя напитков).

Прототип интерфейса системы документооборота, два варианта дизайна и UI-kit в двух вариантах.

Это был очень интересный проект, и нам он по-настоящему нравится. Мы могли и использовать α-версию как прототип, и учитывать наработанный пользователями опыт.

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