Сделал сложную систему оценки доступной

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

Систему оценки ценят опытные, но новички в ней теряются

Проблема

Оценка релиза — главное действие в РЗТ, но система оценки сложная: девяностобалльная шкала, пять критериев и множитель «Атмосферы». Новички видят её без объяснений: у критериев только названия, итог — одна цифра, а полное описание спрятано на странице FAQ. Им кажется, что оценивать долго и сложно, и они не доходят до первой оценки. Опытные пользователи осваивали систему сами — через стримы и привычку — и до сих пор иногда ищут подсказки.

Задача

Сделать так, чтобы новичок понял систему оценки в момент, когда ставит первую оценку, и довёл её до публикации. Саму систему при этом не упрощать: она часть идентичности РЗТ, и опытные пользователи её ценят.

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

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

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

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

1. 01

   UI-аудит

   Аудит интерфейса по эвристикам.

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

2. 02

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

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

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

3. 03

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

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

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

4. 04

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

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

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

5. 05

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

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

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

6. 06

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

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

UX/UI-аудит

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

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

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

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

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

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

HADI-структура

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

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

К системе оценки относились две гипотезы: объяснять её по ходу выставления оценки и разделить быстрый и глубокий сценарии оценки.

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

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

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

Интервью

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

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

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

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

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

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

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

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

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

Решение

Онбординг и подсказки при первой оценке

Систему оценки я не упрощал: она часть идентичности РЗТ, и опытные пользователи её ценят. Вместо этого объясняю её в тот момент, когда она нужна, — обучающим онбордингом при первой оценке и подсказками рядом с критериями.

Обучающий онбординг

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

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

• Когда появляется. Только у нового пользователя, который впервые открыл страницу релиза, — при первом нажатии «+» (добавить оценку) в карточке оценки.
• Как открыть снова. Кнопкой «Как выставить оценку?» над блоком оценивания.
• Где показывается. Зона экрана зафиксирована, и все подсказки появляются внутри неё, поэтому экран не прыгает между шагами.
• Когда перестаёт появляться. После «Понятно» на последнем шаге или после закрытия крестиком онбординг сам больше не открывается — только по кнопке.

1 / 5 · Критерии

Подсказки и валидация оценки

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

Блок оценки

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

Было

Названия критериев без пояснений, итог — одна цифра

Стало

Подсказка под каждым критерием, формула под итогом

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

Описание системы оценивания

Раньше короткая модалка показывала формулу и критерии в аккордеоне, а полное описание лежало на отдельной странице «Часто задаваемые вопросы». Теперь всё собрано в одном окне: что оценивает каждый критерий, таблица множителя «Атмосферы» от 1,0000 до 1,6072 и расчёт итога по шагам.

Было

Короткая модалка, полное описание — на странице FAQ

Стало

Всё описание в одном окне, прокрутите внутри

Валидация

Рецензия необязательна: оценку можно опубликовать и без неё. Поэтому валидация не мешает, пока человек пишет, и включается в нужный момент:

• Когда появляется. Ошибки о пустом поле и минимальной длине — только после нажатия «Опубликовать оценку». Заголовок и текст рецензии проверяются, если хотя бы в одном из этих полей есть символ. Пробелы по краям не считаются, поэтому заголовок из одних пробелов — пустой. Превышение лимита подсвечивается сразу, пока человек печатает.
• Где показывается. Под своим полем: текст ошибки встаёт на место подсказки, поле подсвечивается красным.
• Когда снимается. После ошибки поле проверяется на каждый введённый символ. Как только условие выполнено, ошибка исчезает, а поле возвращается в обычное состояние.
• Счётчики. У заголовка — до 120 символов, у рецензии — до 8 500. Когда рецензия набирает минимум, счётчик становится зелёным.
• Если публикация не прошла. При сбое сети оценка и рецензия сохраняются, и после повтора их не нужно вводить заново.

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

Состояния формы

Кроме ошибок, у формы есть ещё шесть состояний. Гостю она объясняет, что оценивать могут только участники сообщества, и предлагает войти. Перед публикацией просит сверить рецензию с правилами: после отправки её уже не изменить. Рецензия сначала уходит на модерацию, о результате придёт уведомление. После проверки вместо полей появляется сама рецензия, а изменить можно только оценку.

1 / 7 · Без входа

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

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

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

пройти онбординг→выставить критерии→разобраться в итоговой оценке→написать рецензию

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

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

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

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

Онбординг Система оценки

H5. Онбординг объясняет систему оценки и не мешает

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

Проблема

Пользователям не хватало интерактивного обучения, чтобы одновременно с подсказками «испытывать» интерфейс. Из-за этого они закрывали онбординг после 1–2 подсказок.

Решение

Все подсказки стоят в одном месте. Нужные элементы подсвечены и работают: ползунки двигаются, тултипы открываются. Подсказка не исчезнет, пока её не закроют.

Результат

Онбординг проходят до конца: по ходу подсказок двигают ползунки и открывают тултипы.

Итерация 1

Итерация 2

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

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

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

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

Итоги

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

Что дальше

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

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