Репост из: ProductSense
Стартовал второй день продуктовой онлайн-конференции. Публикуем краткий конспект доклада Екатерины Сюма, Product Designer, Miro 🚀
Удалëнные модерируемые UX-тесты: опыт Miro.
Тестирования помогают снижать неопределенность, находить проблемы и улучшать решения на основе инсайтов.
Зачем тестировать:
1) Определяем ключевые бизнес-цели.
2) Тестируем до — находим проблемы.
3) Выпускаем нужные фичи, не выпускаем ненужные
4) Тестируем после — улучшаем продукт.
Нет отдельного исследователя, но есть продакты, продакт-дизайнер, маркетолог и команда.
5 тестов, чтобы выявить основные проблемы → 10 задач, чтобы собрать инсайты → 30 минут на общение с пользователем.
Узнать — это не значит собрать мнения, а наблюдать за поведением пользователей.
Алгоритм:
1) Тестирование прототипа начинаем до запуска решения (с кодом или без).
2) Потом запускаем решение.
3) Тестируем решение в реальном окружении.
✅ Кейс 1: центр уведомлений.
Задача: увеличить активность пользователей.
После интервью пришли к концепции центра уведомлений, который назвали фидом: в виде досок, где можно сразу перейти к уведомлению и ответить на него.
В одной таблице собираем все задачи и гипотезы, трекаем задачи по каждому респонденту. Используем фейсбук, телеграм-каналы, опросы, а также свои инструменты — NPS и тикеты.
Гипотеза: когда пользователи взаимодействуют с фидом, они понимают, что сообщения относятся к разным тредам. Тестирование помогло выявить, что пользователи думают, что это один сплошной тред.
В результате разделили треды по разным карточкам, и это сработало.
После запуска провели юзабилити—тесты. И выяснили, например, что пользователи не знают о фиче или им мало контекста.
✅ Кейс 2: интерактивные фреймворки.
Важно было проверить взаимодействие пользователей, поэтому сделали прототип в коде.
Прототип собрали на хакатоне за пару дней — этого было остаточно, чтобы протестировать его с пользователями.
Выбрали метод RITE (rapid iterative testing and evaluation) — изменения вносятся в прототип после каждой итерации.
Что хотели сделать до тестирования:
— цветовые схемы
— картинки в нодах
— умное поведение горячих клавиш
Что сделали после:
— подсказки
— кнопку автоматического автовыравнивания нодов
— опцию «мультивыделения»
✅ Кейс 3: Miro + Docs.
Придумали Miro Notes — коллаборативный текстовый редактор, встроенный в нашу доску.
Первая итерация: виджет документа для просмотра, для редактирования открывался сайд-бар.
Мы провели пользователей по самим критичным сценариям, чтобы опровергнуть свой концепт. Наша задача в роли исследователей — не гарантировать хеппи энд, а переделывать для получения лучшего результата.
Вторая итерация: новый виджет.
Второй подход помог довести до ума ценность и выкинуть лишнее.
Стадия разработки: отдали концепт людям, чтобы тестировать в живой среде. Бета-тестеров нашли по предыдущим опросам и интервью. Однако мы исключили крупные аккаунты, чтобы минимизировать риски.
Важно: тестировать по чуть-чуть, но делать это постоянно. Нужно вовлекать команду и развивать у них эмпатию.
ИТОГИ
Алгоритм тестирования:
1) Написать скрипт.
2) Дать проверить коллеге.
3) Прогнать в коридоре.
Правила проведения интервью:
1) Собрать инфо о пользователе до интервью.
2) Объяснить сетап (Zoom + PC).
3) Напомнить о звонке за 24 часа.
4) Получить разрешение на запись.
5) Не стучать по клавиатуре (замьютить себя, если ведете заметки).
6) Отключить уведомления.
7) В камере должно быть максимум два исследователя.
8) Расположить человека к себе.
9) Тестировать интерфейс, а не себя.
10) Уточнять, но не давать ответ.
11) Просить пользователя проговаривать все, о чем он думает в процессе.
12) Отстать от пользователя, если не получается получить ответ.
🔥 Подключайтесь к конференции: https://productsense.io/#tickets
Не переживайте, если на что-то не успеете — видеозаписи докладов будут. Записывать мастер-классы не будем.
Удалëнные модерируемые UX-тесты: опыт Miro.
Тестирования помогают снижать неопределенность, находить проблемы и улучшать решения на основе инсайтов.
Зачем тестировать:
1) Определяем ключевые бизнес-цели.
2) Тестируем до — находим проблемы.
3) Выпускаем нужные фичи, не выпускаем ненужные
4) Тестируем после — улучшаем продукт.
Нет отдельного исследователя, но есть продакты, продакт-дизайнер, маркетолог и команда.
5 тестов, чтобы выявить основные проблемы → 10 задач, чтобы собрать инсайты → 30 минут на общение с пользователем.
Узнать — это не значит собрать мнения, а наблюдать за поведением пользователей.
Алгоритм:
1) Тестирование прототипа начинаем до запуска решения (с кодом или без).
2) Потом запускаем решение.
3) Тестируем решение в реальном окружении.
✅ Кейс 1: центр уведомлений.
Задача: увеличить активность пользователей.
После интервью пришли к концепции центра уведомлений, который назвали фидом: в виде досок, где можно сразу перейти к уведомлению и ответить на него.
В одной таблице собираем все задачи и гипотезы, трекаем задачи по каждому респонденту. Используем фейсбук, телеграм-каналы, опросы, а также свои инструменты — NPS и тикеты.
Гипотеза: когда пользователи взаимодействуют с фидом, они понимают, что сообщения относятся к разным тредам. Тестирование помогло выявить, что пользователи думают, что это один сплошной тред.
В результате разделили треды по разным карточкам, и это сработало.
После запуска провели юзабилити—тесты. И выяснили, например, что пользователи не знают о фиче или им мало контекста.
✅ Кейс 2: интерактивные фреймворки.
Важно было проверить взаимодействие пользователей, поэтому сделали прототип в коде.
Прототип собрали на хакатоне за пару дней — этого было остаточно, чтобы протестировать его с пользователями.
Выбрали метод RITE (rapid iterative testing and evaluation) — изменения вносятся в прототип после каждой итерации.
Что хотели сделать до тестирования:
— цветовые схемы
— картинки в нодах
— умное поведение горячих клавиш
Что сделали после:
— подсказки
— кнопку автоматического автовыравнивания нодов
— опцию «мультивыделения»
✅ Кейс 3: Miro + Docs.
Придумали Miro Notes — коллаборативный текстовый редактор, встроенный в нашу доску.
Первая итерация: виджет документа для просмотра, для редактирования открывался сайд-бар.
Мы провели пользователей по самим критичным сценариям, чтобы опровергнуть свой концепт. Наша задача в роли исследователей — не гарантировать хеппи энд, а переделывать для получения лучшего результата.
Вторая итерация: новый виджет.
Второй подход помог довести до ума ценность и выкинуть лишнее.
Стадия разработки: отдали концепт людям, чтобы тестировать в живой среде. Бета-тестеров нашли по предыдущим опросам и интервью. Однако мы исключили крупные аккаунты, чтобы минимизировать риски.
Важно: тестировать по чуть-чуть, но делать это постоянно. Нужно вовлекать команду и развивать у них эмпатию.
ИТОГИ
Алгоритм тестирования:
1) Написать скрипт.
2) Дать проверить коллеге.
3) Прогнать в коридоре.
Правила проведения интервью:
1) Собрать инфо о пользователе до интервью.
2) Объяснить сетап (Zoom + PC).
3) Напомнить о звонке за 24 часа.
4) Получить разрешение на запись.
5) Не стучать по клавиатуре (замьютить себя, если ведете заметки).
6) Отключить уведомления.
7) В камере должно быть максимум два исследователя.
8) Расположить человека к себе.
9) Тестировать интерфейс, а не себя.
10) Уточнять, но не давать ответ.
11) Просить пользователя проговаривать все, о чем он думает в процессе.
12) Отстать от пользователя, если не получается получить ответ.
🔥 Подключайтесь к конференции: https://productsense.io/#tickets
Не переживайте, если на что-то не успеете — видеозаписи докладов будут. Записывать мастер-классы не будем.