Стандарты задротства: чек-листы UX-дизайна финсервисов и банков
Если ты про сервис и UX — ты не просто отрисовываешь экранчики, а проектируешь каждое касание пользователя с продуктом. Сооснователь Angry Наталья Стурза на примере кейса с «МТС Банком» рассказала об аналитическом подходе и чек-листах качества, которые помогают в дизайне сложных продуктов.
«МТС Банк» обратился к нам с запросом сделать интернет-банк для бизнеса. У них уже был готовый UI Kit, поэтому от нас требовалось меньше по визуалу и больше по UX и проработке сценариев.
На этом кейсе можно идеально рассказать о наших подходах к проектированию, потому что не нужно отвлекаться на визуальные решения.
Кто-то скажет, что недочёты продукта всплывают после того, как им начинают пользоваться. Мы скажем: да всплывают, но их значительно меньше, если позаботиться о мелочах на начальном этапе.
Три базовых принципа
1. Незначительных деталей не бывает
Невнимание к мелочам приводит к разрыву целого сценария и тащит за собой вереницу ошибок: потерял дизайнер, потом верстальщик, затем аналитик, упустила разработка — начали работу сначала. Качественный результат состоит из множества заранее предусмотренных моментов.
2. Минимум пространства для творчества
Детальный подход лишает тех, кто в дальнейшем работает над проектом, необходимости проявлять самодеятельность. Все состояния продуманы, возможные шаги просчитаны — на выходе избегаем кругов правок и получаем цельный с точки зрения пользовательского опыта продукт. Если можешь сделать так, чтобы дальнейшие участники процесса ничего не придумывали, — сделай именно так.
3. Дизайн — это не только экраны интерфейса, это любое касание с продуктом
Например, тексты ошибок, email, SMS, прерывания, валидация. Чаще всего их пишут разрабы или другие отделы. Разработчику проще самому доделать, чем тратить часы на коммуникацию и объяснение дизайнеру, где и что нужно доделать. Но это тоже часть опыта и тона продукта, который должен быть единым. Даже электронные письма лучше напишет продуктовый дизайнер с высокой компетенцией в текстах, чем маркетолог (с той же высокой компетенцией), который делает продающие рассылки.
Придумали метафору, которая отлично объясняет наш принцип построения лэйнов дизайна: «пользователь-задрот».
Ему всё интересно и всё нужно. Он кликает на все элементы, заполняет всё что можно и что нельзя, проходит по всем элементам интерфейса, ошибается во всём, в чём можно ошибиться. Это такой тестировщик, но визуальный — он увидит каждое состояние и ответвление от основного сценария.
Главное правило для дизайнера: если пользователь может что-то сделать в сценарии и с чем-то столкнуться — он это сделает.
Метафора «пользователь-задрот» помогает качественно собрать сценарий, который содержит все состояния всех элементов и все ответвления от основного успешного сценария. Кит при этом никто не отменял.
У UX-дизайнера 80% задачи занимает работа с данными — изучение текущих и построение структуры данных будущего сценария.
Входной информацией служат:
- Аналитические данные. Информация о количестве кликов, переходов, ошибок, об использовании тех или иных функций или услуг. У каждого продукта и портрета пользователя аналитика отличается, но приоритеты обычно не меняются. Опираемся на наработанную базу статистических данных.
- UX-исследования. За годы работы с финтех-компаниями провели сотни юзабилити-тестов и глубинных интервью. Знаем, как люди воспринимают тексты, какими терминами называют те или иные сущности, что важно на каждом шаге работы с каждой функциональностью. Всё это качественные инсайты, которых не получить из цифр.
- Продуктовые метрики и транзакционные показатели. Это те самые вводные от бизнеса. У нас есть бэкграунд продуктовой разработки в «Модульбанке», «Точке» и ВТБ, поэтому цифры по всем продуктам и под каждый тип пользователя нам тоже известны. Они помогают приоритизировать бэклог, а в каждой задаче найти компромисс между «хотелками» пользователя и возможностями бизнеса.
- Опыт конкурентов. Изучить, что и как у других — это святое. Полезно пройти опыт работы с сервисами конкурентов как пользователь, чтобы учесть их ошибки. Анализ того, как работают конкуренты — чуть ли не первое, что должен сделать дизайнер для погружения в сферу.
После сбора вводных приступаем к выполнению задачи. В проекте с «МТС Банком» было примерно 20 эпиков — больших задач, которые разбиваются на мелкие. Каждый эпик проходил через внутренний чеклист проектирования (а кроме него есть ещё чеклисты дизайна и работы с китом, текстов и типографики). Расскажем о девяти основных внутренних критериях проектирования.
1. Инфосхема или бизнес-процесс
Проектирование начинается с построения информационной схемы или бизнес-процесса по задаче. Дизайнер до 80% времени от задачи ещё до отрисовки сценариев тратит на изучение данных и продумывание информационной структуры. Исследования, цифры, аналитика, конкуренты, справочники, ресерч проблем в интернете — это всё информационное окружение дизайнера.
Информационная схема проектируется для более или менее статичных страниц, у которых не будет много ответвлений от основного процесса и негативных сценариев. Например, платёж физлицу по реквизитам.
Бизнес-процесс проектируется для user story с разветвлённым сценарием и множеством альтернативных и негативных путей. Например, этапы открытия расчётного счёта. Каждый — это дерево с сотней ветвей, а для пользователя всё выглядит стройно и логично.
Инфосхема или бизнес-процесс включает в себя:
Вход и выход: страницы и места других сценариев, с которых начинается и которыми заканчивается текущий сценарий.
- Наборы данных — конкретные элементы информации. Например, в выставлении счёта у блока данных «Товар или услуга» может быть количество, стоимость, название, единица измерения, сумма, НДС.
- Ограничения или условия к элементам данных. Это те действия и условия, которые накладываются на каждый блок данных. Например, выставленный счёт не могут подписать более пяти пользователей. Номер счёта присваивается системой по порядку.
- Логика — разветвление сценария в зависимости от выбора или условий.
Структура данных помогает продумать всё сразу — и что вводит пользователь, и что выдаёт система. После сдачи этого этапа в задаче не должно появляться новых полей и условий, которые приведут к переделыванию визуальной части.
2. Нулевые, минимальные и максимальные состояния
Понимание минимального и максимального состояния помогает избежать непродуманных моментов, а значит ошибок и проблем с вёрсткой. Наверное, все сталкивались в приложениях с моментами, когда текст вылезает за границы элемента — это значит, что кто-то здесь накосячил. Полезно задаваться вопросами для каждого элемента, списка элементов, страницы, продукта, например:
- Как будет выглядеть элемент и страница, если в поле суммы ввести один рубль (min)? А если ввести 10 цифр с копейками (max)? Вопрос помогает не забыть написать соответствующие тексты ошибок.
- Что увидит пользователь на главном экране мобильного банка, если название компании превышает 20 слов (max)? Если дизайнер не предусмотрел возможность сокращения, то пользователь увидит название на половине экрана. А что если у человека пять компаний и они начинаются с одних и тех же слов до сокращения? Стоит задуматься с точки зрения пользовательского опыта и об этом.
- Какой будет страница истории документов, если в ней до сих пор не создано ни одного документа (zero)? Если дизайнер не продумал это состояние списка, пользователь увидит пустую страницу. А мог бы, например, вовсе её не увидеть или прочитать текст о том, для чего эта страница и как сюда попадут документы.
3. Альтернативные и негативные сценарии
В любом сложном сервисе встречаются нелинейные сценарии. Например, в процессе открытия счёта для юрлиц и ИП нужны разные списки документов, а значит, и разные состояния страниц, немного отличающиеся сценарии и тексты. Карточка компании для юрлиц и ИП тоже будет отличаться набором полей и даже действиями над ними.
4. Продумываем все входы и выходы
При проектировании дизайнер должен продумать начальную и финальную точку сценария работы с каждой функцией. У сложных сервисов в одну и ту же задачу могут вести несколько путей, а от них будет изменяться первоначальное заполнение данных. Если заранее это не предусмотреть, то человеку придётся заново вносить какую-то информацию, которую он уже заполнил в предыдущем шаге. Мы должны продумать эти мостики, чтоб разработчики не забыли их реализовать.
Например, рассмотрим задачу выставления счёта. До экрана, где нужно заполнить данные плательщика, пользователь может дойти несколькими путями:
- с главной страницы из меню;
- из списка частых действий;
- из истории документов и счетов в случае, если повторяет или делает счета на основе уже созданных.
Итого: есть ещё минимум два входа и мостика, передающих первоначальные данные на экран заполнения информации о плательщике.
5. Ошибки, прерывания и ограничения
Дизайнер должен учесть ошибки, которые могут возникнуть у любого элемента по разным причинам. В каждом отдельном случае текст ошибки пишется под конкретную ситуацию, чтобы пользователь понял, что произошло и что делать:
- Можно не ввести номер расчётного счёта.
- Можно ввести его не полностью.
- Можно ошибиться цифрой.
- А можно ввести правильно, но где-то на стороне банка сломается алгоритм, который его проверяет.
Кроме того, в любой момент у пользователя может пропасть соединение с интернетом: что тогда произойдёт? Он просто потеряет настроенную выписку или заполненный платёж? Ему придётся вводить всю информацию заново? Это тоже нужно продумать.
Ограничения — это не ошибки, это условия, в которых существуют элементы интерфейса и за которые они выходить не могут:
- Выписку можно отправить только на пять почтовых адресов за раз.
- В выставленный счёт добавить только трёх подписывающих пользователей.
- В назначение платежа можно ввести только 210 символов, ещё сколько-то останется на НДС.
- У файлов есть форматы, размер и максимальное количество при загрузке в чат.
Иногда это те же самые максимальные состояния из пункта два, но необходимо предупредить пользователя о них. У систем, технических возможностей, бизнеса и регуляторов есть правила и ограничения, которые надо учитывать.
6. Типы пользователей
Учитываем то, как и что каждый тип пользователя видит в функциональности. И это сейчас не про пользовательские ролевые модели и разграничения прав доступа. Мы говорим обо всех возможных пользователях, включая внешних, которые видят или частично участвуют в бизнес-процессах по задаче, могут выступать второй стороной в бизнес-отношениях или использовать внешний результат задачи.
Например, при выставлении счёта:
- Есть создатель счёта(или получатель денег) — тот, кто создаёт и выставляет счёт, это может быть ваш бухгалтер.
- Есть отправитель — тот, кто отправляет или видит готовый счёт, чаще всего это сам гендир, но может быть и тот же самый бухгалтер. На этом шаге важно не пропустить наличие двух состояний одной задачи, которые видят разные по правам пользователи в личном кабинете. Готовый документ мы можем удобно структурировать и брендировать, тем самым ещё раз показать целостность сервиса в мелочах.
- А ещё плательщик — кому выставлен счёт. Он может увидеть его в бумажном виде, или в электронном, пройдя по ссылке, а может увидеть в личном кабинете, если обслуживается в том же банке. И мы снова не забыли и даже сгенерили некоторые состояния.
У каждого из типов пользователей свой сценарий взаимодействия с кусочком сервиса, поэтому про них нельзя забывать.
7. Пишем тексты по всем каналам
Экраны приложения или веб-версии — это всего лишь один, хоть и самый главный из каналов взаимодействия с сервисом. Дизайнер же проектирует взаимодействие со всеми каналами. Это могут быть:
- Внутренние — то, что находится непосредственно в интерфейсе приложения: история действий, события в ленте, снеки, пуши, уведомления в чате.
- Внешние — то, что «делает» продукт вовне и что пользователь получает от продукта через другие апы: SMS, email, мессенджеры.
- Офлайновый — когда клиент взаимодействует с сотрудником сервиса вживую или по телефону. Здесь мы можем спроектировать процесс и данные, проходящие через колл-центр, но скрипты, конечно, будут писать профи в этой сфере. Где-то можно отрисовать карточки с промокодами, которые будут выдаваться при встрече. В любом случае, если не забывать, что у сервиса есть офлайновая часть процесса, продуктовый дизайнер придумает возможности, которые зацепят человека и сделают восприятие ещё круче.
8. UX-тексты в интерфейсе
Их ещё называют microcopy. Текст — это самый главный язык общения с пользователем. У нас интерфейсные тексты пишут UX-дизайнеры, и мы тратим немало ресурсов, чтобы обучить этому.
Два главных требования к текстам — никаких бюрократизмов и ничего лишнего, только смысл действия, которое нужно совершить. И, конечно, писать языком пользователя, насколько это позволяет тон продукта.
В одном из финансовых продуктов к процессу открытия счёта тон позволял написать шуточный текст: «И не забудьте барсетку с документами на встречу». Дизайнеры очень любят, когда можно вставлять такие пасхалочки.
А вот пример перегруженного текста: «Комиссия составляет 230 ₽». Зачем слово «составляет»? «Комиссия — 230 ₽». И короче, и смысл не потерян.
Подробно о чеклистах по текстам в интерфейсе мы уже писали статью.
9. Спецификация к каждому экрану
Наш дизайн разработчики называют визуальным ТЗ. Чем подробнее описание того, как и что работает, тем ниже вероятность ошибок и выбора лёгких путей.
Важно помнить: очевидное для дизайнера может быть неочевидным для других. В работе лучше ориентироваться на ленивого исполнителя, которому надо всё разжевать. Если что-то подробно не описали, а разработчики сделали как поняли или как привыкли — значит, наш косяк.
Что описываем в комментариях к сценариям:
- Самое важное: как работает элемент или набор элементов, какие к нему есть ограничения и как система помогает пользователю. То, что нельзя показать визуально.
- Как пользователь взаимодействует с функцией. Опять же, если из сценария визуально этого не показать.
- Иногда нужно обоснование, почему мы сделали именно так — с точки зрения пользовательского опыта.
- Откуда берутся данные, как называется справочник или алгоритм проверки данных.
Мы проектируем финсервисы и банки, которые используют одни и те же наборы данных. Знание таких вещей сильно упрощает жизнь разработке, которая решает какие-то задачи впервые. Или классическим банкам, которые меняют старые системы на новые.
Почему нам это нравится
Наши критерии качества завышены, потому что основаны на западном подходе и понятии «дизайна», которое значит не просто сделать красиво в десятке уникальных экранов. А значит, что нужно продумать и спроектировать все варианты развития событий и написать всю коммуникацию и ToV. У нас этих экранов в 3–15 раз больше.
Благодаря такому подходу у пользователя нет ощущения разрыва опыта: когда в одном месте с ним поговорили дружелюбно и на его языке, а в другом, куда руки у дизайн-команды не дошли, уже технически или бюрократически.
К тому же с детальным подходом разработка задаёт меньше вопросов, быстрее работает и чётко реализовывает задуманное, а мы не тратим ресурс на доделки и тоже не тормозим разработку.
Это кейс «МТС Банка» на Behance — можете нас поддержать и подписаться, скоро выложим ещё два интересных объёмных проекта.
«UX-исследования. За годы работы с финтех-компаниями провели сотни юзабилити-тестов и глубинных интервью. Знаем, как люди воспринимают тексты, какими терминами называют те или иные сущности, что важно на каждом шаге работы с каждой функциональностью. Всё это — качественные инсайты, которых не получить из цифр»
Сперва я прочитал этот коммерческий текст состоящий из воды. Потом зашел на биханс, для того чтобы проникнуться вашими невероятными инсайтами из глубинных интервью. Скажите пожалуйста, через какой инсайт вы пришли к красной кнопке «Send», рядом с серой кнопкой «Delete», сколько человек в команде были задействованы для этого решения и были ли специальные пояснения, для разработчиков, по этому поводу в макете фигмы?
Правды ради, это проблема красного цвета бренда, из-за чего все становится куда тяжелее.
Еще и на английском. Батюшки. Интерфейс так интерфейс.
Ну для справедливости стоит заметить, они пишут что использовали готовый UI-Kit МТС. Они его не разрабатывали, но вмешаться в него конечно стоило, потому что это видимо тот случай когда фирменный стиль убивает привычные паттерны юзабилити.
Но больше вопросов вызывают подача информации.
Обновился ещё и дизайн приложения, UIX настолько so not frendly, что им пришлось писать отдельный мануал "что где искать"... 😆
А на деле обычный интерфейсОн и должен быть обычным. Даже в "обычных" интерфейсах часто очень много проблем, нет не визуальных а именно с функционалом.
Применение здравогоОни просто рассказывают о своей работе и она во многом и состоит из этого применения этого здравого смысла. И хорошо что рассказывают потому что после недавних статьи здесь на тему дизайна, у многих (совершенно справедливо) складывается ощущение, что UX не нужен. Причем в комментах к статье о каком нибудь (почти любом) продукте, те же люди жалуются обычно как раз на непродуманный UX (типа неудобно сделать то или другое, у конкурента это делается в два клика и т.п).
Сам материал тоже можно обсудить, но уже хорошо, что более подробно рассказали о работе. Хотя понятно, что здесь сжато и на поверхности гладко, а реальном процессе намного сложнее.
inb4: я у них работаю и оправдываю и оправдываю хипстеров от дизайна которые занимаются "просто здравым смыслом" вместо рисования логотипов и визуальных шедевров
Преподноситься как 9 чудо света. А на деле обычный интерфейс. Вот были время...2000 год и интерфейс диабло 2. А тут 2020.