Всё, что нужно знать менеджеру продукта про пользовательский опыт

Всё, что нужно знать менеджеру продукта про пользовательский опыт

Отличная подборка полезных ресурсов и запись вебинара с Михаилом Грековым про UX.

Процитирую несколько крутых мыслей:

✔️Пользовательского опыта не существует, пока у продукта нет аудитории. Это главная причина начать получать обратную связь в процессе разработки как можно раньше (тестирование прототипов, коридорные тесты, запуск через MVP)

✔️Пользовательский опыт неоднороден. У разных частей продукта может быть совсем разный UX (попробуйте найти в Zoom настройки видео). И для разных аудиторий UX может быть разным (1С очень удобен в глазах опытного бухгалтера)

✔️Хороший UX это баланс между удобством (помогаем пользователю дойти до цели кратчайшим путём) и интересами бизнеса (на примере Яндекс Go, продвигаем другие сервисы за счёт простой задачи вызова такси)

✔️Пирамида пользовательских ценностей (см картинку👇🏻). Нет смысла заниматься проблемами на верхних уровнях, если в продукте не решены критичные проблемы на нижних.

Также в презентации есть разбор требований работодателей к менеджерам продукта, связанным с UX, и хороший список рекомендаций как прокачивать эти навыки. Однозначно в избранное!

PayPal: рост аудитории в 5 раз

PayPal - крупнейшая платежная система в мире. Оплаты счетов, денежные переводы и куча всего прочего.

Сегодня кейс о том, как компания увеличила аудиторию в 5 раз.

Что сделали

- переосмыслили подход к привлечению пользователей- за каждую регистрацию начали давать по $20 с порога
- тестили разные формы регистраций
- нашли ту, которая дает самую низкую стоимость привлечения CPA

В итоге, за 5 месяцев аудитория выросла 1 до 5 млн.юзеров.

Со временем начали снижать бонус за регу с $20 до $10, потом до $5 и так до нуля. Дальше сервис раскрутился и начался органический рост.

Посыл

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

Источник - https://bit.ly/2OLQ3qI

Эдвард Скотт написал о сравнении товаров в интернет-магазине.

Прежде, чем добавить эту функцию:

1. Проверьте, что у вас есть данные о параметрах товаров и что они структурированы, то есть, например, размеры не указаны то в сантиметрах, то в миллиметрах.

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

3. Выберите категории товаров, которым точно нужна возможность сравнения. Например, бытовые приборы и электроника. Особенно, если ваша основная аудитория — эксперты или профессионалы, которые умеют интерпретировать важные параметры товаров и методично их сравнивать.

Если вы уже добавили:

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

2. При наведении курсора на контрол «Сравнить» показывайте подсказку с кратким пояснением: что это за инструмент и как он работает. Так его не примут за функцию сравнения цен с другими магазинами.

3. Дайте легко перейти к сравнению выбранных товаров. Например, отобразите панель с кнопкой «Сравнить выбранные товары» и миниатюрами этих товаров, прикреплённую к нижней или верхней границе окна браузера.

https://ux.pub/ux-rekomendatsii-po-uluchsheniyu-instrumenta-sravnenie-tovarov/

Сила комментария

Сила комментария

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

— На карточке клиента: за что предоставили скидку 20%
— На форме заказа: что в дверь звонить не надо
— В тикете техподдержки: ссылка на обсуждение в багтрекинге

Комментарии в интерфейсах недооценены. Аналитики, дизайнеры, программисты — все мы любим и умеем систематизировать информацию. Поэтому любой объект в интерфейсе представляем как набор полей с конкретным назначением: наименование, почтовый индекс, стоимость.

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

Например, на «Дадате» мы используем систему защиты от сетевых атак. У нее есть интерфейс, где можно заблокировать конкретный IP-адрес. Указываешь IP, жмешь «добавить в черный список», злодей получает бан. Что может быть проще?

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

Но постойте, можно же сделать нормальные поля «сотрудник» и «причина блокировки»? Да, можно, но непонятно:

— точно ли нужны именно эти поля?
— действительно ли они нужны?

Добавлять поля просто «чтобы были» — так себе идея. А выяснить реальные сценарии как раз и поможет поле «комментарий». Потом, если что, можно заменить его на поля с конкретным назначением.

Комментарий — элемент хаоса. Но с ним система устойчивее.

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

Михаил Греков написал, как сделать удобнее таблицы, с помощью которых пользователи управляют данными (CRM, ERP и прочие системы).

В первой статье разбирается просмотр данных.

1. Рабочая таблица должна занимать максимум места на экране. Как вариант — опция «на весь экран».
2. Объединяйте данные. Если есть данные о фамилии, имени и отчестве, их целесообразно вывести в один столбец ФИО. Должность или роль в системе тоже можно присоединить к ФИО.
3. Бесконечная прокрутка и кнопка «Показать ещё» не подходят для отображения строк таблицы. Делайте постраничную навигацию. Это удобно и для коллективной работы с таблицей.
4. Показывайте по умолчанию больше строк на одной странице: 50, 100, 500.
5. Используйте цветовые индикаторы. Красить строку целиком стоит только при отклонении от нормы.
6. При наличии цветовых индикаторов полезно отображать легенду цветов.
7. Храните пользовательские настройки вида, не сбрасывайте их после окончания сеанса.
8. Связанные сущности (название организации может быть связано с карточкой организации) полезно делать ссылками на соответствующие карточки. Но если таких сущностей в строке много, выделите только полезные в работе.
9. Строка должна подсвечиваться при наведении курсора. Должна быть возможность выделить строку кликом на неё.
10. Нет ничего страшного при появлении горизонтальной прокрутки.
11. В некоторых случаях полезно маркировать просмотренные записи.
12. Должна быть настройка отображения столбцов с системными свойствами (ID, дата создания, автор, дата изменения).
13. Переход к просмотру записи удобно сделать по двойному клику.
14. Иногда удобен режим предпросмотра, когда по клику открывается не вся запись, а сводка по ней, как в Google Drive.

«Строка в таблице часто является прелюдией к просмотру полной информации по записи. На моей практике в 99% рабочих таблиц модальный режим просмотра уступал просмотру записи на отдельной странице».

Наблюдения

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

Обучение наблюдателей отличается тем, что помимо вводной о проекте к обучению подключается картограф, который подробно объясняет методику наблюдения и принципы работы с картой. Так же, полевиков обучают работе в специальной программе — QGIS.
QGIS — это масштабная открытая геоинформационная система (ГИС), данные которой может использовать любой желающий.

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

Процесс выглядит так: полевик находит проблему, например неправильно припаркованный автомобиль, открывает карту, отмечает на ней место расположения машины; после чего полевик обращается к таблице с категориями проблем — находит там соответствующую проблему, и рядом с точкой на карте приписывает необходимый индекс. Естественно, все это делается на бумаге. Но это ещё не все, после возни с бумагами, полевику необходимо достать смартфон, чтобы сфотографировать неправильно припаркованную машину.

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

По методологии, на наблюдения выходят обычно 4 полевика. Они работают в разные дни, делается это для того, чтобы каждый из них дал свою оценку и увидел то, что мог не увидеть другой (поэтому так важен опыт и внимательность). Иногда только на четвертом проходе обнаруживается какая-то важная пробема..
Получается, работу наблюдателя можно разделить на две части — работа в поле, где он собирает информацию, и обработка полученной информации за программой.
Благодаря этому, исследователям и аналитикам передается уже готовый проект — файл QGIS, где каждая проблема привязана к координатам, имеет индекс, описание и фотографию. Таким образом, информация уже готова для обработки.