Сейчас у меня есть клиент (я об этом уже упоминал), который хочет вывести в Украину новую бонусную систему. Потихоньку она перерастает в платежную. Планы чрезмерно амбициозные, а делается все на коленке. Деньги у клиента большие, но человек старой закалки и привык все делать на лету. Особенно это касается IT.
Как следствие, при тестировании процесса активизации карточки потенциальным владельцем возникла куча проблем. Кратко — 3 шага с возвратом на один шаг, 2 шага для дальнейшего входа в систему, неудобный ввод неудобного пароля. В итоге прогнозируемая эффективность — максимум 10%. Это все следствие отсутствия проектирования посетительского поведения.
Меня подрядили описать «логику того, как работает окошко ввода номера карточки и зачисления бонусов с посетителем». То, как в данный момент работает вся структура (системой боюсь назвать).
Я же окрестил это «проектированием посетительского поведения», разбил на три части: посетитель без карточки+оформление оператором карточки, посетитель зачисляет бонусы на карточку, посетитель расплачивается карточкой.
По идее, все это должно было быть в одном документе, т.к. все это описание процесса одного скрипта. Но объединение логик стало бы очень громоздким и неудобным для изучения, особенно — далеким от IT людям.
В начале работы, «главный» всего этого предприятия после моих объяснений и цены выдал: «да я это за полчаса на коленке с каким-нибудь владельцем магазина за пиво нарисую». Обидело, честно. В итоге процесс, который занимает у посетителя не более одной минуты, был описан за 4 дня полностью отведенных под эту работу.
Конечный вариант и мои рекомендации показали не только узкие места, а факт, что скриптик, работающий на стороне магазина, надо переделывать полностью, и в том виде, в котором он сейчас работает, есть все предпосылки для махинаций, а так же ошибок при зачислении бонусов на счет.
Для себя я поставил задачу сделать процесс работы с карточкой в интерфейсе интернет-магазина максимально простым, защищенным от ошибок и вредительства, четко описать поведение операторов на местах. И ОБЯЗАТЕЛЬНО таким, чтобы в случае каких-либо проблем посетитель мог оперативно, без истерик решить их. Ведь проблемы напрямую влияют на конверсию в магазине, если процесс взаимодействия с окном для ввода карты будет затруднителен — это незамедлительно скажется на конверсии. И клубная система, вообще, будет терять участников.
Получилось, что в спроектированном поведении (далее кратко буду называть «логикой»), есть 3 группы, так называемых, заинтересованных лиц. То есть субъекты, которые принимают участие в процессе. Оператор, посетитель и скриптик. Последний тоже производит в логике важные действия, поэтому я и его зачислил в группы заинтересованных лиц.
Описывать весь процесс не имеет смысла. Схему, по которой составлял логику, вы можете посмотреть по этой ссылке, здесь только самый простой из трех сценариев поведения, но структурно понятно, как делалось остальное.
Я опишу ключевые моменты, которые были раскрыты благодаря проектированию процесса.
В процессе проектирования стало ясно, что помимо самого поля для ввода номера карточки, в рабочий процесс необходимо внести ряд элементов:
В связи с этим я предложил ввести несложный pop-up, который бы не блокировался браузерами и спец. программками, с затемнением основного окна. Никаких всплывающих новых окон, новых вкладок и тд. Нельзя забывать о том, что процесс оформления заказа должен быть линейным, то есть посетитель плавно переходил из одного окна в другое без каких-либо существенных изменений процесса.
Плюс такая мелочь, как предустановленные повторяющиеся цифры карты: 9800000000000 (далее идет изменяющиеся трехзначное число).
Этот вопрос можно решить двумя способами. Привязка карты к аккаунту посетителя в магазине. Работает только, если вы раздаете карты своим клиентам. Один раз привязали (либо оператор, либо сам посетитель) и далее забыли о повторяющейся валидации, что сильно упростит жизнь клиентам конкретного магазина. Но, это уже разборки самого магазина, соответственно его деньги на доработку функционала под привязку карты, за это система бонусных карт платить не будет.
Второй вариант — повторяющаяся валидация. Каждый раз посетитель производит одну и ту же последовательность, если планирует использовать карту.
Первый способ не исключает второй, т.к. клубная бонусная программа подразумевает, что есть и другие владельцы карточек, которые не являются вашими клиентами.
Валидация будет происходить через смс, посетителю надо будет ввести код из смски. Казалось бы, что все просто, «сто раз так делали». На самом деле существует несколько моментов, которые необходимо продумать:
Когда я сдавал работу представителю заказчика, у нас завязался спор по поводу необходимости валидации владельца карты при условии, что клиент просто хочет зачислить деньги на бонусный счет. Казалось бы, зачем тут валидация? Никто же не захочет зачислять деньги на чужой счет.
Я настаивал на валидации, моими аргументами были:
Усложнение процесса налицо, причем появляется куча условий, которые естественно будут ложиться в скрипт и в проектирование посетительского поведения.
Мне понадобился целый час, чтобы убедить представителя клиента в моей правоте.
Система устроена так, что после валидации владельца карты, скрипт получает остаток бонусов по карточному счету и другие данные. Соответственно в память скрипта на стороне магазина заносится информация о доступной сумме бонусов.
Злоумышленник может преднамеренно попробовать обмануть магазин в этот момент, к примеру потратив часть бонусов на пополнение мобильного телефона, поэтому я предусмотрел повторный запрос по балансу, после нажатия кнопки «оплатить».
Нынешняя реальность интернет-магазинов такова, что заказанного посетителем товара может не оказаться в наличии. Соответственно подобные случаи необходимо предусмотреть в логике программулины, которая отправляет данные на сервак системы.
Я рекомендовал функцию резервирования средств на счету посетителя, в случаях, если он оплачивает бонусными средствами заказ. Деньги должны уходить со счета клиента, и попадать в некий буфер, дожидаясь подтверждения со стороны оператора, который исходя из ситуации, либо отменяет проведение операции, либо подтверждает.
Естественно предусмотрена полная замена заказа, с возможностью оператором в телефонном режиме (с клиентов на проводе) изъять бонусные средства со счета клиента.
Эта функция пришла в самый последний момент. Дело в том, что ошибаются не только посетители, но и операторы. Ни для кого не секрет, что в запаре ошибиться или ввести что-то неверно проще простого. Я рекомендовал в функционале скриптика добавить для админки заказа такой checkbox: «я подтверждаю, что повторил(а) посетителю данные карточки». Забавен тот факт, что в этом случае юзабилити checkbox должен быть ужасен — только при клике на сам квадратик. Только поставив галочку, оператор сможет провести дальнейшие изменения заказа.
Эта функция маленькая мелочь, но спасет много нервов операторам и владельцам магазинов из-за разбирательств и возвратов средств.
Некоторые из вышеперечисленных функций могут кому-то показаться банальными или пустяковыми. Хочу заметить лишь одно, именно такие пустяковые банальности и упускаются из виду, во время первого запуска нового сервиса или даже целого интернет-магазина. Скорее всего, я не смог предусмотреть всех проблем, которые возникнут в этом процессе, но, по крайней мере, сократил их количество.
Я осознаю, что в моих терминах и подходе есть доля ламерства, но считаю, что в целом это не сильно повлияло на результат.
Для владельцев интернет-магазинов накидал чек-лист некоторых моментов, про которые забывают при подключении всякой сторонних скриптов, или заключая договор с какой-нибудь клубной системой:
Как следствие, при тестировании процесса активизации карточки потенциальным владельцем возникла куча проблем. Кратко — 3 шага с возвратом на один шаг, 2 шага для дальнейшего входа в систему, неудобный ввод неудобного пароля. В итоге прогнозируемая эффективность — максимум 10%. Это все следствие отсутствия проектирования посетительского поведения.
Меня подрядили описать «логику того, как работает окошко ввода номера карточки и зачисления бонусов с посетителем». То, как в данный момент работает вся структура (системой боюсь назвать).
Я же окрестил это «проектированием посетительского поведения», разбил на три части: посетитель без карточки+оформление оператором карточки, посетитель зачисляет бонусы на карточку, посетитель расплачивается карточкой.
По идее, все это должно было быть в одном документе, т.к. все это описание процесса одного скрипта. Но объединение логик стало бы очень громоздким и неудобным для изучения, особенно — далеким от IT людям.
В начале работы, «главный» всего этого предприятия после моих объяснений и цены выдал: «да я это за полчаса на коленке с каким-нибудь владельцем магазина за пиво нарисую». Обидело, честно. В итоге процесс, который занимает у посетителя не более одной минуты, был описан за 4 дня полностью отведенных под эту работу.
Конечный вариант и мои рекомендации показали не только узкие места, а факт, что скриптик, работающий на стороне магазина, надо переделывать полностью, и в том виде, в котором он сейчас работает, есть все предпосылки для махинаций, а так же ошибок при зачислении бонусов на счет.
Для себя я поставил задачу сделать процесс работы с карточкой в интерфейсе интернет-магазина максимально простым, защищенным от ошибок и вредительства, четко описать поведение операторов на местах. И ОБЯЗАТЕЛЬНО таким, чтобы в случае каких-либо проблем посетитель мог оперативно, без истерик решить их. Ведь проблемы напрямую влияют на конверсию в магазине, если процесс взаимодействия с окном для ввода карты будет затруднителен — это незамедлительно скажется на конверсии. И клубная система, вообще, будет терять участников.
Получилось, что в спроектированном поведении (далее кратко буду называть «логикой»), есть 3 группы, так называемых, заинтересованных лиц. То есть субъекты, которые принимают участие в процессе. Оператор, посетитель и скриптик. Последний тоже производит в логике важные действия, поэтому я и его зачислил в группы заинтересованных лиц.
Описывать весь процесс не имеет смысла. Схему, по которой составлял логику, вы можете посмотреть по этой ссылке, здесь только самый простой из трех сценариев поведения, но структурно понятно, как делалось остальное.
Я опишу ключевые моменты, которые были раскрыты благодаря проектированию процесса.
Изменение оформления интерфейса
В процессе проектирования стало ясно, что помимо самого поля для ввода номера карточки, в рабочий процесс необходимо внести ряд элементов:
- Ссылку типа "Нет карточки? Вы ее получите бесплатно!";
- Краткий описательный текст;
- Телефон службы поддержки;
- Новое поле ввода для валидации владельца карточки (об этом ниже);
- Текст, выдаваемый после валидации владельца карточки.
В связи с этим я предложил ввести несложный pop-up, который бы не блокировался браузерами и спец. программками, с затемнением основного окна. Никаких всплывающих новых окон, новых вкладок и тд. Нельзя забывать о том, что процесс оформления заказа должен быть линейным, то есть посетитель плавно переходил из одного окна в другое без каких-либо существенных изменений процесса.
Плюс такая мелочь, как предустановленные повторяющиеся цифры карты: 9800000000000 (далее идет изменяющиеся трехзначное число).
Валидация владельца карты
Этот вопрос можно решить двумя способами. Привязка карты к аккаунту посетителя в магазине. Работает только, если вы раздаете карты своим клиентам. Один раз привязали (либо оператор, либо сам посетитель) и далее забыли о повторяющейся валидации, что сильно упростит жизнь клиентам конкретного магазина. Но, это уже разборки самого магазина, соответственно его деньги на доработку функционала под привязку карты, за это система бонусных карт платить не будет.
Второй вариант — повторяющаяся валидация. Каждый раз посетитель производит одну и ту же последовательность, если планирует использовать карту.
Первый способ не исключает второй, т.к. клубная бонусная программа подразумевает, что есть и другие владельцы карточек, которые не являются вашими клиентами.
Валидация будет происходить через смс, посетителю надо будет ввести код из смски. Казалось бы, что все просто, «сто раз так делали». На самом деле существует несколько моментов, которые необходимо продумать:
- Смска не пришла, что посетителю делать? Тут то и появляется надобность в номере службы поддержки.
- Смска пришла, но другому человеку (ошиблись вводом или кто-то злоупотребляет), необходимо продумать, что в смске должно быть, помимо номера валидации, чтобы люди не волновались за свои деньги.
Когда я сдавал работу представителю заказчика, у нас завязался спор по поводу необходимости валидации владельца карты при условии, что клиент просто хочет зачислить деньги на бонусный счет. Казалось бы, зачем тут валидация? Никто же не захочет зачислять деньги на чужой счет.
Я настаивал на валидации, моими аргументами были:
- Необходимо предупреждать программно посетителей от их ошибок с неверным вводом карты, я не видел другого способа помимо валидации; (читая Алана Купера, нашел подтверждение своих мыслей в самом начале книги);
- Скрипт не знает, какую операцию хочет произвести посетитель, поэтому необходим ввод дополнительных шагов, типа checkbox «я хочу потратить бонусы»;
- Очень многие посетители захотят потратить бонусы. Поэтому запросов на checkbox будет подавляющее большинство. При этом такое же большинство абсолютно не в курсе, сколько бонусов на счету;
- Из предыдущего пункта возникает проблема проверки бонусов на счету, что подразумевает обязательную валидацию;
- Клиент парировал тем, что они делают платежную систему, и, к примеру, большинство пользователей webmoney знают, сколько у них денег на счету. Вот тут, кстати, закралась ключевая особенность будущего этой клубной карты. Пользователь пользуется вебманями, чтобы оплатить товар, в то время, как покупает товар, пользуясь карточкой, чтобы получить или потратить бонусы. А исходя из метода и принципов распространения карточки, аудитория будет воспринимать ее бонусной, как потом клиент будет работать с изменением ассоциации мне непонятно (извините за лирическое отступление);
- Дополнительные шаги усложняют конверсию. Всем понятно — больше шагов, ниже конверсия;
- Интернет-магазины класть хотели на любые супер-пупер-гипер клубные карты, если они уменьшают конверсию посетителей. Как следует из предыдущих пунктов, усложнение процесса налицо, и многие магазины будут против таких сложностей.
Усложнение процесса налицо, причем появляется куча условий, которые естественно будут ложиться в скрипт и в проектирование посетительского поведения.
Мне понадобился целый час, чтобы убедить представителя клиента в моей правоте.
Подтверждение суммы бонусов на счету
Система устроена так, что после валидации владельца карты, скрипт получает остаток бонусов по карточному счету и другие данные. Соответственно в память скрипта на стороне магазина заносится информация о доступной сумме бонусов.
Злоумышленник может преднамеренно попробовать обмануть магазин в этот момент, к примеру потратив часть бонусов на пополнение мобильного телефона, поэтому я предусмотрел повторный запрос по балансу, после нажатия кнопки «оплатить».
Функция резервирования бонусных средств
Нынешняя реальность интернет-магазинов такова, что заказанного посетителем товара может не оказаться в наличии. Соответственно подобные случаи необходимо предусмотреть в логике программулины, которая отправляет данные на сервак системы.
Я рекомендовал функцию резервирования средств на счету посетителя, в случаях, если он оплачивает бонусными средствами заказ. Деньги должны уходить со счета клиента, и попадать в некий буфер, дожидаясь подтверждения со стороны оператора, который исходя из ситуации, либо отменяет проведение операции, либо подтверждает.
Естественно предусмотрена полная замена заказа, с возможностью оператором в телефонном режиме (с клиентов на проводе) изъять бонусные средства со счета клиента.
Спасение менеджеров
Эта функция пришла в самый последний момент. Дело в том, что ошибаются не только посетители, но и операторы. Ни для кого не секрет, что в запаре ошибиться или ввести что-то неверно проще простого. Я рекомендовал в функционале скриптика добавить для админки заказа такой checkbox: «я подтверждаю, что повторил(а) посетителю данные карточки». Забавен тот факт, что в этом случае юзабилити checkbox должен быть ужасен — только при клике на сам квадратик. Только поставив галочку, оператор сможет провести дальнейшие изменения заказа.
Эта функция маленькая мелочь, но спасет много нервов операторам и владельцам магазинов из-за разбирательств и возвратов средств.
Итог
Некоторые из вышеперечисленных функций могут кому-то показаться банальными или пустяковыми. Хочу заметить лишь одно, именно такие пустяковые банальности и упускаются из виду, во время первого запуска нового сервиса или даже целого интернет-магазина. Скорее всего, я не смог предусмотреть всех проблем, которые возникнут в этом процессе, но, по крайней мере, сократил их количество.
Я осознаю, что в моих терминах и подходе есть доля ламерства, но считаю, что в целом это не сильно повлияло на результат.
Для владельцев интернет-магазинов накидал чек-лист некоторых моментов, про которые забывают при подключении всякой сторонних скриптов, или заключая договор с какой-нибудь клубной системой:
- Проверьте договор, чтобы было ясно указано, кто отвечает за полученные от магазина деньги (деньги клиентов);
- Внимательно прочитайте раздел с расторжением договора. Кто кому и что будет должен;
- Хорошенько задумайтесь, что произойдет, если магазин выйдет из системы? В случае с моим клиентом, у магазина есть возможность просто платить за использование системы, как некий сервис. Прекращение программы будет болезненным процессом для ваших клиентов;
- Изучите процесс возврата денег системой вам. Сроки, комиссии и тд.
- Внимательно изучите юзабилити и интерфейс предлагаемого скрипта. От него может очень сильно зависеть будущая конверсия.
