UX головного мозга🧠

Вот вроде такая фигня, но эти виртуальные медальки в iOS меня оч мотивируют ходить и тренироваться больше Лучший пример ever геймификации в интерфейсе

К нашему последнему посту, вот он реальный фидбек от юзеров😅

Я.Музыка vs Spotify: кто круче? Как будто только ленивый ещё не написал про обновление дизайна Я.Музыки. Очередь теперь дошла и до меня 🥲 Я оч не люблю, когда в продуктовом дизайне начинают придумывать «новые подходы». Есть очень много адептов такого направления, обычно это люди, которые придерживаются подхода «графического дизайна» в плохом смысле этого слова: они привыкли мыслить не удобством, а красотой. Что бросается в первую очередь в новом дизайне? Лично мне бросился в глаза таббар. Да, это красиво, модно и молодежно. Но блэт, как я без подписи пойму че обозначает эта иконка? Ок, есть какие-то общие стандартные метафоры типа профиля, главной, поиска и корзины. Но тут ребята использовали нестандартные метафоры, и это пипец какая когнитивная нагрузка, особенно в первые разы. Тут вспоминаются базовые UX-законы: пользователю проще узнавать, чем вспоминать. А ещё люди ожидают знакомые паттерны, потому что они живут не в одном вашем приложении. Spotify в этом смысле скучный, зато понятный: домик, поиск, медиатека — всё подписано, всё считывается. У Я.Музыки визуально стало свежее и дерзче, но местами ощущение, что красота победила узнаваемость. А таббар — это всё-таки не место для дизайнерского самовыражения. Это навигация, она должна помогать, а не устраивать пользователю квест «угадай раздел по загогулине». Как тебе новый дизайн Я.Музыки? Минус вайб или плюс вайб?

Вайб или не вайб?

Продуктовый дизайнер — это продакт на полшишечки? И да, и нет. Да — продуктовый дизайнер должен шарить не только за «красивую кнопочку вот тут». Он должен понимать юзабилити, сценарии, ограничения разработки, бизнес-метрики и вообще иногда открывать аналитику, не падая в обморок. Потому что если дизайнер не понимает, как его решение влияет на конверсию, удержание, GMV, средний чек или хотя бы количество матерных сообщений в поддержку, то это не продуктовый дизайн. Это декоративно-прикладное искусство в Figma. Но нет — продуктовый дизайнер не становится продактом «лайт». Фокус дизайнера всё-таки на пользовательском опыте: чтобы человек понял, куда он попал, что ему делать дальше, почему это удобно, безопасно, предсказуемо и не вызывает желания удалить приложение вместе с воспоминаниями о нём. Продакт тоже должен думать про пользовательский опыт. Но его основной фокус чаще всего — бизнес: деньги, рост, метрики, приоритеты, стратегия, сроки, рынок, стейкхолдеры и вот это прекрасное «нам надо MVP за две недели, но чтобы как у Apple». А дизайнер в этой истории — человек, который постоянно держит в голове неприятный вопрос: «А пользователь вообще вывезет то, что мы тут придумали?» И вот здесь начинается самое интересное. Хороший продуктовый дизайнер не просто рисует интерфейс. Он помогает продукту не превратиться в Excel с тенями и скруглениями. Он замечает, где бизнес хочет впихнуть ещё один баннер, ещё один попап, ещё один “важный” блок, потому что «ну нам же надо подсветить выгоду». А потом внезапно выясняется, что пользователь пришёл не любоваться выгодой, а просто купить шампунь и уйти жить свою жизнь. В идеальном мире продакт и продуктовый дизайнер — не конкуренты за звание «главного по продукту», а две разные оптики. Продакт чаще спрашивает: «Как это поможет бизнесу?» Дизайнер чаще спрашивает: «Как это переживёт пользователь?» И нормальный продукт рождается где-то между этими двумя вопросами. Проблемы начинаются, когда дизайнеру говорят: «Ну ты же продуктовый, значит, сам придумай стратегию, посчитай экономику, защити перед советом директоров, нарисуй макеты, собери прототип, проведи исследование, напиши тексты, анимации тоже сам, и ещё презентацию красиво оформи». То есть не «продакт на полшишечки», а целый стартап в одном человеке. Только без опционов. Поэтому нет, продуктовый дизайнер — это не недопродакт. Это отдельная роль с продуктовым мышлением, но с фокусом на опыт, поведение и здравый смысл в интерфейсе. А здравый смысл, как мы знаем, в продуктовых командах иногда самый дефицитный ресурс.

Адский UX программы для сдачи экзаменов ГИБДД Я уже около 3 месяцев учусь на права. Это адский опыт, но оставим этот рассказ на потом. Пару дней назад пошла сдавать внутренний экзамен по теории. Села за комп, открыла программу и поняла, что это не экзамен, а аттракцион «угадай, куда нажать, пока у тебя тахикардия». Ты и так в стрессе, потому что нужно сдать 5 билетов по 20 вопросов без ошибок, иначе пересдача за деньги. А перед тобой интерфейс, который выглядит так, будто его последний раз обновляли вместе с ICQ. Кнопки похожи друг на друга, главный сценарий неочевиден, фидбек считывается плохо. Где выбран ответ, где его подтвердить, что уже засчиталось — разбирайся сама. После этого инструктор по теории сказал: «Ой, у меня такое впервые, что человек не понял, куда нажимать». Ну да, конечно. Если человек не понял базовое действие, это точно уникальный дефект человека, а не интерфейс, который не смог объяснить, что от него хотят. Самое смешное, что когда я поставила эту же программу дома и прошла её без стресса, я сдала с первого раза. Сделала одну ошибку, получила 5 дополнительных вопросов и решила их правильно. То есть проблема была не в знаниях, а в том, что в стрессовой ситуации тебе дают интерфейс, который сам нуждается в обучении. Короче, внутренний экзамен по ПДД стал лучшим UX-исследованием месяца. Респондент — я, методика — боль, вывод — если интерфейс выглядит как наказание, люди почему-то страдают. Делитесь своими историями как интерфейс вас подставил

Ты сеньёр или джун?

История заказов больше не кладбище покупок В Lamoda в профиле появился раздел «Гардероб»: там показывают образы, которые можно собрать с вещами, которые вы уже покупали. Это хорошая продуктовая идея: приложение не заканчивает сценарий на «спасибо за заказ», а помогает понять, что с этой вещью делать дальше. Для пользователя это вдохновение: «О, оказывается, эту юбку можно носить не только с белой футболкой». Для бизнеса — мягкая допродажа. Ты смотришь образ с вещью, которая у тебя уже есть, и начинаешь видеть, чего не хватает до полного лука. По сути, Lamoda превращает историю заказов не в склад чеков, а в персональную витрину. Единственное, лейбл «есть у вас» выглядит так, будто интерфейс шепчет из шкафа. Но сама идея — очень продуктовая.

Окей, гипотеза есть. Дальше интервью или сразу A/B-тест? Вот тут важно не начинать с «давайте сделаем интервью» или «давайте запустим опрос». Метод выбирается не потому, что он модный, быстрый или у вас уже оплачен Maze, а потому что он отвечает на конкретный вопрос. Если мы хотим понять, почему пользователь не понимает экран, как он читает лейбл, где у него ломается логика и что он ожидает увидеть после действия — это качественное исследование. Интервью, модерируемый usability test, коридорка, разбор сценария. Тут важно услышать ход мысли, а не просто получить цифру. Если мы хотим понять, сколько пользователей отваливается, на каком шаге, какая версия работает лучше и стало ли меньше ошибок после изменения — это количественное исследование. Аналитика, воронки, опросы, A/B-тесты, немодерируемые тесты на большой выборке. Проще говоря: если мы ещё не понимаем природу проблемы — идём в качественные методы. Если уже поняли проблему и хотим проверить масштаб или эффект решения — идём в количественные. Главная ошибка — пытаться пятью интервью доказать, что «все пользователи тупят», а графиком воронки объяснить, что у человека было в голове. Воронка покажет, где пользователь отвалился. Но она не скажет: «Я подумал, что ваша плашка — это реклама, поэтому проигнорировал». Метод выбирается под вопрос, а не наоборот. Сначала гипотезы, потом что именно проверяем, потом уже инструмент. А не как обычно: «у нас есть молоток, давайте найдём пользователя, который похож на гвоздь».

Как формулировать гипотезы для UX-исследования, чтобы получить вменяемые результаты? Плохая гипотеза: «Пользователям непонятен экран». Супер. Осталось только понять, каким пользователям, что именно непонятно, в каком сценарии, почему и что мы потом с этим знанием будем делать. Ну то есть вообще всё. Хорошая гипотеза — это не «давайте добавим плашку». Это проверяемое предположение о том, где у пользователя ломается понимание или действие. Не так: «Нужно добавить лейбл, чтобы было понятнее». А так: «Пользователь может не понять, что набор собран, потому что статус выгоды не связан с конкретными товарами. Проверяем, сможет ли он без подсказки объяснить, какие товары входят в набор и почему применилась скидка». В Lean UX у Джеффа Готхельфа гипотеза строится вокруг связки: пользователь, проблема, решение и ожидаемый результат. В методологии JTBD фокус вообще не на том, куда человек ткнул, а на том, какую задачу он пытается решить в конкретной ситуации. Поэтому нормальная гипотеза отвечает на три вопроса: - Что мы думаем происходит? - Почему это может происходить? - Как мы поймём, что были правы или ошиблись? Формула примерно такая: «Мы предполагаем, что [тип пользователя] в [сценарии] сталкивается с [проблемой], потому что [причина в интерфейсе]. Из-за этого он [ошибка/сомнение/неверное действие]. Проверяем, сможет ли пользователь [конкретное действие] без подсказки». Главное — не путать гипотезу с любимым решением продакта. Плашка, кнопка, баннер и «давайте просто подсветим зелёненьким» — это не гипотезы, это уже варианты лечения. А перед лечением неплохо бы сначала понять, что именно у пользователя болит.