Есть в Петербурге «главная (если не единственная) платная дорога города» — ЗСД, Западный Скоростной Диаметр . Построено красиво, (временами) позволяет сэкономить довольно много времени.

Но, как и обычно, devil is in the details. И да, часть вопросов находится в той зоне, где для пользователя надо сделать всё возможное — я говорю про интерфейсы оплаты.

Подключившись, человек не сталкивается с этим аспектом работы ЗСД достаточно долго: купив транспондер вы сразу кладете на счет 1000 рублей, чего при моей частоте использования хватило на 3 месяца. Тем более внезапным является момент, когда деньги заканчиваются…

Меня новость об окончании средств застала в выделенном ряду для проезда с транспондером. Денег на счету ноль, кассы, чтобы заплатить наличностью, в этих рядах нет. «Выделенный ряд» в данном случае еще обозначает и то, что просто перестроиться в соседний ряд с кассой не получится – между рядами идет разделитель… Вот и начал я свою эпопею с оплатой с печальной езды задом…

Итак, первая беда: нет внятного уведомления о том, что деньги на счете скоро заканчиваются (или уже закончились). Да, на маленьком табло высвечивается не только сумма к оплате, но и предупреждение, но, поверьте, водитель в этот момент смотрит на поднимающийся шлагбаум. Для того, чтобы отправить уведомление с нормальной инструкцией есть всё: номер телефона, личный кабинет, email…

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

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

Кажется нет, кажется не могу: номер надо вводить не целиком.

Список платежных методов тоже вызывает вопросы. Совершенно не понятно, где оплата Webmoney и Qiwi, и почему в списке есть МТС и Билайн, но при этом нет Мегафона (напомню, дело происходит в Петербурге).

Всё же попробуем заплатить банковской картой:

Форма вызывает вопросы. Номер карты не бьется по группам, валидация в момент ввода не осуществляется, комментарии полей вынесены в сторону, не связаны с самими полями и почему-то находятся в блоке «Рекомендации». Сама форма слабо приспособлена для использования на мобильных устройствах (изменений никаких не происходит, правый край экрана просто «обрубается»). Отметим, что ни на этом экране, ни на предыдущем нельзя подписаться на автоматическое пополнение счета. И всё же попробуем нажать кнопку «ОК» (что «ОК»? оплатить?)

Выполняется что? Переход куда?!! Напомню, в 99.9% случаев этот комментарий читает пользователь, который ничего не знает о внутренней механике интернет платежей, для которого слово «эквайринг» не значит ровно ничего.

Коротко:

• Отсутствует система внятных уведомлений о скором окончании средств на балансе
• Неконсистенность данных о балансе клиента, возможность уйти в минус (на самом деле, минус достаточно спорный, слепое исправление этого недочета может быть финансово и технологически неоправданным)
• Неочевидное расположение ссылки на оплату в Личном Кабинете
• Сложность нахождение основного идентификатора, используемого при оплате – номера транспондера
• Очень странный выбор идентификатора назначения платежа (часть номера транспондера), отсутствие предзаполнения для авторизованных пользователей
• Отсутствие нескольких популярных платежных методова (Webmoney, QIWI, мобильные платежи Мегафон)

• Отсутствие подписки на автосписание средств (с карты или электронного кошелька)
• Плохо разработанная форма оплаты банковскими картами
• Невнятные комментарии, зачастую просто пугающие пользователя
• Отсутствие адаптации под мобильные устройства

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

Совсем общие принципы:

1. Мы не пугаем пользователя. Ему в каждый момент должно быть понятно, что происходит и зачем.
2. Достичь результата, т.е. заплатить должно быть максимально просто. Мы не должны спрашивать у пользователя то, что можем узнать сами.
3. Мы делаем вещи, затрагивающие платежи, т.е. мы должны заботиться о безопасности и соблюдении формальных требований (законодательство, требования МПС и т.д.).

А теперь ближе к делу:

1. Общее
   1. Только https, только PCI DSS
   2. Поддерживаем все типы карт. Не забываем, что есть карты с длинной номера отличной от 16.
   3. На странице есть все необходимые по стандартам элементы (логотипы Visa/MasterCard, если требуется – оферта с условиями проведения платежа)
   4. На странице есть информация о заказе. Сразу понятно, что оплачивает человек.
   5. Не спрашиваем то, что и так можем узнать (например, тип карты мы можем определять по БИНу)
   6. Страница корректно ведет себя в iframe и в полноэкранном режиме
   7. Форма нормально работает на мобильных.
      • “Складывается” под размер экрана
      • fat-finger-friendly
      • Клавиатуру показываем по типу содержимого. Например, для номера карты – цифровая клавиатура.
   8. Понятно, как выводить доп. поля, иногда необходимые для проведения платежа (доп. поля для фрод-мониторинга, хайриск и т.д.)
   9. Понятно, как делать рекурренты
   10. Форма в полном размере максимально повторяет внешний вид карты (вкусовщина, по хорошему надо ставить эксперименты)
   11. CVC корректно/понятно подписан
   12. Есть контактные данные саппорта
2. Валидация
   1. expiry date не в прошлом
   2. Номер карты проходит валидацию по Luhn (https://ru.wikipedia.org/wiki/Алгоритм_Луна)
   3. Пропускаются короткие имена/фамилии (1-2 буквы) и составные фамилии (содержат дефис)
3. Поведение
   1. Номер карты можно скопировать и вставить в форму. Более того, форма должна быть дружественна к приложениям, сохраняющим и заполняющим данные карты (1password, iCloud keychain и т.д.)
   2. Цифры в номере карты форматируются по группам
   3. Между полями можно переходить по табуляции. Последовательность перехода соответствует визуальному расположению полей на форме.
   4. Вбиваемая кирилица приводится к латинице. Все буквы приводятся к верхнему регистру
4. Доп. функционал (специфично для интеграторов, но… мало ли)
   1. Кастомизируется под мерчанта – фоны-логотипы
   2. Максимально много информации для предзаполнения можно передать со стороны мерчанта
   3. Понятно, как делать рекурренты – https://www.chargify.com/, https://recurly.com/

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

• https://jessepollak.github.io/card/
• https://creditcardjs.com/
• https://kenkeiter.com/2013/07/21/redesigning-credit-card-inputs/ — https://news.layervault.com/stories/6355-beautifully-designed-credit-card-form
• https://baymard.com/blog/visually-reinforce-sensitive-fields
• https://gigliwood.com/blog/designing-the-perfect-credi.html
• https://zoliang.com/post/37178942744/making-beautiful-forms-square-and-recurly
• https://www.lukew.com/ff/entry.asp?1667
• https://bradfrost.com/blog/post/single-field-credit-card-input-pattern/
• https://designmodo.com/ux-credit-card/
• https://designmodo.com/ux-credit-card-payment-form/
• https://dribbble.com/shots/797913-Credit-Card-input

Последнее время я стал гораздо больше ездить на машине и, как следствие, плотнее общаться с разнообразными приложениями для автомобилистов. Прежде всего – навигаторами (CityGuide & Яндекс.Навигатор) и Dash’ем – своеобразным фитнесс-трекером для машины. И чем больше я еду, тем больше у меня ощущение, что функционал того же Dash просто обязан мигрировать в навигаторы, да и без этого у них должно появиться достаточно много новых функций.

Купите время…

Навигаторы здесь и сейчас никак не учитывают “платность” дороги. Максимум вариантов выбора – кратчайший или самый быстрый маршрут. Платные дороги можно только отключить в принципе, осмысленность проезда по ним никак не учитывается. Тот же Ситигид регулярно тащит на ЗСД ради того, чтобы сэкономить 2-3 минуты. И в этот момент появляется мысль: у навигатора есть возможность предоставлять уникальный in-app purchase – время… Т.е. можно честно предлагать человеку «купить» время, скажем, заплатив 40 рублей за 20 сэкономленных на маршруте минут. Либо же делать проще и менее явно для пользователя: просто считать дельту по времени между двумя вариантами маршрута и выбирать маршрут, включающий платную дорогу, если он оказывается быстрее, скажем, на 5-10%. Понятно, что можно давать пользователю задавать «стоимость» своего времени, но… сколько пользователей реально воспользуются такими настройками? Да, в идеале бы еще сделать и возможность оплаты проезда с телефона, но это уже большие вопросы с тем, чтобы договориться.

Интеграция с OBD

Тут для начала надо коротко рассказать, что такое Dash, Automatic и прочие подобные программы. Базовый принцип достаточно просто: в сервисный порт автомобиля ставится модуль стоимостью примерно от $5-10, который может отдавать по Bluetooth диагностическую информацию (скорость, расход бензина, температуру двигателя, количество бензина в баке и т.д.) на телефон. Приложение получается возможность отслеживать всё, что происходит во время движения – как вы разгоняетесь и тормозите, какой дорогой едете, в каком состоянии мотор…

Другой вопрос, что тот же Dash ничего не знает, да и не может знать о состоянии маршрута – пробка, гололед… Наличие этой же информации в навигаторе позволило бы значительно увеличить удобство работы с ним. Заканчивается бензин? Ок, предложим без лишних напоминаний заехать на ближайшую АЗС справа от маршрута, или же перепроложим маршрут так, чтобы заехать на любимую заправку. То же с ремонтом и сервисом…

На самом деле, не понятно, почему бы навигаторам не пойти дальше и не предлагать делать остановки в кафе с приличным рейтингом?.. Я помню, как ездил, скажем Петербург-Москва или Петербург-Хельсинки, и такие подсказки от навигатора мне бы сильно помогли.

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

Действующие лица:

• Важный-важный менеджер по продажам, радеющий за дело и kpi
• Начальник склада, тупая бюрократическая гнида и формалист
• Самый важный менеджер по продажам, человек возвышенный и стремящийся в деталях разобраться в происходящем
• Директор автосалона
• Массовка (продажники, складские, девочки на ресепшене)

Акт 1

Давным-давно в одной далекой галактике… Как-то раз один важный-важный менеджер по продажам большого автосалона пришел на склад.

— Эй, ребята, я тут продал клиенту машину. Вон ту.

— Ну… здорово, поздравляем, можно забирать.

На следующий день на склад (почему на склад? ну… у продажника надо спросить) позвонил покупатель:

— А крыло к машине уже приделано?

— ?!! Какое крыло?

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

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

— Да, разузнайте, но мне очень срочно, и мне уже обещали.

читать дальше »