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

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

Александр Ревяко
Арт-директор Студия Борового

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

В этой статье мы не станем называть компании. Это сделано преднамеренно. Если надеетесь прочесть критический обзор, вы не там ищете. Но если вы хотите узнать, как построить функционирующий мобильный банкинг — продолжайте читать.

Давайте начнем с базового строительного блока: выбора счета. Это может быть осуществлено двумя основными способами: с помощью picker’а (называемого spinner’ом на Android) или с помощью отдельной страницы выбора (также называемой «table view»).

Picker/Spinner

Перед вами распространенный шаблон для переводов-самому-себе (те перевод средств между двумя вашими собственными счетами, например расчетным и сберегательным):

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

Александр Ревяко
Арт-директор Студия Борового

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

Скорее всего автор просто поленился подготовить хороший тестовый перечень (рыбу).
Если же я ошибаюсь и это реальная ситуация в банковских системах США, то это полный кошмар: держать в голове и понимать разницу между A, B, C, D выбирая нужный счет. Никаким повышением юзабилити форм и макетов здесь не обойтись: нужно комплексно пересматривать взаимодействие, или хотя бы дать пользователям возможность задавать удобные имена своим счетам.

Как это работает на мобильных устройствах? Не очень хорошо. Слепое копирование методов полноформатной Сети — довольно примитивный подход, очень часто оказывающийся губительным и выливающийся в негативный опыт. И вот почему. Вместо 20-30-и пунктов, демонстрируемых полностью в выпадающем меню, стандартное окно выбора iPhone вмещает лишь 3 пункта видимых полностью и еще 2 — частично:

.

На Android 4.0 (самой свежей рабочей версии, названной Ice Cream Sandwich) ситуация несколько лучше. Вместо пикера, пользователи Android OS используют spinner, вмещающий целых 8 пунктов. К сожалению, его возможности форматирования весьма ограничены, в результате его текстовая область на 20% уже экранной, так как спиннер не использует полную ширину дисплея устройства. Это приводит к сминанию текста и цифр в две-три строчки:

Интересно, что подобный шаблон используют некоторые онлайн-банки для вывода списка счетов. Впрочем, по необходимости (и дабы избежать путаницы от сбитого в кучу текста на старых и более дешевых устройствах с меньшими экранами) они используют короткие коды для обозначения счетов, такие как CHK, SAV и CC1. Подобные сокращения работают довольно неплохо для текстового банкинга, где царят лаконичные формулировки («C U L8R»). Однако, шифрограммы весьма далеки от понятия высококлассных элементов пользовательского интерфейса, которые клиенты ожидают увидеть на экранах своих смартфонов. Они насмотрелись на текст в «простых» и BlackBerry телефонах, DOS’е и программах сторонних разработчиков. Держать в голове кодовые обозначения собственных счетов — это совсем не то, чего желает человек, играющий в Angry Birds и совершающий покупки на Amazon и Gilt. Для создания лучшего механизма нам потребуется совсем другой шаблон дизайна: отдельная страница выбора.

Отдельная страница выбора

Более изящным и удобным, нежели picker или spinner, мобильным шаблоном для представления списка аккаунтов является отдельная страница выбора (также именуемая «table view»). На ней могут быть свободно представлены 10 и более счетов. Как сказано в руководстве для iOS разработчиков от Apple, «Всегда используйте table view вместо picker’а, если вам необходимо представить действительно большой список значений, так как первый предоставляет гораздо больше пространства по высоте, что ускоряет просмотр».

Вот как это выглядит на эскизе, сделанном по гибкой методике с использованием стикеров (см. «Дополнительно» в конце этой статьи):

Преимущества от использования отдельной страницы выбора, по сравнению с picker’ом или snipper’ом, заключаются в следующем:

• Любой шрифт и оформление по вашему вкусу;
• Работа на любой платформе;
• Использует полную ширину страницы;
• Текст адаптируется по ширине, а значит, страница одинаково комфортно выглядит на различных устройствах;
• Демонстрирует 10 или более пунктов одновременно, между ними легко перемещаться.

И самое главное, на отдельной странице легко можно разместить полное наименование счета и его баланс.

Александр Ревяко
Арт-директор Студия Борового

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

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

Форма с отдельными страницами выбора

Идея этого шаблона проста: скопировать стандартную полноформатную веб-форму, но использовать отдельные страницы, вместо picker’ов или spinner’ов.

При использовании подобного шаблона, наши внутренние переводы будут выглядеть следующим образом:

1. Пустая форма;
2. Отдельная страница для выбора исходящего счета;
3. Возврат к форме (пункт «Со счета» теперь заполнен);
4. Отдельная страница для выбора входящего счета;
5. Возврат к форме (пункты «Со счета» и «На счет» теперь заполнены);
6. Заполнение окон «Сумма» и остальных, активация кнопки «Далее»;
7. Подтверждение введенных данных.

Вот как выглядит процесс на эскизах, выполненных с помощью техники стикеров:

Хотя подобный шаблон работает, он растягивает процесс на семь страниц. Можно ли его сократить? Конечно же. Одним из блестящих мобильных решений является отдельный пошаговый процесс.

Александр Ревяко
Арт-директор Студия Борового

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

Отдельный пошаговый процесс

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

При ее применении, наш внутренний перевод будет выглядеть вот так:

1. Отдельная страница выбора исходящего счета;
2. Отдельная страница выбора входящего счета;
3. Отдельная страница с цифровой клавиатурой для ввода суммы;
4. Страница подтверждения данных.

А вот как выглядит процесс с использованием методики стикеров:

Этот шаблон отлично работает с короткими формами и служит хорошим примером мобильно-ориентированного метода проектирования Люка Вроблевски. Весь процесс проходит всего в четыре шага. Заметьте, что страница подтверждения (позволяющая клиенту перепроверить все данные, прежде чем нажать на кнопку «Transfer») рекомендуется в этом шаблоне как обязательная. Отметьте также, что использование «хлебных крошек» как шаблона, позволяет клиенту знать, на каком из этапов процесса он находится, и сколько еще осталось. Этот элемент отлично вписывается в общий макет. Мы закончили на этом? Можем ли мы использовать выделенный пошаговый процесс для каждой операции на нашем мобильном банковском сайте? Не нужно спешить.

В вопросах мобильных устройств ничто не дается даром. Это относится и к отделенному пошаговому процессу, который совершенно не работает в длинных формах. Основной идеей является наличие отдельной страницы выбора для каждого пункта формы. Но если она включает в себя пять и более элементов, процесс начинает отнимать слишком много времени. Еще одним недостатком подобного шаблона является невозможность отделить необязательные пункты (такие как «Комментарии») от обязательных (таких как «Сумма»). В этом шаблоне каждый элемент получает персональную выделенную страницу с соответствующей клавиатурой и, скорее всего, будет восприниматься как «обязательный». Даже если клиент понимает, что ему не нужно ничего вводить, каждый элемент требует от него как минимум взглянуть на страницу и нажать кнопку «Далее».

Александр Ревяко
Арт-директор Студия Борового

Еще одним недостатком этого решения является необходимость проходить с самого начала все шаги в случае если на одном из экранов была допущена неточность. Это очень неудобно. Теоретически этого можно избежать и расширить данный процесс до большего числа шагов (5-7) используя динамические хлебные крошки. В противном случае максимальный резерв шаблона всего 2-3 шага.

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

Пошаговый процесс с формой

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

Использование подобного макета для внутреннего переводы будет выглядеть следующим образом:

1. Отдельная страница для поля «Со счета»;
2. Отдельная страница для поля «На счет»;
3. Переход к форме (с уже заполненными двумя первыми полями);
4. Введение суммы и заполнение остальных полей, переход по кнопке «Далее».

Вот эскиз, сделанный по гибкой методике:

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

Редактирование также много проще, чем в любом другом шаблоне. Вместо того, чтобы вновь проходить ведь процесс от начала до конца, клиенту нужно отредактировать лишь поля, требующие этого. К примеру, для корректировки входящего счета, клиент активирует соответствующее поле и перемещается непосредственно на выделенную страницу выбора входящего счета, после выбора которой тут же возвращается назад без необходимости проходить весь цикл “From” account → “To” account → Amount еще раз.

Александр Ревяко
Арт-директор Студия Борового

Это хорошее решение. Недостатки его в следующем:

1. Не виден текущий статус процесса на первых обязательных экранах.
2. Ограниченность применения паттерна. При чередовании состояний выбора из списка и полей ввода последовательность действий становиться запутанной и неочевидной. К примеру, если выбор счета идет после указания суммы.

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

Мобильность: мыслите иначе

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

Александр Ревяко
Арт-директор Студия Борового

Задача рассмотренная в статье сводиться исключительно к улучшению юзабилити: процесс перевода между счетами рассматривается в отрыве от окружающих мясных мешков житейских бурь (называемых контекстом взаимодействия в окружении) в котором пользователь вынужден использовать «эту фигню отвлекающую от игры в Энгри Бёрдз» (иногда называемую интерфейсом интернет-банка). Фундаментальные проблемы взаимодействия в этом решении не затронуты. Ключевая проблема интерфейсов была и остается в том, что они становятся проще управляемыми, но не ближе человеческими. Обладая чуть ли не всеми знаниями о пользователе, всей его истории покупок, платежей, интерфейс ни на шаг не становятся ближе к человеку. Почему система зная, что я регулярно откладываю часть денег на два депозита: на отдых и на черный день не дает мне сделать это в одно действие или не может это делать сама? Почему я должен проходить пусть даже очень удобные, но муторные нажатия пальцами, когда мне нужна одна кнопка: «Отложить 100 рублей на черный день»?

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

Создание мобильного дизайна требует иного мышления. Помните, что в мобильных устройствах каждое поле формы требует как минимум одного дополнительного нажатия для вывода клавиатуры, picker’a, отделенной страницы или другого элемента данных. Вместо вертикального потока, направляющего пользователя к следующему полю, используйте горизонтальное расположение. Ищите этапы и операции, от которых можно избавиться. Когда только возможно минимизируйте число страниц, через которые должен пройти пользователь для завершения процесса, это поможет снизить число допускаемых им ошибок и улучшит впечатления клиента. И последнее, но не менее важное, — проведите пользовательское тестирование своего мобильного проекта и постарайтесь проверить все, что можно, и как можно раньше.

Дополнительно

• «Простое руководство по реактивной хирургии», Стив Краг (New Riders: New York, 2010)
• «Как заставить гибкую методологию работать в вашем мобильном дизайн-проекте», (требуется регистрация) Грег Нудлман, видео с виртуального семинара по основам мобильного дизайна, DesignCaffeine
• «Полное руководство по созданию мобильных NFC приложений, за которые вам не будет стыдно», Грег Нудлман, DesignCaffeine
• "Мобильность прежде всего",Люк Вроблески

Оригинал: http://mobile.smashingmagazine.com/2012/07/05/essential-design-patterns-mobile-banking/