Дизайн

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

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

Последние несколько лет я проектирую стартап-инкубаторы и цифровые сейфы (что-то типа Leafplanner, но для индивидуального пользования) для HNWI/UHNWI (человеческим языком – для состоятельных людей), и это дало уникальный опыт, особенно в части организации безопасности: иногда лучший способ защитить дверь — это спрятать её там, где никто даже не подумает её искать.

И сегодня я расскажу, почему «User-Hostile дизайн» может стать вашим лучшим другом в вопросе безопасности.

Имя Раймонда Лоуи (Raymond Loewy, 1893–1986) знакомо каждому, кто хоть раз пил из бутылок Coca-Cola, заправлялся на АЗС Shell или восхищался ретро-автомобилями Studebaker. Этот человек стал одним из первых, кто превратил промышленный дизайн в искусство, а функциональность — в эстетику. Его работы повлияли на всё: от упаковки сигарет до космических кораблей NASA.

Но как скромный эмигрант из Франции стал легендой, определившей визуальный язык современности? Давайте проследим его путь — от первых эскизов в Париже до мирового признания.

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

Надо ли говорить, что открытки с котиками пользовались максимальным спросом! Но недовольных тоже было немало. Газеты и общество били тревогу: скоро все вообще разучатся писать длинные тексты и формулировать мысли. К тому же больше никакой приватности: открытки не упаковывали в конверты, а значит, текст могла увидеть прислуга. Инфраструктура тоже трещала по швам: мешки почтальонов переполнялись огромным количество открыток, а это вело к травмам и потере важных сообщений.

Что-то все это напоминает, не правда ли? Технологии меняются быстро, а вот люди — не очень. Все это и обсудим дальше.

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

Важной частью работы дизайнеров является передача интерфейсов в руки фронтенд-разработчиков (mobile и web). Но, между творческим замыслом дизайнера и его воплощением в коде может возникнуть немало трудностей. 

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

Привет, Хабр! Я Маша, продуктовый дизайнер в ОТП Банке. Наш банк последнее время активно развивает дизайн, сегодня хочу поделиться опытом работы с иконками. Сразу скажу, большинство перечисленных принципов вам скорее всего знакомы, но есть некоторые неочевидные нюансы, на которые стоит обратить внимание 👇

Речь идёт о замене звукоснимателей и установке двух «тяни-толкай» (пуш-пул) потенциометров, позволяющих получить от пары хамбакеров не только звучание одиночных синглов, но и убедительное «стекло» как у стратокастера.

Привет! Я Александр Букин, дизайн-лид направления Фудтех в Магнит OMNI, объединяющем сервис доставкивертикаль «Магнит Фудтех», маркетплейс «Магнит Маркет» и программу лояльности «Магнит Плюс».

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

Рынок digital-услуг в России в 2025-м остается хаотичным, без четких стандартов и объективных критериев качества. Клиенты не могут заранее понять, кто выполнит работу хорошо, а кто просто продаст красивую презентацию. Изначальные причины этого понятны. Агентства не продают готовый продукт, а оказывают услугу по созданию этого продукта, поэтому их реальный уровень становится очевидным только после начала работы. Это базовые условия, проблем не в этом факте, а в том, что происходит дальше.

За этапом пресейла часто можно увидеть как даже масштабные проекты передают людям без опыта на непосредственное исполнение. Вчерашний школьник, освоивший Figma за пару вечеров, может легко получить заказ, потому что границы профессии размыты. Достаточно разместить вакансию «senior дизайнер» и посмотреть отклики, чтобы убедиться в масштабе проблемы, и кто сегодня считает себя дизайнерами такого уровня. HR разбираться с квалификацией не будут, им надо затыкать дыры, и так вчерашний студент может оказаться в перегруженном агентстве у которого нет лавки с резервом ресурса (потому что это дорого) на большом проекте, делать же кому-то нужно.

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

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

В этой статье я расскажу о том, что такое MVC и об идеях, которые были заложены в этот шаблон его создателем. Мы рассмотрим, как MVC улучшит UI и UX ваших приложений, сделав их понятнее и прозрачнее для пользователей. Рассмотрим способы организации кода по этому шаблону, чтобы вы смогли сразу применить эти знания в своей работе. А так же посмотрим на несколько вариаций этого шаблона, которые улучшают тестирование и ускоряют разработку.

Framer был создан в 2014 году бывшими дизайнерами из Facebook и Google для создания прототипов с использованием кода, основанный на JavaScript и CoffeeScript. Основные функции включали анимацию и взаимодействие.

Всем привет! Это мой первый пост на хабре, и я решил рассказать о своём тестовом задании на позицию Junior Product Designer. C радостью поделюсь подробностями, факапами и полезными выводами, которые сделал в процессе.

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

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

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

Собрал конкретные примеры неправильных чекбоксов с крупных сайтов, чтобы вам было проще защищать свои интерфейсные решения и больше никогда не ошибаться

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

«Сделай удобно» #1. «Сделай удобно» #2. «Сделай удобно» #3. «Сделай удобно» #4, «Сделай удобно» #5, «Сделай удобно» #6, «Сделай удобно» #7, «Сделай удобно» #8, «Сделай удобно» #9.

Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.

Под катом: Yandex Go, Intsagram, Amie, Aviasales, Tinder.

Привет! Меня зовут Даша Меркулова, я развиваю маркетинг в ИТ-разработчике Orion soft. Хочу поделиться впечатлениями об одном из самых больших челленджей нашей команды в 2024 году — организации ИТ-конференции Orion Digital Day на 1100 оффлайн участников. Это был большой вызов, для которого понадобилось объединить все креативные силы нашей команды. 

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

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

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

Привет, Хабр! Меня зовут Игорь Бутков, я старший дизайнер в компании Friflex. Мы занимаемся разработкой мобильных приложений и веб-сервисов.

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

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