UX/UI сложных банковских приложений

UX/UI сложных банковских приложений

Привет. Эта статья — текстовая версия моего доклада на конференции RAUX 2021. Ниже будет ссылка на видео.

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

Я делаю крупные приложения для топовых российских компаний. В основном для банков. Стараюсь больше руководить, но бывает, что дизайню и программирую. Занимаюсь этим уже почти 10 лет, и возникло наблюдение...

Создание UX/UI, длится минимум 3 месяца. Бывает и 6–9 месяцев. При этом, очень редко выходит закончить проект с тем же дизайнером, с которым начинали его делать. По дороге люди выгорают и уже не могут выполнять свою работу эффективно. При том, что на проектах поменьше (1–2 месяца), всё проходит куда как менее кровопролитно.

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

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

В статье я расскажу из чего состоит UX/UI банковских проектов и почему это такое скучное занятие.

Будет полезно начинающим дизайнерам. И тем, кто хочет перейти на выполнение крупных проектов.

Кому удобнее смотреть видео, тут запись с конференции:

Содержание

При чём тут скучные люди, станет понятно в самом конце. Но для начала:

В чём измеряется сложный проект?

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

Для какого-нибудь лендинг пейджа достаточно 3–5 экранов. Для интернет-магазина 10–20 экранов. Банковские приложения для юр. лиц начинаются от 100 экранов.

Причём, 100 экранов — это дизайнеру для разминки пальцев. В процессе они ещё много раз переделываются, а на выходе заказчик получает 150 – 200 экранов (не считая ночных тем и мобильных версий).

Если это крупный банк, который меняет свой дизайн, то через 2–3 года, когда дизайн разойдётся по разным командам и отделам банка, в нём будет уже 1000+ экранов.

Что заказчик ценит в дизайне

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

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

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

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

  3. Масштабируемость. Дизайн должен быть применим не только к тем кейсам, с которыми вы работаете прямо сейчас, но и к тем кейсам, о которых сейчас можно только подозревать. В каком-то смысле, нужно постараться поглубже заглянуть в будущее.

Ниже попробую показать, как именно можно использовать эти принципы.

Этапы создания дизайна крупного проекта

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

В целом, работа состоит из четырёх этапов:

  1. Постановка задачи
  2. Дизайн
  3. Передача результатов
  4. Сопровождение

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

UX/UI сложных банковских приложений

Команда состоит из 10–13 человек. В полном составе это:

  1. Дизайн-директор (это я). Отвечает за весь проект в целом. Занимается планированием, начальной постановкой и контролем качества работы.

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

  4. Ассистент UX-исследователя. Помогает UX-исследователю, ведёт записи (в том числе видео), конспекты и тд.

  5. Front-end разработчик. Делает кликабельный прототип приложения для UX-тестов.
  6. Бизнес-аналитик. Помогает разобраться в требованиях заказчика. Проверяет дизайн на соответствие этим требованиям.

  7. Бухгалтер-консультант. Представляет собой главную целевую группу нашего приложения. Делится с нами инсайтами о своей работе.

  8. Старший дизайнер. Рисует основные, самые главные и критичные сценарии.

  9. Помощник старшего дизайнера. Рисует всё, что не успевает старший дизайнер.

  10. Дизайнер данных. Следит, чтобы в макетах были правильные и консистентные данные.
  11. Графический дизайнер. Рисует презентации по итогам UX-тестов и по итогам всей работы.

  12. Иллюстратор. Делает иконки и прочие иллюстрации, нужные для приложения.
  13. Монтажёр. Монтирует записи по итогам UX-тестов.

Этап № 1. Постановка задачи

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

Ответственность за правильно поставленную задачу должна лежать на исполнителе.

Для заказчика это вообще может быть первый проект по дизайну в его жизни. Откуда он может знать, что нужно делать?

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

От заказчика, конечно, нужно получить какую-то начальную постановку. Но совершенно не стоит ожидать, что это её финальный и законченный вариант. Финальный вариант как раз должен предоставить ты.

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

Постановка задачи состоит из 4 фаз:

  1. Изучение требований и текущего приложения (если оно есть)
  2. Интервью с пользователями
  3. Скетчирование
  4. Составление пользовательских сценариев

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

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

Для интервью с пользователями подключается UX-исследователь. Ему нужно выяснить, за что пользователи любят текущее приложение (чтобы не потерять эту функциональность в будущем), какие у них проблемы с ним.

Тут же мы должны выявить основные сценарии использования приложения и группы пользователей, составить портреты пользователей.

На конференции мне уже предъявили, что в докладе маловато примеров. Говорю «составить портреты», а не показываю, как они могут выглядеть.

Мы сейчас ведём активные переговоры с клиентами, чтобы они нам разрешили это показать. Пока что большая часть работы под NDA. Поэтому реальных примеров будет немного.

Но если коротенько, то портрет выглядит примерно так:

Вивальди Клавдия Денисовна. 50 лет. Пол жизни работает бухгалтером. Последние 10 лет — главный бухгалтер в компании ООО "Нога Императора". Компания занимается оптовой поставкой сандалей в страны Средиземноморья. Клавдия работает в 1С и заходит в банковское приложение несколько раз в день, чтобы импортировать документы из 1С, проверить правильность их заполнения и отправить на подпись руководителю.

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

Клавдия и Валентина пользуются клиент-банком исключительно с рабочих компьютеров.

Их руководитель, Иванов Адольф Сергеевич, 40 лет. Занятой и хорошо обеспеченный человек. Пользуется клиент-банком на ходу и второпях. Чаще всего с телефона. Раз в день он подписывает документы.

Надеюсь, у вас сложилась картинка.

Дальше дизайн-директор рисует скетчи. Именно дизайн-директор, не дизайнер. И тут мы выясняем, как заказчик видит проект на самом деле. Обычно на этапе скетчей получается закрыть большую часть правок.

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

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

И наконец, дизайн-директор и UX-исследователь из нарисованных скетчей составляют пользовательские сценарии.

Пример: Клавдия Денисовна импортирует документы из 1С. Она открывает главный экран, нажимает кнопку импорт. Выбирает нужные файлы. Вдруг видит ошибку, какой-то из документов неправильно заполнен. Клавдия открывает этот документ и исправляет его прямо в клиент-банке, и тд.

Для каждого из шагов должен быть готов скетч.

Может быть несколько разных возможных сценариев. У Клавдии может не возникнуть ошибки в процессе и всё пройдёт гладко. Или Клавдия захочет настроить автоматическую выгрузку из 1С.

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

Закрепим:

UX/UI сложных банковских приложений

Этап № 2. Дизайн

Вот только теперь начинается главная работа. Состоит из 4 фаз:

  1. Дизайн

  2. Прототипирование

  3. UX-исследование

  4. Экспертная оценка

Эти фазы повторяются по кругу до полного истощения всех участников или пока не будет достигнут желаемый результат. Мы обычно укладываемся в 3 круга.

Дизайн делается старшим дизайнером. Точнее, он начинает, рисует основные экраны, а потом работу подхватывает второй дизайнер, чтобы первый не закапывался.

В то же время, дизайнер данных следит, чтобы все ИНН, КПП, ИТД были похожи на настоящие, чтобы в текстах не было крамолы, чтобы из экрана в экран данные были верные и не вызывали бы вопросов.

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

Ну и в тестированиях это тоже помогает не вводить пользователя в заблуждение.

Прототип делают UX-исследователь и front-end разработчик. Можно, теоретически, обойтись без разработчика и сделать кликабельный прототип в Figma или Invision. Но HTML работает гораздо лучше. Пользователи воспринимают HTML как самое настоящее приложение и ведут себя заметно по-другому по сравнению с тем, когда они просто видят кликабельные картинки.

UX-тестирование проводит, соответственно, UX-исследователь. Ему в этом помогает ассистент. На этом этапе хорошую отдачу дают юзабилити-тесты. Вот тут моя статья о том, как мы проводили один из таких: UX-исследование ДБО: наш опыт, ошибки и открытия

На этапе UX-исследования проверяется юзабельность приложения. А это, как я писал выше, очень ценно для заказчика.

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

Экспертную оценку нужно получить как минимум от четырёх источников:

  1. UX-эксперт говорит о том, соответствует ли приложение пользовательским ожиданиям

  2. Бизнес-аналитик — соответствует ли бизнес требованиям

  3. Разработчик — соответствует ли техническим требованиям

  4. Заказчик — соответствует ли его ожиданиям

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

Составляем комментарии для дизайнеров и начинаем всё по новому кругу.

Закрепим:

UX/UI сложных банковских приложений

Этап № 3. Передача результатов

Вот про это уже многие дизайнеры (и даже довольно крупные компании) начинают забывать.

Отправил клиенту просто ссылку на фигму (а дальше пусть сам разбирается) — считай, ничего не сделал, работа в корзину.

Для правильного эффекта нужно сделать:

  1. UI-кит

  2. UX-гайд

  3. Провести презентацию

Про UI-кит в целом все ещё знают. Нужно вынеси всё, что кликается и всё, что имеет разные возможные состояния на отдельные слайды. Это делает старший дизайнер.

А вот UX-гайд (или что-то, на него похожее) уже мало кто делает. Нужен он для того, чтобы проверить масштабируемость проекта. Создаёт его дизайн-директор.

Пример (пока только текстом, без картинок, сори): У тебя есть список документов. Например, платёжных поручений. Этот список можно сортировать, фильтровать, в нём видны какие-то данные документов.

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

Можно ли будет использовать те же принципы фильтрации, сортировки? Встанут ли данные из нового документа в ваш текущий шаблон? Можно и нужно ли будет сделать его импорт/экспорт/редактирование по тем же сценариям, что и платёжное поручение?

В UX-гайде нужно описать, по каким правилам можно добавлять новые сущности в наше приложение.

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

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

Закрепим:

UX/UI сложных банковских приложений

Этап № 4. Сопровождение

Чтобы уж прям наверняка гарантировать качественный результ, нужны:

  1. Авторский надзор

  2. Новые UX-исследования
  3. Уточнение гайдов

Во время авторского надзора дизайнер смотрит, что делают разработчики и корректирует их, чтобы было как в макете.

Для следующих UX-исследований — статья 21 метод UX-исследований: какой выбрать. Из неё пригодятся те, что находятся в правой части графика.

И стоит заранее предупредить заказчика, что ваши гайды скорее всего не покроют 100% всего, что нужно. И поэтому через пол года – год их нужно будет скорректировать и уточнить.

UX/UI сложных банковских приложений

Как помочь разработчикам

Четыре простых правила, которые сделают твой дизайн приятнее для разработчиков:

  1. Продумай кейсы с ошибками. И не просто с ошибками на полях ввода, например. А с ошибками в сценариях. Выше я уже приводил пример, когда Клавдия Денисовна получила ошибку при импорте документов.
  2. Строго следуй заявленным переменным. В основном это касается цветов. Дизайнеры любят заявлять, что использовано 5–7 цветов (это красиво выглядит в презентации на беханс), когда в макете реально используется 20. Для цветов мы используем Opium.Fill (это тоже ссылка на мою статью), что в целом сильно помогает наладить взаимопонимание.
  3. Следи за правильностью наполнения. Выше я писал, зачем нужен дизайнер данных. Разработчикам тоже важно, чтобы данные были консистентными.
  4. Показывай пустые списки, пустые страницы.

Заключение

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

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

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

Удачи.

Статью написал Денис Элиановский. Спасибо Станиславу Лушину и Татьяне Китаевой за помощь с расшифровкой видео, Елене Ефимовой — за иллюстрацию в шапке.

5959
16 комментариев

Скучненько, спасибо

12
Ответить

Интересно, спасибо! Сама являюсь дизайнером банковских приложений. Только вот в нашей компании исследования игнорируют, а за дизайн данных, всех страниц приложения, иконок, UI-китов отвечает один человек на проекте. И "бонусом" дизайнер работает над 3-4 крупными проектами одновременно, ну и вдобавок еще несколько мелких. Я уже держусь больше полугода :)

6
Ответить

Я иногда помогаю строить UX/UI процессы в компаниях моих друзей. И чем больше команда, тем больше это занимает времени.

В компании 100+ человек от полного игнорирования UX-тестов до их использования с разделением труда (хоть и не на всех проектах) уходит чуть больше года.

Так что держитесь) Если внутри кто-нибудь эту тему продвигает, то осталось ещё пол года :)

1
Ответить

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

Жаль, что таких дизайнеров всего в России 3-5 человек и они очень дорого стоят

3
Ответить

Уверен, что таких дизайнеров может становиться все больше и больше. Жаль, никто не собирается давать возможность молодым специалистам. Все гоняются за этими 3-5 людьми. 

Ведь, чтобы сейчас быть хорошим специалистом, это нужно было начать 5-6 лет назад минимум. Тогда и запросы другие были. А сейчас что делать тем, кто 1-2 года опыта или только начал? Возможно среди них как раз и есть толковые ребята, которые и за умеренную оплату готовы поработать. 

Ответить

Вот мне сейчас надо гордиться или плакать? Не скажу что все прям идеально получается, но все что было вышеуказанно (задачи первых 10 человек) делаю один  ((

1
Ответить

В целом это тоже вариант. Если есть такие способности — почему нет)

Мы раньше делали всё в 3–4 человека. Но вот такое разбиение позволяет почти полностью убрать фактор автобуса и гарантировать выполнение проекта.

1
Ответить