644 подписчика

8 важных навыков UX-дизайнера в финтех-сфере

22 сентября 202022 сен 2020

2380

8 мин

Автор: Юлия Бондаренко

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

Содержание

Изучите тему: финансовые процедуры и терминология
Исследование пользователей и работа с гипотезами
Работа со стейкхолдерами
Информационная архитектура
Права и пользовательские роли
Форматирование и локализация
Государственные стандарты и регламенты
Визуализация информации

1. Изучите тему

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

Что такое счет-фактура (юридическое определение и назначение)
Какие существуют комиссии и пошлины и как они применяются. К примеру, в Германии есть список всех пошлин и формулы их расчета. Зачем дизайнеру это знать? К примеру, вы можете настроить автоматический расчет пошлины
в зависимости от суммы счета. А, кстати, есть еще разные типы пошлин… но это уже другая история.
План выплат
Отсрочка выплат

… и многое другое.

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

2. Исследование пользователей и работа с гипотезами

Проводить пользовательское исследование в конкретной сфере бизнеса — довольно сложно и затратно. Для исследования нужно будет отбирать пользователей, которые обладают определенными знаниями и навыками в конкретной сфере. Плюс, большинство финтех проектов работают в контексте B2B, так что добраться до непосредственных пользователей тоже может быть не просто. Ну, и конечно, все перечисленные ниже рекомендации не работают сами по себе: их следует применять в совокупности с эффективными, проверенными техниками тестирования ☝️

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

3. Работа со стейкхолдерами

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

Дизайнеру постоянно приходится собирать детали по проекту: системные требования, истории клиентов, метрики, KPI и кучу других мелочей. Для этого приходится общаться с самыми разными участниками процесса. Кроме того, дизайнер отвечает за ход проекта и должен следить, чтобы обратная связь от стейкхолдеров поступала вовремя. Вот несколько техник, которые помогут эффективнее работать со стейкхолдерами 👩‍💼👨‍💻:

Сразу уточните, к какому дню/часу вы рассчитываете получить обратную связь. Это действительно очень помогает.
Когда отправляете стейкхолдеру документ на ревью, сразу назначьте встречу по итогам ревью. Письмо-приглашение может звучать так: “Это встреча по итогам ревью документа (ссылка). Мы обсудим ваши комментарии и определим цели на новую итерацию”. Если стейкхолдер не делает ревью, вы можете пробежаться по документу прямо на встрече и сразу зафиксировать обратную связь.
Это кажется очевидным, но все же: всегда назначайте встречу, чтобы пробежаться по прототипу и собрать фидбэк по нему.

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

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

Вот что я советую почитать:

Информационная архитектура в интернете: оригинал | перевод
Руководство по бизнес-анализу знаний (Babok Guide). Очень важно освоить азы бизнес-анализа. Но без фанатизма — изучайте только нужные главы.

Концепт базовой банковской системы, на основе которого нужно спроектировать навигацию (я намеренно изменила оригинальное изображение).

5. Права и пользовательские роли

“Вы говорили можно!” — Операционист банка, после того случайно поменял процентные ставки для всех клиентов банка.

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

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

В зависимости от прав пользователей, дизайнер решает, какие функции будут активны, а какие скрыты в разных режимах (например, режим редактирования и режим просмотра).
Как выглядит экран, когда некоторые функции скрыты.
Поддерживает ли информационная архитектура все возможные права и роли? Может ли пользователь с ограниченными правами открывать определенные страницы, или они для него будут заблокированы?
Что будет, если пользователю скинут ссылку на страницу, которую он не имеет прав просматривать? Система может отобразить страницу в режиме просмотра. Или вы можете вывести сообщение, что у пользователя нет прав на доступ. А может быть такому пользователю вообще не нужно знать о существовании этой страницы?

Закладывайте костяк пользовательских ролей в самом начале проекта и постепенно наращивайте систему прав и разрешений.

6. Форматирование и локализация

Вот что бывает, когда не соблюдаются стандарты

💰Написание десятичных дробей может отличаться от страны к стране. Почитайте о разделителях в десятичных дробях; или вот вам отрывок из стандарта ISO 31-0:

“Длинные числа можно сделать более читаемыми, разделив последовательность цифр на группы — предпочтительно по три цифры — небольшими пробелами [...]. Не следует отделять группы цифр точкой или запятой, поскольку эти символы используются для обозначения десятичных дробей. К примеру, один миллион (1000000) можно записать как 1 000 000,00” (,00 автор добавил для ясности)

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

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

Но даже если вы вы выберете международный формат даты гггг-мм-дд, все равно будет не сразу понятно, какие две цифры месяц, а какие — день? С другой стороны, международный формат даты привнесет в дизайн согласованность. К тому же по нему удобно сортировать информацию в таблице.

💶 До того, как я пришла в финтех, валюта была для меня просто милой иконкой. Очень скоро я узнала, что использовать иконки для обозначения валюты — неправильно. К тому же, есть целое руководство по форматированию валют и стандарт ISO 4217.

🌎 Специфические форматы данных, которые отличаются от страны к стране. Это могут быть клиентские номера, номера банковских счетов и номера карт:

Клиентский номер (customer number) как правило определяется национальным идентификационным номером клиента, хотя это может отличаться от страны к стране. Этот номер также зависит от типа клиента: физическое или юридическое лицо. Чтобы обеспечить согласованность лейаута и форматирования, можно добавлять нули (0) в начале клиентского номера, чтобы заложить большее количество цифр. К примеру, если система поддерживает 11-значные номера лицевых счетов, а у нас есть номер клиента в формате 45059410, можно забить его как 000450.59410.
Номер банковского счета может существовать в разных форматах и составляться по разным алгоритмам — в зависимости от страны.
Номер банковской карты должен соответствовать стандарту ISO/IEC 7812. Очень важно, чтобы при печати или отображении на экране номер карты был частично “замаскирован”. Номер карты целиком можно отображать только в некоторых административных системах и только авторизованным пользователям.

8. Визуализация информации

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