Стандарты задротства: чек-листы UX-дизайна финсервисов и банков

Если ты про сервис и UX — ты не просто отрисовываешь экранчики, а проектируешь каждое касание пользователя с продуктом. Сооснователь Angry Наталья Стурза на примере кейса с «МТС Банком» рассказала об аналитическом подходе и чек-листах качества, которые помогают в дизайне сложных продуктов.

«МТС Банк» обратился к нам с запросом сделать интернет-банк для бизнеса. У них уже был готовый UI Kit, поэтому от нас требовалось меньше по визуалу и больше по UX и проработке сценариев.

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

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

1. Незначительных деталей не бывает

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

2. Минимум пространства для творчества

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

3. Дизайн — это не только экраны интерфейса, это любое касание с продуктом

Например, тексты ошибок, email, SMS, прерывания, валидация. Чаще всего их пишут разрабы или другие отделы. Разработчику проще самому доделать, чем тратить часы на коммуникацию и объяснение дизайнеру, где и что нужно доделать. Но это тоже часть опыта и тона продукта, который должен быть единым. Даже электронные письма лучше напишет продуктовый дизайнер с высокой компетенцией в текстах, чем маркетолог (с той же высокой компетенцией), который делает продающие рассылки.

У UX-дизайнера 80% задачи занимает работа с данными — изучение текущих и построение структуры данных будущего сценария.

Входной информацией служат:

• Аналитические данные. Информация о количестве кликов, переходов, ошибок, об использовании тех или иных функций или услуг. У каждого продукта и портрета пользователя аналитика отличается, но приоритеты обычно не меняются. Опираемся на наработанную базу статистических данных.
• UX-исследования. За годы работы с финтех-компаниями провели сотни юзабилити-тестов и глубинных интервью. Знаем, как люди воспринимают тексты, какими терминами называют те или иные сущности, что важно на каждом шаге работы с каждой функциональностью. Всё это качественные инсайты, которых не получить из цифр.
  
• Продуктовые метрики и транзакционные показатели. Это те самые вводные от бизнеса. У нас есть бэкграунд продуктовой разработки в «Модульбанке», «Точке» и ВТБ, поэтому цифры по всем продуктам и под каждый тип пользователя нам тоже известны. Они помогают приоритизировать бэклог, а в каждой задаче найти компромисс между «хотелками» пользователя и возможностями бизнеса.
  
• Опыт конкурентов. Изучить, что и как у других — это святое. Полезно пройти опыт работы с сервисами конкурентов как пользователь, чтобы учесть их ошибки. Анализ того, как работают конкуренты — чуть ли не первое, что должен сделать дизайнер для погружения в сферу.

После сбора вводных приступаем к выполнению задачи. В проекте с «МТС Банком» было примерно 20 эпиков — больших задач, которые разбиваются на мелкие. Каждый эпик проходил через внутренний чеклист проектирования (а кроме него есть ещё чеклисты дизайна и работы с китом, текстов и типографики). Расскажем о девяти основных внутренних критериях проектирования.

Проектирование начинается с построения информационной схемы или бизнес-процесса по задаче. Дизайнер до 80% времени от задачи ещё до отрисовки сценариев тратит на изучение данных и продумывание информационной структуры. Исследования, цифры, аналитика, конкуренты, справочники, ресерч проблем в интернете — это всё информационное окружение дизайнера.

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

Бизнес-процесс проектируется для user story с разветвлённым сценарием и множеством альтернативных и негативных путей. Например, этапы открытия расчётного счёта. Каждый — это дерево с сотней ветвей, а для пользователя всё выглядит стройно и логично.

Инфосхема или бизнес-процесс включает в себя:

• Вход и выход: страницы и места других сценариев, с которых начинается и которыми заканчивается текущий сценарий.

• Наборы данных — конкретные элементы информации. Например, в выставлении счёта у блока данных «Товар или услуга» может быть количество, стоимость, название, единица измерения, сумма, НДС.
• Ограничения или условия к элементам данных. Это те действия и условия, которые накладываются на каждый блок данных. Например, выставленный счёт не могут подписать более пяти пользователей. Номер счёта присваивается системой по порядку.
• Логика — разветвление сценария в зависимости от выбора или условий.

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

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

• Как будет выглядеть элемент и страница, если в поле суммы ввести один рубль (min)? А если ввести 10 цифр с копейками (max)? Вопрос помогает не забыть написать соответствующие тексты ошибок.
• Что увидит пользователь на главном экране мобильного банка, если название компании превышает 20 слов (max)? Если дизайнер не предусмотрел возможность сокращения, то пользователь увидит название на половине экрана. А что если у человека пять компаний и они начинаются с одних и тех же слов до сокращения? Стоит задуматься с точки зрения пользовательского опыта и об этом.
• Какой будет страница истории документов, если в ней до сих пор не создано ни одного документа (zero)? Если дизайнер не продумал это состояние списка, пользователь увидит пустую страницу. А мог бы, например, вовсе её не увидеть или прочитать текст о том, для чего эта страница и как сюда попадут документы.

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

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

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

• с главной страницы из меню;
• из списка частых действий;
• из истории документов и счетов в случае, если повторяет или делает счета на основе уже созданных.

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

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

• Можно не ввести номер расчётного счёта.
• Можно ввести его не полностью.
• Можно ошибиться цифрой.
• А можно ввести правильно, но где-то на стороне банка сломается алгоритм, который его проверяет.

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

Ограничения — это не ошибки, это условия, в которых существуют элементы интерфейса и за которые они выходить не могут:

• Выписку можно отправить только на пять почтовых адресов за раз.
• В выставленный счёт добавить только трёх подписывающих пользователей.
• В назначение платежа можно ввести только 210 символов, ещё сколько-то останется на НДС.
• У файлов есть форматы, размер и максимальное количество при загрузке в чат.

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

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

Например, при выставлении счёта:

• Есть создатель счёта(или получатель денег) — тот, кто создаёт и выставляет счёт, это может быть ваш бухгалтер.
• Есть отправитель — тот, кто отправляет или видит готовый счёт, чаще всего это сам гендир, но может быть и тот же самый бухгалтер. На этом шаге важно не пропустить наличие двух состояний одной задачи, которые видят разные по правам пользователи в личном кабинете. Готовый документ мы можем удобно структурировать и брендировать, тем самым ещё раз показать целостность сервиса в мелочах.
• А ещё плательщик — кому выставлен счёт. Он может увидеть его в бумажном виде, или в электронном, пройдя по ссылке, а может увидеть в личном кабинете, если обслуживается в том же банке. И мы снова не забыли и даже сгенерили некоторые состояния.

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

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

• Внутренние — то, что находится непосредственно в интерфейсе приложения: история действий, события в ленте, снеки, пуши, уведомления в чате.
• Внешние — то, что «делает» продукт вовне и что пользователь получает от продукта через другие апы: SMS, email, мессенджеры.
• Офлайновый — когда клиент взаимодействует с сотрудником сервиса вживую или по телефону. Здесь мы можем спроектировать процесс и данные, проходящие через колл-центр, но скрипты, конечно, будут писать профи в этой сфере. Где-то можно отрисовать карточки с промокодами, которые будут выдаваться при встрече. В любом случае, если не забывать, что у сервиса есть офлайновая часть процесса, продуктовый дизайнер придумает возможности, которые зацепят человека и сделают восприятие ещё круче.

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

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

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

А вот пример перегруженного текста: «Комиссия составляет 230 ₽». Зачем слово «составляет»? «Комиссия — 230 ₽». И короче, и смысл не потерян.

Подробно о чеклистах по текстам в интерфейсе мы уже писали статью.

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

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

Что описываем в комментариях к сценариям:

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

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

Наши критерии качества завышены, потому что основаны на западном подходе и понятии «дизайна», которое значит не просто сделать красиво в десятке уникальных экранов. А значит, что нужно продумать и спроектировать все варианты развития событий и написать всю коммуникацию и ToV. У нас этих экранов в 3–15 раз больше.

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

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

Это кейс «МТС Банка» на Behance — можете нас поддержать и подписаться, скоро выложим ещё два интересных объёмных проекта.