Интерфейсы *

В первой части я показал, как пузырьковая диаграмма помогает увидеть связи в данных, которые не видны в таблице. Но как только данных становится больше — всё начинает ломаться: пузырьки наезжают друг на друга, цвета путают, а статичная картинка перестаёт что-то объяснять.
Это тот момент, где многие говорят: «Ну значит, инструмент не подходит».

На практике — подходит. Просто его нужно довести до рабочего состояния.

В этой части разберу три вещи, без которых bubble chart в реальных задачах не живёт:

• как справляться с наслоением,

• как использовать цвет без визуального шума,

• и как добавить время, чтобы график начал показывать не только «что есть», но и «что происходит».

Покажу на том же кейсе складской аналитики — с интерактивными приёмами, которые реально работают в дашбордах и на встречах.

Честно говоря, я долго не мог решиться написать и опубликовать эту статью. Зачем, думал я, возиться с не самой популярной технологией и изобретать велосипед — реализовывать функции, которые уже где‑то есть? На этот вопрос у меня нет универсального ответа — каждому своё.

Сначала мне казалось, что рассказывать о таких «подвигах» не слишком интересно. Все любят истории об успешном успехе. Потом я вспомнил: главное — не итог, а путь, опыт и знания, которые ты получаешь по дороге. Как только я начал смотреть на материал как на обучающий, делиться им стало намного проще.

Бывает так: с какой то технологией уже разобрался, а вот перейти к новой боязно. Учить новые движки непросто, да и текущий инструмент уже не справляется с задумкой… Сомнения часто мешают двигаться вперёд, но народная мудрость «глаза боятся, а руки делают» никогда не подводит.

В итоге я решился и попробовал FXGL для 3D‑рендеринга. Но не для того, чтобы сделать полноценную игру(хотя она и получилась), а чтобы соединить расчёты по системному моделированию с элементами геймификации. Уточню: я не призываю использовать FXGL во всех случаях. Для серьёзных 3D‑проектов есть отличные инструменты — Unigine, jMonkeyEngine, Godot, Unreal Engine. Я попытался собрать и упорядочить знания, которые получил в ходе своего небольшого эксперимента.

Модальные окна — пожалуй, самый спорный элемент любого интерфейса. Они врываются в процесс, требуют внимания и вынуждают принимать решение прямо сейчас. Поэтому хорошая «модалка» — это не про красивый внешний вид, а про уместность. Про то, чтобы вмешаться в нужный момент и не навредить.

Но чтобы понять, где эта грань, стоит сначала разобраться: а что вообще происходит, когда модальное окно появляется на экране?

Привет, я Таня — работаю ведущим продуктовым дизайнером опыта покупателя в Ozon. Среди моих продуктов «Избранное», «Вишлисты», мини-апп «Доставки посылок», а в прошлом я дизайнила «Карточку товара». Год назад я ротировалась в команду «Корзины», потому что хотела для себя новых вызовов.

На примере редизайна «Корзины», я хочу показать, как сегодня меняется роль дизайнера в продукте, чем дизайн-стратегия отличается от просто красивого концепта, почему такие изменения невозможно делать в одиночку.

28 марта 2026 года инженер Midjourney Cheng Lou выложил в открытый доступ библиотеку, которая за неделю набрала почти 40 тысяч звёзд на GitHub. И имя ей — Pretext. Это движок текстовой верстки на чистом TypeScript, который полностью обходит DOM и браузерный layout рефлоу. За этим стоит вполне большая проблема и красивое решение.

Давайте разберемся, что это такое, зачем оно нужно, как устроено и стоит ли тащить к себе в проект.

Привет! Мы — команда hh.ru: Андрей Панкратов, исследователь пользовательского опыта, Регина Насибулина и Лиза Спицына, специалисты по рекруту респондентов. Мы на регулярной основе проводим интервью с пользователями, чтобы лучше понимать их опыт и быть на связи с соискателями и работодателями. Важный момент: в этих беседах мы ищем не новых сотрудников в компанию, а именно тех людей, которые готовы поделиться опытом использования нашего сервиса.

Рекрут респондентов в hh.ru ведётся двумя способами: через опросы на сервисе и с помощью целевого обзвона аудитории. По итогам 2025 года из 10 согласившихся поучаствовать до интервью доходят только 7.  Остальные отказываются прямо перед встречей или просто перестают выходить на связь. Мы проанализировали причины отказов участвовать, чтобы найти точки роста и повысить мотивацию пользователей.

Привет! Меня зовут Даниил Замешаев, я frontend-разработчик в компании МойСклад, и в том числе занимаюсь развитием внутреннего UIKIT компании.

В этой статье я расскажу про подход к анализу дизайнерских требований для frontend-разработчиков. На примере реального кейса я хочу поговорить о двух практических вещах:

• как анализировать дизайнерские требования так, чтобы на выходе получать понятные технические требования, пригодные для реализации;

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

В основном я буду говорить про UIKIT и компоненты дизайн-системы, но сами принципы применимы к любым макетам и требованиям от дизайнеров, аналитиков и продактов.

В нашу жизнь уже достаточно давно ворвался тренд на дизайн-системы. Пройдя через все стадии принятия, почти все, наверное, уже поняли, что нет того самого идеально-единого-гибкого решения, которое устранит все проблемы, ускорит процесс разработки и исключит изобретение велосипеда (если у кого-то получилось идеально, дайте знать).

Меня зовут Катя Бурлакина, я старший продуктовый дизайнер в VK Tech и занимаюсь развитием дизайн-системы. В этой статье я не буду рассказывать про весь наш путь, а расскажу про его часть — систему дизайн-токенов. Спойлер: при помощи нее у нас получилось устранить некоторые проблемы, ускорить процесс разработки и даже исключить изобретение велосипеда. 

Иногда возникает странное ощущение, что фронтенд уже не про решение задач.
А про поддержание сложности.

Я в разработке ещё до AngularJS и React. Тогда всё было просто: HTML и немного JavaScript — и этого хватало даже для приложений с rich UI.

Потом пришли фреймворки.
Один из первых — AngularJS — и это был вау-эффект.
Ты больше не трогаешь DOM руками. Просто описываешь, что хочешь получить.

Потом: Flux, Redux, TypeScript, Angular 2+. Фронтенд в этот момент стал высокотехнологичным, но в то же время неприятным. Нужно писать кучу обслуживающего кода, не всегда понятно, как оно работает, возникают сложности с отладкой.

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

Эта подборка поможет увидеть актуальные UX-тренды и найти вдохновение для развития собственного e-commerce-проекта.

Привет, Хабр! Меня зовут Саша Митрохина, я руковожу блоком проектной деятельности модерации и взаимодействия с пользователями VK. Сегодня расскажу об одной из самых дорогих кнопок любого цифрового продукта.

В интерфейсе кнопка «Пожаловаться» выглядит почти бесплатной: небольшой элемент UI, который можно добавить за один спринт. Но зачем она вообще нужна?

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

На уровне системы каждое нажатие запускает одну из самых дорогих цепочек обработки в продукте. И чем быстрее растёт аудитория и UGC от неё, тем заметнее становится эта стоимость.

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

Tailwind отлично работает для быстрого прототипирования, но становится проблемой когда проект растёт. Разбираю три подхода к построению дизайн-системы на Tailwind — CVA, CSS-переменные и @utility — и объясняю почему каждый из них не решает проблему комбинаторного взрыва вариантов.

Привет, Хабр.

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

Сегодня хочу рассказать про простые CSS-техники, которые помогут сделать любой интерфейс более дружелюбным к пользователю. Не важно, какие фреймворки и библиотеки вы используете. Мои советы универсальны и могут быть реализованы везде.

Давайте посмотрим, что я вам подготовил.

Здравствуйте, меня зовут Дмитрий Карловский и я.. автор самого крутого на текущий момент (и в ближайшем будущем) фреймворка $mol. Вот уже десяток лет я рассказываю о заложенных в него идеях, которые конкуренты, если и пытаются повторить, то получается у них плохо. За это время вокруг него сложилось множество мифов, которые люди с радостью ретранслируют друг другу для самоуспокоения. Что ж, давайте соберём их все вместе, разберёмся, как они возникли, и как обстоят дела на самом деле.

Далее идёт развеивание мифов, касательно разработки "на $mol" в сравнении с разработкой "на React", как типичной ситуации в индустрии. Но вместо React вы смело можете подставлять любой другой его аналог.

Когда обсуждают AI-generated UI, разговор обычно быстро уходит в одну из двух крайностей.

Первая крайность звучит так: можно ли это сразу нести в продакшен?

Вторая так: насколько результат похож на дизайн-языки, от Apple до Material Design.

Проблема в том, что мы слишком рано начинаем оценивать AI-картинку как почти готовый интерфейс. Хотя во многих случаях она полезна совсем по другой причине. Не потому, что экран уже получился зрелым, воспроизводимым и пригодным для продуктовой среды. А потому, что он принёс редкую визуальную комбинацию, до которой человек вручную шёл бы заметно дольше, либо вообще не полез бы в эту сторону с первой попытки.

Главная польза AI-generated UI часто лежит не в скорости производства экранов, а в поставке визуальных мутаций.

Но и это, как мне кажется, ещё не самый интересный слой темы.

Есть перспектива глубже. AI полезен не только тем, что выбрасывает необычные визуальные сочетания. Он постепенно меняет саму точку входа в процесс. Раньше сильный визуальный ход обычно должен был родиться внутри головы дизайнера. Теперь он всё чаще может возникнуть снаружи, в виде машины, которая массово производит промежуточные формы. После этого дизайнер уже не столько изобретает первый образ, сколько отбирает, фильтрует, нормализует и превращает удачное отклонение в систему.

Именно этот сдвиг, по-моему, и заслуживает более внимательного разговора.

Quirk – браузерный симулятор квантовых схем, "toy quantum circuits simulator".

Его разработал Крейг Гидни (Craig Gidney), инженер, работающий в Google над квантовыми вычислениями. Исходный код открыт, а сам симулятор доступен по адресу algassert.com/quirk

Главная особенность Quirk – симуляция в реальном времени без необходимости запуска вычислений вручную. Схема пересчитывается на каждом кадре с задержкой 0,1 секунды. Автор указывает, что это в 100 раз быстрее реализации на чистом JavaScript.

Стартовый гайд, для тех, кто хочет на простом примере научиться генерировать из Figma как минимум веб-страницу, которая: сделана по дизайну, адаптивна под разные размеры экрана, учитывает retina и non-retina дисплеи, поддерживает локализацию с динамическим переключением языков и позволяет реализовать другие свои хотелки

Когда RuStore только запускался, мы строили дизайн на основе UI-кита от VK — удобно, практично, а главное помогло нам быстро вывести продукт на рынок. Но стор рос, интерфейсов становилось больше, дизайнеры — смелее, а требования — сложнее. И вот настал день, когда мы решили добавить тёмную тему. И всё сломалось. 

Именно тёмная тема вскрыла нашу главную проблему — ранняя структура цветовых токенов не готова к масштабируемости. Любое изменение запускало каскад правок и ломало синхронизацию между макетами и кодом. 

Под катом мы — Элина Шевченко, продуктовый дизайнер RuStore, и frontend-разработчик Андрей Едунов — расскажем историю, как мы полностью перестроили систему, не останавливая разработку, аккуратно вынесли всё из Figma в код и почему теперь можем масштабировать дизайн без драмы, даже если завтра понадобится не только тёмная тема, но и ностальгия по 2008-му, где primary — это чистый #000000, а secondary — оттенок тоски.

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

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

Хабр, привет! Меня зовут Никита Евдокимов, я работаю старшим разработчиком в «Лаборатории Касперского», а также являюсь мейнтейнером репозитория Kaspresso. Это наш фреймворк для тестирования пользовательских интерфейсов на Android, основанный на Kakao, Espresso и UI Automator.

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

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