Сделать в России простую и удобную платёжную систему как для продавца, так и для покупателя — серьёзный вызов для любого UX-специалиста/проектировщика интерфейсов. Чем интереснее и сложнее задача, тем больше опыта и знаний получаешь в процессе работы. Именно над такой задачей я работаю и в этой статье хотел бы поделиться полученным опытом по перепроектированию и доработке системы интернет-платежей A1Pay.
В статье рассмотрены этапы работы, решения, которые были приняты и то, на ч��м они основывались. Описать в одной статье все интересные идеи, возникшие трудности и их решения, находки и т.д. -. не простая задача. Часть важных вопросов, например, измеряемые KPI и их значения, по понятным причинам, остались совсем за рамками.
К началу моей работы над интерфейсом, A1Pay уже была работающей системой приема интернет-платежей со своими сильными сторонами: высокими технологическими мощностями, защитой от мошенничества, службой поддержки партнёров и абонентов, налаженными процессами работы и т.д. Однако системе сильно не доставало в дружелюбности использования.
Для руководства компании стало очевидным — чтобы система и бизнес в области интернет-платежей росли, необходим продукт, ориентированный на пользователя.
Пользователей платежной системы можно разделить на три большие группы:
- Продавцы/партнёры — владельцы веб-сайтов
- Покупатели — пользователи, совершающие покупку на сайтах продавцов
- Сотрудники компании
- Исследование: Изучить цели, задачи и потребности пользователей при взаимодействии с системой.
- Аудит: Выявить и исправить существующие интерфейсные проблемы. Создать юзабилити-гайдлайн для стандартизации UI.
- Проектирование: По итогам первых двух этапов спроектировать интерфейс для новой версии системы.
- Тестирование: Измерить KPI после внедрения нового интерфейса, получить обратную связь от пользователей.
- Кайдзен (непрерывное совершенствование): Постоянные небольшие улучшения системы.
Исследование
В активной фазе работы над проектом время на исследования сильно ограничено. В этом случае длительные серии глубинных интервью или сравнительное юзабилити-тестирование не подходят.
Возможно вы слышали о методике персонажей от компании Cooper, однако в этом проекте я её не использовал. Почему — отдельный вопрос для отдельного обсуждения. Вместо этого я разделил пользователей на группы. Группу «Продавцы/партнёры», о которой было упомянуто выше, я разделил на подгруппы:
- Соискатели — те, кто только узнал о системе и ещё не имеют своего аккаунта в ней.
- Новые партнёры — продавцы, которые только зарегистрировались и начали работать с системой.
- Опытные партнёры — те, кто уже давно работает с системой.
- Бывшие партнёры — покинувшие по каким либо причинам систему.
Веб-аналитика
В качестве инструмента веб-аналитики я использовал Google Analytics. В нём я отслеживал частоту посещений, цепочку навигации, самые посещаемые страницы, конверсию и т.д. Это дало количественное представление о реальном использовании системы. В одном абзаце статьи тяжело рассказать о возможностях этого инструмента для UX-специалиста. Рекомендую к прочтению книгу Брайана Клифтона «Google Analytics. Профессиональный анализ посещаемости веб-сайтов» и книги Авинаша Кошика.
Тикеты службы поддержки
Нет лучше способа развить эмпатию (сопереживание другому) и почувствовать реальную боль пользователей, чем какое-то время поотвечать на тикетах службы поддержки. В компании Zappos.com (которая славится своей корпоративной культурой и клиентоориенированным подходом) каждый сотрудник, будь то разработчик, маркетолог или менеджер проектов на испытательном сроке часть времени отвечает на запросы в службу поддержки. Вопросы и предложения действующих пользователей Вашей системы, при понимании причин и фильтрации — это неисчерпаемый источник идей для улучшения взаимодействия. Если сложности или один тот же вопрос возникает у нескольких пользователей, то это верный признак — в конкретном месте системы есть трудности. Задача проектировщика интерфейсов зафиксировать проблему, предложить решение, вынести его на обсуждение с командой (адвокат пользователя) и вместе решить, как это должно быть реализовано и добиться реализации или внесения в план разработки.
Форум, социальные сети и блоги
Как уже было сказано, для создания впечатляющего UX важна коммуникация. A1Pay представлена во всех популярных социальных сетях и сервисах: Twitter, Вконтакте, Facebook и LiveJournal. Аккаунт в каждый из них заведен для диалога. В них специалисты компании отвечают на вопросы пользователей, готовы выслушать предложения и замечания. Кроме того, постоянно мониторятся блоги и форумы, оперативно обрабатываются все сообщения. В отличии от обращений в тех.поддержку в своём собственном блоге человек беспристрастен и свободен в самовыражении, поэтому иногда встречаются и эмоциональные отзывы. Надо понимать, что у пользователя есть все причины для негодования. Проблема, с которой он столкнулся, для него всегда самая главная. Он Ваш союзник т.к. ему не всё равно. Он хочет, чтобы система была лучше и удобнее. Особый интерес представляет конструктивная критика. Реакция проектировщика по данным сообщениям, как и по тикетам поддержки: фиксация проблемы, анализ, обсуждение, исправление или внесение в план разработки. В дополнении к внешним каналам на сайте работает форум, где партнёры спрашивают, предлагают, обсуждают, помогают друг другу и т.д.
Анкетирование
На основании полученных данных и знакомства с системой я сформировал гипотезу об основных сценариях использования системы: регистрация — настройка и тестирование — мониторинг — вывод средств. В каждом из этих сценариев есть взаимодействие, которые можно улучшить. Выяснить подробности и подкрепить гипотезу я решил анкетированием. Среди выборки партнёров мы распространили анкету со следующими вопросами:
- Какую информацию в системе A1Pay (показатели, отчёты и т.д.) Вы проверяете и считаете наиболее важной?
- Как часто Вы её проверяете?
- Хватает ли Вам информации, которую Вы получаете? Есть ли какие-то показатели, которые Вам приходиться рассчитывать самим?
- Возникают ли у Вас какие-то трудности при работе с системой A1Pay? Пожалуйста, расскажите об этом подробнее.
Аудит
Выяснилось, что общих требований к UI нет и на каждом участке системы интерфейс создавал разработчик конкретного модуля. Как правило, такой подход создаёт две большие проблемы: Когда каждый отвечает за свою частью, никто не отвечает за взаимодействие в целом. Другая проблема в неконсистентности интерфейса. Одни и те же операции в разных частях системы можно было сделать по-разному. Чем больше система, тем ощутимее влияние этих проблем. Решением стала стандартизация интерфейса в юзабилити-гайдлайне.
О том, как гайдлайны могут улучшить качество веб-проектов, я подробно написал в статье «Использование usability guidelines для повышения качества веб-разработок». Продемонстрирую некоторые интерфейсные проблемы и их решения.
Подтверждение операции
У важных операций, когда данные не могут быть восстановлены (например удаление), отсутствовало подтверждение. Было сформулировано следующее правило:
Для операций удаления или других невозвратных операций выводятся сообщение для подтверждения. В тексте обязательно сообщается наименование объекта, над которым совершается действие.
Контекстная система помощи
Судя по обращениям в службу технической поддержки значение некоторых терминов, принципов работы системы или условий вызывало вопросы.
Было предложено разместить в правой части темплейта иконку контекстной помощи, которая ведёт на описание текущего экрана (сервиса, операции и т.д.) в базе знаний. Справка открывается в новом окне.
Стандартизация UI ожидаемо потребовала доработок системы и создание новой функциональности.
Прототип
На данный момент существует большое количество инструментов прототипирования. Каждый может найти инструмент удобный для себя и задач, которые перед ним стоят. Однако, суть не в инструменте, а в том, что Вы в нём создаёте и что хотите проработать. В данном проекте стояла задача создать интерактивный, высокодетализированный прототип, поэтому я использовал Axure.
Созданию детального прототипа предшествовало концептуальное проектирование. На этом этапе прорабатывалась информационная архитектура, навигация, архитектура взаимодействия и т.д. Как мне кажется, прежде чем использовать какой-то из инструментов надо «подумать» на бумаге. Она всё стерпит.
На стадии концептуального проектирования для меня вопросом была навигация. Делать её горизонтальной с вкладками и подменю или вертикальной, как в старом варианте? Нарисовав оба варианта на бумаге (на изображении вертикальный) и сопоставив с планами развития системы, я решил остановиться на горизонтальном варианте. Логика моего решения следующая:
- При появлении в системе новых модулей и решений не загромождается меню.
- За счёт освободившейся области слева увеличилась рабочая область экрана.
- В каждый конкретный момент пользователь работает с одним экраном. Нет сценария при котором пользователю была бы необходима быстрая навигация по всей системе.
- Даже если такая необходимость (быстрой навигации) возникнет, то её можно реализовать за счёт контекстных ссылок-операций.
Ещё одним важным моментом концептуального проектирования стало появление, ранее отсутствовавшей «приборной доски» (dashboard) как главного экрана. Основной и частотный сценарий работы с системой — мониторинг. Дашборд должен однозначно показывать состояние системы, изменения и их причину. В местах, где это обусловлено контекстом дать быстрые ссылки на детализацию информации в глубь системы (например на детальную статистику и т.д.). Так на бумаге были отрисованы дашборд с основными блоками: график доходов, баланс, счета, новости, новые тикеты и т.д. На панель были вытянуты некоторые элементы модулей, чтобы увеличить скорость (дать «быстрые ссылки»).
О проектировании dashboard Вы можете прочитать прекрасную книгу Стивена Фью «Information Dashboard Design: The Effective Visual Communication of Data», посмотреть презентацию Аарона Харсмана или примеры на сайте Dashboard Spy.
После концептуального проектирования началась детальная отрисовка всех экранов системы в программе Axure. Всего было спроектировано около 30 экранов. Интерактивный прототип позволил наглядно демонстрировать и обсуждать планируемый UI с командой.
Дизайн
После защиты и утверждения прототипа, выяснения требований руководства к графическому оформлению мы перешли к отрисовке дизайна. Проектировщик должен активно работать в паре с графическим дизайнером, обьясняя механику работы и возможные состояния некоторых элементов интерфейса. При работе с удалённым дизайнером необходимо снабдить прототип дополнительными комментариями. Для этих целей я использовал возможности программы по снятию скриншотов FastStone Capture. На Хабрахабре часто появляются статьи о колоборативных веб-сервисах, которые позволяют комманде цивилизованно обсуждать дизайн и хранить результаты в облаке. Такие сервисы из-за Лебедева иногда называют линчелками.
Графический дизайн трудно формализуем. Маловероятно получить нужный результат с первого раза. После нескольких итераций ревизия-доработка удалось приблизиться к приемлемому варианту. Количество итераций зависит от мастерства графического дизайнера и от Вашего умения видеть конечный результат.
На этом этапе дизайнером был также нарисован логотип.
Проверка решения и дальнейшие действия
Спустя какое-то время после запуска я всё ещё вижу места, которые следует доработать или улучшить. Если Вы читали книгу «Дизайн пользовательского интерфейса2. Искусство мыть слона» Влада Головача, то знаете, что это свойственно проектировщикам интерфейсов и это часть профессионального развития.
У системы есть конкретные KPI, которые отслеживаются онлайн. (выводятся на большом телевизоре). После перепроектирования уменьшилось количество обращений в службу поддержки по вопросам работы с системой, выросло общее число партнёров, наметился рост лояльности и т.д.
Доработка и улучшение взаимодействия осуществляются в каждом спринте (работаем по SCRUM).
Выводы
Юзабилити и user experience важная, неотъемлемая часть клиентоориентированного сервиcа. Мне известны очень мало примеров (сервисов или продуктов), где без специально выделенных ��пециалистов добивались значительных долгосрочных результатов (если только это не 37 сигналов, где UX поднят на флаг). С другой стороны, лозунг «UX is king» остаётся в статьях западных юзабилити-гуру. В реальности user experience и юзабилити обслуживает бизнес. Часто UX специалисту приходится упираться в технические, юридические и политические ограничения. Где-то искать компромисс, где-то продавливать решение в первоначально предложенном виде, а иногда наоборот отказаться от него целиком — действительность проектирования интерфейсов.
Работа UX специалиста внутри веб-сервиса или продукта возможна по методологии UCD с множеством итераций.
В этом кейсе я показал из каких частей состояла работа над веб-интерфейсом системы интернет-платежей A1Pay. Вы можете использовать мой опыт частично или целиком. В планах рассказать про перепроектирование промосайта и платёжного окна. Готов ответить на Ваши вопросы.
