Веб-дизайн *

Этот значок на компьютере моего коллеги выглядит лучше

Как-то я общался с коллегой у него за компьютером и заметил, что логотип выглядит не совсем так, как моём компьютере. На компьютере коллеги он казался тоньше и больше походил на исходное изображение. Он имел размер 15px; на картинке выше показана его увеличенная версия.

Примечание: показано не исходное изображение. Это было уже довольно давно, поэтому я создал новое изображение, чтобы продемонстрировать, в чём же проблема.

Если прищуриться или отойти подальше, то изображение из Chrome выглядит толще. Это немного странно, но если заменить картинку на SVG, то проблема исчезнет. Однако мне всё равно стало любопытно: почему она вообще так рендерится?

Я провёл исследование и обнаружил в Chrome изящную оптимизацию, используемую для рендеринга JPEG в мелком масштабе.

Грязный макет — грязный код. Чистый макет — адекватный код и отсутствие вопросов «что тут имелось в виду»: разработка получает то, с чем можно работать.

Элементарщина, про которую забывают/не успевают, ведь это просто, примитивно, но страдают все… В СВОЙ Тех решили написать спецификацию по тому, в каком виде желательно отдавать макеты в разработку. Разработка получила аргументацию для возвращения макета. Потому в «сесть и сделать сразу хорошо» заинтересованы все — но это время, и его надо закладывать в процессы. Внутри — правила, советы, рекомендации и чек‑лист для краш‑теста, которые помогают собраться и сделать хорошо сразу.

Из элементарного строится бо́льшее...

90-е были для Интернета чем-то вроде эпохи Дикого Фронтира: никаких правил, никакой цензуры и никакого блёклого веб-дизайна от биг-корпов. Стремясь перетянуть на свою сторону ещё не слишком многочисленную онлайн-толпу, компании и стартапы пытались придумать что-то этакое — и порой создавали очень странные, но безумно интересные продукты.

Собрались однажды продакты, разработчики и отдел дизайна и решили: хватит терпеть жалобы на устаревший и запутанный интерфейс. Был сервис деск-лабиринт, стал продукт с умной навигацией — минус половина элементов, без боли адаптации, с добавлением привычных паттернов.

Привет, Хабр! Меня зовут Света, проектирую интерфейсы в ITSM 365. Мы с командой стояли у истоков дизайна первой версии системы, потом упростили его и распространили на новые продукты, сейчас запускаем интерфейс 2.0. Расскажу и покажу, что было раньше и как мы это изменили.

Пользователи не читают ваши страницы — они их сканируют. Взгляд прыгает по подзаголовкам, как по слоям пирога, и от того, что он там находит, зависит, останется человек или уйдёт. Разбираю паттерн layer-cake, F-паттерн и почему всё решается на этапе вёрстки, а не редизайном.

Почему ввод кода из смс раздражает, хотя занимает всего несколько секунд? Казалось бы, OTP-поле — простой элемент интерфейса, но именно на этом этапе пользователи часто сталкиваются с мелкими, на первый взгляд, проблемами: не срабатывает автоподстановка, неудобно вставляется код, теряется фокус, приходится заново вводить символы после ошибки. Каждая из этих деталей сама по себе кажется незначительной, но вместе они замедляют авторизацию, увеличивают количество ошибок и ухудшают пользовательский опыт.

Меня зовут Антонина, я дизайнер интерфейсов ЮMoney. Мы изучили десятки исследований — от Baymard Institute до Google web.dev. Единого документа с лучшими практиками не нашлось: источники противоречили друг другу или оказывались слишком общими.

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

Этот подход плзволяет избавиться от таких проблем, как: неактуальность макетов для разработки, долгий поиск макетов и задач в фигме, протухание информации в макетах, увеличение memory usage и долгая загрузка файлов.

Раньше для согласования интерфейса я собирал макет в Figma, описывал каждое поле, отдавал его дизайнеру, а потом отдельно объяснял логику фронтенд-разработчику.

В 2026 году тот же путь можно пройти быстрее: передать ИИ требования и за несколько итераций получить кликабельный прототип на HTML, CSS и JavaScript — с формами, модальными окнами, валидацией и тестовыми сценариями.

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

Прохожу полный путь новичка на Хабр от регистрации до заполнения профиля и отмечаю критические ошибки в интерфейсе с позиции UX/UI дизайна и принципов эвристики доступности

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

«Может» — слово с лазейкой. Оно намекает на выбор: хочешь — берешь новые инструменты, не хочешь — работаешь как привык. Но выбора нет. Дело не в том, что кто-то работает хуже: если рядом коллега проходит тот же путь заметно быстрее, разрыв в скорости рано или поздно заметят — сначала команда, потом рынок. Вопрос только в том, когда это коснется вас.

Я продуктовый дизайнер в Cloud.ru, проектирую интерфейсы для ИИ-агентов. У нас в компании активно внедряют ИИ-инструменты в работу, и между дизайнерами принято делиться практиками — кто что попробовал, что зашло, что нет.

Эта статья из таких: показываю свой опыт. Недавно я с нуля собрал раздел проверки безопасности для одного из наших продуктов. Раньше задача в таком виде заняла бы у меня недели полторы — здесь я уложился в три рабочих дня до согласованного флоу макетов. Разберу по шагам, где ИИ сократил путь, а где встал намертво и заставил все объяснять руками. Если вы продуктовый дизайнер и пока приглядываетесь к этим инструментам со стороны — статья для вас.

Мир сильно изменился с начала 21 века. В том числе, что касается систем авторизации. Мы продвинулись от авторизации через обычный логин и пароль к использованию централизованных сервисов вроде Google и Apple. Но так ли хорошо это для пользователя? И можно ли сказать, что его данные принадлежат ему?

Итеративный дизайн на самом деле не только про дизайн, но и про подход к созданию продукта. Он связывает дизайнеров, команду разработки, PO (product owner), PM (project manager) и пользователей в систему, где каждый влияет на то, каким становится продукт.

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

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

Несколько лет назад в процессе подготовки очередной статьи (о ней чуть ниже) я вынужденно столкнулся с новым редактором Habr, которого до этого мне удавалось избегать, и который к тому моменту стал безальтернативным.

Тогда “по мотивам” пользования этим поделием почти сама родилась статья Несколько «добрых» слов о текущей версии редактора Habr, в которой я изложил всё, что я думал о новом редакторе (вернее ту часть мыслей, которую можно было напечатать, поскольку значительная их часть была непечатной)

Я будучи пессимистом тогда наивно полагал, что “хуже быть не может”, однако как оказалось ситуация тогда была оптимистическая, и “может быть еще хуже”

Несколько дней назад я сделал маленький инструмент для себя. Надоело каждый раз начинать новый проект с колеса оттенков: крутишь Coolors, листаешь Pinterest, смотришь на чужие палитры, которые «почти подходят». А ведь у проекта уже есть образ, это слово. Рассвет. Шторм. Тёмный лес. У каждого слова есть свой цвет, который чувствуешь интуитивно. Просто никто не переводит его в HEX за тебя.

Так появился Колорит: вводишь слово, ИИ собирает палитру. Я написал про него на Хабре. А потом поймал себя на новой мысли. Палитра это ведь только начало. После цвета всё равно нужно имя, слоган, шрифты, ощущение движения. Почему всё это должно начинаться с нуля, если отправная точка одна и та же?

Так Колорит перестал быть просто генератором палитр и стал маленьким конструктором бренда.

Как-то вечером я поймал себя на том, что трачу по 20 минут на поиск цветовой палитры для каждого нового проекта. Coolors, Adobe Color, случайные пины в Pinterest — и всё равно ощущение «не то». Тогда я задал себе вопрос: а что если вместо колеса оттенков начинать со слова? «Рассвет», «шторм», «лакшери» — у каждого слова есть интуитивный цвет.

Так появился Колорит — инструмент, который превращает слово или фотографию в цветовую палитру с помощью ИИ. В этой статье расскажу про технические решения, prompt engineering для DeepSeek и пару неочевидных браузерных API.

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

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

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

Привет друзья! Меня зовут Тима, я дизайнер в дизайн-системе Альфа-Бизнес.  Когда в крупном финтех-продукте заходит речь об обновлении иконок, со стороны это кажется легкой творческой задачей на пару недель: сел, порисовал в Figma, выгрузил — готово. Но в реальности бигтеха любая попытка просто «освежить визуал» моментально сталкивается с суровой инфраструктурой, сотнями легаси-компонентов и хаосом, который годами копился в коде и макетах.

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

Те, кто уже проходил через подобное в больших продуктах, скорее всего узнают знакомые проблемы. А тем, кто только собирается нырнуть в такое приключение, статья поможет чуть раньше подметить проблемы, которые обычно всплывают сильно позже.

История началась с довольно простой задачи — обновить иконки. Но чем дальше я погружался, тем понятнее становилось, что история здесь шире рядового редизайна.

Создание единой дизайн-системы для крупного кроссплатформенного продукта — это всегда вызов. А если процесс совпадает с масштабным ребрендингом компании, задача усложняется в разы. В этой статье мы разберем двухлетний кейс команды «Туту», которая прошла путь от полного отсутствия стандартов до гибкой, масштабируемой и строго контролируемой архитектуры токенов цвета.

Привет, меня зовут Николай Разумовский, я дизайнер в команде цифровой трансформации Ареал. Как дизайнер я регулярно сталкиваюсь с задачей: нужно быстро получить уникальные изображения для интернет-магазинов, корпоративных сайтов, лендингов и презентаций. Если опираться только на стоки, процесс затягивается, а визуально проекты становятся похожими друг на друга.

Генерация через нейросети решает сразу несколько задач: