На связи Антон Черный, лид команды продуктового дизайна. На примере типовой задачи рассказываю, как мы пересобрали UX-процесс и ускорили проверку гипотез с помощью AI-first прототипирования.
Пользователи DeFi‑приложений — независимо от опыта — в первой сессии сталкиваются с нагрузкой, где нужно разбираться в ключах, адресах, комиссиях, пулах ликвидности и пр., что становится причиной финансовых ошибок и высокой доли отказов
Проверил гипотезу влияния выбора модулей приложения в онбординге на устойчивость к ошибкам, понятность и скорость сценариев перевода, обмена и стейкинга
50 итераций колесом мыши, чтобы просмотреть содержимое одного выпадающего списка. Это не баг — это фича Хабра и десятков других сайтов.
Мы часто думаем, что плохой интерфейс — это про кнопки, цвета или сетку. Но чаще он ломается не из-за пикселей. А из-за того, что дизайнер не учитывает, как на самом деле работает мозг.
Пользователь — не машина. Он устает. Спешит. Тревожится. Делает выводы на основе первых впечатлений.
И вот здесь включаются когнитивные искажения. Разберём 5 самых опасных для UX.
Около 90% фронтенд‑разработчиков в нашей команде используют ИИ‑помощников для написания кода. Лично у меня — и как я могу заметить, у многих — был такой опыт: вы только начинаете пользоваться ИИ‑помощником, просите его сгенерировать какое‑нибудь классное MVP, получаете результат минут за пять и думаете: «Вау, неужели это возможно? Как это вообще работает и как это круто».
А дальше вас ждёт сюрприз.
Всем привет, меня зовут Валерий Баранов, я руковожу командой технологий фронтенда в Яндекс 360. Мы занимаемся тем, что сами называем «общим фронтендом»: общими техническими компонентами, общим CI/CD, платформами дистрибуции общих компонентов. Сегодня я хочу рассказать, как мы в Яндекс 360 сделали фронтенд‑проекты по‑настоящему AI‑ready: научили ассистентов понимать структуру наших репозиториев, работать с внутренними библиотеками и даже соблюдать паттерны дизайн‑системы.
Продолжаем рассматривать случаи, когда изменения в интерфейсах и сценариях их использования помогают продукту работать эффективнее.
В предыдущей части мы разобрали:
Привет Хабр!
Дисклеймер:
в данной статья я не преследую цель опорочить репутацию Яндекса, с этим они и сами справятся. Я лишь хочу достучаться до них и подсветить проблемы, которые, по моему субъективному, не должны быть у таких гигантов так много лет. Все чувствительные пользовательские данные на скринах намеренно заблюрил, во избежание нарушений законодетельства, но в правом верхнем углу оставил время и дату, как пруфы.
Я настраиваю рекламу в Яндекс Директе с 2017 года и на протяжении этих лет я наблюдаю проблему, с которой неоднократно и безуспешно обращался и в поддержку, и к персональным менеджерам. Каждый раз я получал шаблонный ответ отписку, который не давал ответа на вопрос и разваливается от моих последующих аргументов или мне назначался новый менеджер, которому я заново объяснял все и так было несколько раз. Если честно, то я уже давно смирился. Но так как только за мои 9 (!) лет использования ЯД, проблема все еще не решена, я решил о ней рассказать.
Итак, к самой проблеме. Она в отображении конверсий в интерфейсе. Да да, это одна из главных сущностей, по которой меряется эффективность рекламных компаний и потраченных на нее денег.
Заходим в Директ Про
Выбираем фильтр «этот месяц» и цели настроенные в кампании.
Открываем "обзор" и видим 10 конверсий.
Привет, меня зовут Евгений Алаев, я разработчик интерфейсов в команде Yandex DataLens. Это облачный BI‑инструмент для анализа данных и построения дашбордов, и графики в нём — не «одна из фич», а сердце продукта. Пользователь открывает дашборд и первое, что видит, — визуализации. Именно они отвечают на вопрос: «Что происходит с моими данными?»
DataLens работает в двух инсталляциях — для самого Яндекса и для внешних пользователей. Суммарно на сегодня создано больше 18,3 млн графиков. Каждый из этих графиков — результат работы той самой библиотеки визуализации, о которой пойдёт речь.
Долгое время графики в DataLens строились на Highcharts. Поначалу это был разумный выбор: быстрый старт, богатый набор типов, большое сообщество. Но BI‑инструмент со временем становится сложнее — появляются нестандартные требования к поведению, дизайн‑система, которую нужно выдерживать в едином стиле. И в какой‑то момент Highcharts начал мешать больше, чем помогать.
В этой статье расскажу, как и почему мы приняли решение написать собственную опенсорс‑библиотеку для визуализации — @gravity‑ui/charts. Мы с коллегой — core‑контрибьютеры этой библиотеки, так что я в подробностях расскажу, что нас не устраивало в Highcharts, какие альтернативы рассматривали, как устроена архитектура и с какими конкретными техническими вызовами столкнулись в процессе.
Половина сотрудников увольняется, не проработав и месяца. Новички ошибаются, опытные перегорают, а отдел сортировки лаборатории напоминает проходной двор. В попытке решить эту проблему мы поняли простую вещь: всё внимание пользователя сосредоточено на пробирке, экран лишь помогает. Рассказываю, как мы пересобрали онбординг, встроив его в «танец» сортировщика, и получили измеримый бизнес‑результат.
Меня зовут Герман, я 8 лет занимаюсь B2B‑продуктами и сложными производственными системами.
Привет Хабр!
Меня зовут Дмитрий Гаврин, я заместитель директора департамента «Цифровые решения» компании «Диасофт». Есть тип совещаний, которые я узнаю с первой секунды по интонации приглашения. Когда директор проекта пишет «зайди, поговорим по цифрам» - это не про то, что кто-то перевыполнил план. Это про интеграцию. Почти всегда про нее.
Привет всем!
Ко мне часто обращаются молодые инженеры с вопросом: «А зачем вообще идти в аспирантуру?» Я обычно рассказываю, какие плюсы и минусы есть у такого шага — как учёба прокачивает навыки, помогает упорядочить знания и освоить грамотную постановку экспериментов. Но выбор каждому нужно делать самому, стоит ли прокачивать такие навыки или нет.
И вот во время одного такого разговора, погрузившись в воспоминания о собственных научных делах, я случайно наткнулся в интернете на хакатон. И угадайте, по какой теме? По диагностике асинхронных электродвигателей — прямо в точку! Своего рода - мой незакрытый гештальт во время собственного обучения.
Решили с товарищем поучаствовать. Правда, мы были вдвоём, а в команде могло быть до 9 человек. Спойлер: мы не взяли первое место и даже не попали в шорт‑лист из 9 команд — заняли 16‑е место из 35.
Да, это не история про успех, а про опыт — тот самый, который, как известно, «сын ошибок трудных». Главный урок прост: да, быть экспертом и действовать в одиночку — это неплохо. Но настоящая суперсила — в команде!
А теперь — обо всём по порядку…
Привет, Хабр! Я Виктория Левена, руководитель отдела аналитики в AGIMA. По моему опыту редизайн часто начинается с ощущения, что что-то не так. Кажется, наш сайт выглядит устаревшим. Кажется, технологии и пользовательские привычки меняются — и нам тоже надо. Кажется, никому в команде не нравится сайт, но никто не может объяснить, почему. С такими ощущениями сложно работать: непонятно, что менять, и главное, как потом доказать, что стало лучше, а не просто по-другому.
На проекте по редизайну сайта «Халвы» мы как раз оказались в этой точке. И в этой статье я хочу поговорить не столько про дизайн, сколько про измерение его результата. Как понять, что пользовательский опыт действительно стал лучше? Какие метрики помогают это увидеть, а какие создают ложное чувство уверенности? И почему цифры иногда обманывают — даже когда выглядят убедительно?
Решил с понедельника открыть сезон стримов на Ютубе. Идея банальная: показывать вживую, как я проектирую и вайбкодю пет-проект. Ну как пет-проект… В мае ему уже исполнится год и по архитектуре и функциям он разросся настолько, что уже приходится относиться к нему со всем уважением :-)
Пошёл в ChatGPT, поделился идеей. «Идея замечательная!» — сказал чат и начал уже было расхваливать меня, но я его остановил. «Мне нужна помощь с OBS: хочу сделать в стриме плашку с информацией: кто я, что прямо сейчас делаю, ссылки, время, вот это всё». «Спокойствие, сейчас всё объясню!» — сказал ChatGPT — и именно с этого началась моя история, в которой я впервые за долгое время реально разозлился на ИИ.
Привет, меня зовут Ваня, я работаю в Атоме техническим специалистом и мне часто приходится взаимодействовать с электромобилем. Я организую его логистику на выставки и мероприятия, сопровождаю на событиях, помогаю устанавливать его на стендах и участвую в разных спецпроектах.
Так вышло, что за последний год мне удалось протестировать Атом в самых разных сценариях. Это и обычная городская эксплуатация в Москве с пробками, парковками и плотным потоком, и тестовые поездки в других регионах, и участие в выставках, и даже поездки в северные города с суровыми морозами.
Скоро первые покупатели уже получат свои Атомы, а пока делюсь своим опытом эксплуатации и впечатлениями от этого электромобиля.
Внутренний трекер задач — Яндекс Трекер — важная часть Яндекса. В нём хранятся почти все планы: от целей отделов, до тикетов поддержки. RPS на фронтенд измеряется сотнями, а количество хитов в месяц — десятками миллионов. При таком масштабе даже небольшие задержки могут становиться критичными, поэтому мы задались целью ускорить Трекер. Спойлер: всё получилось не совсем так, как мы ожидали. Но обо всём по порядку.
Для измерения скорости сервисов в Яндексе используется метрика Velocity Index — это агрегация метрик Web Vitals (FCP, LCP, TBT, INP, CLS). Итоговое значение получается в диапазоне от 0 до 100 баллов. Хорошим результатом считается индекс больше 85.
Мы поставили себе амбициозную цель: увеличить Velocity Index до 85, а заодно подлечить очевидные «узкие места» в скорости и ускорить всё, до чего сможем дотянуться.
Но до заветных 85 баллов мы так и не добрались.
До этого мы говорили о том, где лучше не экспериментировать. Но интерфейсы все же меняются — и иногда довольно радикально. Это подтверждается современными UX-трендами и анализом развития интерфейсных решений.
Это происходит не из-за желания обновить визуал, а из-за изменений в сценариях работы: растет объем данных, усложняются процессы, увеличивается частота операций, появляются новые устройства. В таких условиях старые решения начинают замедлять работу. Сейчас мы начнем рассматривать именно эти случаи — когда изменения в интерфейсах и сценариях их использования помогает продукту работать эффективнее.
Еще недавно большинство действий в цифровых продуктах строились вокруг страниц и кнопок. Затем появились мобильные устройства, свайпы, жесты, бесконечные списки и контекстные действия. То, что сначала казалось непривычным, со временем стало стандартом.
Хороший пример — автосохранение. Когда-то закрыть документ без ручного сохранения означало потерять работу. Сегодня автосейв — базовое поведение системы, о котором пользователь даже не задумывается. Та же история с бесконечной прокруткой. Infinite scroll начинался как экспериментальная альтернатива пагинации, а сейчас это норма для лент, каталогов и социальных сервисов.
Чаще это происходит в B2C-продуктах, где аудитория легче адаптируется к новому. В B2B все иначе: интерфейс — рабочий инструмент. Любое изменение влияет на скорость работы и экономику процессов. Поэтому здесь особенно важно понимать, где нововведение действительно улучшает сценарий.
Когда в продукте идет одновременно много разных процессов, о которых надо сообщить пользователю, он начинает зарастать тултипами, турами и всплывающими окнами о новых фичах. Кроме этого есть еще уведомления из мессенджеров и календаря. Я попробовала найти научные исследования про то, каким процессам в работе программиста это мешает сильнее всего и какие именно уведомления самые вредные.
Два года назад рынок обсуждал, заменят ли нейросети дизайнеров. В 2026-й мы вошли с другим вопросом: как изменилась сама профессия и требования к ней.
Чтобы не ограничиваться личным мнением, мы собрали комментарии дизайн-лидов из крупных российских компаний — финтеха, e-Com, экосистемных сервисов. Их ответы показывают: сегодня дизайн — это роль в бизнесе, архитектура продукта и работа с пользовательским восприятием. Разберемся, как AI встроился в практику и какие задачи по-прежнему остаются за человеком.
Привет, Хабр!
Мне нравятся красивые и удобные интерфейсы. С самого начала карьеры я всегда старался делать всё, что мог для комфорта пользователя. Этим я выделялся среди коллег. Большая часть из них не тратили время, продумывая взаимодействие пользователя с интерфейсом.
Я даже думал, что есть разработчики, которые специально хотели помучить пользователей. К сожалению, тогда я ничего не знал об ужасных интерфейсах, поэтому не мог помочь им. Хочу исправиться!
Сегодня я рассмотрю несколько практических ловушек, из-за которых пользователи вспомнят разработчиков не очень хорошим словом. Будьте в этом уверены. В основном мы будем использовать только HTML. Так что вы быстро сможете внедрить их в свои проекты.
Давайте посмотрим, что я вам подготовил.
Почему большинство CRM не работают в автосервисах "Гараж", ?
Потому что их проектируют 30-летние разработчики,
а используют 45-летние мастера, в мазуте и информация о пк заканчивается на Скайпе.
Когда я взял в аренду автосервис, оказалось, что: весь учёт ведётся в блокноте и это норма у 80% автосервисов, сложные CRM никто не хочет открывать, интерфейс должен быть быстрее бумаги
Это история о демографии отрасли, UX для мастеров и попытке сделать CRM, которой реально будут пользоваться.
