Интерфейс можно описывать не только через доступные действия, но и через продолжения, которые он делает более лёгкими. В статье предлагается рамка “архитектуры продолжений”: как после действия один следующий ход становится естественным, а другие остаются возможными, но требуют отдельного усилия.
Привет! Хочу рассказать вам о том, как мы применили продуктовый подход к исследованию опыта разработчиков при работе с Figma, чтобы создать единый стандарт оформления макетов в компании.
На Хабре уже есть несколько отличных разборов того, как разные команды наводят порядок в Figma: аннотации, стрелки, сценарии, раскладки макетов и так далее. Я видел материалы Ozon Tech, t2, Иннотех — это классные справочники правил, можно брать и пользоваться. Но, когда в 2024 году я взялся за задачу подготовки стандарта для нашей компании, то столкнулся с вопросами, о которых нигде ничего не нашел. Как разработать единый подход? Что считать правильным и почему? Как упаковать эту идею и «продать» остальным членам команды, а главное: что делать дальше?
В этой статье поделюсь нашим методом поиска ответов на эти вопросы.
Всем привет! Мы — команда Облака Mail: редакторка Наташа, дизайнер Саша и исследовательница Лена.
Мы вместе работаем над улучшением сервисов Mail: проводим исследования пользовательского опыта, много дискаверим, проверяем гипотезы, проектируем интерфейсы и пишем тексты, которые помогают пользователям лучше ориентироваться в продукте.
В этой статье подробно разберём, как столкнулись с нетипичной проблемой заметности элементов в интерфейсе и как через исследования, анализ поведения пользователей и системный дизайн пришли к созданию масштабируемой механики фокусировки.
Я объясняла, что такое доступный дизайн, наверное, сто раз. В статьях, на созвонах, в комментариях. И каждый раз ловила одну и ту же реакцию: люди кивают, соглашаются, что это важно, — и через неделю выкатывают серую кнопку на сером фоне.
Дело не в том, что они плохие дизайнеры или им всё равно. Дело в том, что доступность невозможно понять головой. Её можно только почувствовать. А пока проблема не твоя — ты её не чувствуешь.
Я долго думала, как это починить. И в итоге перестала объяснять словами. Я сделала штуку, которая даёт побыть тем самым пользователем — на несколько секунд. Расскажу, как она устроена и почему чек-листы не работают.
Пожар в Нотр-Дам-де-Пари в 2019 году часто представляют как трагичный случай, разрушивший исторический памятник. Но для проектировщика в этой истории важен ещё один слой: система обнаружила проблему, выдала сообщение с зоной и номером датчика, а человек не смог быстро превратить эти данные в действие. Формально информация была передана. На практике интерфейс не помог понять, где именно возник пожар и что нужно сделать дальше.
Пользовательские ошибки часто воспринимают как проблему плохого обучения, невнимательности или недостаточного опыта: кто-то не туда нажал, не прочитал подсказку, выбрал не тот пункт или пропустил обязательное поле. Но в сложных системах ошибка не всегда возникает только на стороне пользователя. Чаще она появляется на стыке интерфейса, задачи, контекста и ментальной модели человека.
Меня зовут Елизавета Давыдова, я UX-исследователь в экосистеме Лукоморье. Под катом расскажу, как теории человеческой ошибки и методы когнитивной эргономики помогают смотреть на интерфейс через потенциальные сбои в действиях пользователя. На нашем кейсе покажу, как мы применили методологию SHERPA и иерархический анализ задач к интерфейсу таск-трекера: разложили пользовательский сценарий на шаги, классифицировали возможные ошибки и использовали эту модель как основу для проектировочных решений.
В детстве меня каждый раз поражало, когда в фильмах виртуозно набирали текст на клавиатуре, не отрывая взгляда от экрана. Как только у меня появился свой компьютер, я несколько раз пытался освоить слепой десятипальцевый набор. Возвращался к этой идее с интервалом в несколько лет, но каждый раз бросал: прогресс шел медленно, нервной энергии тратилось много. Хотеть-то хотел, а вкладываться в это не был готов.
Позже я занялся эргономикой и эстетикой рабочего места. И неожиданно для себя все-таки осилил этот навык. Только пришел к нему не через тренажеры, а через минималистичный сплит на 36 клавиш. В статье расскажу, что мне мешало в стандартной клавиатуре и что помогло минимизировать затраты на освоение сплита.
Свежее исследование Стэнфорда (Nature Health, январь 2026) связало дальтонизм с поздней диагностикой рака мочевого пузыря — у пациентов-дальтоников смертность за 20 лет на 52% выше. Причина в том, что главный ранний симптом, кровь в моче, они просто не видят: цвет для них не считывается. Это медицинская история, но она точно описывает ошибку, которую дизайнеры делают каждый день — кодируют критическую информацию одним только цветом. Разбираю, как устроена эта ошибка в интерфейсах и что с ней делать на практике.
Привет! Я Катя Ильиных — UX-исследователь в Контур.EDI. От наших читателей поступил вопрос:
Можно ли делать выводы на основе ответов 8 клиентов?
Короткий ответ: можно, но не всегда. В статье разберемся, в каких случаях 8 ответов будет достаточно, а в каких случаях придется увеличить выборку.
LLM уже умеют быстро собирать мобильные макеты, и на первый взгляд результат часто выглядит убедительно. Кнопки похожи на кнопки, bottom sheet на bottom sheet, экран не разваливается, и его можно показать на обсуждении. Но на практике это всего лишь аккуратный черновик, который ещё нужно как следует доработать: посмотреть компоненты, состояния, навигацию, safe area, длинные тексты и поведение на маленьком экране.
Поэтому предлагаю разобраться, где LLM-инструменты действительно снижают стоимость первой итерации, а где просто переносят сложность на следующий этап: дизайн-ревью, разбор состояний и ручную адаптацию под мобильный контекст. Зафиксируем практические границы применимости LLM при работе с мобильными макетами.
UI-kit, которым пользуются несколько продуктовых команд, нельзя просто отправить в будущее и переписать под новый дизайн. За ним тянется прошлое: старые CSS-переменные, публичный API, кастомизации у потребителей и независимые релизные циклы. При этом бренд уже меняется, дизайнеры приносят новую палитру, типографику, motion, скругления и тёмную тему и всё это нужно аккуратно посадить на компоненты, которые продолжают работать в продакшене.
Привет, Хабр! Меня зовут Амир, я Senior Vue.js Frontend Developer в экосистеме Лукоморье. Уже шесть лет я развиваю фронтенд большой внутренней ERP-платформы, в том числе внутренний UI-kit: около 50 компонентов на Vue 3 и TypeScript, которыми пользуются несколько продуктовых команд в Ростелекоме.
В этой статье расскажу, как мы устроили для UI-kit такое «назад в будущее»: в одной долгоживущей ветке sova провели редизайн поверх работающих компонентов, сохранили публичный API для команд-потребителей и перевели визуальный слой на новую архитектуру. Мы внедрили 3-tier-систему дизайн-токенов, собрали pipeline на Style Dictionary и Tokens Studio for Figma, оставили старые CSS-переменные через legacy-алиасы, а заодно закрыли несколько долгов библиотеки: типизацию шаблонов, встроенный SVG-спрайт на 816 иконок, утилиту темизации и вынос runtime-зависимостей с сокращением бандла с 940 до 150 КБ.
Материал будет полезен инженерам дизайн-систем, фронтенд-архитекторам и тимлидам, которые поддерживают UI-kit для нескольких продуктовых команд и думают, как провести редизайн без поломки потребителей. Внутри — код, архитектурные решения, компромиссы и честные выводы по итогам миграции.
Два часа ночи, у разработчика горит релиз, он подключает ваш API — и получает в ответ голое «invalid_request». Что не так, почему, что делать — ни слова. Сорок минут гаданий и злое письмо в поддержку.
Разбираем, как сделать опыт разработчика (DX) человеческим: как переписать ошибки по стандарту RFC 9457, но для живого человека; почему время до первого успешного вызова — главная метрика онбординга; и отчего предсказуемый, «скучный» API — это комплимент. С готовым шаблоном, который можно прикрутить к себе сегодня.
Проведём небольшой тест. Откройте свой сайт и посмотрите на него глазами не живого пользователя, а ИИ-агента.
Не на красивую кнопку «Записаться». А на то, что получает ChatGPT или браузерный агент, когда ваш клиент просит его: «запиши меня на стрижку вот в эту студию». Чаще всего там каша из HTML. Смысл спрятан в вёрстке, кнопка нарисована картинкой, а цену подгружает скрипт через пару секунд после открытия.
Человек в этой каше разберётся. Он видит страницу целиком, догадывается по контексту, тыкает наугад и попадает. Агент не догадывается. Агент исполняет буквально. И если смысл живёт только в том, как страница выглядит, для агента его просто нет.
Вот это и есть Agent Experience — опыт, который ваш продукт даёт ИИ-агенту.
Боль бизнеса очевидна – по максимуму избавиться от рутины и механических действий, чтобы можно было сконцентрировать усилия на основном продукте и конечной ценности.
Но рутины очень много: документы, коммуникации, задачи, сроки, база знаний, финансы, корпоративное обучение, тестирование знаний, исследование рынка, реклама, корпоративный сайт и т.д.
Как-то так случилось, что многие сервисы стали укрупняться и совмещать несколько инструментов в одном. Я задался вопросами: «Хорошо это ли плохо?» и «Насколько такие мегакомбайны будут востребованы через год, два, пять?» Порассуждал об этом в статье.
Продолжаем серию заметок по улучшению UI нашего любимого браузера. На этот раз поменяем кнопку включения VPN на тулбаре.
Всем привет! Меня зовут Данила Максишко, я руковожу командой продуктовых исследователей в hh.ru. В статье расскажу, как мы работаем с обратной связью через важный инструмент — бэклог болей пользователей.
Это текст от исследователя для исследователей. Если вы строите или масштабируете ресёрчи у себя, наш опыт поможет избежать части ошибок и быстрее выстроить рабочую систему.
Большинство ИИ помогают работать быстрее. По‑настоящему хорошие — делают пользователей компетентнее. Начинаешь с малого: просишь исправить письмо. Потом пробуешь сложнее — функцию на незнакомом языке. Затем поручаешь целую фичу. В какой‑то момент ИИ уже кажется не стажёром, а экспертом. Сначала это впечатляет, что месяц работы укладывается в несколько дней. Но потом наступает момент, когда ИИ возвращает задачу с ошибкой. Ты не знаешь, как её исправить, и просто пишешь «попробуй другой подход», надеясь на удачу.
На этой неделе прочитала свежую статью Кьяры Пеллегрини из NN/g: «AI-агенты теперь тоже пользователи наших интерфейсов». Автор — серьёзный исследователь, статья хорошо аргументирована. У агента есть цели, агент сталкивается с интерфейсом, агент пытается достичь целей через наш дизайн. По функциональному определению — пользователь.
Я не согласна с этой рамкой. И думаю, что разница принципиальная.
Восемь лет я работала клиническим врачом, потом перешла в продуктовый дизайн. Сейчас веду UX/UI в крупной российской IT-компании. Этот переход дал мне странное двойное зрение: я постоянно вижу в дизайне проблемы, которые медицина решала десятилетиями. Вопрос с агентами — один из них.
Агент — это не новый пользователь. Это новый посредник.
Меня зовут Алёна Байкова, я отвечаю за проверку тестовых заданий кандидатов на роль UX-исследователей.
Когда потребность в исследователях в компании выходит на новый уровень, вакансий становится больше, возрастает популярность и количество откликов на них, в любой команде может встать вопрос о том, как организовать и без ущерба по времени встроить подбор кандидатов в рабочий процесс.
Одно из направлений проверки знаний и навыков кандидатов — проверка выполненных тестовых заданий. Тут нужно решить сразу несколько задач: как не повесить всю нагрузку на одного человека, как организовать работу группы проверяющих и как прийти к общему мнению о кандидате. А также, как не заставлять ждать кандидатов неделями и всегда возвращаться к ним с ответом.
При этом проверка и качественная обратная связь — это всегда время сотрудников. Для нас было важно найти баланс в этих процессах. Со временем мы смогли сделать процесс прозрачным, быстрым и удобным. Про это сегодня и поговорим.
Прототип сайта на Тильде нельзя рассматривать только как черновик будущего дизайна.
Тильду часто воспринимают как инструмент, где можно быстро собрать сайт из готовых блоков. Это правда, когда структура заранее ложится на логику платформы. Но если сначала нарисовать свободный макет, а потом пытаться перенести его в конструктор без учета стандартных блоков, Зеро-блока, адаптива, форм, SEO-структуры и будущего редактирования, скорость быстро исчезает.
Когда команда запускает витрину продукта — каталог, рекомендации или подборки, — почти сразу возникают вопросы: «Будут ли пользователи что-то из неё скачивать или покупать и какая будет конверсия?»
До запуска на них сложно ответить честно: у пользователей ещё нет привычки, у продукта — стабильной выдачи, у витрины — накопленного доверия, а у команды — реальных данных поведения. Поэтому полезнее временно отложить вопрос «какая будет конверсия?» и спросить иначе: «Сможет ли витрина запустить выбор, когда у пользователя ещё нет сформулированного запроса?»
Меня зовут Таня Лескова, я ведущий UX-исследователь в магазине приложений RuStore. На примере исследований витрины RuStore расскажу, как мы проверяем такие сценарии до запуска: смотрим не на гипотетическое «скачал бы или не скачал», а на более раннюю цепочку — заметил, понял, поверил, захотел разобраться дальше.
