Интерфейсы *

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

Я в разработке ещё до 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.

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

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

В этом выпуске пробежимся по самым интересным новостям марта, которые точно стоит посмотреть и взять себе на заметку:

1) Кит — маскот Firefox
2) Новинки от Apple
3) Слоты в Figma
4) Сразу два новых шрифта: Snickers Sans и TikTok Sans
5) Апдейт Google Stitch
6) Интересный UX-кейс с «читами»
7) Дизайн для «Backstage Roasters»
8) SVG-иконки и новые эмодзи
9) «Агентурная» работа прямо на холсте Figma

На связи Антон Черный, лид команды продуктового дизайна. На примере типовой задачи рассказываю, как мы пересобрали UX-процесс и ускорили проверку гипотез с помощью AI-first прототипирования.

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

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

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

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

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

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

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

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

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

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

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

Привет Хабр!

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

Я настраиваю рекламу в Яндекс Директе с 2017 года и на протяжении этих лет я наблюдаю проблему, с которой неоднократно и безуспешно обращался и в поддержку, и к персональным менеджерам. Каждый раз я получал шаблонный ответ отписку, который не давал ответа на вопрос и разваливается от моих последующих аргументов или мне назначался новый менеджер, которому я заново объяснял все и так было несколько раз. Если честно, то я уже давно смирился. Но так как только за мои 9 (!) лет использования ЯД, проблема все еще не решена, я решил о ней рассказать.

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

Заходим в Директ Про
Выбираем фильтр «этот месяц» и цели настроенные в кампании.
Открываем "обзор" и видим 10 конверсий.