Дизайн
Юлия Дюк
3799

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

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

В закладки

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

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

Метаморфоза первая: демотивация

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

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

Метаморфоза вторая: саботаж

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

Метаморфоза третья: провал цели

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

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

Дизайн enterprise-систем

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

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

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

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

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

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

Round 1. Fight!

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

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

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

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

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

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

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

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

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

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

Round 2. Fight!

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

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

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

Добавьте в форму создания нового клиента инпут «ссылка на систему ХХХ».

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

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

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

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

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

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

Round 3. Fight!

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

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

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

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

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

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

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

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

Fatality!

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

Я смотрю почту, и там нет ни одного письма с вопросом: «Как это работает?». По-моему, это успех :)

Service Owner

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

Впервые сегодня создавала нового клиента в CRM. Стало суперудобно! Мы ждали этого много лет :)

клиентский менеджер

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

Finish him!

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

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

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

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

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

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

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

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

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

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

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

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

{ "author_name": "Юлия Дюк", "author_type": "self", "tags": [], "comments": 27, "likes": 13, "favorites": 128, "is_advertisement": false, "subsite_label": "design", "id": 97820, "is_wide": false, "is_ugc": true, "date": "Thu, 26 Dec 2019 17:54:10 +0300", "is_special": false }
0
27 комментариев
Популярные
По порядку
Написать комментарий...
19

А дизайн-то где? Где конкретные решения про которые вы вдохновленно пишите? Сейчас эта статья выглядит как шаблон истории для кино утром в воскресенье:

 
 1. Главный герой узнает, что мир умирает и спасти его может только он. 

2. Герой изучает заклинания: CJM, алахомора, Custdev, Roadmap (ну, и далее по тексту), которые помогут ему победить. 

3. Герой знакомится с антагонистом и в сложном поединке одерживает верх. 

4. Все танцуют и поют. 

Или Райффайзен запрещает показывать что вы такое надизайнили? Но зачем тогда весь этот текст? Я ещё могу понять, когда пишут про рекламу подобную воду, но писать про дизайн без примеров - это нонсенс.

Ответить
–10

Спасибо за комментарий) Это статья про культуру разработки дизайна, поэтому я намеренно не публиковала макеты. Кроме того, они вам ничего не скажут вне контекста использования. Но если вам так хочется посмотреть на мои работы, то можете сделать это тут: http://antipo.tilda.ws/

Ответить
0

Зашёл в портфолио , ни одного примера внутренних корпоративных систем не нашёл , класс

Ответить
1

Жаль, что разочаровала вас. Скоро будет отдельная статья с картинками до и после)

Ответить
0

Ваши комментарии задизлайкал, но за портфолио респектую

Ответить
6

Юля, где макеты?

Ответить
–4

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

Ответить
4

Сначала мы делали плохо и все работало плохо. Потом мы стали делать хорошо и получилось збс. 

Ответить
0

Считаете, недостаточно детализированно?

Ответить
0

Тот случай когда картинка стоит тысячи слов.

Поскольку вы не указывали никаких численных метрик, то показывайте результат работы визуально)

Ответить
0

Численные метрики на внутренних системах это вообще песня, достойная отдельного поста) CRM только-только запустилась, поэтому определение целей пока в процессе. На момент запуска цель была одна — daily usage 90%, и она достигнута. А с картинками сделаю отдельный пост попозже.

Ответить
2

Хороший специалист очень часто бывает "сапожник без сапог"))

Ответить
0

ага, оч странно отдавать дорогущую брендовую обувь на починку чумазому таджику в каморке, внутри которой как после бомбардировки)

Ответить
1

Интересно было бы увидеть конкретные примеры в формате "было - стало"

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

Ответить
1

Спасибо за фидбек, обязательно напишу отдельную статью с примерами)

Ответить
1

"У нас есть такие приборы! Но мы вам о них не расскажем!"

Юля, я понимаю что вы под NDA, а описать кейс хочется. Но вот ей-богу — лучше никак, чем эти 10 ведер воды. Тема-то очень интересная и актуальная. 

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

Ответить
0

Спасибо, Александр! Постараюсь согласовать такое с нашей СБ и напишу отдельную статью с картинками)

Ответить
0

Может кто посоветовать материал, содержащий правильные названия элементов UI?

Ответить
–1

Конечно) https://www.w3.org/

Ответить
0

Макеты было бы интересно посмотреть

Ответить
0

Это статья про культуру разработки, но я обязательно покажу макеты, когда напишу про процесс визуального дизайна)

Ответить
0

Удивлена что в Райфе один дизайнер разрабатывает crm сам, в одиночку. Обычно это так не работает.

Ответить
0

Конечно, это было не так) Над CRM работали, по сути, две скрам-команды. Сильно помогала дизайн-система.

Ответить
0

так а где сами сапоги то?

Ответить
0

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

Расскажи плиз, какая была главная причина для бизнеса отказаться от коробки?
И какие метрики успеха закладывали в новую crm?

Ответить
0

Главной причиной стали систематические задержки со стороны вендора по внедрению запланированного функционала. В какой-то момент просто решили отдать одну из задач вендора на команду in-house разработки. И они работали параллельно с вендором 1 спринт. В конце спринта стало очевидно, что наша команда сделала определенный объем, а вендор не продвинулся вообще.

Сейчас у нас цель по daily active users. Нужно, чтобы добровольно пользовались системой не менее 90% менеджеров. Эту цель недавно достигли, какие будут на 2020, пока обсуждаем.

Ответить
0

Спасибо за интересную статью! 

Жду продолжения с макетами ДО и ПОСЛЕ. 

Ответить

Комментарии

null