Дизайн

Как дизайн-студии защитить свою интеллектуальную собственность

Любая дизайн-студия может обладать внушительным портфелем объектов интеллектуальной собственности. И это не только товарные знаки, но и, например, промышленные образцы, программы для ЭВМ и многое другое.

Все эти объекты можно юридически защитить после регистрации в Роспатенте.

Зачем это нужно дизайн-студии?

Самое очевидное:

• Надлежащее оформление, например, товарного знака  позволяет оградить ваше дело от «патентных троллей» и конкурентов;

• Вы получите возможность передавать имеющиеся объекты интеллектуальной собственности по коммерческим договорам третьим лицам;

• При обнаружении нарушений — с несоблюдающих закон можно взыскать серьезную компенсацию (например, при фиксации факта неисполнения требований по использованию товарного знака — до 5 млн рублей).

Можно примеры, когда дизайн-студия зарегистрировала интеллектуальную собственность?

Конечно. Самая известная в России дизайн-студия — «Студия Артемия Лебедева».

На юридическое лицо этой компании зарегистрировано сразу пять товарных знаков («Артемий Лебедев», «Николай Иронов», Art.Lebedev — в двух вариациях — и Potokus), несколько промышленных образцов (например, шрифт «ARTEMIUS TEXT REGULAR») и программы для ЭВМ («Имприматур / Imprimatur», «Николай Иронов»).

Незаконное использование третьими лицами указанных нематериальных активов нередко становится причиной для направления исков со стороны правообладателя. Об объемах работы юридического отдела «Студии» можно прочитать здесь.

Сложно ли регистрировать указанные объекты интеллектуальной собственности?

Формат регистрации в Роспатенте — стандартный. Заявитель собирает документы, передает материалы на экспертизу, оплачивая госпошлины. Если в представленных материалах не найдут ошибок, то происходит регистрация. В обратном случае — заявитель может получить отказ.

Последнее — вовсе не исключено, если Вы действуете самостоятельно и не знаете мельчайших деталей, касающихся особенностей оформления тех или иных объектов интеллектуальной собственности.

Чтобы сэкономить время, силы и финансовые ресурсы, стоит обратиться к профессионалам, которые зарегистрируют объекты вашей интеллектуальной собственности без проблем и в кратчайшие (предусмотренные законом) сроки.

Зарегистрировать товарный знак можно здесь. А промышленный образец (патент на дизайн) тут.

Вышла седьмая версия UIKit — ключевой библиотеки дизайн‑системы Gravity UI

Добавили больше возможностей, которые упрощают создание доступных интерфейсов.

• Все всплывающие элементы реализованы на основе Floating UI вместо устаревшего popper.js. Эта библиотека позволяет делать такие элементы более доступными и предоставляет более богатый инструментарий для настройки их поведения.

• Компоненты Button и Link расширяют интерфейс базовой кнопки или ссылки. Теперь их легче использовать как нативные элементы.

• Обновили дизайн у компонента RadioButton, заодно сменили его имя. Новое название SegmentedRadioGroup точнее отражает суть.

• Переработали Popover, удалили из него всё лишнее, упростили API — теперь компонент стал проще, понятнее и ближе к лучшим практикам разработки. Старую версию отметили как устаревшую.

• Компонент NumberInput перенесли из тестирования в основные компоненты.

• Новый компонент Breadcrumbs с улучшенной логикой схлопывания элементов и доступностью также перенесли в основные компоненты, старый отметили как устаревший.

• Переработали Tabs, теперь это набор компонент TabList, Tab и TabPanel с улучшенной доступностью. Компонент Tabs отметили как устаревший.

• Добавили новые размеры в компоненты Avatar, User и UserLabel.

• Убрали стилизацию скроллбаров страницы по умолчанию.

Полный список изменений можно посмотреть здесь. Если вы уже используете Gravity UI, будем рады обратной связи: обязательно заглядывайте в наш комьюнити‑чат. А также ставьте звёздочки на GitHub и следите за обновлениями!

Сражение на море электролиза

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

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

Заходите посмотреть проект и добавить в вишлист.

По итогам жарких обсуждений и критики по поводу медленного кода и плохого fps в тесте вывода на экран графика sin()+noise для Matplolib были внесены усовершенствования и привлечен ИИ для полировки. Исходная статья и код https://habr.com/ru/articles/878002/

Отказ от медленного вывода текста, применение FuncAnimation вместо простого цикла, применение мэджик команды для подключения PyQT backend. FPS поднялся с 12 до 35. Подробности читайте в исходной статье https://habr.com/ru/articles/878002/

м

Если вы искали ответ на вопрос «Сколько людей пользуется темной темой?», то вот он, рассказываю. 

На примере букмекерского продукта, в мобильном приложении больше 40% пользователей видят темную тему, когда заходят в приложении. Это может быть как системная настройка переключения темы на устройстве (таких кстати ~85% пользователей), так и вручную переключились и сидят только на темной. 

В вебе процент меньше, около 25%. Вероятно, это связано с тем что не все компьютеры/ноутбуки умеют в системную смену темы девайса, а также с тем что часть веб (особенно десктоп) аудитории довольно таки консервативна, и для них сайт - это обязательно что-то на белом фоне.

Так что, если вы сомневались нужна ли темная тема в продукте. Не сомневайтесь, нужна.

Написана статья о тестировании (и сравнении FPS) на скорость рисования 2D графиков на python популярных и относительно малоизвестных графических пакетов 2D и 3D (Mayavi 3D, PyVista, Matplotlib, PyQTGraph, Plotly, PyGame, Arcade, pyOpenGL, VisPy, Bokeh) Возникли некоторые технические проблемы и срок публикации пока не ясен (надеюсь, на следующей неделе). Поэтому, заинтересовавшиеся коллеги, прошу подписаться на мой профиль на хабре, чтобы не пропустить публикацию этой статьи. В статье будут видео с отрисовкой в реальном времени 2D графиков и будут измерены FPS. Специально использовался слабенький мини ПК без дискретки. Тем не мене FPS достигал в некоторых случаях 100. Пример видео ниже:

https://habr.com/ru/articles/878002/

Файлы к статье

Тестирую, насколько концепция "Write once, run anywhere" работает на практике. Цель - один jar с 3D-игрой, который работает на 4х-платформах - J2ME, Windows, Linux, OS X. Кроме того, демку можно будет запустить на первых Android-смартфонах в мире (в Android dex вместо обычного jvm-байткода, поэтому не перечислил в списке основных платформ) и если у меня появится BlackBerry с GLES по типу 8900 - то и на нем. Само собой о разработке демки будет статья.

Привет, Хабр! 👋 Сегодня говорим про

WCAG и подбор цветов: когда можно сделать исключения и как это влияет на доступность проекта

При проектировании интерфейсов важно учитывать доступность (a11y) и следовать Web Content Accessibility Guidelines (WCAG). Однако иногда возникают ситуации, когда строгие требования контрастности могут мешать эстетике или логике интерфейса. Сегодня разберём, когда можно делать исключения и как это влияет на UX.

Как WCAG регулирует цвет и контраст

WCAG (Web Content Accessibility Guidelines) — набор рекомендаций, который делает цифровые продукты доступными для людей с ограничениями зрения. Основные требования:

✅ Минимальный контраст текста к фону: 4.5:1 для обычного текста и 3:1 для крупного (AAA — 7:1 и 4.5:1 соответственно).

✅ Элементы интерфейса должны иметь контраст 3:1 относительно фона.

✅ Информация не должна передаваться только через цвет (например, ошибки должны сопровождаться иконкой или текстом).

Но есть ситуации, когда эти правила можно гибко адаптировать.

Когда можно отступить от строгих требований?

1. Дизайн под слабовидящих пользователей Если аудитория вашего продукта — пользователи с нарушениями зрения, они часто используют персонализированные настройки контраста и цвета. В таком случае важно дать им возможность адаптировать интерфейс (например, смена темы, поддержка high contrast mode в OS).

2. Декоративные элементы Если текст является неинтерактивным и несёт лишь декоративную нагрузку, требования к контрасту могут быть мягче. Например, логотипы брендов или фоновые иллюстрации не обязаны соответствовать 4.5:1.

3. Темные интерфейсы (Dark Mode) В тёмных темах контрастность воспринимается иначе. Чрезмерный контраст (белый текст на чёрном фоне) может быть утомительным. В таких случаях допускается снижение контраста для улучшения читабельности.

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

5. Игровые и мультимедийные продукты Если цвет является частью художественного замысла (например, в видеоиграх или анимации), строгий контраст может испортить атмосферу. Но в таких случаях лучше давать альтернативные режимы или настраиваемую палитру.

Как сделать интерфейс доступным даже при отклонениях от WCAG

💡 Добавьте альтернативные способы восприятия информации — используйте иконки, текстовые метки, контуры для важных элементов.

🎨 Тестируйте цвета на симуляторах дальтонизма — инструменты вроде Stark или встроенные в Figma помогают оценить восприятие цветов разными группами пользователей.

🔄 Позвольте пользователю выбрать контрастную тему — динамические настройки темы решают множество проблем.

📊 Проводите тестирование с реальными пользователями — иногда теоретически допустимый цвет в реальности оказывается плохо читаемым.

Итоги

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

Где почитать:
Самый полный гайд по контрастности интерфейсов от DSGNERS
Про инклюзивность и доступность от AGIMA на Хабре
Руководство по доступности контента от WCAG

До связи 🤝

Привет, Хабр! 👋

Сегодня обсудим:

Как дизайнеру грамотно называть классы в HTML, чтобы проект был понятен не только разработчикам, но и самому себе.

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

Почему правильные названия классов важны?

Многие дизайнеры считают, что верстка — задача разработчиков. Но структура кода начинается с дизайна. Если слои в макете не организованы, разработчику придётся разбираться вручную, а это замедляет проект.

Правильное именование классов:

Быстро передаёт логику интерфейса от дизайна к коду.
Упрощает поиск и правки элементов.
Ускоряет работу всей команды.

Как закладывать названия классов в Figma?

1. Осмысленно именуйте слои

Избавьтесь от названий вроде Rectangle 57. Используйте понятные иерархические названия, отражающие суть элемента:

button/primary вместо Rectangle 3.

card/header вместо Frame 7.

Используйте иерархию через /:

form/input — поле формы.

menu/item, menu/icon — структура меню.

2. Смысл важнее внешнего вида

Названия должны описывать функциональность элемента, а не его внешний вид:

❌ red-button, big-header.

✅ button/primary, header/main.

3. Группируйте элементы в компоненты

Например, карточка:

card/container — внешний фрейм.
card/header — заголовок.
card/description — текст.

4. Добавляйте комментарии

Если элемент сложный, подпишите его в Figma:

У слоя button/primary напишите: «Класс button--primary».

Как формировать названия классов в HTML?

1. Используйте методологию BEM

Методология BEM (Block Element Modifier) позволяет структурировать классы:

Блок — независимый элемент (button, card).
Элемент — часть блока (card__title, button__icon).
Модификатор — состояние или вариация (button--primary, button--disabled).

Пример:

<div class="card">
  <h3 class="card__title">Заголовок</h3>
  <p class="card__description">Описание</p>
  <button class="button button--primary">Подробнее</button>
</div>

2. Не перегружайте классы визуальными характеристиками

❌ card-blue-border.

✅ card--highlighted (если это акцентная карточка).

3. Сократите вложенность

Чем проще структура, тем легче её поддерживать.
Плохой пример:

<div class="container">
  <div class="card">
    <div class="card__header">
      <h3 class="card__title">Заголовок</h3>
    </div>
  </div>
</div>

Лучше так:

<div class="card">
  <h3 class="card__title">Заголовок</h3>
</div>

Практический пример: кнопки

В макете есть три вида кнопок: основная, второстепенная и отключённая.

В Figma:

button/primary.

button/secondary.

button/disabled.

В HTML:

<button class="button button--primary">Купить</button>
<button class="button button--secondary">Подробнее</button>
<button class="button button--disabled" disabled>Недоступно</button>

Если названия в Figma понятные, разработчик легко перенесёт их в HTML.

Частые ошибки

1. Слои без имён
   Rectangle 47 или Frame 8 только замедляют работу.

2. Визуальные характеристики в названиях
   Названия вроде red-button или big-header усложняют масштабирование проекта.

3. Сложные иерархии
   Чрезмерная вложенность в макете или коде создаёт путаницу.

Мини-чеклист для дизайнера

1. Осмысленно и структурировано именуйте слои в Figma.

2. Избегайте визуальных характеристик в названиях.

3. Используйте иерархию через / для группировки элементов.

4. Добавляйте подсказки для разработчиков.

5. Согласуйте с командой принципы именования до старта.

Итоги

Грамотно продуманные названия классов и слоёв:

Упрощают связь между дизайном и кодом.
Экономят время команды.
Делают проект удобным для доработок и масштабирования.

Закладывайте структуру на этапе дизайна, и работа станет проще для всех. 🚀

Где почитать:
BEM для дизайнеров от DSGNERS
Подробно на Хабре про взаимодействие дизайнеров и разработчиков от PIXONIC
Про нейминг слоев от Павла Пономаренко

До связи 🤝

Лишь обрывки сигнала в виде текстовых символов передают трагические события из удаленной космической колонии “Последняя надежда”.

Сделал планету с локациями для демо версии. 

1. Прохождение одной локации открывает доступ к соседним. 

2. Проходить локации можно в любом порядке. 

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

Плейтест запускаю в феврале! Записаться можно вот тут. Всем хороших выходных!

Привет, Хабр! 👋 Сегодня говорим про

Дизайн-токены: как настроить зависимости между базовыми и сложными токенами, и не потеряться

Что такое дизайн-токены?

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

Разделяются на:

Базовые — это минимальные элементы (цвета, отступы, шрифты). Например:

color-primary: #FF5722;   
spacing-base: 8px;   
font-size-base: 14px;  

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

button-primary-bg: color-primary;
button-primary-padding: spacing-base * 2;  

Почему важно настраивать зависимости?

Представьте, что вы меняете один базовый токен, например, брендовый цвет. Если сложные токены связаны с базовым, изменения автоматически распространятся на все связанные элементы интерфейса. Это:

🚀 Ускоряет внесение правок.

⚖️ Гарантирует консистентность.

📈 Облегчает масштабирование.

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

Как настроить зависимости между токенами?

1. Начните с базы

Создайте чёткий набор базовых токенов, которые описывают вашу визуальную систему. Они должны быть универсальными и легко читаемыми.

Пример:

color-primary: #FF5722; 
color-secondary: #2196F3; 
spacing-base: 8px; 
font-size-base: 14px; 
radius-base: 4px;

2. Используйте базовые токены в сложных

При работе с компонентами используйте базовые токены как основу для сложных. Это создаёт гибкую систему, где каждый компонент "наследует" свойства от базовых переменных.

Пример:

button-primary-bg: color-primary;
button-primary-text-color: #FFFFFF;
button-primary-padding: spacing-base * 2;
card-border-radius: radius-base;

3. Структурируйте токены по уровням

Для больших проектов важно организовать токены в логичные группы:

Базовые токены: цвета, размеры, отступы.
Токены компонентов: кнопки, карточки, поля ввода.
Токены состояний: ховер, фокус, отключённые элементы.

Пример структуры:

// Базовые токены 
color-primary: #FF5722; 
color-primary-hover: darken(color-primary, 10%); 
spacing-base: 8px;
// Кнопки 
button-primary-bg: color-primary; 
button-primary-hover-bg: color-primary-hover; 
button-primary-padding: spacing-base * 2;

4. Автоматизируйте процесс

Для упрощения работы с токенами и синхронизации между дизайном и разработкой используйте инструменты:

Figma Tokens — плагин для создания токенов в Figma.
Style Dictionary — инструмент для генерации токенов в разных форматах (CSS, SCSS, JSON).

5. Тестируйте на реальных кейсах

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

Частые ошибки при работе с токенами

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

Отсутствие связи между токенами
Избегайте "хардкода". Например, вместо #000000 используйте базовый токен color-primary.

Игнорирование инструментов
Попытки вручную управлять токенами в большом проекте только усложняют процесс.

Что мы получим, если сделаем всё правильно?

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

Где почитать:
Простыми словами про токены на Хабре
Ультимативный гайд по дизайн-токенам на Хабре от Usetech
Про взаимодействие дизайнеров и инженеров при работе с токенами на DevMaster

До встречи, Хабр!

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

Слэш (/) используется для разделения клавиш, которые выполняют одну и ту же функцию на разных платформах (Mac OS / Windows)

Навигация по слоям
Когда макет разрастается до десятков фреймов и сотен слоёв, ручное копание в слоях превращается в мучение, но процесс можно ускорить:

Cmd/Ctrl — Выделение конкретных объектов внутри группы

Enter — Провалиться на слой ниже

Shift + Enter — Подняться на слой выше

Cmd/Ctrl + Y — Переход в режим скелета (помогает найти потеряшек)

…

Перемещение объектов
Часто объект просто не хочет встать на место, потому что автолайаут тянет его туда, куда не надо. Добавьте гибкости в перенос с помощью клавиш:

Shift + Cmd/Ctrl + R — Вставка с заменой выбранного элемента

Перемещение с зажатым Space — Игнорирование структуры макета

Перемещение с зажатым Сontrol/Ctrl — Игнорирование автолайаута

…

Масштабирование
Хватить мучать колесико мыши и «зумить» вручную, просто зажимай:

Shift + 1 — Показ всех макетов

Shift + 2 — Фокусировка на выделенном объекте

Shift + 0 — Зум до 100%

Двойной клик по иконке слоя — Фокусировка рабоче области на объекте

…

Общее

/ — Включить курсорный чат

Shift + С — Скрыть комменты

Cmd/Ctrl+ L — Скопировать ссылку на конкретный фрейм/объект

Shift + Cmd/Ctrl + С— Скопировать выделенный объект в буфер обмена как PNG

…

Персональные горячие клавиши
Если действие повторяется часто, а стандартной горячей клавиши для него нет, можно создать свою. В macOS доступна установка пользовательских комбинаций для любых действий через настройки клавиатуры. Важно: название меню переписываем точно как в Figma.

Совет: Добавляйте горячие клавиши для плагинов и действий, если используете их хотя бы раз в неделю. Это заметно ускорит работу и избавит вас от лишних кликов.

Привет, Хабр! 👋 Сегодня говорим про

UX‑аудит, как найти и устранить проблемы интерфейса с помощью UX‑законов

Создание удобного интерфейса — сложная задача, где даже мелкие недочёты могут вызвать недовольство пользователей. Если метрики падают, а отзывы оставляют желать лучшего, вам нужен UX‑аудит. Сегодня расскажу как провести аудит, какие методы использовать и как помочь себе с помощью UX‑законов.

Что такое UX‑аудит и зачем он нужен?

UX‑аудит — это проверка интерфейса на удобство использования. Его цель — выявить проблемные точки, которые мешают пользователям выполнять задачи.

Когда проводить UX‑аудит?

📉 Низкая конверсия или высокий показатель отказов.

👿 Пользователи жалуются на сложности.

👨‍🎨 Вы готовитесь к редизайну.

Методы UX-аудита

1. Использование UX-законов

UX-законы — принципы, объясняющие поведение пользователей. Примеры:

Закон Миллера: Человек удерживает в памяти 5–9 элементов. Убедитесь, что ваш интерфейс не перегружен информацией.

Закон Фиттса: Чем дальше и меньше элемент, тем сложнее на него нажать. Проверьте размеры кнопок.

Эффект Зейгарник: Незавершенные действия запоминаются лучше. Например, используйте прогресс-бары или напоминания.

2. Анализ данных

Инструменты аналитики помогут найти проблемные места:

Карта кликов: показывает, какие элементы привлекают внимание, а какие игнорируются.

Сессии пользователей: дают понять, где пользователи застревают.

Конверсия и отказы: указывают на слабые места в пути пользователя.

3. Пользовательские исследования

Юзабилити‑тесты: наблюдайте, как пользователи выполняют ключевые задачи.

Опросы: выясните, что нравится или раздражает.

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

4. Хейтерская сессия

Попробуйте сами быть самым критичным пользователем: что мешает вам дойти до цели? Этот метод помогает выявить очевидные проблемы. Не переусердствуйте!

Как провести UX‑аудит?

1. Сбор данных

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

2. Проверка по UX‑законам

Проанализируйте интерфейс: Не перегружен ли он информацией? Удобно ли пользоваться навигацией? Интуитивно ли расположены кнопки?

3. Тестирование с пользователями

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

4. Составление рекомендаций

После сбора данных подготовьте список аргументированных доработок.

Например: Оптимизировать структуру страниц. Улучшить тексты, чтобы они стали понятнее. Изменить дизайн кнопок или форм.

Зачем учитывать UX‑законы?

Применение UX‑законов помогает избежать распространенных ошибок. Например:

Проблема: высокая отказоустойчивость в онлайн‑магазине.

Решение: сократили количество фильтров (закон Миллера), упростили поиск. Конверсия выросла на 20%.

Итоги UX‑аудита

После UX‑аудита ваш продукт станет:

Понятным: пользователи быстрее осваивают интерфейс.

Интуитивным: меньше ошибок и сложностей.

Эффективным: выше конверсии, меньше отказов.

Где почитать:
Подробно про аудит и как его делать от Fuse8
Руководство по улучшению интерфейса от Pixcap
Чек-лист по юзабилити в e-commerce от TexTerra

Помните: UX‑аудит — это не разовая акция, а постоянный процесс. Всегда найдётся, что улучшить! До связи 🤝

Привет, Хабр! 👋 Поговорим о том,

Как учесть особенности Android и iOS при проектировании интерфейсов

Делаете приложение для Android и iOS? Отлично! Но чтобы ваш продукт стал действительно удобным и естественным для пользователей обеих платформ, нужно учитывать их особенности. Сегодня расскажу, как платформа влияет на дизайн, в чем основные различия и как с этим работать.

Почему важно учитывать специфику платформ?

Каждая платформа формирует свои привычки и ожидания у пользователей. Если их игнорировать:

Пользователи почувствуют, что «что-то не так» — привычные жесты или расположение кнопок будут работать иначе, что вызовет раздражение.

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

Продукт потеряет доверие пользователей, если взаимодействие с ним будет неестественным.

Разберем ключевые различия между Android и iOS

Навигация

🤖 Android: используют нижнюю панель (Bottom Navigation) или бургер-меню.
🍏 iOS: предпочитают Tab Bar и размещают кнопку «Назад» в верхнем левом углу.
👉 Совет: следуйте нативным паттернам платформы. Например, Tab Bar на iOS работает лучше, чем бургер-меню.

Кнопки

🤖 Android: чёткие формы с тенями (Material Design).
🍏 iOS: минимализм с большим количеством свободного пространства.
👉 Совет: создайте универсальный UI-kit с вариантами для каждой платформы.

Шрифты

🤖 Android: шрифт Roboto.
🍏 iOS: шрифт San Francisco, оптимизированный для устройств Apple.
👉 Совет: используйте нативные шрифты, чтобы текст выглядел привычно.

Анимации

🤖 Android: акцент на плавных переходах и изменениях состояния.
🍏 iOS: сложные жесты и динамичные анимации для интерактивности.
👉 Совет: обсуждайте анимации с разработчиками, чтобы они соответствовали возможностям платформ.

Иконки

🤖 Android: детализированные, с акцентом на материалы.
🍏 iOS: минимализм, строгие пропорции.
👉 Совет: согласуйте с командой размеры и формат иконок заранее.

Как это влияет на продукт?

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

На чем фокусироваться?

Изучайте гайдлайны: перед проектированием прочитайте рекомендации для Android и iOS. В Figma Community можно найти актуальные гайдлайны для обеих систем и опираться на них.

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

Создавайте дизайн-систему: унифицируйте элементы, но учитывайте специфику каждой платформы. Разделяйте, стандартизируйте в меру и поддерживайте актуальность.

Тестируйте на устройствах: проверяйте макеты на реальных Android и iOS.

Итог

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

До связи 🤝

Как эффективно давать фидбек дизайнеру?

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

Отсутствие токсичности

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

Внятность

«Макеты красивые, спасибо!» — такой ответ не дает дизайнеру понимания «В чем они красивые?», аналогично с негативной стороны.

Уместность

Если обратная связь дается по конкретной серии макетов, то добавлять мнение о поведении на дейликах не несет смысла.

Время

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

Сбалансированность

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

—

Подписывайтесь на мой блог @markuxuich. В блоге я пишу про рост в дизайне, финансы, лайфхаки и важные заметки для дизайнеров.

Привет, Хабр!

Сегодня хочу поговорить о том, как развить дизайн‑концепцию, создать UI‑kit, и шагнуть на новый уровень с помощью дизайн‑систем.

Готовы? Окей летс го!

Что такое дизайн‑концепция?

Это основа вашего визуального решения: стиль, настроение и принципы, которые делают продукт узнаваемым и целостным. Это как фундамент дома — без него всё развалится.

Зачем она нужна?

💡 Помогает визуально выделить продукт на рынке.

🎯 Упрощает коммуникацию с командой: все работают в одном направлении.

⏱️ Экономит время: больше не нужно гадать, как стилизовать новый экран.

Как развить свою дизайн‑концепцию?

Погрузитесь в проект
Исследуйте продукт, целевую аудиторию, конкурентов. Поймите, какие эмоции должен вызывать ваш дизайн: доверие, радость, уверенность?

Пример:
Для финтех‑приложения важно создать ощущение надёжности. Значит, дизайн должен быть строгим, минималистичным, с использованием сдержанных цветов.

Определите основные элементы стиля:
Шрифты / Цветовая палитра / Графика и иконки / Стиль фотографий или иллюстраций

Совет: Не пытайтесь придумать всё сразу. Начните с базовых вещей: 2–3 основных цвета и 1–2 акцента.

Соберите мудборд
Мудборд — это ваша визуальная карта. Используйте Pinterest или Figma, чтобы собрать примеры шрифтов, цветов и графики, которые отражают ваш стиль.

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

Создание UI‑kit: с чего начать?

UI‑kit — это набор компонентов, который помогает вам быстро собирать интерфейсы.

Определите основные компоненты
Кнопки, текстовые поля, переключатели, карточки — начните с самых базовых элементов.

Пропишите состояния
У каждой кнопки или поля ввода есть несколько состояний:
Нормальное / Наведение / Активное / Ошибка / Заблокированное

Пример: Кнопка «Купить» в обычном состоянии зелёная, а при наведении становится чуть темнее.

Унифицируйте стили
Используйте одни и те же отступы, закругления, шрифты.

Задокументируйте
Пропишите, где и как использовать каждый элемент. Это сэкономит время команде.

Что дальше? Дизайн‑система!

Когда ваш UI‑kit становится большим и вы начинаете работать с масштабными проектами, пора задуматься о дизайн‑системе. (тут можно упомянуть работу с токенами, но это тема для отдельного поста)

Дизайн‑система — это:

Чёткий свод правил и компонентов.

Инструмент для масштабирования дизайна.

Связующее звено между дизайнерами и разработчиками.

Пример структуры дизайн‑системы:

1. Гайдлайны: цвета, шрифты, стили.

2. Библиотека компонентов: кнопки, карточки, модальные окна.

3. Паттерны: как компоненты используются вместе.

4. Документация: примеры и объяснения.

Итог:

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

Думайте стратегически: ваша концепция — это не просто про красоту, а про решение задач.

Делайте проще: UI‑kit и дизайн‑системы помогут вам ускорить работу.

Тестируйте: каждый элемент должен быть полезным и логичным.

Где почитать:
Что такое UI-kit от Bang Bang Education
Доходчиво про дизайн-системы от моих любимых Tilda Publishing
Еще про дизайн-системы на Практикуме

До встречи на Хабре! 👋

Хабр, привет!

Сегодня поговорим о UX-тестировании и глубинных интервью.

Как сделать так, чтобы тесты выявляли настоящие проблемы, а интервью давали ценную обратную связь? Разбираем степ бай степ!

Что такое UX-тестирование?

Это процесс, в котором вы наблюдаете за тем, как пользователь выполняет определённые задачи в вашем продукте. Цель - понять, что работает, а что вызывает сложности.

Как провести эффективное тестирование?

1. Сценарии вместо вопросов.
Давайте пользователям конкретные задачи, а не абстрактные вопросы. Вместо «Что вы думаете об этом экране?» скажите: «Попробуйте найти ближайший магазин на карте». Это помогает увидеть реальное взаимодействие.

2. Тестируйте с целевой аудиторией.
Если ваш продукт для бухгалтеров, тестируйте на бухгалтерах, а не на друзьях или коллегах. Только реальные пользователи покажут настоящие проблемы.

3. Молчите и наблюдайте.
Когда пользователь запутался, не спешите подсказывать. Вместо этого спросите: «Что бы вы сделали дальше?» или «Почему вы решили нажать сюда?». Молчание помогает понять, где интерфейс недоработан.

4. Фиксируйте факты.
Записывайте то, что пользователь делает, а не то, что вам кажется важным. Например, вместо «он ошарашен и запутался» напишите: «трижды нажал на кнопку “Назад”, чтобы найти меню».

Что такое глубинные интервью?

Это формат, где вы задаёте пользователю вопросы, чтобы узнать его опыт, мотивацию и проблемы. Главное здесь - не задавать наводящих вопросов.

Как провести глубинное интервью?

1. Открытые вопросы — наше всё.
Спрашивайте так, чтобы человек мог подробно ответить. Например: «Как вы обычно ищете билеты на концерт?», а не «Вам нравится искать билеты в приложении?».

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

3. Уточняйте детали.
Если человек сказал что-то важное, не бойтесь уточнить: «Почему это для вас важно?», «Что именно было неудобным?». Это раскроет проблему глубже.

4. Не оценивайте ответы.
Сохраняйте нейтральность. Например, не говорите «Это интересное мнение». Пользователь может начать говорить только то, что, как ему кажется, вам нужно услышать.

5. Всегда спрашивайте: «Что я забыл спросить?»
Этот вопрос открывает новые инсайты. Пользователь может вспомнить то, о чём вы даже не подумали.

Зачем это всё?

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

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

Где почитать:
Про виды и методы UX-тестирования на Яндекс.Практикум
9 методов UX-тестирования на UX Journal от Рината Шайхутдинова
Про глубинные интервью от UPROCK

Привет Хабр!
Сегодня обсудим две важные составляющие работы дизайнера:

User Flow и персоны.

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

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

Что такое User Flow?

User Flow — это визуальная карта пути пользователя внутри продукта. Она показывает, какие шаги он проходит, чтобы достичь своей цели.

Представьте, что вы проектируете интернет-магазин. У пользователя есть цель - купить товар. User Flow отвечает на вопрос:
Как он попадёт из точки А (поиск товара) в точку Б (успешная покупка)?

Как построить User Flow?

1. Определите цели пользователя
   Задайте себе вопрос: зачем пользователь пришёл в продукт? Цель должна быть конкретной: «купить», «забронировать», «подписаться».

2. Выделите ключевые этапы пути
   Разделите процесс на шаги. Например, для покупки это может быть:
   - Поиск товара
   - Добавление в корзину
   - Оформление заказа
   - Оплата

3. Проработайте детали каждого этапа
   Уточните: где пользователь может столкнуться с затруднениями? Какие действия он совершает на каждом шаге?

4. Используйте визуализацию
   Постройте схему: можно использовать FigJam, Miro или даже обычный блокнот. Главное, чтобы было наглядно.

Что такое Персоны?

Персона — это собирательный образ вашего пользователя. Она помогает «оживить» аудиторию и лучше понять её нужды, мотивацию и поведение.

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

Как создавать персоны?

1. Соберите данные
   Анализируйте:
   - Результаты интервью и опросов
   - Аналитику
   - Поведение пользователей

2. Опишите основные характеристики
   Персона должна включать:
   - Имя (пусть даже вымышленное)
   - Возраст, пол, профессию
   - Основные задачи и цели
   - Боли и сложности

   Пример:
   Анастасия, 32 года. Маркетолог. Работает удалённо, ищет инструмент для быстрой совместной работы с коллегами. Главная боль — сложные интерфейсы, где всё непонятно и долго.

3. Определите сценарий использования продукта
   Как персона будет использовать ваш продукт? Зачем он ей нужен? Какие барьеры могут возникнуть на пути?

4. Фокусируйтесь на конкретике
   Чем детальнее будет персона, тем легче будет понять её поведение и проработать дизайн для её задач.

Почему важно работать с User Flow и персонами?

Понимание пользователя
Вы создаёте продукт не для себя, а для конкретных людей. Персоны и User Flow помогают глубже понять их потребности и мотивы.

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

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

Маленький лайфхак

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

Где почитать:
Исчерпывающе о User Flow на UX journal
О методе персон на Uplab
Еще база про User Flow на Skillbox

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

Хабр, привет!

Сегодня поговорим о пользовательских сценариях. Как сделать так, чтобы взаимодействие с продуктом стало для пользователя лёгким и комфортным, словно прогулка по парку? Давайте разбираться!

Что такое пользовательский сценарий?

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

Сценарии позволяют не просто создать красивый интерфейс, а заложить в продукт логику, которая ведёт пользователя от точки А к точке Б максимально естественно.

Зачем их проектировать?

Интуитивность: Чтобы пользователи не терялись в интерфейсе.
Удобство: Минимум действий для достижения цели.
Эффективность: Меньше ошибок, выше удовлетворённость.

Как строить сценарии?

1. Определите цели пользователя

Поймите, зачем человек пришёл в ваш продукт. У каждой задачи есть своё назначение: узнать информацию, купить, оставить заявку. Чётко сформулируйте эту цель.

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

2. Разберите путь до цели

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

Пример:
- Открыть приложение.
- Выбрать вкладку «Концерты».
- Найти нужное событие.
- Нажать «Купить билет».Выбрать место.
- Оплатить.

Каждый шаг должен быть логичным и максимально простым.

3. Учитывайте возможные сложности

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

Ошибок (например, неверный пароль).
Сложностей (нет информации о доступных местах).
Альтернативных путей (не хочет регистрироваться перед покупкой).

Дайте пользователю подсказки, упрощайте процесс, устраняйте лишние барьеры.

4. Применяйте «золотое правило UX»

Каждый сценарий должен быть:

Простым (минимум шагов).
Понятным (никаких сложных терминов).
Предсказуемым (пользователь должен понимать, что произойдёт дальше).

5. Тестируйте

Проверьте сценарии на реальных пользователях. Задайте себе вопросы:

Удобно ли им проходить путь?
Все ли шаги логичны?
Нет ли лишних действий?

Маленький лайфхак:

Думайте о сценариях, как о маршруте в навигаторе. Вы должны привести пользователя к цели коротким и понятным путём, убрав все препятствия. Очень удобно писать сценарии и строить взаимосвязи в инструменте FigJam.

Итог

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

Где почитать:
Про пользовательские сценарии для начинающих пишет UPROCK
Про виды сценариев и как из строить рассказывает Денис Нарижный из Студии F1
Еще про сценарии на Яндекс.Практикуме

До встречи!

Сделал локацию "Отдых и прокачка" для моей игры Effulgence, созданной из текстовых символов. Нахождение в ней медленно восстанавливает HP. Можно заселиться в гостиницу, чтобы моментально восстановить 100% HP.

Все объекты в игре - лишь тонкая пленка формы, с трудом удерживающая хаос текстовых символов)) Поэтому полное восстановление - это разрушение и пересборка.

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

Заходите посмотреть на проект в Steam и добавить в вишлист, если вам понравился стиль.