User eXperience 2014: Создание проектов и ошибки, которые мы совершаем

24 октября в Москве, в Медиа-центре Mail.Ru Group, прошел второй день конференции User Experience 2014, посвященной вопросам юзабилити и вовлечения пользователей и заинтересованных лиц со стороны бизнеса.

В рамках секции, посвященной проектированию сервиса, Александр Феоктистов (Яндекс.Маркет) представил доклад «Создание проектов и ошибки, которые мы совершаем». В своем выступлении Александр кратко рассказал о наиболее распространенных заблуждениях, свойственных проектировщикам интерфейсов и юзабилити-специалистам.

Среди них:

Ошибка № 1. «Не знаю, для кого это, я бы никогда».

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

Ошибка № 2. Создание интерфейса без участия пользователей.

Если вы работаете над интерфейсом сайта и не привлекаете при этом его потенциальных посетителей/клиентов, то вероятность провала проекта увеличивается в разы.

Ошибка № 3. Спрашивать пользователей, что вам нужно сделать, чтобы они совершили покупку.

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

Ошибка № 4. Делать работу за дизайнера.

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

Ошибка № 5. Ориентироваться только на результаты тестирований.

Никакие тестирования не могут и не должны заменять здравый смысл. Ни в коем случае не подменяйте стратегию результатами тестов.

Ошибка № 6. Стремиться быть лучшим во всем.

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

Ошибка № 7. Препятствовать взаимодействию пользователя с продуктом.

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

Ошибка № 8. Считать пользователя глупее себя.

Ошибка № 9. «Как пользователь узнает, что ему нужно кликнуть именно сюда?»

Эта ошибка тесно связана с предыдущей. У современного пользователя достаточно опыта, чтобы понять, какое действие от него требуется. Поэтому перегружать интерфейс лишними элементами для 1% особо недогадливых посетителей не стоит.

Ошибка № 10. Изменять элементы интерфейса только для того, чтобы они стали заметнее.

Ошибка № 11. Не обращать внимания на чужие проекты.

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

Алексей Копылов (Flexis), специалист в области user experience и юзабилити, выступил с докладом «Customer Journey Map. Неочевидные тонкости применения», дополняющим статью "Customer Journey Map. Главный инструмент проектировщика услуг".

Сегодня пользователи окружены огромным количеством услуг, с которыми они взаимодействуют через разные каналы. Customer Journey Map (CJM) — ориентированный граф, на который с помощью точек контакта отображается путь потребителя предоставляемой услуги. CJM фиксирует подробности взаимодействия с услугой.

Из-за необходимости контактировать с несколькими разными агентами на пути к услуге потребитель может не достигнуть конечной точки. CJM позволяет поставить под контроль процесс проектирования услуг, которые реализованы с помощью различных интерактивных продуктов.

Какие задачи решает CJM?

1. Создание непрерывного User Experience на протяжении всего потребления услуги.
2. Увеличение конверсии потребителей.
3. Повышение лояльности потребителей.
4. Повышение ответственности специалистов компании.
5. Ускорение разработки многоканальных услуг и продуктов.
6. Создание новых захватывающих взаимодействий.

Способы фиксации CJM

1. Карта «Как есть» (As is)

Фиксируется изначальное положение вещей, чтобы затем его оптимизировать.

2. Карта «Как должно быть»

Визуализируется концепция будущей услуги.

3. Карта «День из жизни»

Глубокое погружение в деятельность пользователя, чтобы понять, что он из себя представляет.

4. Service blueprint

Фиксируются все стороны взаимодействия.

Проблемы CJM

1. Слишком много типов клиентов

Это приводит к тому, что одна часть сценариев может совпадать, а другая — нет. Сопровождать изменение сценариев очень сложно.

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

2. Наличие двух сторон взаимодействия

Своего рода Customer Journey Map проходят не только клиенты, но и сотрудники компании. Поэтому в идеале для них тоже стоит сделать карту, а затем создать общую комфортную CJM.

Решить эту проблему помогут service blueprint (схема, описывающая процесс предоставления услуг и элементы, участвующие в этом процессе) или swimlanes (визуальным элементом, используемые в процессе технологических схем, описывающих, что или кто работает на определенной части процесса) (BPM).

3. Нелинейность CJM

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

Для решения этой проблемы докладчик предложил достаточно радикальный метод — отказаться от всех ненужных каналов.

4. Пучковость каналов

В одну точку контакта клиенты попадают разными путями. И в зависимости от «траектории» пути пользователя он будет сталкиваться с разными барьерами.

Так как решить эту проблему достаточно сложно, Алексей просто предложил не обращать на нее внимание.

Саша Куценко (Aidem) представил доклад «Почему в больших проектах нельзя без документации к сервису». В своем выступлении Саша рассказал о том, чем полезна подробная спецификация, на примере работы Aidem над интернет-магазином KEY:

1. До 20% каждого макета уточняется при его описании.

2. Каждые две недели заказчик получает артефакт на руки.

Плюсы:

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

3. У всех стороны зафиксированы и прописаны требования.

Плюсы:

• исключается вариант «Вы говорили иначе».
• этап чаще сразу передается в работу.
• один документ обеспечивает одинаковое понимание у всех участников.

4. Исполнитель точнее оценивает время и объем работ.

Плюсы:

• оценить эти показатели только по макетам сложно.
• уменьшается diff — разница в ожиданиях заказчика и планах разработчика.

5. У разработчиков есть подробное руководство, в котором они могут найти ответы на все вопросы.

6. На этапе контроля качества спецификация помогает уточнить нюансы.

7. Контент готовится при постоянной сверке со спецификацией.

8. При необходимости возвращения к предыдущим этапам, внести правки или что-то новое все работы также проводятся через спецификацию.