Компанию «Ингосстрах» знает каждый, рассказывать о ней смысла нет. А вот о проекте, который мы для неё делали, поведать стоит.

О проекте

Представьте, есть огромное количество разного рода компаний, сотрудники которых застрахованы в «Ингосстрахе». Это называется корпоративное страхование. При этом в некоторых из этих компаний количество сотрудников исчисляется тысячами (например, в «Кока-коле»). Все они поделены на группы и застрахованы по разным тарифным планам с разными условиями. Например, рядовые сотрудники имеют доступ только к базовым планам страхования, в то время как топ-менеджмент корпораций имеет возможность получать медицинские услуги в лучших клиниках по всему миру.

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

Так наш менеджер зарисовал карту процессов в момент первого скайп-колла с заказчиком.

Всем этим занимаются HR-партнёры — выделенные роли в компаниях-клиентах, которые являются связующим звеном между сотрудниками и «Ингосстрахом». Система, в которой они работают, называется личным кабинетом HR-партнёра. Здесь создаются договоры, формируются запросы, выгружаются отчеты, хранятся списки лечебно-профилактических учреждений и базы кураторов. Суммарное количество сущностей, с которыми работают партнеры, переваливает за пятнадцать.

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

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

Задача

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

Исследование и аналитика

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

Выдвигаемся на воркшоп в офис клиента. В составе нашей делегации арт-директор и UX-инженер. Со стороны «Ингосстраха» — куратор проекта Екатерина и еще пара заинтересованных лиц.

Кстати, о диктофоне. Первое, что мы сделали — это в процессе прослушивания записи разделили её на множество коротких (до 10 минут) файлов и разложили их по папкам, в соответствии с функционалом, о котором на них идёт речь. Это очень помогло нам в дальнейшем при проектировании, так как не приходилось переслушивать всю запись целиком и искать нужный фрагмент.

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

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

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

Ситуация напоминала большой запутанный клубок рыболовной лески.

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

Архитектура, формы и таблицы

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

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

Так, у нас появились умные формы — когда 15-20 полей первоначально скрыты в пять, а остальные появляются только в случае, если сценарий заполнения предполагает наличие этого поля. Учитывая, что практически весь личный кабинет состоит из таблиц и форм, это существенно облегчило работу пользователям.

Кстати, о таблицах. Зачастую количество столбцов в них доходило до 25-30 штук. Очевидно, работа с такими монстрами в рамках обычного десктопного разрешения похожа на пытки. Нужно постоянно пользоваться длинным горизонтальным скроллом, что дико неудобно.

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

Проанализировав все данные, мы поняли, что на самом деле большинство пользователей работают в постоянном режиме примерно с 7–9 колонками, иногда им требуется еще 4–6, а остальными пользуются крайне редко. Но у всех ролей это были разные наборы полей. В качестве одного из решений мы предоставили пользователю возможность самостоятельно настраивать колонки в таблицах, сохранять настройки для каждой отдельной таблицы и предусмотрели функцию быстрого показа/скрытия столбцов. Другим решением стал быстрый поиск внутри каждого столбца Таким образом, теперь в одном столбце можно найти нужную фамилию или название компании, а в другом отсортировать по ЛПУ или конкретному плану страхования. Этот функционал значительно расширил возможности сортировки и фильтрации.

Панель управления таблицей и встроенный в каждую колонку поиск

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

Проектирование

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

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

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

Так, шаг за шагом, собралась махина из 73 прототипов, каждый из которых представлял отдельную страницу или экран. Внутри каждого могло быть до 6–7 всплывающих окон или модалок. В итоге мы согласовали около сотни различных экранов.

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

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

Суммарно, бэклог доработок насчитывал около 40 часов — менее 5% от общих трудозатрат по проекту.

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

Пару слов об онбординге

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

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

Дизайн

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

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

Над дизайном параллельно работало три человека под контролем арт-директора и руководителя проектов. Спустя два с половиной месяца мы утвердили последний дизайн-макет. Проект можно было считать завершённым. Все выдохнули.

В завершении

Это была большая работа. Очень большая работа. Настолько большая, что этот кейс появился спустя почти год после её завершения. За это время проект выиграл два золота в номинациях «Лучший юзабилити» и «Совершенное исполнение», бронзу в номинации «Дизайн интранета» и принёс «Эвересту» почётное звание компании «Открытие года» по версии Tagline Awards 2018 (читайте, как это было).

Видео-кейс
Контакты
Пишите
Звоните
Москва
Ленинская слобода, 26
Тамбов
Кавалерийская, 7А