{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

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

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

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

Карточка клиента

Все действия, выполняемые в CRM менеджером, так или иначе связаны с клиентом-организацией. Страница с карточкой организации — самая востребованная и нагруженная в системе.

Вот так она выглядела в старой CRM:

А вот новый дизайн карточки клиента:

Здесь мы:

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

Остальные экраны собраны таким образом, чтобы менеджер мог прокликать основные процессы, не задумываясь и не бегая глазами по странице в поиске нужных кнопок. Таких процессов на момент запуска CRM было два: создание карточки нового клиента и создание отчета о встрече.

Создание карточки нового клиента

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

Так выглядела форма создания нового клиента в старой CRM:

А вот новый дизайн этой формы:

Здесь мы:

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

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

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

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

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

Это увеличивает когнитивную нагрузку: трудно запомнить нюансы процесса, когда он не соответствует человеческой логике.

Это просто неудобно: создание контактных лиц — нудная работа, не несущая сама по себе никакой ценности.

Так выглядела форма создания отчета о встрече в старой CRM:

А вот новый дизайн этой формы:

Здесь мы:

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

Важные детали

На некоторых деталях мы старались держать фокус вне зависимости от бизнес-процессов:

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

Процесс визуального дизайна внутренних систем — самая маленькая часть работы UX/UI дизайнера.

Отрисовка экранов заняла у меня не более 30% общего capacity, причем некоторые макеты перерисовывались полностью, с нуля, по несколько раз. Это происходило, когда мы понимали, что идем не в ту сторону.

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

Юрий Ветров, руководитель направления бренд-менеджмента и цифрового дизайна Райффайзенбанка

И на этом хочется акцентировать внимание после комментариев к первой части. В 2020 году продуктовому дизайнеру не имеет смысла закапываться в технических деталях: у нас под рукой дизайн-системы, гайдлайны и тонны готовых неплохих UI Kit'ов в открытом доступе. Вы никого не удивите, отрисовав уникальный набор иконок для своего продукта. А если удивите — на мой взгляд, это повод задуматься о смене специализации.

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

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

Первая часть про культуру разработки здесь:

0
1 комментарий
SergejAntipov

Спасибо за информацию.

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда