Интерфейсы *

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

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

Пользователь — не машина. Он устает. Спешит. Тревожится. Делает выводы на основе первых впечатлений.

И вот здесь включаются когнитивные искажения. Разберём 5 самых опасных для UX.

Около 90% фронтенд‑разработчиков в нашей команде используют ИИ‑помощников для написания кода. Лично у меня — и как я могу заметить, у многих — был такой опыт: вы только начинаете пользоваться ИИ‑помощником, просите его сгенерировать какое‑нибудь классное MVP, получаете результат минут за пять и думаете: «Вау, неужели это возможно? Как это вообще работает и как это круто». 

А дальше вас ждёт сюрприз. 

Всем привет, меня зовут Валерий Баранов, я руковожу командой технологий фронтенда в Яндекс 360. Мы занимаемся тем, что сами называем «общим фронтендом»: общими техническими компонентами, общим CI/CD, платформами дистрибуции общих компонентов. Сегодня я хочу рассказать, как мы в Яндекс 360 сделали фронтенд‑проекты по‑настоящему AI‑ready: научили ассистентов понимать структуру наших репозиториев, работать с внутренними библиотеками и даже соблюдать паттерны дизайн‑системы. 

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

В предыдущей части мы разобрали:

Привет, меня зовут Евгений Алаев, я разработчик интерфейсов в команде 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, которой реально будут пользоваться.

На российском рынке электроники сегодня трудно открыть каталог или тендерную документацию и не увидеть формулировку «спроектировано в РФ». Она встречается повсюду: от систем видеонаблюдения до промышленной электроники.

Как инженер-разработчик в компании, которая много лет варится внутри этой кухни, я регулярно сталкиваюсь с путаницей вокруг терминов OEM и ODM. Причём путаница есть не только у заказчиков - иногда и внутри отрасли трактовки «плавают».

В этой статье попробую разобрать где заканчивается OEM и начинается ODM, почему формулировка «спроектировано в РФ» ещё не всегда залог правдивости и что на практике означает глубина собственной разработки. Без попыток объявить кого-то правильным, а кого-то нет. OEM - это не зло. ODM - тоже.  Но понимать разницу сегодня критически важно.

Смотреть шоу, телеканалы, спортивные трансляции, фильмы и другой контент на Smart TV, используя приложения видеоплатформ — уже типовой сценарий. По данным на конец 2025 года, объём потребления контента в VK Видео увеличился в 2,1 раза (на 110%) по сравнению с аналогичным периодом 2024 года. Наибольшее вовлечение аудитории зафиксировано на платформе Smart TV: в начале 2026 года среднее время просмотра на одного пользователя — 241 минута. При этом многие не думают, как устроен софт для большого экрана.

Показываю, как ИИ берёт на себя две трети работы аналитика 1С — и делает её лучше человека.

Написать эту статью меня сподвиг свежий видеокурс «Аналитик. Старт» от Учебного центра №1 1С. Это не реклама: я не только хвалю его, но и покажу, где он неидеален.

В курсе приведен практический пример работы аналитика 1С. Мне стало любопытно – а сколько труда из приведенного примера сможет взять на себя ИИ? Получилось – две трети. Причём решение, предложенное искусственным разумом, оказалось принципиально лучше, чем вариант от учебного центра.