Сапоги для сапожника: как разработать UX и UI внутренней системы

Я разработала UX- и UI-дизайн CRM для корпоративного сектора «Райффайзенбанка». Хочу поделиться своим опытом и ободрить всех, кто занимается разработкой инхаус-сервисов.

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

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

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

Так и с сервисами. В некрасивом сервисе не хочется работать. Хочется поскорее проскочить необходимые процедуры и выйти из него. Отсюда вытекает…

Люди — изобретательные, творческие создания. Чтобы побыстрее проскочить ненавистный процесс, они придумают такие уловки, что останется только удивляться. Телефонные номера из единичек, наборы букв вместо наименований и тому подобное. Легко представить, какое качество данных получится на выходе в таком сервисе. Отсюда вытекает…

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

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

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

Теперь, закончив разработку первой версии корпоративной CRM для «Райффайзенбанка», я хочу поделиться своим опытом со всеми, кто работает над продуктами для внутреннего заказчика. Вы не одни, у вас всё получится!

В «Райффайзенбанке» мы начали решать эту проблему силами двух команд. Одна из них разрабатывала калькулятор для расчёта ставок корпоративным клиентам, другая пилила CRM для клиентских менеджеров.

Корпоративный клиентский менеджер банка оперирует множеством сложных финансовых показателей. У меня по экономике была четвёрка за хорошую посещаемость, на этом моё знакомство с областью финансов заканчивалось. Service owner, техлид, лидеры сегментов и аналитики несколько раз объясняли мне одно и то же разными словами, чтобы я поняла суть задачи.

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

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

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

Табы в две строчки, последний из них — ролловер, в котором скрывается ещё столько же табов.

На стартовой странице — четыре поля для поиска по разным параметрам.

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

Алерт! Какое-то из полей, оказывается, было обязательным для заполнения, хотя звёздочка у лейбла не стояла.

Алерт! Ошибка номер XZHEFRSJL8912JGFFAK-0009 (это оригинальный текст).

Или просто бесконечно вращающиеся песочные часы.

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

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

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

На драфтах я провела тесты с несколькими пользователями в гибридном формате Think Aloud + Teaching. Некоторых пригласила поодиночке, другие тестировали в паре.

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

И тут приходит письмо от коллеги, с которой мы никогда раньше не встречались, с директивой:

Почувствовав, что это только начало «улучшений», я решила отстаивать каждый инпут. Узнала, кто это, познакомилась и назначила встречу, чтобы выяснить, откуда взялась такая задача и какую бизнес-цель она решает.

Оказалось, что это нужно, чтобы рассчитать TTY. Коллеги хотели заставить пользователей, заводя заявку в сторонней системе, копировать оттуда URL, открывать в соседней вкладке нашу CRM, создавать карточку клиента и в отдельном поле вставлять эту ссылку. И были уверены, что пользователи действительно станут это делать.

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

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

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

Так удалось не только избежать обрастания бесполезной функциональностью, но и найти точки роста нашей CRM.

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

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

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

Несколько месяцев потребовалось, чтобы бизнес прислушался к аргументам команды. Было очень тяжело признать, что «коробка» не взлетела и необходимо переходить на inhouse-разработку. Большим подспорьем стал пример команды калькулятора. В течение контрольного спринта ребята сделали своими руками то, что в коробочном решении настраивали месяцами.

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

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

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

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

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

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

Спустя две недели после запуска на групповую почту начали приходить письма от сотрудников, которые работают в подразделениях, смежных с нашими целевыми пользователями. Они просили: предоставьте нам тоже доступ в новую систему, нам тоже это нужно. Пришлось объяснять, что мы пока не планировали подключать к CRM другие подразделения, но обязательно обсудим это с бизнесом. Почта ломилась от желающих тоже попасть в новую, красивую и удобную CRM. И это на этапе MVP.

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

• Не принимать в работу директивы.
  

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

• Искать мотив.

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

• Давать пользователям то, что им нужно, а не то, чего они просят.

Перефразируя Генри Форда, если бы я спросила пользователей, чего они хотят, они бы попросили сделать им более быстрый Excel.

• Пробовать разные методы UX-исследований.

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

• Вовлекать разработчиков.

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

UPD: О том, как всё стало выглядеть после обновления, читайте во второй части статьи.