Веб-дизайн *

Иконки-кнопки и кнопки-иконки: как дизайнеру не совершить ошибку и не запутать окружающих

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

Иконки-кнопки

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

Почему иконки-кнопки — это не очень хорошо?

1. Мы искажаем формулировку

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

2. Коммуникация

   В данном случае мы не разделяем сущности. Разделение же на «иконку» и «кнопку-иконку» упрощает общение с разработчиками. Иконка — это графика, а кнопка-иконка — кнопка с графическим элементом. Это помогает избежать путаницы, когда рядом находятся кликабельные иконки и просто графические элементы.

3. Размер контейнера

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

4. Дисбаланс

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

5. Исключения

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

Кнопки-иконки

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

Почему кнопки-иконки — это мастхэв?

1. Чёткость формулировок

   Нет путаницы: это кнопка с функцией действия, а не просто графический элемент (иконка)

2. Упрощают коммуникацию

   На созвонах с разработчиками мы чётко понимаем, о чём идёт речь: о кнопке или о графическом элементе

3. Системные размеры контейнеров

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

4. Баланс

   Хорошо выстроенная система кнопок-иконок сбалансирована и не требует лишних усилий для выравнивания элементов

5. Ghost кнопки

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

Итого

Использование кнопок-иконок вместо иконок-кнопок предполагает:

— Упрощение коммуникации
— Соответствие логике сущностей
— Соответствие названий элементов интерфейса логике сущностей
— Понятные и простые тачзоны
— Нативная поддержка системно сбалансированных сущностей
— Есть исключение в виде icon info

А вы выносите в отдельные компоненты кнопки с иконками? Или поддерживаете кнопки с полным набором атрибутов: иконки, текст, каунтеры и другим?

Вышла седьмая версия 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 и следите за обновлениями!

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

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
Про нейминг слоев от Павла Пономаренко

До связи 🤝

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

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

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

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

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

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

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‑аудит — это не разовая акция, а постоянный процесс. Всегда найдётся, что улучшить! До связи 🤝

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

Сегодня хочу поговорить о том, как развить дизайн‑концепцию, создать 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
Еще про сценарии на Яндекс.Практикуме

До встречи!

Ребята, привет! Давайте поговорим про:

Анализ конкурентов

Это одна из самых интересных и полезных практик, которая помогает нам делать продукты лучше. Но, как и во всём, тут есть тонкости. Цель анализа - не копировать чужие решения, а понять, что работает, что нет, и придумать что-то своё, уникальное. Как это сделать? Сейчас разберём!

Зачем анализировать конкурентов?

Анализ конкурентов - это не только про то, чтобы узнать, что делают другие. Это про то, чтобы:

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

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

Выявить слабые места. У каждого продукта есть недостатки. Их можно превратить в ваши преимущества.

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

Как правильно анализировать конкурентов?

Вот пошаговый план:

1. Определите, кого анализировать.

Составьте список конкурентов. Это могут быть:

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

2. Изучите продукт.

- Зарегистрируйтесь и попробуйте продукт как пользователь.
- Изучите весь пользовательский путь: от первых экранов до глубины функционала.
- Проверьте их мобильные и веб-версии, если они есть.

3. Проанализируйте интерфейс и UX.

Какие паттерны и подходы они используют?

- Легко ли понять их продукт? Какие элементы интерфейса кажутся удачными?
- Какие моменты вызывают вопросы или трудности?

4. Оцените визуальный стиль.

- Как выглядит их дизайн? Современный, минималистичный, классический?
- Есть ли в нём что-то, что может выделять их среди других?

5. Соберите отзывы пользователей.

Отзывы - это кладезь информации. Люди часто рассказывают, что им нравится и что не устраивает. Загляните в:

App Store, Google Play.
Соцсети и форумы.
Обзоры на профильных сайтах.

6. Проанализируйте метрики.

Если есть доступные данные, изучите их:

- Количество скачиваний.
- Рейтинг приложения.
- Активность в соцсетях.

Как не копировать, а адаптировать?

Вот несколько советов:

Понимайте контекст. Если у конкурента что-то работает, это не значит, что оно сработает у вас. Понять, почему решение эффективно, - уже половина успеха.

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

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

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

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

Сделайте себе простую таблицу для анализа конкурентов. Например:

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

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

И помните: лучший продукт - это не тот, который делает всё как у других, а тот, который делает это лучше.

Где почитать:
Руководство по конкурентному анализу от Андрея Шилова на Medium (идти с прокси)
Конкурентный анализ от UPROCK
Статья на Хабре от Никиты Колюгина

До скорого!

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

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

UX-аналитика: Фокус на пользователе

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

Что важно учитывать:

Поведение. Какие экраны популярны? Где пользователи чаще всего уходят?

Барьеры. Что вызывает трудности? Это могут быть длинные формы, сложная навигация или непонятный интерфейс.

Удовлетворённость. Насколько пользователи довольны вашим продуктом? Здесь помогут NPS, CSAT или отзывы.

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

Бизнес-аналитика: Фокус на цифрах

Бизнес-аналитика отвечает на вопрос: как ваши решения влияют на показатели компании? Это про деньги, рост и эффективность.

Что здесь важно:

Конверсия. Сколько пользователей совершает целевое действие?

Доход. Какие изменения влияют на рост выручки?

Затраты. Как оптимизировать расходы без потери качества?

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

Почему важно соединить UX и бизнес-аналитику?

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

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

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

Как связать UX и бизнес-аналитику?

1. Определите общие метрики.
   Начните с ключевых показателей, которые важны как для UX, так и для бизнеса. Например: Время завершения целевого действия (UX) - Конверсия в продажу (бизнес). Доля возвратов (UX) - Затраты на обработку возвратов (бизнес).

2. Собирайте данные совместно.
   Используйте инструменты аналитики, которые учитывают и пользовательский опыт, и бизнес-метрики. Например, связывайте результаты A/B-тестов с доходом или конверсией.

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

4. Итеративно улучшайте.
   Любое изменение проверяйте с двух сторон: стало ли пользователям удобнее, и как это повлияло на показатели бизнеса.

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

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

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

Где почитать:
Собака Павлова пишет о решении бизнес задач при при помощи дизайна.
Бизнес аналитик Ирина Козлова рассказывает на Хабре про слонов и деревья
Неплохая статья на AskUsers о дизайне и анализе данных

До встречи в следующих постах!

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

Вот и первый пост из нашего цикла, итак:

Генерация гипотез

Сегодня давайте поговорим о том, почему так важна генерация гипотез в нашей работе и как правильно подходить к этому процессу. Умение формулировать правильные гипотезы - это один из основных признаков профессионального дизайнера. И если вам кажется, что это непростая задача, не переживайте - этот навык приходит с опытом. Готовы разобраться? Поехали!

Почему гипотезы так важны?

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

Как правильно формулировать гипотезы?

Есть отличная структура, которая упрощает процесс:

Если мы сделаем [изменение], то пользователи смогут [результат], потому что [обоснование].

Пример:

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

Гипотеза должна быть понятной и проверяемой. Это не гадание на кофейной гуще - мы выдвигаем предположения и тестируем их.

Где искать идеи для гипотез?

Не знаете, с чего начать? Вот несколько надежных источников:

1. Данные. Проанализируйте статистику: какие экраны вызывают затруднения? Где пользователи чаще всего «застревают»?

2. Юзабилити-тесты. Наблюдайте за пользователями, задавайте им вопросы - это кладезь инсайтов.

3. Конкуренты. Посмотрите, как похожие задачи решаются в других продуктах. Что можно сделать лучше?

4. Личный опыт. Ведь вы тоже пользователь! Иногда достаточно взглянуть на интерфейс свежим взглядом.

Что делать с гипотезами дальше?

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

2. Тестирование. Проверяйте гипотезы через A/B-тесты, прототипы, аналитику. Главное - опираться на реальные данные.

3. Итерации. Если гипотеза не сработала, не переживайте - это тоже результат! Проанализируйте, что пошло не так, и двигайтесь дальше.

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

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

И помните: генерация гипотез - это не магия. Это инструмент, который помогает нам расти как профессионалам и создавать крутые решения для пользователей. Экспериментируйте, делитесь идеями, и вместе мы найдём самые классные подходы!

Где почитать:
Skillbox хорошо разобрали виды гипотез и процесс работы с ними
Шаблон формулирования гипотез от AGIMA
Гипотезы для usability теста на Tproger

До встречи в следующих постах!

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

Не так часто ко мне поступают вопросы по дизайну на Хабр Карьере, но вот недавно одна коллега-дизайнер прислала мне настоящий список запросов, по которым она хотела бы получить развернутые консультации. И я понял, что таких вопросов не только у неё, а вот полезных материалов по ним в открытых источниках часто не хватает - или они слишком фрагментированы.

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

Что планирую рассмотреть:

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

2. UX-аналитика и Бизнес-аналитика. Как связать анализ пользовательского опыта с бизнес-позициями и почему важно не забывать про оба аспекта.

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

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

5. User Flow и Персоны. Как создавать User Flow и прорабатывать персоны для детального понимания того, как пользователи себя ведут.

6. UX-тестирование и Глубинное интервью. Как сделать тестирование таким, чтобы оно реально выявляло проблемы, а глубинные интервью давали ценную обратную связь.

7. Создание дизайн-концепции. Как развить свою дизайн-концепцию, составить UI-kit и начать работать с дизайн-системами.

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

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

10. Токены. Как правильно настроить зависимости между сложными токенами и базовыми (цвета, отступы, размеры), и не потеряться в этом процессе.

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

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

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

До скорого в следующих постах!

Представлен проект капчи DOOM CAPTCHA, где нужно убить минимум трёх монстров на карте secret level E1M9 в режиме Nightmare. Стрейфиться нельзя, управление - стрелки вперёд. назад, вправо, влево, стрельба - пробел.

В сети появился онлайн-скринсейвер Screensaver Chess, который решает шахматные головоломки.

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

❌ Бесконечно бодаться из-за правок, доказывая заказчику, что их нельзя вносить

В результате выпустить материал с сильной задержкой или не выпустить совсем.

✅ Спокойно и профессионально аргументировать точку зрения, а после отпустить заказчика с миром

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

Как может выглядеть аргументация для заказчика:

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

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

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

Больше советов для тех, кто работает с текстом, — на канале Плохое/хорошее.

Недавнее исследование выявило и классифицировало 68 уникальных типов «тёмных паттернов» в дизайне пользовательских интерфейсов. Эти паттерны были организованы в пять основных категорий:

• Препятствия (Obstruction): Намеренное усложнение или запутывание процессов.

• Укрывательство (Sneaking): Сокрытие или искажение информации с целью введения пользователей в заблуждение.

• Интерференция интерфейса (Interface Interference): Манипуляции элементами интерфейса для влияния на поведение пользователей.

• Принуждение (Forced Action): Обязательное выполнение пользователем определённых действий для достижения желаемого результата.

• Социальная инженерия (Social Engineering): Использование социальных норм или давления для манипуляции поведением пользователей.

Кроме того, таксономия включает 8 новых подкатегорий и 24 дополнительных типа тёмных паттернов, таких как:

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

• Новые тёмные паттерны: Принудительный льготный период (Forced Grace Period), только первоначальные выплаты (Only Initial Payouts), бесконечная прокрутка (Infinite Scrolling) и другие.

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

https://arxiv.org/pdf/2412.09147

Чат-боты стали неотъемлемой частью цифровых взаимодействий, однако их эффективность во многом зависит от восприятия пользователями их производительности и стиля общения. Исследования показывают следующее:

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

• Человечный стиль общения повышает удовольствие: Хотя человеческий стиль общения (например, эмпатия, шутки, эмоциональные реакции) не оказывает существенного влияния на восприятие простоты использования или полезности, он значительно увеличивает ощущение удовольствия от взаимодействия, делая общение с чат-ботом более приятным.

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

https://www.tandfonline.com/doi/epdf/10.1080/10447318.2023.2175158