Когда компания «АльфаСтрахование» обратилась в «Собаку», у нее уже была внутренняя информационная система — для своих сотрудников и внештатных страховых агентов. Эта система позволяла продавать только полисы автомобильного страхования — КАСКО, ОСАГО и Зеленые карты. Остальные продукты — а у «Альфы» их с десяток (страховки для зарубежных поездок, страхование жизни и здоровья, страхование имущества, гражданской ответственности и т.д.) — оформлялись в Excel. Это очень умная программа, но ей далеко до централизованной информационной системы.

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

Усугубим. Продукты «АльфаСтрахования» продают самые разные люди: сотрудники компании, ее партнеры и многочисленные агенты. Если сотрудники «Альфы» пользуются тем инструментом, который выдал работодатель, то агенты вольны выбирать — продавать КАСКО от «АльфаСтрахования» или от ее конкурентов. Комиссионные ставки примерно одинаковы и особой роли при выборе партнера не играют.

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

 Плюсы:

• Опытный заказчик. Наш партнер — дока в сфере страхования и готов вывалить на нас тонны полезной информации о предметной области.
• Доступ к пользователям. Можно пообщаться с пользователями системы, понаблюдать за ними в их естественной рабочей среде.
• Масштабный проект. Есть время и ресурсы основательно погрузиться и долго не выныривать.
• Все участники проекта технически компетентны. Не тратим времени на выяснение возможностей и ограничений, легко находим общий язык.
• Собственная команда разработчиков. У заказчика свои специалисты, которые уже не «пилят ядро», а занимаются связкой фронтэнда с бэкэндом и очень ждут от нас интерфейсов — это обещает быструю обратную связь и на этапе разработки, и на этапе опытной эксплуатации.

Минусы: 

• Технические ограничения. Уже готовые технические задания и выбранная библиотека UI-элементов ограничивают возможность реализовать «прорывной интерфейс», где-то придется идти на компромисс.
• У проекта много стейкхолдеров и бенефициаров. Есть риск, что мы забыли учесть чьи-то интересы, не услышали или неправильно поняли чьи-то слова.
• Распределенная команда. Заказчик в Москве, финансовый центр «АльфаСтрахования» — в Волгограде, а мы в Петербурге. Общаться планируем каждый день, но живой контакт ограничен голосами в скайпе.
• Решено не подключать дизайнера. Это значит, что, хотя все интерфейсы получатся простыми, удобными и логичными, у них не будет шарма, ласкающего глаз пользователя. От микроанимации и графических решений придется отказаться.

Аналитика

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

1. Организовали круглый стол в петербургском офисе «АльфаСтрахования», куда пригласили кураторов и менеджеров продукта. Позволили им жаловаться на тяжелую жизнь в течение двух часов (сегодня такой формат модно называть «воркшоп»). Слушали, кивали и записывали. С нашей стороны участвовали менеджер проекта и ведущий проектировщик. Они вернулись с длинным списком узких мест нынешней инфосистемы.
2. Позвонили в финансовый центр «АльфаСтрахования» в Волгограде и пообщались со специалистами, которые начисляют агентские вознаграждения и ведут всю документацию. Задача — выяснить, с какими ошибками и проблемами они сталкиваются. С их помощью мы нашли болевые точки отношений между агентами и «АльфаСтрахованием». Мы хотели, чтобы новый интерфейс решал эти проблемы. Пусть система ведет агентов за ручку и обеспечивает «защиту от дурака» — а для этого надо добавить подсказок и проверок.
3. Побеседовали с продавцами полисов в офисе продаж «Альфы» и в офисе партнера — крупного автодилера. Взяли интервью у агента-новичка на фрилансе. Понаблюдали даже за агентом, который пытался оформить Зеленую карту в будке на трассе СПб — Выборг — Хельсинки. Пользовательский опыт говорил, что кроме функционала интерфейса люди озабочены его отзывчивостью, скоростью реакции и защитой данных.
4. Пообщались с программистами, которым предстояло воплощать наши интерфейсы, и выяснили, что мы ограничены компонентами UI-фреймворка Vaadin. Пожалуй, это было единственным, но самым серьезным ограничением — любую интерфейсную идею надо было проверить на совместимость и реализуемость.

Вот что вышло.

Если серьезно, то после аналитики мы поняли, кому и зачем нужна новая система.

• Руководителям продуктов — чтобы без проблем запускать новые продукты на едином интерфейсе, чтобы интерфейс помогал их продавать, увеличивал средний чек и легко адаптировался к изменениям в бизнесе.
• Кураторам — чтобы агенты-новички делали меньше ошибок в оформлении полисов, быстрее осваивали новые продукты, задавали меньше глупых вопросов и тратили больше времени на сбор информации о клиентских потребностях.
• Продавцам полисов в офисах «АльфаСтрахования» — чтобы не краснеть перед клиентом, по десять раз задавая ему одни и те же вопросы при сборе личных данных, и не заполнять заново бесконечные формы для очередного ценового предложения.
• Бизнес-партнерам «АльфаСтрахования», для которых полисы — не основная задача. Им нужно, чтобы полис ОСАГО или КАСКО мог оформить даже неподготовленный стажер, которому и так есть чему поучиться на рабочем месте.
• Агентам, которые продают страховые полисы по всей России, — чтобы полис можно было успешно оформить и на старом компе с 15" монитором, и на планшете.

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

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

Поехали!

Видение продукта — зона ответственности клиента. Это важно. Фактически клиент ставил задачу: «Проектируем оформление полисов страхования имущества физических лиц. Программисты приступят к кодированию через две недели. Вот ТЗ, где подробно описан весь функционал». Документ выглядел примерно так — без намека на картинки.

 

Менеджер проекта с нашей стороны обладал достаточным техническим бэкграундом, чтобы понять ТЗ в таком виде, задать уточняющие вопросы руководителю продукта, программистам и аналитикам «АльфаСтрахования», а потом вместе с проектировщиком набросать черновик.

 

Результат сразу обсуждался с заказчиком по скайпу и в несколько итераций допиливался до финального варианта, который учитывал функционал по ТЗ, ограничения фреймворка Vaadin и, конечно же, пожелания пользователей.

Вначале мы прототипировали на бумаге — подход, который экономит время и деньги заказчика. Рисовать на бумаге в разы быстрее, чем на самом лучшем компьютере в самом продвинутом софте. Причем делать это могут одновременно несколько человек, если лист бумаги достаточно большой (мы использовали листы форматом от А4 до А0). Нарисованное удобно обсуждать — мы не ограничены размерами монитора и можем повесить на стену или разложить на столе столько экранов, сколько нам нужно. Мы видим их все сразу и моментально переключаемся с одного на другой. А главное — плохой результат не жалко выбросить.

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

 

И где ж тут работы на полгода?

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

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

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

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

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

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

 

Информация о том, насколько интенсивно пользователь работает с системой в течение дня, накапливается и помогает планировать время.

 

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

 

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

Смысл

Проект стал одним из самых масштабных в истории «Собаки». За одиннадцать месяцев (вначале речь шла только о шести, но заказчика было не остановить) над проектом успели потрудиться три менеджера и пять проектировщиков. Мы научились бесшовно для процесса и бескровно для заказчика передавать проект от одного сотрудника у другому, с минимальными потерями времени и знаний о предметной области.

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

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

 

КЕЙС В КЕЙСЕ: КАК НЕ НУЖНО ПИСАТЬ КЕЙСЫ

Мы писали этот кейс почти два года. Трудилось восемь человек: два владельца «Собаки Павловой», менеджер проекта, руководитель контентного направления, копирайтер, редактор, корректор, аккаунт-менеджер. Переписывали всё с нуля четыре раза. Потратили бесчисленное количество часов на обсуждения. Как согласовывали с заказчиком — отдельная история. Мы работали по NDA и не могли рассказывать о проекте ничего без разрешения.

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

Выдохнули.

Обнаружили, что в кейсе нет ни одного полного скриншота, ни одного из 32 спроектированных экранов. Только несколько вырванных из контекста картинок.

Не делайте так никогда! И мы постараемся.

 

Подробнее на сайте.