Короткий ответ

UI, или user interface, это все элементы, через которые пользователь взаимодействует с продуктом: кнопки, формы, таблицы, меню, тексты, иконки и layout. Для frontend-разработчика UI важен как конкретная реализация поведения и визуального состояния.

Короткий ответ

UX, или user experience, это опыт пользователя при достижении цели в продукте. UX включает понятность сценария, скорость, ошибки, доверие, доступность и ощущение контроля.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

User journey описывает более широкий путь пользователя: контекст, ожидания, точки контакта, эмоции и проблемы. User flow обычно уже и ближе к конкретному экрану.

Короткий ответ

Wireframe - это черновая схема экрана без детальной визуальной стилистики. Он помогает договориться о структуре, приоритетах и сценарии до дорогой проработки деталей.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Разработчик решает, как работают loading, empty, error, focus, keyboard navigation, адаптивность и реальные данные. Именно в коде часто появляются сценарии, которых не было в статичном макете.

Короткий ответ

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

Короткий ответ

Cognitive load - это умственное усилие, которое нужно пользователю для понимания интерфейса и принятия решения. Чем больше лишних вариантов, нестандартных паттернов и неясных текстов, тем выше нагрузка.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Обычно нужны default, hover, focus, active, disabled, loading, success и error, если компонент участвует в действии. Для интерактивных элементов важно продумать мышь, клавиатуру и touch.

Короткий ответ

Loading state показывает, что данные или действие еще выполняются. Он должен объяснять, что происходит, особенно если ожидание дольше мгновения.

Короткий ответ

Empty state показывает, что данных пока нет, но экран работает корректно. Хороший empty state объясняет причину и часто предлагает следующий шаг.

Короткий ответ

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

Короткий ответ

Disabled state означает, что элемент сейчас недоступен для взаимодействия. Если причина не очевидна, рядом нужна подсказка или другой способ понять ограничение.

Короткий ответ

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

Короткий ответ

Spinner не говорит, что именно происходит и сколько ждать. Без контекста пользователь может подумать, что интерфейс сломался или действие не началось.

Короткий ответ

Пустой экран выглядит как ошибка или незагруженный интерфейс. Empty state должен объяснить состояние и подсказать, как получить первые данные.

Короткий ответ

Нужны initial, dirty, valid, invalid, submitting, success, server error и disabled по правам или контексту. Также важно решить, когда показывать ошибки и как не потерять введенные данные.

Короткий ответ

Нужны loading, частичная загрузка, empty, error, filtered empty, pagination, sorting, selected rows и обновление данных. Для больших таблиц важны стабильные размеры колонок и отсутствие layout shift.

Короткий ответ

Нужны пустой запрос, typing, loading, results, no results, error и stale results. Хороший поиск показывает, что именно искалось, и помогает изменить запрос.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Он делает интерфейс быстрее на ощущение, потому что пользователь сразу видит результат действия. Это хорошо работает для частых и обычно успешных операций.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Нужно показывать прогресс, сохранять структуру экрана, кешировать предыдущие данные и не блокировать все приложение. Для долгих операций полезны статусы, фоновые обновления и понятный retry.

Короткий ответ

Интерфейс должен различать offline, timeout, server error и stale data. Пользователь должен понимать, какие данные уже сохранены, что можно повторить и что требует подключения.

Короткий ответ

Error state означает, что сценарий не выполнен. Degraded state означает, что продукт работает частично: например, показаны кешированные данные без свежих рекомендаций.

Короткий ответ

Skeleton полезен, когда известна структура будущего контента и важно сохранить layout. Spinner подходит для коротких операций или небольших областей, где структура заранее неясна.

Короткий ответ

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

Короткий ответ

Нужно резервировать место под контент, задавать размеры медиа, таблиц и карточек, а также не вставлять поздно крупные элементы перед уже показанным контентом. Это улучшает и UX, и Core Web Vitals.

Короткий ответ

Perceived performance - это ощущение скорости, а не только реальное время ответа. Понятный loading, стабильный layout и ранний показ полезного контента делают ожидание короче субъективно.

Короткий ответ

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

Короткий ответ

Нужно менять состояние конкретного действия: loading label, disabled от повторного запуска, progress или inline status. Важно не блокировать больше интерфейса, чем требуется.

Короткий ответ

На frontend нужно блокировать повторную отправку, показывать submitting state и игнорировать лишние клики до ответа. На backend все равно нужна идемпотентность или защита от дублей.

Короткий ответ

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

Короткий ответ

Label объясняет, что нужно ввести в поле. Он нужен для понятности, доступности, автозаполнения и правильной работы screen reader.

Короткий ответ

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

Короткий ответ

Validation message объясняет, почему значение не подходит. Хорошее сообщение говорит не только о проблеме, но и о том, как ее исправить.

Короткий ответ

Client-side validation дает быстрый feedback в браузере. Server-side validation является обязательной, потому что сервер отвечает за безопасность, бизнес-правила и достоверность данных.

Короткий ответ

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

Короткий ответ

Required field - это поле, без которого форму нельзя успешно отправить. Пользователь должен заранее понимать, какие поля обязательны и почему.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Сообщение “invalid value” не помогает восстановиться. Пользователю нужен следующий шаг: “Введите email в формате name@example.com”.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Inline validation показывает feedback рядом с конкретным полем. Она удобна, когда ошибка локальная и пользователь может исправить ее сразу.

Короткий ответ

Это постепенное раскрытие дополнительных полей или настроек только при необходимости. Такой подход снижает шум и помогает не перегружать основной сценарий.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Нужен явный status: “Сохранено”, “Сохраняем”, “Не удалось сохранить”. Для важных данных полезны время последнего сохранения и понятный retry.

Короткий ответ

Нужно заранее объяснять последствия, выделять destructive action и давать шанс остановиться. Если возможно, лучше сделать действие обратимым через undo.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Save button лучше для явного контроля, autosave - для частого редактирования без финального шага, optimistic save - для быстрых надежных операций. Выбор зависит от риска, стоимости ошибки и ожиданий пользователя.

Короткий ответ

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

Короткий ответ

Keyboard navigation позволяет пользоваться интерфейсом с клавиатуры без мыши. Это важно для доступности, power users и ситуаций, где мышь неудобна.

Короткий ответ

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

Короткий ответ

Outline часто является единственным видимым индикатором фокуса. Если его убрать, нужно дать равноценный и заметный focus style.

Короткий ответ

Semantic HTML использует элементы по смыслу: button для действия, a для ссылки, label для поля, heading для структуры. Это помогает браузеру, assistive technologies и разработчикам.

Короткий ответ

Label связывает текстовое описание с полем ввода. Благодаря этому поле можно понять, сфокусировать кликом по подписи и корректно озвучить screen reader.

Короткий ответ

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

Короткий ответ

Когда изображение декоративное и не несет смысла. Пустой alt позволяет screen reader пропустить его и не создавать шум.

Короткий ответ

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

Короткий ответ

Порядок фокуса должен соответствовать визуальному и смысловому порядку экрана. Иначе пользователь клавиатуры теряет контекст и может пропустить важные действия.

Короткий ответ

Фокус должен переходить внутрь dialog, оставаться внутри до закрытия и возвращаться на элемент, который его открыл. Нужны понятный заголовок, закрытие с клавиатуры и недоступность фонового контента для взаимодействия.

Короткий ответ

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

Короткий ответ

ARIA добавляет семантику там, где native HTML не хватает. Она нужна для сложных custom components, но не должна заменять обычные HTML-элементы без причины.

Короткий ответ

Native элементы уже имеют встроенное поведение, роли, keyboard support и совместимость. ARIA легко применить неправильно и получить интерфейс, который выглядит доступным только в коде.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Нужно пройти сценарий с клавиатуры, проверить focus states, labels, contrast, heading structure и сообщения об ошибках. Автоматические проверки полезны, но не заменяют ручной проход.

Короткий ответ

Частые проблемы: div вместо button, потеря фокуса, недоступные custom select, слабый контраст, ошибки без текста и modal без focus management. Большинство из них дешевле исправлять во время разработки.

Короткий ответ

Нужно включить keyboard flow, focus state, labels, contrast, error handling и базовые проверки в критерии готовности. Так accessibility становится обычной частью разработки, а не отдельной фазой в конце.

Короткий ответ

Design system может централизовать доступные компоненты, цветовые токены, focus styles, labels и примеры паттернов. Это снижает вероятность повторять одни и те же ошибки в каждом feature.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Microcopy - это короткие тексты интерфейса: кнопки, подсказки, ошибки, empty states, labels и confirmations. Они направляют пользователя в момент действия.

Короткий ответ

В формах, уведомлениях, меню, onboarding, CTA, validation messages, placeholders и success states. Почти каждый интерактивный элемент нуждается в понятном тексте.

Короткий ответ

Текст кнопки задает ожидание результата. “Сохранить изменения” понятнее, чем “OK”, потому что описывает конкретное действие.

Короткий ответ

“OK” часто не объясняет, что произойдет после нажатия. Конкретный текст снижает риск ошибки и повышает уверенность.

Короткий ответ

Пользователь должен понять проблему без знания backend, HTTP-кодов или внутренних терминов. Хорошая ошибка помогает продолжить сценарий.

Короткий ответ

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

Короткий ответ

CTA должен совпадать с намерением пользователя и результатом операции. “Создать проект” лучше, чем “Продолжить”, если после клика создается проект.

Короткий ответ

Нужно назвать действие и объект: “Удалить отчет” вместо “Подтвердить”. Если последствия серьезные, текст должен прямо сказать, что будет потеряно.

Короткий ответ

Нужно писать через практическое последствие и вариант решения. Вместо “limit exceeded” лучше: “Можно добавить до 5 участников на текущем тарифе”.

Короткий ответ

Они непонятны пользователю и могут раскрывать внутренние детали системы. Frontend должен перевести ошибку в безопасное и полезное сообщение.

Короткий ответ

Нужно сопоставить код ошибки с пользовательским сценарием. Например, EMAILALREADYEXISTS можно показать как “Такой email уже зарегистрирован. Войдите или используйте другой email”.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Понятный текст снижает сомнения и ошибки в ключевых шагах. Это может повысить conversion rate без изменения механики интерфейса.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Нужно договориться о терминах, tone of voice и источнике правды для сообщений. Support полезен, потому что знает, какие формулировки пользователи реально понимают.

Короткий ответ

Разные названия для одного действия создают сомнения и ошибки. Единая терминология делает продукт предсказуемым.

Короткий ответ

Нужно заранее определить цель и сравнить поведение пользователей до и после изменения. Одних мнений команды недостаточно: нужны данные, feedback или usability check.

Короткий ответ

Подходят conversion rate, task success rate, time on task, drop-off, error rate, rage clicks, retention и обращения в support. Метрика должна соответствовать конкретной задаче интерфейса.

Короткий ответ

Conversion rate показывает долю пользователей, которые выполнили целевое действие. Например, отправили форму, завершили оплату или включили нужную настройку.

Короткий ответ

Task success rate показывает, какая доля пользователей смогла выполнить задачу. Эта метрика полезна для usability, потому что смотрит на результат, а не только на клики.

Короткий ответ

Time on task - это время, которое пользователь тратит на выполнение задачи. Меньше не всегда лучше: для рискованных действий полезнее осознанность, а не скорость.

Короткий ответ

Drop-off показывает, на каком шаге пользователи покидают сценарий. Он помогает найти места, где интерфейс сложен, медленен или вызывает недоверие.

Короткий ответ

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

Короткий ответ

Funnel - это последовательность шагов к цели, например просмотр товара, корзина, оплата и подтверждение. Он помогает видеть потери на каждом этапе.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Полезны start, field error, submit attempt, submit success, submit failure, abandon и retry. Не стоит отправлять сами значения чувствительных полей.

Короткий ответ

Результат зависит от сегмента, сезона, качества выборки, метрики и побочных эффектов. Иногда тест показывает изменение, но не объясняет причину.

Короткий ответ

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

Короткий ответ

Например, conversion может вырасти из-за давления или скрытия отказа. Пользователь выполнит действие, но доверие, удержание или support load ухудшатся.

Короткий ответ

Нужно смотреть на весь journey, а не только на один экран. Улучшение одного шага не должно переносить сложность на следующий.

Короткий ответ

Данные показывают, где проблема, а feedback и research помогают понять почему. Хорошее решение использует оба источника и проверяет гипотезу на реальном сценарии.

Короткий ответ

Qualitative research дает объяснения, мотивы и контекст на небольшом числе пользователей. Quantitative analytics показывает масштаб и частоту поведения.

Короткий ответ

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

Короткий ответ

Можно провести usability test, prototype review, feature flag rollout, интервью, анализ support tickets или dogfooding. Выбор зависит от риска и стоимости ошибки.

Короткий ответ

Медленный интерфейс повышает drop-off, ошибки, повторные клики и недоверие. Особенно сильно это влияет на формы, checkout и мобильные сценарии.

Короткий ответ

Они измеряют загрузку, отзывчивость и стабильность layout. Это не вся UX-картина, но хороший базовый сигнал качества frontend-реализации.

Короткий ответ

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

Короткий ответ

Разработчик участвует в обсуждении сценариев, метрик и trade-offs. Понимание bias помогает замечать слабые аргументы и проектировать интерфейс честнее.

Короткий ответ

Confirmation bias - это склонность искать и замечать данные, которые подтверждают уже выбранную точку зрения. В продукте это может привести к игнорированию неудобного feedback.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Status quo bias - это предпочтение текущего состояния только потому, что оно привычно. Пользователи и команда могут сопротивляться изменениям даже при объективной пользе.

Короткий ответ

Редизайн ломает привычные маршруты и требует заново учиться. Даже хороший новый UX может сначала восприниматься хуже, если переход не объяснен и не поддержан.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Framing effect означает, что формулировка влияет на восприятие одного и того же выбора. “Сэкономьте 20%” и “Не переплачивайте 20%” могут восприниматься по-разному.

Короткий ответ

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

Короткий ответ

Это связано с ownership bias и sunk cost: людям сложнее признать проблему в решении, куда уже вложено много сил. Помогают пользовательские данные, дизайн-ревью и фокус на цели, а не на авторстве.

Короткий ответ

Громкие пользователи чаще пишут, спорят и имеют сильную мотивацию. Их feedback важен, но его нужно сверять с данными и сегментами аудитории.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Нужно заранее сформулировать гипотезу, success metric и признаки неуспеха. Полезно специально искать данные, которые могут опровергнуть решение.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Нужно отделять проблему от решения, фиксировать критерии, рассматривать альтернативы и возвращаться к данным. Хорошо, когда у обсуждения есть фасилитатор и явные trade-offs.

Короткий ответ

Данные показывают масштаб, research объясняет причины, дизайн-ревью проверяет качество решения и consistency. Вместе они дают более надежную картину, чем любой один источник.

Короткий ответ

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

Короткий ответ

Они могут краткосрочно улучшить метрику, но ухудшают доверие, retention, support load и репутацию. В некоторых случаях они также создают юридические риски.

Короткий ответ

Forced continuity - это автоматическое продолжение платной услуги после trial без достаточно ясного предупреждения. Проблема не в подписке, а в непрозрачности и потере контроля.

Короткий ответ

Confirmshaming - это текст, который стыдит пользователя за отказ. Например, кнопка отказа с формулировкой “Нет, я не хочу экономить”.

Короткий ответ

Hidden cost - это скрытая стоимость, которая появляется поздно в сценарии. Такой прием ухудшает доверие, особенно в checkout и подписках.

Короткий ответ

Preselected option - это заранее выбранная опция, которая может быть выгодна бизнесу, но не обязательно пользователю. Особенно опасно, если она добавляет оплату, рассылку или передачу данных.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Нужно прямо называть действие, объект, стоимость, срок, потерю доступа или данных. Важные последствия нельзя прятать в tooltip или длинный legal text.

Короткий ответ

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

Короткий ответ

Он может показать риск, предложить честную альтернативу, сослаться на данные, support impact и maintainability. Важно обсуждать не “плохие намерения”, а последствия решения.

Короткий ответ

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

Короткий ответ

Нужно уточнить responsive behavior, состояния, ошибки, пустые данные, длинные тексты, доступность и реальные данные. Также стоит спросить, какие части макета критичны, а где допустимы компромиссы.

Короткий ответ

Нужно не додумывать молча, а уточнить ожидаемое поведение и предложить вариант. Error state является частью сценария, а не второстепенной деталью.

Короткий ответ

Нужно обсудить breakpoints, приоритеты контента и поведение сложных элементов на малом экране. Простое сжатие desktop макета часто ломает UX.

Короткий ответ

Нужно запросить состояния или использовать правила design system, если они есть. Особенно важно не забыть focus state, потому что он влияет на keyboard navigation.

Короткий ответ

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

Короткий ответ

Нужно смотреть не только на пиксели, а на состояния, данные, adaptive layout, accessibility, сложность реализации и edge cases. Хороший review заканчивается списком уточнений и рисков.

Короткий ответ

Отсутствующие состояния, слишком длинные тексты, непонятные ошибки, недоступные controls, сложные таблицы, маленькие touch targets и неоднозначные действия. Чем раньше риск найден, тем дешевле исправление.

Короткий ответ

Нужно объяснять ограничение через последствия: сроки, сложность поддержки, performance или accessibility. Хорошо приносить альтернативу, а не только отказ.

Короткий ответ

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

Короткий ответ

Нужно говорить о цели и trade-offs, а не о вкусе. Формулировка “можем сохранить сценарий, но упростить компонент” обычно лучше, чем “это слишком сложно”.

Короткий ответ

Edge cases часто меняют структуру компонента и контракты API. Если их найти поздно, команда получает переделки, хрупкие условия и неполный UX.

Короткий ответ

Лучше записывать их в задаче, acceptance criteria, комментарии к макету или документацию компонента. Устные решения быстро теряются.

Короткий ответ

Когда проблема не блокирует текущий релиз, но требует дизайна, аналитики или согласования. Так UX-долг становится видимым, а не растворяется в коде.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

Нужно определить основной сценарий, обязательные состояния, доступность, ошибки и recovery path. MVP может быть узким, но не должен быть непонятным или опасным.

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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

Короткий ответ

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