Кратчайший путь к сердцу пользователя

Юзабилити из неотъемлемой части работы над большинством проектов, превратилось в самоцель. Сомневаемся, что это правильно и рассуждаем об идеальном интерфейсе.

Юзабилити стало самодостаточной сущностью, единственным методом постановки задачи и управления процессом разработки UI. Что не всегда верно: приправа, даже такая обязательная, как соль, не должна превращаться в блюдо. А юзабилити — это все же приправа. А если быть более точными — это качественная оценка удачности UI.

Сегодня порассуждаем на тему идеального интерфейса на примере банковского приложения. Известно, что есть элементы UI, «танцующие» от счета клиента (сначала выбираем счет или карту, а потом операции с ними), а есть элементы, которые начинаются действием (перевести деньги), а предмет выбирается на втором шаге. Эти два кейса легко обобщить и применить ко всем UI, не только банковским: бывает отглагольная, а бывает объектная навигация, от существительного.

Какую выбрать? Давайте сделаем обе, и пользователь выберет ту, которая ему удобна! Но опытный UI/UX проектировщик сразу скажет, что это не решение, а уход от него. Пространство пользовательского интерфейса ограничено, невозможно все варианты навигации сделать равнодоступными: что-то будет ближе, что-то дальше.

Выбрать поможет его величество сценарий. Use case. Модель поведения пользователя. К сожалению, не все разработчики готовы залезать в чужую шкуру и подходят к задаче с фразой «наши пользователи слишком разные». Но так ли это?

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

Попробуем пройти чуть дальше: принести деньги в банк = пополнить счет. Мотивация действия глагольная, но выбор счета является неизбежным первым шагом. В то же время пользователь нуждается в том, чтобы ему подсказали, какие именно счета требуют пополнения. Реализация этого механизма заодно решит часть задачи для группы сценариев «получение информации». Вопрос «сколько я должен банку?» при нынешнем проникновении кредитных инструментов — один из ключевых, поэтому его стоит вынести на видное место.

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

• рекуррентные (оплата мобильного);
• частые, но нецикличные (оплата парковки);
• событийные (оплата штрафа);
• казуальные (оплатить замену прав или паспорта).

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

Третий вид сценариев — информационный. Строго говоря, это неправда. У человека не бывает чистой незамутненной потребности в информации. Ну не бывает нужно человеку просто вот так, ни для чего, узнать, где находится отделение банка или каков процент по срочному вкладу. Ему что-то другое нужно, и информация — только шаг на пути к этой цели. Хорошо бы понимать и удовлетворять именно цель.

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

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

Пополнить баланс (вы должны 52378 р.)

Оплатить/перевести деньги (доступно 120567 р.)

• За интернет 500р.
• За телефон 1000р.
• Штраф ГИБДД 250р.

Другие операции

• Внести наличные

Информация

• Виды пластиковых карт
• Депозиты
• Инвестиционные инструменты

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

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