diff --git a/src/pages/ui-ux/index.md b/src/pages/ui-ux/index.md index dbfc0a9..15761fb 100644 --- a/src/pages/ui-ux/index.md +++ b/src/pages/ui-ux/index.md @@ -3385,8 +3385,19 @@ Microcopy - это короткие тексты интерфейса: кноп **Полный ответ** -Microcopy - это короткие тексты интерфейса: кнопки, подсказки, ошибки, empty states, labels и confirmations. Они -направляют пользователя в момент действия. +Microcopy — это текст, который помогает человеку понять текущее состояние интерфейса и выполнить конкретное действие. +Его качество определяется не длиной, а тем, отвечает ли он на вопросы **что произойдет, почему и что делать дальше**. + +Например, «Сохранить черновик» задает ожидание результата, «Сохранено в 14:32» подтверждает его, а «Не удалось +сохранить. Повторить» дает способ восстановления. Эти тексты образуют один сценарий, хотя находятся в разных +компонентах. + +Хорошее microcopy должно совпадать с реальным поведением: нельзя писать «Готово», если запрос еще выполняется или +операция завершилась только локально. При локализации учитывают длину, формы множественного числа и tone of voice; +жестко зашитый в компонент текст быстро становится техническим долгом. + +На интервью полезно показать **связь между текстом, состоянием приложения и следующим действием**, а не ограничиваться +перечислением кнопок и подсказок. @@ -3402,8 +3413,19 @@ Microcopy - это короткие тексты интерфейса: кноп **Полный ответ** -В формах, уведомлениях, меню, onboarding, CTA, validation messages, placeholders и success states. Почти каждый -интерактивный элемент нуждается в понятном тексте. +Microcopy сопровождает почти весь user flow: от названия поля и placeholder до подтверждения платежа, текста загрузки, +сообщения об ошибке и empty state. Особенно важно оно там, где пользователь принимает решение, ждет результата или +исправляет ввод. + +Например, экран импорта файлов требует нескольких разных сообщений: поддерживаемые форматы до выбора, прогресс во время +загрузки, причину отклонения конкретного файла при ошибке и результат после завершения. Один общий toast не заменяет эти +состояния. + +У текста есть контекст размещения. Короткая подсказка рядом с полем полезнее отдельной страницы документации для частой +ошибки, но длинную инструкцию не стоит постоянно показывать всем пользователям. Для повторяющихся сообщений можно +использовать общие словари, не теряя контекст конкретного действия. + +На интервью пройдите **один законченный сценарий** и объясните, какой текст нужен до действия, во время него и после. @@ -3419,8 +3441,19 @@ Microcopy - это короткие тексты интерфейса: кноп **Полный ответ** -Текст кнопки задает ожидание результата. “Сохранить изменения” понятнее, чем “OK”, потому что описывает конкретное -действие. +Подпись кнопки формирует ожидание **непосредственного результата клика**. Если написано «Отправить заявку», пользователь +должен понимать, будет ли заявка отправлена сразу или откроется дополнительное подтверждение. + +В форме с несколькими действиями «Сохранить черновик» и «Отправить на согласование» различают два разных последствия. +Вариант «Продолжить» подходит для перехода на следующий шаг, но вводит в заблуждение, если запускает необратимую +операцию. + +Frontend обязан поддерживать обещание текста: обрабатывать состояние загрузки, предотвращать случайную повторную +отправку и показывать результат. Если надпись временно меняется на «Сохраняем…», ширина кнопки не должна неожиданно +сдвигать соседние элементы. Иконка без текста требует доступного имени. + +На интервью свяжите **название действия, фактическое поведение и feedback**, а не обсуждайте текст отдельно от +реализации. @@ -3435,7 +3468,17 @@ Microcopy - это короткие тексты интерфейса: кноп **Полный ответ** -“OK” часто не объясняет, что произойдет после нажатия. Конкретный текст снижает риск ошибки и повышает уверенность. +«OK» не объясняет, что именно подтверждается. В диалоге с несколькими возможными последствиями это увеличивает риск +ошибочного выбора, особенно когда пользователь возвращается к экрану после отвлечения. + +Для подтверждения удаления понятнее «Удалить отчет» и «Отмена», чем «OK» и «Cancel». Если действие необратимо или +затрагивает других людей, рядом нужно пояснить последствия: какие данные исчезнут и можно ли восстановить их позже. + +Однако «OK» не всегда ошибка. В простом информационном уведомлении без альтернативных действий «Понятно» может быть +достаточно, поскольку пользователь ничего не меняет. Контекст важнее универсального правила «никогда не писать OK». + +На интервью предложите **критерий выбора подписи**: пользователь должен понимать исход действия по тексту кнопки и +ближайшему контексту, не угадывая реализацию. @@ -3451,8 +3494,18 @@ Microcopy - это короткие тексты интерфейса: кноп **Полный ответ** -Пользователь должен понять проблему без знания backend, HTTP-кодов или внутренних терминов. Хорошая ошибка помогает -продолжить сценарий. +Хорошее сообщение об ошибке обычно состоит из трех частей: **что не получилось, что это значит для данных и какой +следующий шаг доступен**. Внутренний код или stack trace редко отвечает на эти вопросы. + +Например, после неудачного сохранения вместо «HTTP 503» полезнее написать «Не удалось сохранить изменения. Они остались +в форме. Повторите попытку». Последнее утверждение допустимо только тогда, когда frontend действительно сохранил +введенные данные. + +Ошибки отличаются по контексту: поле с неверным форматом требует локальной подсказки, временная ошибка сети — +возможности повторить действие, а отказ в доступе — объяснения прав без раскрытия защищенных деталей. Не нужно обещать +retry, когда повторный запрос небезопасен или действие уже могло выполниться на сервере. + +На интервью покажите **ошибку и recovery flow**, включая состояние данных и риск повторной операции. @@ -3468,8 +3521,18 @@ Microcopy - это короткие тексты интерфейса: кноп **Полный ответ** -Он объясняет последствия, ограничения и следующий шаг. Хороший текст уменьшает неопределенность и снижает число -ошибочных действий. +Текст снижает неопределенность, когда объясняет существенные условия **до** действия. Пользователь должен понимать +стоимость, область изменений, доступность отмены и ожидаемый результат, если они влияют на выбор. + +Например, при предоставлении доступа фраза «Пригласить участника» неполна, если приглашенный получит права +администратора. Уточнение «Участник сможет просматривать и изменять все проекты» меняет качество решения сильнее, чем +декоративный tooltip. + +Важны timing и hierarchy: критичную информацию нельзя прятать в ссылку мелким шрифтом после основного CTA. Но чрезмерное +количество предупреждений тоже вредно — пользователь привыкает их игнорировать. Выделяйте только существенные +последствия, остальное раскрывайте по запросу. + +На интервью опишите **решение с риском и какую информацию нужно показать перед подтверждением**. @@ -3485,8 +3548,18 @@ CTA должен совпадать с намерением пользовате **Полный ответ** -CTA должен совпадать с намерением пользователя и результатом операции. “Создать проект” лучше, чем “Продолжить”, если -после клика создается проект. +CTA (call to action) должен соответствовать намерению пользователя и ближайшему следующему шагу. Если кнопка запускает +оплату, «Оплатить 990 ₽» понятнее расплывчатого «Продолжить», когда цена уже известна и подтверждается этим нажатием. + +Но точная подпись зависит от flow. Если после клика лишь открывается платежный провайдер, «Перейти к оплате» честнее, +чем «Оплатить». При многошаговой регистрации кнопка «Продолжить» допустима, если она действительно переходит к +следующему экрану без необратимых последствий. + +CTA нельзя рассматривать изолированно от заголовка, условий и вторичных действий. На мобильном экране текст может +переноситься; решение — адаптировать layout, а не терять важную часть смысла. Для локализации не следует собирать +надписи из отдельных склоняемых фрагментов. + +На интервью сравните **фактическое действие и обещание CTA**, затем проверьте, что они совпадают во всех состояниях. @@ -3502,8 +3575,19 @@ CTA должен совпадать с намерением пользовате **Полный ответ** -Нужно назвать действие и объект: “Удалить отчет” вместо “Подтвердить”. Если последствия серьезные, текст должен прямо -сказать, что будет потеряно. +Для разрушительного действия назовите объект, масштаб и возможность восстановления. Диалог «Удалить рабочую область?» с +кнопкой «Удалить рабочую область» понятнее универсального «Вы уверены?», особенно когда рядом существуют действия +архивации и отключения. + +Если удаление необратимо, об этом нужно сказать явно и до подтверждения. Если доступно восстановление, не называйте его +необратимым. Для массовых операций уточните количество элементов: например, «Удалить 12 выбранных файлов», но убедитесь, +что число соответствует фактически выбранным объектам. + +Не каждое действие требует отдельного confirm dialog. Если действие обратимо и безопасно, undo может уменьшить трение. +Для действительно критичных операций возможны дополнительное подтверждение или ввод имени объекта, но такие шаги должны +соответствовать уровню риска. + +На интервью сравните **confirm, undo и дополнительную проверку** и объясните, когда каждый подход оправдан. @@ -3519,8 +3603,18 @@ CTA должен совпадать с намерением пользовате **Полный ответ** -Нужно писать через практическое последствие и вариант решения. Вместо “limit exceeded” лучше: “Можно добавить до 5 -участников на текущем тарифе”. +Ограничение лучше объяснять через **наблюдаемую причину, влияние на текущую задачу и доступный путь решения**, а не +через внутренний термин системы. + +Например, вместо «QuotaExceededError» можно написать «На текущем тарифе доступно до 5 участников. Удалите одного +участника или измените тариф». Если повышенный тариф недоступен пользователю, не стоит показывать неработающее обещание +обновления. + +Предупреждать желательно до заполнения длинной формы, а не только после submit. Для числового лимита интерфейс может +показывать счетчик, но проверка на сервере все равно обязательна: квота могла измениться из-за параллельных действий. Не +нужно объяснять конфиденциальные ограничения, если они раскрывают внутренние правила безопасности. + +На интервью покажите **предупреждение до действия, серверную проверку и понятный feedback при гонке состояний**. @@ -3536,8 +3630,19 @@ CTA должен совпадать с намерением пользовате **Полный ответ** -Они непонятны пользователю и могут раскрывать внутренние детали системы. Frontend должен перевести ошибку в безопасное и -полезное сообщение. +Технические сообщения часто рассчитаны на разработчика, а не пользователя: содержат названия сервисов, stack traces, +SQL, внутренние идентификаторы или детали авторизации. Они не помогают восстановить сценарий и иногда раскрывают +информацию, которую нельзя показывать клиенту. + +Frontend должен работать с **согласованным контрактом ошибок**: машинный код, допустимые поля, безопасное +пользовательское объяснение и идентификатор запроса для поддержки. Код нужен для выбора локализованной строки, но текст +backend нельзя автоматически вставлять в HTML. + +При неизвестной ошибке допустим нейтральный fallback с контекстом операции и безопасным вариантом дальнейших действий. +Подробная диагностика остается в защищенных логах, а correlation ID можно показать пользователю для обращения в +поддержку, если это предусмотрено системой. + +На интервью разделите **сообщение пользователю, техническую телеметрию и безопасный error contract**. @@ -3553,8 +3658,20 @@ CTA должен совпадать с намерением пользовате **Полный ответ** -Нужно сопоставить код ошибки с пользовательским сценарием. Например, `EMAIL_ALREADY_EXISTS` можно показать как “Такой -email уже зарегистрирован. Войдите или используйте другой email”. +Начните с классификации машинных ошибок в контексте операции. Например, `VALIDATION_FAILED` превращается в сообщения у +конкретных полей, `RATE_LIMITED` — в объяснение временного ограничения, а `VERSION_CONFLICT` — в предупреждение о +конфликте сохранения с вариантом перечитать данные. + +Не следует автоматически показывать текст backend или опираться только на HTTP status. Один `409 Conflict` может +означать разные бизнес-ситуации, поэтому стабильный код ошибки надежнее парсинга строк. Неизвестные коды должны попадать +в безопасный fallback и диагностику. + +Есть важный security edge case: при регистрации ответ «Этот email уже зарегистрирован» может раскрывать наличие учетной +записи. Для публичного восстановления доступа или регистрации формулировки выбирают с учетом угроз account enumeration и +политики продукта. + +На интервью опишите **mapping API code → локализованное сообщение → UI state → recovery action**, включая обработку +неизвестного кода. @@ -3570,8 +3687,18 @@ email уже зарегистрирован. Войдите или исполь **Полный ответ** -Конкретная ошибка лучше, если команда знает причину и следующий шаг. Общий текст допустим только как fallback, но рядом -должны быть retry или способ получить помощь. +Конкретное сообщение полезнее, когда система достоверно знает причину и может подсказать действие. «Файл больше 10 МБ. +Выберите файл меньшего размера» помогает завершить задачу, а «Что-то пошло не так» — нет. + +Но недостоверная конкретика хуже нейтрального текста. Если сервер вернул неизвестную ошибку, нельзя утверждать «Нет +интернета» или «Файл поврежден» без подтверждения. Лучше написать «Не удалось загрузить файл» и предложить безопасный +retry или обращение в поддержку. + +Контекст и состояние данных важны: после ошибки оплаты нельзя бездумно предлагать «Оплатить еще раз», если результат +первого платежа неизвестен. Сначала требуется проверка статуса операции или безопасная серверная идемпотентность. + +На интервью сформулируйте правило: **точность важнее детализации; сообщение должно опираться на известное состояние +системы**. @@ -3587,8 +3714,18 @@ email уже зарегистрирован. Войдите или исполь **Полный ответ** -Когда действие рискованное, ограничение неочевидное или ошибка требует объяснения. Слишком короткий текст может скрыть -важные последствия. +Краткость работает для привычных и обратимых действий, но опасна там, где нужно понять ограничение, необратимые +последствия или нетривиальный следующий шаг. «Удалить» достаточно для корзины с восстановлением, но не для +окончательного удаления организации со всеми данными. + +Полезен **progressive disclosure**: короткое название действия, рядом — ключевое последствие, а подробности по запросу. +Важные условия не должны прятаться только в tooltip, который недоступен при touch или keyboard interaction. + +Излишняя длина тоже мешает. Плотный абзац в диалоге трудно прочитать в стрессовой ситуации; его можно разбить на +заголовок, одно предложение с последствием и два понятных действия. При локализации проверяйте переносы и +масштабирование текста, а не задавайте жесткую высоту контейнера. + +На интервью объясните **стоимость ошибочного действия** как критерий необходимой подробности. @@ -3604,8 +3741,19 @@ email уже зарегистрирован. Войдите или исполь **Полный ответ** -Понятный текст снижает сомнения и ошибки в ключевых шагах. Это может повысить conversion rate без изменения механики -интерфейса. +Понятный текст может уменьшать ошибки, нерешительность и незавершенные действия воронки. Например, пояснение к полю +«Зачем нужен телефон» способно повысить доверие, а явная итоговая стоимость может снизить число отказов на позднем шаге. + +Однако **рост conversion rate не гарантирован**: честное раскрытие условий иногда уменьшает мгновенные клики, но снижает +возвраты, жалобы и отмены. Важно оценивать не только CTR кнопки, но и завершение сценария, ошибки, обращения в поддержку +и долгосрочное качество решений. + +Изменения лучше проверять через исследование или A/B-тест с заранее выбранной основной метрикой и guardrails. Учитывайте +достаточный размер выборки, сезонность, сегменты и эффект новых пользователей; одна удачная цифра после релиза не +доказывает причинность. + +На интервью предложите **гипотезу, вариант текста, primary metric и guardrail**, а не обещайте конверсию от любого +нового CTA. @@ -3621,8 +3769,18 @@ email уже зарегистрирован. Войдите или исполь **Полный ответ** -Текст может давить, стыдить, скрывать последствия или делать отказ психологически сложным. Тогда он работает против -интересов пользователя. +Microcopy превращается в манипуляцию, когда заставляет выбирать выгодный продукту вариант через стыд, ложную срочность, +сокрытие условий или запутанные формулировки. Например, «Нет, я не хочу экономить» вместо обычного «Нет, спасибо» давит +на человека при отказе. + +Другой пример — кнопка «Начать бесплатно», под которой не раскрыто автоматическое платное продление. Даже если формально +ссылка на тариф существует, критичные условия должны быть доступны в момент решения. + +Проблема не в убедительном тексте как таковом: ясное объяснение преимуществ допустимо. Граница проходит там, где +искажают факты, затрудняют отказ или обходят информированное согласие пользователя. Это создает риски доверия, поддержки +и соответствия применимым требованиям. + +На интервью сравните **честный upsell и манипулятивную подачу одного предложения**. @@ -3637,7 +3795,18 @@ email уже зарегистрирован. Войдите или исполь **Полный ответ** -Подсказка помогает принять информированное решение. Манипуляция искажает выбор, скрывает цену или давит на эмоции. +Подсказка улучшает информированность и оставляет человеку **реальный выбор**. Например, «Уведомления можно отключить в +настройках» объясняет последствие включения, но не убеждает страхом и не скрывает отказ. + +Манипуляция возникает, когда интерфейс намеренно делает один вариант визуально или словесно обманчивым: «Продолжить» +вместо согласия на подписку, негативно окрашенный отказ, заранее отмеченная нежелательная опция или искусственный +countdown. + +Проверка практична: одинаково ли понятны оба варианта, раскрыты ли цена и последствия до действия, может ли пользователь +отказаться без лишних препятствий? При этом не любое выделение primary CTA является dark pattern: важны правдивость +сообщения, прозрачность условий и баланс контроля. + +На интервью оцените **сценарий выбора глазами пользователя, который не согласен с предлагаемым действием**. @@ -3653,8 +3822,20 @@ email уже зарегистрирован. Войдите или исполь **Полный ответ** -Нужно договориться о терминах, tone of voice и источнике правды для сообщений. Support полезен, потому что знает, какие -формулировки пользователи реально понимают. +Тексты стоит рассматривать как **часть продуктового контракта**: product определяет смысл и бизнес-условия, UX +writing/design отвечает за ясность, frontend связывает строку с состоянием приложения, backend задает стабильные коды +ошибок, support помогает обнаруживать непонятные формулировки. + +В реальном проекте полезны глоссарий терминов, таблица сообщений и их контекстов, локализационные ключи и review +изменений. Например, текст для `ACCOUNT_LOCKED` нельзя менять без согласования с политикой безопасности и поведением +поддержки. + +Ключи локализации должны описывать назначение сообщения, а не текущую английскую строку; нужно поддерживать plurals, +placeholders и контекст. При изменении бизнес-логики важно одновременно обновлять API mapping, документацию и тесты, а +не только перевод. + +На интервью предложите **единый процесс владения текстами**, который не заставляет каждую команду копировать строки +вручную. @@ -3669,7 +3850,20 @@ email уже зарегистрирован. Войдите или исполь **Полный ответ** -Разные названия для одного действия создают сомнения и ошибки. Единая терминология делает продукт предсказуемым. +Последовательная терминология помогает пользователю переносить привычный опыт между экранами. Если в одном разделе +действие называется «Архивировать», а в другом «Удалить», пользователь может неверно оценить возможность восстановления +данных. + +Единый глоссарий и библиотека текстовых паттернов уменьшают расхождения. Но одинаковая надпись оправдана **только при +одинаковой семантике**: «Сохранить» локальные изменения и «Опубликовать» их для всех участников — разные действия, +поэтому насильственная унификация опасна. + +Учитывайте локализацию и контекст: прямой перевод термина может быть неестественным, а одну английскую строку иногда +приходится переводить по-разному из-за грамматики. Не склеивайте фразы из мелких строк; задавайте отдельные сообщения +для различающихся сценариев. + +На интервью покажите, как **терминология отражает доменную модель и ожидаемые последствия действия**, а не просто +улучшает единообразие интерфейса.