Ошибки в UX у Хабр

Прохожу полный путь новичка на Хабр от регистрации до заполнения профиля и отмечаю критические ошибки в интерфейсе с позиции UX/UI дизайна и принципов эвристики доступности

Регистрация

Как только пользователь проходит регистрацию и подтверждает почту, он ожидает, что попадет на ту же самую страницу, откуда начал регистрацию. Это базовый принцип UX, заключающийся в предсказуемости. Однако пользователя переносит на техническую страницу, которая явно неуместна в данном пути пользователя:

Скрин приветствия

Мыслим с позиции юзера: для чего человеку, который только что указал свой актуальный email и пароль понадобится их менять?

Чтобы отсюда перейти на, например, на ленту статей Хабра, пользователь вынужден зайти в бургер-меню > выбрать Хабр > попасть в ленту > снова войти в аккаунт > и только теперь пользоваться продуктом. Это целых две ошибки: перегруженность интерфейса и нарушение принципа последовательности по Нильсену.

При повторной инициации входа на сайт вышла такая ошибка:

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

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

Онбординг

Хабр настоятельно запрещает пользователю пользоваться продуктом. Это нарушает эвристику контроля и свободы в интерфейсе.

Теперь нужно пройти онбординг и ответить на вопросы. Я не просто так написал, что это нужно, а не можно: кнопка "пропустить онбординг" просто не работает. Даже с выключенным блокировщиком.

Скринкаст

Однако, пройдя первый вопрос, все таки можно вернуться назад и кнопка "Пропустить" на этот раз станет активна.

Это нарушение сценария взаимодействия. Уже на этапе принуждения к опросу, большая часть пользователей разозлится и покинет сайт.

Авторизация

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

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

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

Скрины окна авторизации

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

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

Если же отключен только вход через зарубежные сервисы, из-за нового закона, и почта все таки синхронизируется (например, если это mail/yandex), нужно убрать вариант входа через недоступные ресурсы, опять же, проинформировав пользователя о том, что его аккаунт никуда не пропал и доступен, например, по коду подтверждения на почту

Отсутствие подсказок

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

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

Хотя в случае с X (Twitter), система и вовсе не даст пользователю понять в чем ошибка. Ни один из испробованных вариантов формата ввода не подошел.

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

По закону Постеля (будь требователен к тому, что отправляешь, и лоялен к тому, что принимаешь), не нужно бить палкой пользователя, за то, что тот скопировал и вставил ссылку, или по привычке указал @. Молча обрабатываем ссылку, валидируем и сохраняем.

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

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

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

Также сделал копирайтинг заголовка для блока и убрал инструкцию за ненадобностью

Инклюзивность

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

Хабр просит убирать крупные фото под спойлер для сокращения расхода трафика пользователя. Это костыль, который только снижает удобство чтения статей. Надо перестать перекладывать инфраструктурные задачи на пользователей.

Решить проблему совершенно не сложно. Нужно конвертировать все медиафайлы из тяжелых PNG, JPG и т.п. в легкие веб форматы AVIF или WEBP. Это снизит вес фото на 95-98% без потери качества. Принцип работы:

1. Автор загружает любой тяжелый PNG/JPEG. Он падает в S3 в оригинальном качестве

2. В коде статьи ссылка на картинку ведет не напрямую на S3, а через прокси-сервер (imgproxy или Thumbor)

3. Когда читатель открывает статью, его браузер отправляет запрос на картинку. В заголовках запроса (Accept) браузер сообщает, какие форматы он поддерживает (современные браузеры отдают приоритет image/avif и image/webp)

4. imgproxy на лету сжимает картинку из S3 в AVIF (или WebP, если это какой-нибудь старый хлам типа Safari на древней iOS), кэширует результат на уровне CDN и отдает пользователю

По данным Can I use веб форматы медиаконтента имеют доступность более 96%, результат будет на лицо. Статья даже в метро с ешкой будет летать

Итог

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

Пользователю не платят деньги, чтобы разбираться в том, как устроен сайт и почему у него ничего не работает. Он молча уходит и навсегда заб(ы/и)вает о нем.

Бонус

Чтобы резюмировать описанное, визуализировал путь новичка со всеми критическими точками и барьерами на User Flow. Показывает, где именно ломается пользовательский опыт.