Привет! Я Владимир Крылов, продуктовый дизайнер и тимлид. В этой статье я поделюсь опытом проведения ретроспектив по методологии Squad Health Check, придуманной в Spotify. Расскажу, почему нам не подошел стандартный формат ретроспектив, в чём суть метода, какие темы для анализа проблем мы выбрали и к каким результатам в итоге пришли.
В первой части мы разобрали, зачем дизайнеру знать основы вёрстки и как это помогает создавать реализуемые макеты и экономить время. Теперь перейдём от теории к практике и познакомимся с главным языком разметки — HTML.
Если CSS отвечает за то, как выглядит страница (цвета, шрифты, отступы), то HTML (HyperText Markup Language) отвечает за то, что на ней находится и какую смысловую роль играет каждый элемент. Это скелет вашего сайта.
Послезавтра у меня выступление на бизнес-встрече.
И, как это обычно бывает (по крайней мере у меня), за два дня до выступления я решила, что презентация никуда не годится. Причем не в смысле «пару слайдов поправить», а полностью пересобрать фокус выступления.
Часы до дедлайна тикают, времени немного, а перспектива сидеть полночи в Figma вообще не вдохновляет.
И тут я вспомнила простую истину. Лень – двигатель прогресса. Значит, будем искать способ, как сделать быстрее.
К моменту, когда заказ доходит до этапа формирования производственной панели, основная проверка данных уже проведена: слои проверены на соответствие технологии, выявлены и исправлены потенциальные проблемы. Теперь перед производителем стоит задача — объединить несколько заказов в одну панель и подготовить её к запуску в производство.
В этой статье мы расскажем, как формируются производственные панели, по какому принципу объединяются заказы и какие операции выполняются на этапе подготовки данных.
В статье расскажу про незаслуженно неизвестный, надёжный, стабильный и по-своему красивый монтажный стол, интегрированный в программу blender. Дам краткое пошаговое руководство по созданию клипа вместе с его исходниками, которые вы сможете скачать и изучить.
Видели ли вы, как пользователи объясняют неудачи в продукте собственной глупостью? Может, слышали в кулуарах, как разработчики соглашаются с пользователями и не знают, чем помочь, — ведь «всё предельно понятно», «для дураков сделано». А бизнес-команда между тем опускает руки и задаётся вопросом, не дураки ли они сами, если не могут донести логику продукта до пользователя?
Меня зовут Анастасия Лестова, и я социальный антрополог с инженерным бэкграундом, а сейчас исследую опыт пользователей в Контур.Маркировка. В своём докладе на CodeFest 2026, опираясь на социальные науки и нейробиологию, я рассказала, что жизненный контекст и плохие интерфейсы делают с психикой и мозгом пользователя (спойлер: буквально снижают его когнитивные способности). А в сегодняшней статье раскрою тему более детально. Понимая психофизиологические механизмы происходящего, мы разберёмся, как всё это лечить с помощью конкретных инструментов в интерфейсе.
Триангуляция — это принцип, позволяющий получить более полную и точную картину за счёт сочетания разных методов в одном исследовании. Например, можно объединить интервью, юзабилити‑тестирование и количественный немодерируемый тест. В UX-исследованиях этих методов не обязательно три — всё зависит от задачи и ресурсов для решения. Наша задача — по-максимуму сочетать методы и строить сложные подходы для таких исследований. Особенно, когда сама команда не знает, какое исследование они хотят, в условиях ограничения сроков и ресурсов.
Привет! Мы — Юля, Лика и Настя – UX-исследователи из Alfa Research Center, профессионально ломаем голову над креативными проектами. Разберём, как работает этот метод на примере одной истории, в которой исследователи разрываются между внешними ограничениями и желанием «сделать хорошо». На нашем примере покажем, как работает триангуляция и чем полезнее простого юзабилити-тестирования зрелых сервисов.
Интерфейс можно описывать не только через доступные действия, но и через продолжения, которые он делает более лёгкими. В статье предлагается рамка “архитектуры продолжений”: как после действия один следующий ход становится естественным, а другие остаются возможными, но требуют отдельного усилия.
Привет! Хочу рассказать вам о том, как мы применили продуктовый подход к исследованию опыта разработчиков при работе с Figma, чтобы создать единый стандарт оформления макетов в компании.
На Хабре уже есть несколько отличных разборов того, как разные команды наводят порядок в Figma: аннотации, стрелки, сценарии, раскладки макетов и так далее. Я видел материалы Ozon Tech, t2, Иннотех — это классные справочники правил, можно брать и пользоваться. Но, когда в 2024 году я взялся за задачу подготовки стандарта для нашей компании, то столкнулся с вопросами, о которых нигде ничего не нашел. Как разработать единый подход? Что считать правильным и почему? Как упаковать эту идею и «продать» остальным членам команды, а главное: что делать дальше?
В этой статье поделюсь нашим методом поиска ответов на эти вопросы.
Всем привет! Мы — команда Облака Mail: редактор Наташа, дизайнер Саша и исследователь Лена.
Мы вместе работаем над улучшением сервисов Mail: проводим исследования пользовательского опыта, много дискаверим, проверяем гипотезы, проектируем интерфейсы и пишем тексты, которые помогают пользователям лучше ориентироваться в продукте.
В этой статье подробно разберём, как столкнулись с нетипичной проблемой заметности элементов в интерфейсе и как через исследования, анализ поведения пользователей и системный дизайн пришли к созданию масштабируемой механики фокусировки.
Сначала был громкий тезис: «ИИ заменит дизайнеров». Потом пришел другой, помягче: мол, ничего он не заменит, наоборот — открыл возможности, дизайн теперь может больше. Звучит добрее, а врет сильнее.
«Может» — слово с лазейкой. Оно намекает на выбор: хочешь — берешь новые инструменты, не хочешь — работаешь как привык. Но выбора нет. Дело не в том, что кто-то работает хуже: если рядом коллега проходит тот же путь заметно быстрее, разрыв в скорости рано или поздно заметят — сначала команда, потом рынок. Вопрос только в том, когда это коснется вас.
Я продуктовый дизайнер в Cloud.ru, проектирую интерфейсы для ИИ-агентов. У нас в компании активно внедряют ИИ-инструменты в работу, и между дизайнерами принято делиться практиками — кто что попробовал, что зашло, что нет.
Эта статья из таких: показываю свой опыт. Недавно я с нуля собрал раздел проверки безопасности для одного из наших продуктов. Раньше задача в таком виде заняла бы у меня недели полторы — здесь я уложился в три рабочих дня до согласованного флоу макетов. Разберу по шагам, где ИИ сократил путь, а где встал намертво и заставил все объяснять руками. Если вы продуктовый дизайнер и пока приглядываетесь к этим инструментам со стороны — статья для вас.
Хочу рассказать об основах вёрстки для дизайнеров. Научить базовым принципам и показать, как проверять реализацию макета в коде. Статья будет полезна начинающим дизайнерам, которые пока не представляют, как их макеты оживают на реальных сайтах.
Я объясняла, что такое доступный дизайн, наверное, сто раз. В статьях, на созвонах, в комментариях. И каждый раз ловила одну и ту же реакцию: люди кивают, соглашаются, что это важно, — и через неделю выкатывают серую кнопку на сером фоне.
Дело не в том, что они плохие дизайнеры или им всё равно. Дело в том, что доступность невозможно понять головой. Её можно только почувствовать. А пока проблема не твоя — ты её не чувствуешь.
Я долго думала, как это починить. И в итоге перестала объяснять словами. Я сделала штуку, которая даёт побыть тем самым пользователем — на несколько секунд. Расскажу, как она устроена и почему чек-листы не работают.
Начиная с 2023 года автономные грузовики Navio ежедневно возят коммерческие грузы по главным магистралям страны. За это время мы получили богатый опыт, подробно изучили отрасль и выявили основные трудности с которыми она сталкивается. Ответом на эти вызовы стал прототип автономного тягача Navio L5. Его концепция отражает наше видение ближайшего будущего автономных грузоперевозок. В прошлой статье мы подробно рассказывали о ключевых идеях и о процессе создания дизайна тягача L5.
Однако мы видим долгосрочный потенциал в развитии рынка автономных грузоперевозок, поэтому хотим взглянуть еще дальше — на перспективу 30-50 лет вперед.
Привет! Меня зовут Оля, я ведущий дизайнер в Домклик. Работала в бигтехе (Сбер, Московская биржа).
В последнее время в найме наблюдаются панические настроения, поэтому ко мне стали часто обращаться ребята, чтобы я помогла составить резюме и подсказала, как лучше себя презентовать. Решила оформить в небольшую статью часто встречающиеся ошибки. Описала, с чем сталкивалась сама как соискатель и нанимающий менеджер.
Пожар в Нотр-Дам-де-Пари в 2019 году часто представляют как трагичный случай, разрушивший исторический памятник. Но для проектировщика в этой истории важен ещё один слой: система обнаружила проблему, выдала сообщение с зоной и номером датчика, а человек не смог быстро превратить эти данные в действие. Формально информация была передана. На практике интерфейс не помог понять, где именно возник пожар и что нужно сделать дальше.
Пользовательские ошибки часто воспринимают как проблему плохого обучения, невнимательности или недостаточного опыта: кто-то не туда нажал, не прочитал подсказку, выбрал не тот пункт или пропустил обязательное поле. Но в сложных системах ошибка не всегда возникает только на стороне пользователя. Чаще она появляется на стыке интерфейса, задачи, контекста и ментальной модели человека.
Меня зовут Елизавета Давыдова, я UX-исследователь в экосистеме Лукоморье. Под катом расскажу, как теории человеческой ошибки и методы когнитивной эргономики помогают смотреть на интерфейс через потенциальные сбои в действиях пользователя. На нашем кейсе покажу, как мы применили методологию SHERPA и иерархический анализ задач к интерфейсу таск-трекера: разложили пользовательский сценарий на шаги, классифицировали возможные ошибки и использовали эту модель как основу для проектировочных решений.
Итеративный дизайн на самом деле не только про дизайн, но и про подход к созданию продукта. Он связывает дизайнеров, команду разработки, PO (product owner), PM (project manager) и пользователей в систему, где каждый влияет на то, каким становится продукт.
Дизайнер перестаёт быть исполнителем макетов и становится участником продуктовых решений. Разработчик перестаёт просто отрисовывать экраны по макету и влияет на продукт на протяжении всего его жизненного цикла, замечает то, что не видно на этапе проектирования, и предлагает свои гипотезы. Пользователь получает возможность формировать будущее продукта через свою обратную связь, а команда быстрее проверять гипотезы и корректировать направление работы. PO перестаёт быть просто постановщиком задачи, он помогает расставлять приоритеты и принимает решения на основе того, что показала каждая итерация.
В этой статье поделимся опытом использования итеративного подхода в дизайне в разных масштабах: на крупных веб-сервисах и больших продуктовых итерациях, на маленьких недельных спринтах и на более локальных задачах — презентациях, сайтах, лендингах. С какими сложностями столкнулись, в чём преимущества и недостатки.
Если сегодня взять и выставить на 30 градусный мороз всю дизайн команду сервиса ВК Видео, а затем весь менеджмент ответственный за принятие решений и страт развитие, и не нанимать никого лет 5 — ни один пользователь этого не заметит.
Традиционно 1 декабря в 2ГИС включается зимний слой — это особый режим карты, который превращает привычный город в зимнюю сцену: меняются цвета карты, появляются тематические 3D-модели, украшения и анимации. Мы обновляем новогодний слой каждый год, чтобы добавить карте праздничного настроения и создать то самое тёплое ощущение приближающегося праздника...
Можно подумать, а что это летом вдруг вспомнили про снег, ёлки и гирлянды. А всё потому, что готовить магию декабря мы начинаем задолго до морозов.
В этой статье — как переосмыслили новогодний слой 2ГИС. Если вы продуктовый дизайнер и ищете способ наладить совместную работу между дизайном и производством, наш кейс вам точно пригодится.
Привет! Меня зовут Рома. С 2023 года я отвечаю за технику и архитектуру дизайн-системы в Туту, а с 2025 — возглавляю саму команду.
За это время я понял: дизайн-система — это сложный и местами болезненный компромисс между кодом, дизайном и бизнесом. Написать гибкие компоненты и собрать UI-кит — лишь 20% успеха. Остальные 80% — это долгие детальные переговоры и поиск точек соприкосновения. Продуктовые команды тоже хотят делать качественный продукт, но их главный ресурс — время.