Новым подписчикам

Вот что произошло. Вы подписались на авторский канал про редактуру. Веду его я, UX-редактор Вова Лалош — раньше редачил в Сбере, МТС и QIWI, а сейчас в свободном плавании.

В основном пишу про редактуру интерфейсов, потому что больше в ней понимаю. Но и об универсальном копирайтерском тоже. Вот какие есть рубрики:

#совет — проверенные опытом советы по редактуре,
#мысливслух — внезапные идеи после утренних пробежек,
#ответ — ответы на вопросы из бота (жду ваших!),
#разбор — перемываю косточки чужим UX-текстам.

welcome, bem-vindo, მობრძანებით 💜

​​Как указать коллеге на ошибку?
#ответ

Jane J.: Корректно ли (и как) сказать об опечатке или фактологической ошибке в тексте коллеги-писателя, если ещё не выпущенный материал случайно попался на глаза, а peer-ревью в команде не в ходу?

———

Давайте разберём вообще, что тут вообще за конфликт. С одной стороны есть общее дело — хочется выпустить хороший продукт (если у вас не так, стоит задуматься о другом месте работы). А значит, любые действия, советы и замечания, которые сделают продукт лучше, должны приветствоваться по умолчанию. Тогда откуда этот страх указать кому-то на ошибку?

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

💔 У тебя времена рассогласованы!
💜А так и должно быть, что мы пишем сначала в настоящем времени, а потом в прошедшем?

Вы ведь тоже можете тоже ошибаться:

— Да, так и должно быть, это же «фолкнеровская инверсия»!
— А, круто!

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

А в этом абзаце всё ок? Факт-чек делали?

Способов смягчить много. А вообще культура прозрачности решает. В моей идеальной команде работает такая формула:

Толерантность к ошибкам + Общая ответственность за результат

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

Пока на улице холодало, а ноябрь планомерно готовил нас к самым лёдосодержащим месяцам в году, со всех сторон на нас валились словно снег лавины новостей. НО! У гика при себе всегда цифровая лопата, поэтому самые лучшие из них я аккуратно подобрал и взял в наш традиционный аудитодайджест. Это не блины, конечно, но всё равно налетайте.

А в качестве эксперта сегодня у нас Владимир Лалош, UX-писатель и автор канала «Плавучая редакция». Поехали слушать!

​С чего начать первому UX-редактору?
#ответ

Дина: С чего начать работу UX-редактору в компании, если до него их не было?

———

Окей, вот мой список дел, которые я обычно ставлю перед собой в новой команде без редакторов:

1. Найти стейкхолдеров. Вам нужно 2-3 человека, которые лучше других понимают, как устроен продукт, его цели и проблемы. Чаще всего это владелец продукта, дизайнер, но может быть и аналитик, исследователь. Кроме этого, узнайте, кто уже участвует в создании коммуникаций или заинтересован в них (юристы, менеджеры поддержки, маркетологи) — они вам тоже скоро пригодятся.

2. Объяснить свою роль. Команда может думать, что UX-редактор просто будет править текст, переписывать его лаконично. Лучше сразу сломать этот стереотип. Сделайте небольшую презентацию, расскажите, как будете строить общение с пользователем (вы ведь будете, правда?).

3. Начать изучать продукт. Обычно это значит: стать пользователем самому (если есть возможность); просмотреть исследовательские и маркетинговые отчеты; попросить дизайнера объяснить всё, что у него уже есть в макетах; заглянуть в продукты конкурентов.

4. Приоритизировать проблемы. Нет смысла бросаться за всё подряд. Фокусируемся на срочном + важном; несрочное + важное — откладываем; срочное + неважное — делегируем тем, кому важно; несрочное + неважное — не делаем вообще. Сначала можно довериться приоритизации дизайнера или продакта, но с ростом вашего авторитета вы всё больше сможете на неё влиять.

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

🫵 Вы тоже можете задать свой вопрос через бота. На интересные обязательно отвечу.

​Может ли UX-редактор быть интровертом?
#ответ

Алиса: Интроверту совсем плохо будет ux-редактором, да?) Прям совсем-совсем?

———

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

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

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

А ещё мне кажется, что интровертность у многих — это обычный страх от недостатка навыков общения. А навыки — дело наживное.

Неверное время
#ответ

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

Это точно верное время? 🤔 Напиши его в формате часы/минуты. С точкой 22.00 или двоеточием 22:00 — как тебе удобнее

———

Если дело в формате, то «верное время» не подходит. «Неверное время» — это 13:15 вместо 15:00. А если человек вводит «78», то лучше сказать, что он вводит что-то не то.

Не могу разобрать время 🤔

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

Не могу разобрать время 🤔 Попробуй написать так: 22:00 или «в семь вечера»

Нужно ли убирать «вы»?
#ответ

David: «Есть мнение некоторых райтеров, что в банковской сфере стоит избегать большого количества "вы", "ваш", "вас". чем меньше - тем лучше. На чем базируется это мнение?».

———

Да, такое негласное правило есть. Но оно касается не только банков.

Дело даже не в подчёркнутой вежливости. Если в тональности обращение на «ты», будет то же самое.

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

Чисто технически в этом нет ничего аномального. Обычный диалог. Но если вы хотите вовлекать, хотите, чтобы пользователь ощущал приложение как продолжение себя, то лучше не подчёркивать эту разницу «вы-мы» слишком активно. Лучше пусть это будут мысли самого пользователя или что-то нейтральное.

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

Я поставил приложение — понятно, что здесь будет про меня. Так дайте мне заниматься моими делами.

Должны ли дизайнеры проверять ошибки
#ответ

Nina: Дизайнерам пофиг на русский язык или они столько работают, что не замечают? Кто-то вообще еще верит в то, что тексты должны быть грамотными и это ответственность дизайнеров в том числе?

———

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

🔹В процессе дизайна возникает множество итераций текста, если каждый причёсывать и проверять — можно сойти с ума. Поэтому обычно на ошибки проверяют в конце, когда уже всё готово. Часто за это отвечают другие люди — из маркетинга или контентщики. Но этот этап в релизной горячке может выпасть.

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

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

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

А решат проблему специально выделенные в рабочем флоу проверки:
1) перед тем как отдать дизайн разработчикам,
2) перед релизом.

Кто должен проверять? Понятно, что профессионального корректора (а это профессия!) в команде чаще всего нет. Но можно попробовать восполнить инструментами — прогонять через спелчекеры, просить чатгпт проверить, проверять вдвоём и так далее. Было бы желание.

Используют ли неразрывные пробелы в UX?
#ответ

Sasha R: А где и как в интерфейсах используются неразрывные пробелы?

———

Используются очень активно. Коротко напомню: неразрывный пробел не даёт делать переносы по строкам там, где вам не нужно. Ставится сочетанием ⌥ + Пробел, а в винде: Ctrl + Shift + Пробел.

Когда пригодится

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

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

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

Пополните баланс и пользуйтесь
кошельком
↓
Пополните баланс
и пользуйтесь кошельком

Подводные камни

1. Если переборщить, на маленьких экранах будут странные лесенки из слов, по слову в строке → Придётся ставить только в самых важных местах. Какими-то переносами придётся жертвовать.

2. Разработчик может увидеть странный символ и заменить его на обычный пробел → Значит надо заранее всех предупредить, что бывают неразрывные пробелы. Можно дополнительно помечать в файлах, но мне кажется, это ненадёжно. Обучение и авторский надзор решают вопрос.

3. Просто задалбывает ставить → Пользуйтесь плагинами, которые расставляют автоматически: SBOL Typograph, Text Prettier и прочими. Но тогда тем более не забудьте проверить, что в узком экране у вас не появляется лесенка из слов.

Можно ли писать на кнопке от первого лица?
#ответ

Элина: Кнопка всегда должна быть с действием пользователя или возможны исключения? Например, на картинке кнопка «Читать кейс», но очень хочется ее переименовать в «Рассказываем как». Допустимо ли это, и если нет, то почему?

———

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

— Вот тут говорим мы, авторы
— А здесь ты отвечаешь!

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

К счастью, люди не роботы. Они в состоянии отличить кнопку на лендинге от простого текста. И не актёры, которые упадут в обморок, воскликнув «О нет, мне подсунули чужие слова!». Скажу шокирующую вещь — многие пользователи смогут догадаться, что кнопка делает, даже если текст убрать СОВСЕМ.

Будут ли они нажимать на кнопку с «Рассказываем»? Да будут, если всё остальное на лендинге их убедило и кнопка органично вписывается.

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

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

Показать или посмотреть?
#ответ

Яна: Возник спор, как назвать кнопку, которая показывает все результаты поиска: «Показать все результаты» или «Посмотреть все результаты»? Вроде как от лица пользователя логичнее «посмотреть», диалог пользователя с интерфейсом и все-такое. С другой стороны, кнопка же в итоге покажет все результаты и это прямое указание системе, что ей надо сделать — «показать». Есть ли тут правильный ответ или просто вкусовщина?

———

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

я хочу посмотреть → система показывает → я смотрю

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

я хочу посмотреть → я смотрю

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

Представьте ребёнка, который хочет посмотреть мультик. Как он будет просить? «Покажи мне мультик» или «Хочу, чтобы ты показал мне мультик»? Вряд ли. Ребёнок скажет «Хочу смотреть мультик!» или просто «Хочу мультик!».

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

🪄 Должны ваши пользователи чувствовать себя настолько интуитивно, что сам сервис будто ни при чём? — Тогда пишите «посмотреть», «хочу», «получить», «мои файлы».

🧑‍🏭 Важно сберечь диалог и фигуру помощника, который всё ищет и делает за пользователя? — Больше подойдут «показать», «требуется», «отправить», «ваши файлы».

Читайте также связанный пост про Личные вещички