Делая интернет-платежи простыми и удобными. Перепроектирование системы A1Pay

    Перепроектирование системы A1Pay

    Сделать в России простую и удобную платёжную систему как для продавца, так и для покупателя — серьёзный вызов для любого UX-специалиста/проектировщика интерфейсов. Чем интереснее и сложнее задача, тем больше опыта и знаний получаешь в процессе работы. Именно над такой задачей я работаю и в этой статье хотел бы поделиться полученным опытом по перепроектированию и доработке системы интернет-платежей A1Pay.

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

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

    Пользователей платежной системы можно разделить на три большие группы:
    • Продавцы/партнёры — владельцы веб-сайтов
    • Покупатели — пользователи, совершающие покупку на сайтах продавцов
    • Сотрудники компании
    В этой статье я расскажу подробнее о перепроектирование интерфейса для продавцов. Мы называем их партнёрам, т.к. вместе делаем общее дело. Я подключился к проекту, когда было необходимо поддерживать текущую версию системы и одновременно началась разработка новой версии с расширенными возможностями и новым интерфейсом. В своей работе я ориентируюсь на подход UCD (User-Centered Design или дизайн ориентированный на пользователя, с недавних пор переименованного в Human-Centered Design). Следуя этому подходу, необходимо понять цели и задачи пользователей, привлечь пользователя к процессу разработки. Применительно к A1Pay я определил следующие этапы:
    1. Исследование: Изучить цели, задачи и потребности пользователей при взаимодействии с системой.
    2. Аудит: Выявить и исправить существующие интерфейсные проблемы. Создать юзабилити-гайдлайн для стандартизации UI.
    3. Проектирование: По итогам первых двух этапов спроектировать интерфейс для новой версии системы.
    4. Тестирование: Измерить KPI после внедрения нового интерфейса, получить обратную связь от пользователей.
    5. Кайдзен (непрерывное совершенствование): Постоянные небольшие улучшения системы.

    Исследование


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

    Возможно вы слышали о методике персонажей от компании Cooper, однако в этом проекте я её не использовал. Почему — отдельный вопрос для отдельного обсуждения. Вместо этого я разделил пользователей на группы. Группу «Продавцы/партнёры», о которой было упомянуто выше, я разделил на подгруппы:
    • Соискатели — те, кто только узнал о системе и ещё не имеют своего аккаунта в ней.
    • Новые партнёры — продавцы, которые только зарегистрировались и начали работать с системой.
    • Опытные партнёры — те, кто уже давно работает с системой.
    • Бывшие партнёры — покинувшие по каким либо причинам систему.
    Это позволило определить сценарии и то, как текущая функциональность и содержимое удовлетворяет потребностям различных подгрупп пользователей и KPI, по которым можно отслеживать результаты.

    Веб-аналитика


    В качестве инструмента веб-аналитики я использовал Google Analytics. В нём я отслеживал частоту посещений, цепочку навигации, самые посещаемые страницы, конверсию и т.д. Это дало количественное представление о реальном использовании системы. В одном абзаце статьи тяжело рассказать о возможностях этого инструмента для UX-специалиста. Рекомендую к прочтению книгу Брайана Клифтона «Google Analytics. Профессиональный анализ посещаемости веб-сайтов» и книги Авинаша Кошика.

    Тикеты службы поддержки


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

    Форум, социальные сети и блоги


    Как уже было сказано, для создания впечатляющего UX важна коммуникация. A1Pay представлена во всех популярных социальных сетях и сервисах: Twitter, Вконтакте, Facebook и LiveJournal. Аккаунт в каждый из них заведен для диалога. В них специалисты компании отвечают на вопросы пользователей, готовы выслушать предложения и замечания. Кроме того, постоянно мониторятся блоги и форумы, оперативно обрабатываются все сообщения. В отличии от обращений в тех.поддержку в своём собственном блоге человек беспристрастен и свободен в самовыражении, поэтому иногда встречаются и эмоциональные отзывы. Надо понимать, что у пользователя есть все причины для негодования. Проблема, с которой он столкнулся, для него всегда самая главная. Он Ваш союзник т.к. ему не всё равно. Он хочет, чтобы система была лучше и удобнее. Особый интерес представляет конструктивная критика. Реакция проектировщика по данным сообщениям, как и по тикетам поддержки: фиксация проблемы, анализ, обсуждение, исправление или внесение в план разработки. В дополнении к внешним каналам на сайте работает форум, где партнёры спрашивают, предлагают, обсуждают, помогают друг другу и т.д.

    Анкетирование


    На основании полученных данных и знакомства с системой я сформировал гипотезу об основных сценариях использования системы: регистрация — настройка и тестирование — мониторинг — вывод средств. В каждом из этих сценариев есть взаимодействие, которые можно улучшить. Выяснить подробности и подкрепить гипотезу я решил анкетированием. Среди выборки партнёров мы распространили анкету со следующими вопросами:
    1. Какую информацию в системе A1Pay (показатели, отчёты и т.д.) Вы проверяете и считаете наиболее важной?
    2. Как часто Вы её проверяете?
    3. Хватает ли Вам информации, которую Вы получаете? Есть ли какие-то показатели, которые Вам приходиться рассчитывать самим?
    4. Возникают ли у Вас какие-то трудности при работе с системой A1Pay? Пожалуйста, расскажите об этом подробнее.
    Анкета состояла из открытых вопросов, что позволило получить качественную информацию.

    Аудит


    Юзабилити-гайдлайн системы A1Pay

    Выяснилось, что общих требований к UI нет и на каждом участке системы интерфейс создавал разработчик конкретного модуля. Как правило, такой подход создаёт две большие проблемы: Когда каждый отвечает за свою частью, никто не отвечает за взаимодействие в целом. Другая проблема в неконсистентности интерфейса. Одни и те же операции в разных частях системы можно было сделать по-разному. Чем больше система, тем ощутимее влияние этих проблем. Решением стала стандартизация интерфейса в юзабилити-гайдлайне.

    Юзабилити-гайдлайн системы A1Pay

    О том, как гайдлайны могут улучшить качество веб-проектов, я подробно написал в статье «Использование usability guidelines для повышения качества веб-разработок». Продемонстрирую некоторые интерфейсные проблемы и их решения.

    Подтверждение операции


    У важных операций, когда данные не могут быть восстановлены (например удаление), отсутствовало подтверждение. Было сформулировано следующее правило:

    Подтверждение операции

    Для операций удаления или других невозвратных операций выводятся сообщение для подтверждения. В тексте обязательно сообщается наименование объекта, над которым совершается действие.

    Контекстная система помощи


    Судя по обращениям в службу технической поддержки значение некоторых терминов, принципов работы системы или условий вызывало вопросы.

    Контекстная система помощи

    Было предложено разместить в правой части темплейта иконку контекстной помощи, которая ведёт на описание текущего экрана (сервиса, операции и т.д.) в базе знаний. Справка открывается в новом окне.

    Стандартизация UI ожидаемо потребовала доработок системы и создание новой функциональности.

    Прототип


    На данный момент существует большое количество инструментов прототипирования. Каждый может найти инструмент удобный для себя и задач, которые перед ним стоят. Однако, суть не в инструменте, а в том, что Вы в нём создаёте и что хотите проработать. В данном проекте стояла задача создать интерактивный, высокодетализированный прототип, поэтому я использовал Axure.

    Axure

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

    Прототип на флип-чарте

    На стадии концептуального проектирования для меня вопросом была навигация. Делать её горизонтальной с вкладками и подменю или вертикальной, как в старом варианте? Нарисовав оба варианта на бумаге (на изображении вертикальный) и сопоставив с планами развития системы, я решил остановиться на горизонтальном варианте. Логика моего решения следующая:
    • При появлении в системе новых модулей и решений не загромождается меню.
    • За счёт освободившейся области слева увеличилась рабочая область экрана.
    • В каждый конкретный момент пользователь работает с одним экраном. Нет сценария при котором пользователю была бы необходима быстрая навигация по всей системе.
    • Даже если такая необходимость (быстрой навигации) возникнет, то её можно реализовать за счёт контекстных ссылок-операций.
    Элементы навигация были упорядочены на основании статистики посещения и данных исследования. Наиболее частотные операции и модули расположены выше и левее.

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

    О проектировании dashboard Вы можете прочитать прекрасную книгу Стивена Фью «Information Dashboard Design: The Effective Visual Communication of Data», посмотреть презентацию Аарона Харсмана или примеры на сайте Dashboard Spy.

    После концептуального проектирования началась детальная отрисовка всех экранов системы в программе Axure. Всего было спроектировано около 30 экранов. Интерактивный прототип позволил наглядно демонстрировать и обсуждать планируемый UI с командой.

    Storyboard

    Дизайн


    После защиты и утверждения прототипа, выяснения требований руководства к графическому оформлению мы перешли к отрисовке дизайна. Проектировщик должен активно работать в паре с графическим дизайнером, обьясняя механику работы и возможные состояния некоторых элементов интерфейса. При работе с удалённым дизайнером необходимо снабдить прототип дополнительными комментариями. Для этих целей я использовал возможности программы по снятию скриншотов FastStone Capture. На Хабрахабре часто появляются статьи о колоборативных веб-сервисах, которые позволяют комманде цивилизованно обсуждать дизайн и хранить результаты в облаке. Такие сервисы из-за Лебедева иногда называют линчелками.

    Комментарии к дизайну

    Графический дизайн трудно формализуем. Маловероятно получить нужный результат с первого раза. После нескольких итераций ревизия-доработка удалось приблизиться к приемлемому варианту. Количество итераций зависит от мастерства графического дизайнера и от Вашего умения видеть конечный результат.

    Дизайн

    На этом этапе дизайнером был также нарисован логотип.

    Логотип

    Проверка решения и дальнейшие действия



    Спустя какое-то время после запуска я всё ещё вижу места, которые следует доработать или улучшить. Если Вы читали книгу «Дизайн пользовательского интерфейса2. Искусство мыть слона» Влада Головача, то знаете, что это свойственно проектировщикам интерфейсов и это часть профессионального развития.

    Даша помогает расти KPI

    У системы есть конкретные KPI, которые отслеживаются онлайн. (выводятся на большом телевизоре). После перепроектирования уменьшилось количество обращений в службу поддержки по вопросам работы с системой, выросло общее число партнёров, наметился рост лояльности и т.д.

    Доработка и улучшение взаимодействия осуществляются в каждом спринте (работаем по SCRUM).

    Выводы


    Юзабилити и user experience важная, неотъемлемая часть клиентоориентированного сервиcа. Мне известны очень мало примеров (сервисов или продуктов), где без специально выделенных специалистов добивались значительных долгосрочных результатов (если только это не 37 сигналов, где UX поднят на флаг). С другой стороны, лозунг «UX is king» остаётся в статьях западных юзабилити-гуру. В реальности user experience и юзабилити обслуживает бизнес. Часто UX специалисту приходится упираться в технические, юридические и политические ограничения. Где-то искать компромисс, где-то продавливать решение в первоначально предложенном виде, а иногда наоборот отказаться от него целиком — действительность проектирования интерфейсов.

    Работа UX специалиста внутри веб-сервиса или продукта возможна по методологии UCD с множеством итераций.

    В этом кейсе я показал из каких частей состояла работа над веб-интерфейсом системы интернет-платежей A1Pay. Вы можете использовать мой опыт частично или целиком. В планах рассказать про перепроектирование промосайта и платёжного окна. Готов ответить на Ваши вопросы.
    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 37

      +4
      Хорошая статья
        +2
        Отличные картинки. Все надписи на них легко читаются.
          +4
          Картинки то отличные, но почему бы не выложить их в нормальном размере по клику?
            +8
            особенно последняя картинка в картинке отличная
              0
              Вы можете посмотреть на систему и не на картинках. На сайте A1Pay.ru есть возможность выполнить демо-вход (нажмите на кнопку «Посмотреть демонстрацию»). Кроме того, воспользоваться системой можно имея аккаунт в соц.сетях и почте: Facebook, Twitter, Вконтакте, Gmail и OpenID и других (т.к. мы используем Логинзу)
                0
                Не стал нажимать «Посмотреть демонстрацию» ожидая увидеть какое-нибудь видео :)
              0
              Отличная статья получилась. Радует, что описанный подход работы по стандарту ISO 9241-210 можно применять и на других проектах, используя данную статью как руководство по применению))
              У меня возникли несколько вопросов:
              1. Целью перепроектирования были удержание готового ядра пользователей или больше привлечение новых? Просто анкетирование, я так понял, было рассчитано на пользователей, которые уже используют данную систему.
              2. Было введено только подтверждение удаления или еще и функция Undo? На рисунке показана функция Восстановить.
                +1
                1. На привлечение новых партнёров и удержание старых интерфейс и взаимодействие влияет только отчасти. Для партнёров очень важны и другие факторы, например условия работы, отчисления и т.д. Скорее целью было создать интерфейс для масштабируемой системы, исправить ошибки предыдущей версии и улучшить пользовательские качества в целом.

                2. Было сделано подтверждение операции. Undo (как в Gmail и как на картинке) это пример предложения, которое по разным причинам реализовать не удалось.
                +3
                Мотиватор на последнем изображении на стене расставил все по своим местам. Вот из-за чего рождаются хорошие идеи и хочется работать :)
                  +1
                  Павел а вы в своих статьях уже раскрыли как у вас устроен рабочий процесс? Интересует какая роль отводится задачам связанным с UX в спринте или они не имеют приоритета над остальными задачами.
                    +1
                    Про деятельность UX специалиста в рамках SCRUM я ещё не рассказывал. Пока набираюсь опыта работы в гибких методологиях. Публиковал на Хабре перевод чужого опыта «Совместная жизнь Agile и UCD на примере реального проекта».

                    Чистые активности по UX мы в спринт пока не включали. Однако, в некоторых задачах есть работа над интерфейсом и это учитывается при оценке и описании результата (демо). В таких задачах участвует как разработчик, так и проектировщик UI.
                    +1
                    Самое неудобное — раздел «цены».
                    Особенно по странам, отличным от России:
                    Цена SMS для абонента 4.26 gbp
                    Доход партнера, руб. 123.665

                    Цена SMS для абонента 1.67 eur
                    Доход партнера, руб. 36.943
                    и т.д.
                      +1
                      Мне интересно, возле кнопки «стать партнером» только я вижу чуть заметный прямоугольник? Косяк))
                        0
                        На сайте a1pay.ru/
                          +1
                          Нет, не вы один. Он там правда есть, но едва заметный.

                          Еще на главной хотелось бы, чтобы айфон смотрел в другую сторону.
                          0
                          Если долго смотреть на иконку с изображением земного шара в «Преимуществах», то можно увидеть прилив и отлив Тихого океана
                          +1
                          Отличная работа!
                            +1
                            Супер! Особенно радуют отсылки к книгам и инструментам. Заставляет понять откуда берется тот или иной факт об интерфейсах.
                              0
                              «наметился рост лояльности» — это как оценивалось, если не секрет? Человек ведь не возвращяется на любимый платежный шлюз только для того, чтобы еще и еще раз заплатить.
                                +1
                                Имеется в виду среди партнёров системы. Это владельцы сайтов, которые устанавливают платёжное решение для своих пользователей.

                                Кстати, в рамках A1Pay есть платёжное окно A1Lite оно было тоже спроектировано и я планирую рассказать и о нём. Вот там как раз есть взаимодействие с конечными пользователями о которых Вы говорите.
                                  0
                                  Это оценивается так — у Робокассы от 30 секунд до бесконечности покупатель ждет пока платеж пройдет, часто слетает все. Меня как магазин, например, это не устроило.
                                    0
                                    Вопрос то был про то, как оценивается лояльность для вывода на экран. То что вы, как клиент Робокассы, были недовольны качеством предоставления услуг и от этих услуг отказались — событие. А вот как Робокассе или другому сервису это событие оцифровать и наглядно для своих представить? В этом вопрос и есть.
                                  +1
                                  Мне тут знакомый разработчик из Вашей компании сообщил, что система почти полностью реализована на PHP/MySQL. Довольно смелый выбор для платежного шлюза. Может сделаете отдельный топик о технических решениях, как там внутри у вас это устроено и масштабируется? Было бы интересно.
                                    +1
                                    Почему бы и нет, огромное кол-во высоконагруженных сервисов реализованно на этих технологиях — facebook, вконтакте и многие другие. Тут вопрос кривизны рук.
                                    0
                                    На Хабрахабре часто появляются статьи о колоборативных веб-сервисах, которые позволяют комманде цивилизованно обсуждать дизайн и хранить результаты в облаке. Такие сервисы из-за Лебедева иногда называют линчелками.

                                    А что лично вы использовали в данном случае, скриншоты какого из сервисов приведены?
                                      +1
                                      В статье я написал «использовал возможности программы по снятию скриншотов FastStone Capture». Нужно освоить какой-то удобный, полноценный сервис, потому что FastStone Capture не позволяет открывать и редактировать картинку с комментарием. Возможно кто-то из читателей поделиться опытом и ссылками на подобный сервис.
                                        +1
                                        В статье я написал «использовал возможности программы по снятию скриншотов FastStone Capture».

                                        Хм, пользуюсь ей иногда, но о таком функционале не знал.

                                        Несколько подобных сервисов видел, (PicBite, Lynchelka, например), но они неудобны для коллективной работы.
                                        Даже правки, элементарно, внести нельзя.

                                        Возможно кто-то из читателей поделиться опытом и ссылками на подобный сервис.

                                        Было бы полезно, да.
                                          +1
                                          Я использую связку Ножницы (стандартно в win7) + Гугл док в режиме комментариев.
                                          На ножницы вешается хоткей, например Ctrl+Alt+S — захватываем любую нужную область экрана будь то сайт или макет, фрагмент автоматически заноситься в буфер.
                                          Из буфера в гугл-док, FF это поддерживает, к каждой картинке текстом замечания. Док в совместном доступе с исполнителем → непонятные моменты обсуждаются в комментариях в привязке к контексту.
                                            0
                                            Очень интересная связка. Спасибо за то, что поделились. Скажите, эти самые «Ножницы» как-то можно поставить не под Win7, а под XP или Vista? Хотя я сейчас подумал, что FastStone Capture тоже можно так настроить, там достаточно богатый функционал
                                              0
                                              Была похожая маленькая программка — позволяла обрисовать произвольную область с занесением в буфер. В свое время искал — не нашел. FStone думаю вполне можно подстроить.
                                      • UFO just landed and posted this here
                                        0
                                        Статья — печальный пример того, что некоторым проектам зачастую полезнее отсутствие дизайнера.
                                        Прототипы гораздо нагляднее и приятнее, чем итоговый дизайн.
                                        На прототипе дашборда мы видим информацию, на дизайне — синие плашки, которые своей массой задавили в макете все показатели. Кастомные элементы, табы, менюшки, мелкие контролы выполнены крайне грязно.
                                        Использование синих стенсилов в Акшуре бы дало на порядок более качественный дизайн, чем то что было затем «отрисовано».
                                        Проектировщику — пряник, а дизайнеру — розги, обмазать малиной и выгнать в лес к медведям.
                                          0
                                          А вот логотип — хороший, хотя капельку левую ветку «y» можно было поправить оптически в ущерб «правильной» геометрии. Предположу, что делал тот же человек, что и интерфейс. А зря!
                                          Специализации нужно придерживаться: интерфейс — не картинки!
                                            0
                                            Логотип рисовал 2-ой дизайнер, т.е. не проектировщик интерфейсов. Специализации придерживаюсь )
                                          +1
                                          Хорошая статья и интерфейс зачетный. Это не интерфейсы Сбербанка
                                            0
                                            В статье рекомендуется к прочтению первое издание книги Брайана Клифтона «Google Analytics: профессиональный анализ посещаемости веб-сайтов», которое было издано в 2009 году. Сейчас на habrahabr`е обсуждается вопрос о необходимости перевода на русский язык третьего издания книги «Advanced Web Metrics with Google Analytics» («Google Analytics для профессионалов»), которое выйдет на английском языке в январе 2012 года в США

                                            Only users with full accounts can post comments. Log in, please.