Собрал релиз, оценку и рецензии на одной странице

Проблема, задача, ограничения

Страница релиза — центр главного сценария, но её трудно быстро считать

Проблема

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

Задача

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

Ограничения и как я с ними работал

Рабочий процесс

От аудита к проверенным решениям

Каждое решение опирается на данные предыдущего шага: аудит дал гипотезы, интервью и тесты их подтвердили или отсеяли, а дизайн проверялся повторным тестированием.

1. 01

   UX/UI-аудит и конкурентный анализ

   Бенчмаркинг 6 платформ и аудит интерфейса по эвристикам.

   Проблем нашлось много, поэтому нужно было выбрать главные.

2. 02

   Гипотезы и приоритизация

   Каждую проблему перевёл в гипотезу по HADI-структуре и приоритизировал по адаптированной ICE.

   Гипотезы нужно было проверить на реальных пользователях.

3. 03

   Глубинные интервью

   Поговорил с новичками и опытными пользователями РЗТ.

   После всех исследований появилась опора для изменений в интерфейсе.

4. 04

   UI-кит и редизайн

   Визуальная система и контентные блоки.

   Главное действие в РЗТ — оценка релиза, и весь путь к ней проходит через страницу релиза. Поэтому следующим шагом стала она.

5. 05

   Ключевой сценарий — страница релиза

   User flow AS IS и TO BE, метаданные релиза, вход и регистрация, рецензии.

   Решения нужно было проверить на пользователях.

6. 06

   Юзабилити-тест

   Модерируемый тест кликабельного прототипа с новичками.

UX/UI-аудит

Где продукт теряет новичка

Конкурентный анализ

Прямого аналога РЗТ в СНГ нет, поэтому я изучил музыкальные и контентные платформы со схожими сценариями и сравнил в таблице бенчмаркинга: структуру сервисов, работу с основной единицей контента, оценки и рецензии, поиск нового контента, рейтинги и социальные механики.

UI-аудит по эвристикам

Проанализировал основные экраны и зафиксировал проблемы прямо на скриншотах. Что проверял:

• Визуальная иерархия
• Консистентность компонентов и состояний
• Сетка и группировка
• Типографика и контраст
• Понятность иконок и цветов
• Обратная связь интерфейса
• Отображение оценок

Гипотезы и приоритизация

От проблем к проверяемым гипотезам

HADI-структура

Каждую проблему из аудита я описал цепочкой по адаптированному HADI-циклу:

проблема→гипотеза→решение→способ проверки→метрика

К странице релиза относились две гипотезы: показывать визуальную расшифровку оценки и выводить рецензию вместе с понятной оценкой.

Приоритизация по ICE

Приоритизировал гипотезы по адаптированной модели ICE: разделил сложность реализации на дизайн и разработку, чтобы не недооценивать проектирование и проверку.

Цвет строки — приоритет:низкийвышевысокийсамый высокий

Интервью

10 интервью с двумя сегментами

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

Новички Опытные

Подтверждение гипотез

Итоги исследований

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

Что показала проверка

Итоговые выводы

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

User flow оценки

User flow: оценка релиза и рецензия

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

Путь новичка до первой оценки

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

Схемы целиком

Новый и опытный пользователь. Схема открывается крупно по клику.

AS IS TO BE

Страница релиза

Страница с главным сценарием

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

Редизайн страницы

Проблемы страницы пришли из интервью с опытными пользователями и новичками.

Было

Стало

Вход и регистрация

Раньше вход и регистрация были отдельной страницей: чтобы оценить релиз, приходилось уходить с него и заполнять длинную форму. Теперь они открываются в модальном окне прямо на странице релиза, и пользователь не выпадает из сценария оценки. Убрал «причину регистрации» и обязательное подтверждение автора через соцсети: статус автора можно подтвердить позже в профиле.

Вход Регистрация

Было

Отдельная страница: чтобы войти, нужно уйти с релиза

Стало

Модальное окно поверх страницы релиза

Ошибки

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

Было

Стало

Матрица ошибок — 12 ситуаций во входе и регистрации и текст, который видит пользователь

Юзабилити-тест

Что показал тест прототипа

После первой итерации я провёл модерируемый юзабилити-тест на кликабельном прототипе с новичками. Формат простой: одна гипотеза — одно задание, затем наблюдение и вывод. Задания покрывают путь новичка целиком:

понять, что это за сервис→найти релиз→оценить его→написать рецензию

Всё, что подтвердилось с уточнением или не подтвердилось, я поправил во второй итерации.

Вторая итерация

Поправил и протестировал

Каждая правка закрывает гипотезу, которая подтвердилась с уточнением или не подтвердилась. Все правки я проверил повторным тестом на тех же заданиях. UI-кит не менялся: все правки собраны на тех же компонентах.

Моя оценка Оценка без входа Модерация Оценка в рецензии

H4. Пользователь сам находит, где поставить оценку

Подтвердилась с уточнением→Подтвердилась

Проблема

Плюс в блоке оценки замечали, но не нажимали на него, чтобы перейти к оценке. Они просто скролили до блока оценки.

Решение

При первом заходе плюс в блоке «моя оценка» мягко мерцает. Его замечают, нажимают и сразу переходят к оценке.

Результат

Участники сами нажимают на плюс и переходят к оценке, а не скролят мимо него.

Итерация 1

Итерация 2

Метрики успеха

Как измерять успех редизайна

Редизайн — инициативный концепт, поэтому доступа к продуктовой аналитике и данных «до» у меня не было. Два юзабилити-теста показали, что решения работают на прототипе, но это нельзя назвать статистикой. Поэтому ниже я описываю план: какие метрики можно было бы измерить и как их посчитать.

Воронка оценки

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

Метрики и как их посчитать

Итоги

Что получилось

Что дальше

• Количественный тест. Провести количественный тест на большей выборке, новичках и опытных, и замерить время и долю завершённых оценок. Два качественных теста этих цифр не дают.
• Реальные метрики. Вместе с разработкой настроить продуктовую аналитику и события на каждом шаге воронки оценки, снять базовые значения и следить за метриками из раздела «Метрики успеха» уже на живых данных. Новые функции запускать через A/B-тест.

Другие кейсы проекта