Изменив одно местоимение, можно на 90% увеличить показатель кликабельности (CTR) кнопки, которая приведет новых пользователей. Дописав одно предложение, можно увеличить количество оплаченных покупок и снизить нагрузку на саппорт. Поставив одну запятую, можно было бы сохранить 5 миллионов долларов. ОК, третий пример про договоры, но все равно показателен.

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

Исследование Nielsen Norman Group показало, что лаконичный, объективный (без маркетологического хвастовства) текст, который легко читается пользователем, увеличивает юзабилити сайта на 124%. Только текст. UX и навигацию не трогали.

В вашем продукте (сайте, программе, приложении и т.д.) есть английский текст, и вы хотите, чтобы он приносил вам выгоду, а не просто занимал место? Читайте статью дальше. Я расскажу, как писать по-английски нужно, и как не нужно.

А судьи кто?

Я старший технический писатель в компании Plesk. Я и мои коллеги отвечаем за английский текст в интерфейсе Plesk. Мы пишем UX-тексты с нуля, а также редактируем тексты наших коллег (разработчиков, PM-ов, дизайнеров, тестировщиков и тд).

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

Тема UX writing необъятна и будет только расти. По ней есть много отличных книг, статей и стайл гайдов (ссылки на некоторые будут). Я не ставила себе целью написать “Войну и мир”. Я хотела сделать статью формата “помоги себе сам”, где есть советы, которые может применить любой IT специалист.

Погнали.

Базовые принципы UX writing

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

Краткость не в ущерб смыслу

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

Безжалостно зачеркивайте все слова и фразы, которые не несут полезного смысла. Представьте, что вы из своего кармана платите за каждое слово, которое вы пишете. Я не призываю писать в телеграфном стиле опуская все служебные части речи (предлоги, союзы, местоимения, артикли). Но советую тщательно оценивать каждое слово. Нужно ли оно здесь? Можно ли без него обойтись? Есть список слов-филлеров, без которых обойтись можно.

Слова и фразы филлеры

“Филлерами” я называю слова и фразы, которые не несут ни пользы, ни смысла в UX тексте, а лишь занимают ценное место. В UX-тексте до редактуры филлеры встречаются часто. Их можно вычеркнуть, а освободившееся место отдать под действительно полезную информацию, если таковая имеется. Не имеется — не пишите. “Природа не терпит пустоты” — это не про UX writing.

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

Are you sure/Do you want/Do you wish

Видите такое на экране confirmation dialog — вычеркивайте.

Confirmation dialog и без текста представляет собой шанс для пользователя передумать. Все эти “уверен-не уверен” — лишние. Лучше напишите что-то действительно полезное. То, что заставит меня задуматься, не хочу ли я выстрелить себе в ногу. Что именно? Будет в статье дальше.

Please

Используйте слово “please” экономно, потому что:

• Оно захламляет текст.
• Его отсутствие вряд ли шокирует. UX-текст пестрит глаголами в повелительном наклонении (click, go to, sign in и т.д.). Это норма.
• Если вы извиняетесь за каждый чих, ценность вашего извинения начинает стремиться к нулю.

Please нужно использовать только в этих случаях:

• Без please будет грубо. Сравните: Please wait (Пожалуйста, подождите) и Wait (Ждите).
• Вы доставляете пользователю неудобство или извиняетесь за косяк в продукте.

      “The license key has expired. Please contact your service provider.” — доставляем неудобство.

      “Repair Kit fixed all issues it could. If some issues still remain, please try fixing them manually or contact Plesk Support.” — извиняемся, что продукт не может исправить все поломки.

• Вы просите пользователя об одолжении (“We have integrated Plesk with a new service. Please help us improve the experience by taking two short usability tests.”)

Не все легко принимают идею, что слово “please” в UX-тексте часто лишнее. Чтобы развеять сомнения, добавлю апелляцию к авторитетам: Microsoft Style Guide и Google developer documentation style guide.

Successfully/unsuccessfully

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

Бинарная оппозиция successfully/unsuccessfully лукаво подсказывает, что сценариев только два: установилось успешно или неуспешно (это как вообще?). Хотя по логике сценариев три:

Установилось/Не установилось/Установилось с косяками: и вот какими.

Поэтому можно вычеркнуть слова successfully/unsuccessfully и уделить внимание нормальному описанию третьего сценария. Что именно пошло не так > какие последствия это несет > как это починить (если вообще возможно).

Понятность

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

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

Active voice

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

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

Есть лишь несколько случаев, когда использование пассивного залога желательно и оправданно:

• Когда пользователю неважно или ненужно знать, кто совершил действие. Важен сам предмет (“Your profile was updated.”)

      Note: Хотя некоторые UX writing стайл гайды предлагают и тут обходиться без пассивного залога. Например, “Updated the profile”. Дело вкуса и стайл гайда, принятого в вашей компании.

• Когда нужно сместить акцент на предмет действия, чтобы не обвинять пользователя. “Over 50 conflicts were found in the file.” вместо “You created over 50 conflicts in the file.”

Консистентность терминов

Одну и ту же вещь можно назвать по-разному, и все варианты будут верными.

Enable или turn on? VPS или virtual machine? Setting или option? Clean up, delete или empty?

Вы можете выбрать любой вариант по душе — главное придерживаться его.

Консистентность терминов вносит огромный вклад в понятность UX-текста и не только его. Консистентность особенно важна между различными интерфейсами продукта (GUI, CLI, API), технической документацией и языком техподдержки. Но увы. Порой термины плавают даже на соседних экранах одной последовательности действий.

Чтобы такого не произошло, вам нужен редактор (технический или UX-писатель) и глоссарий. Или хотя бы глоссарий. Чтобы разработчики не ломали голову как назвать сущность, которая уже попадалась на глаза пользователю. Чтобы переводчики (if any) переводили быстро и правильно, не задавая кучу вполне обоснованных вопросов.

Артикли

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

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

• Любое исчисляемое существительное в единственном числе должно иметь слово детерминатив, т.е. неопределенный артикль/определенный артикль/притяжательное местоимение и т.д.

      Может быть: a server, the server, your server, a user’s server. Но нельзя бросить слово “server” в тексте без всего вообще, потому что серверы можно посчитать.

• Притяжательные местоимения всегда спасают положение. Не нужно ломать голову между a и the.
• Что если нужно ломать голову между a и the? The server — это тот самый конкретный сервер и никакой другой. A server — любой server, неважно какой, неважно чей. Твой, мой, соседа, неважно.

      Сообщение “The server was deleted” говорит, что был удален один конкретный сервер, который пользователь выбрал.

      Сообщение “A server was deleted” говорит, что был удален какой-то несчастный сервер, который проиграл в русской рулетке/функции randomize.

• Если существительное неисчисляемое, неопределенного артикля “a” быть не может. Или the, или никакого артикля.
• Не всегда легко понять, исчисляемое существительное или нет. Более того, в одном значении существительное может быть исчисляемым, в другом — неисчисляемым.

      Например, слово issue является исчисляемым в таких примерах как a personal issue, an old issue of the newspaper. И неисчисляемым здесь: issue of commemorative postage stamps.

      В трудных случаях полезно заглянуть в словарь. Сambridge Dictionary помечает существительные следующим образом: [С] (countable), [U] (uncountable) или [C or U]. Другие словари могут отмечать это по-другому.

      Note: В отличие от русского “хранилище”, слово storage является неисчисляемым, поэтому мы не можем написать a storage, two storages, storages. Если нам все же нужно посчитать хранилища, добавляем исчисляемое существительное (storage point, storage space, storage device и т.п.)

Всегда ли исчисляемые существительные в интерфейсе имеют артикли или другие детерминативы? Нет, не всегда. Очень часто артикли опускаются в названиях кнопок, вкладок, иногда залоговков и опций — везде, где артикли могут захламлять интерфейс. Но это зависит от вашего продукт и стайл гайда.

Артиклей в названиях кнопок нет:

Артиклей в названиях шагов процедуры нет:

Артикли в подзаголовках процедуры есть:

Полезность

Полезность UX-текста очень сложно описать парой слов. Я пойду от противного и расскажу, где я часто вижу бесполезность: в расплывчатых сообщениях об ошибках и сonfirmation dialogs, которые скромно молчат о главном.

Сообщения об ошибках

Как пишет Kinneret Yifrah в своей книге “Microcopy The Complete Guide”, сообщение об ошибке — это единственный текст, который мы надеемся, пользователь не прочитает.

Хорошее сообщение об ошибке строится по следующей формуле:

Что пошло не так или что произошло + Почему + Одно или более решение, чтобы исправить ошибку + Кнопка или ссылка на действие, которое является решением (если это возможно)

Хорошее сообщение об ошибке выглядит как-то так:

У вас выросли рога, потому что выбранное заклинание работает в бета-режиме. Обратитесь в хирургическое отделение по месту жительства или в [техподдержку богини Бат](ссылка на сайт техподдержки, где можно завести тикет).

А теперь представьте, что большинство сообщений об ошибках ограничиваются “У вас выросли рога”. Спасибо, кэп.

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

Обвинение пользователя может выглядеть так:

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

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

Не надо так. Может это не я, а кошка пробежала по клавиатуре. Лучше было бы так: “Incorrect username or password. Try again or recover your password.”

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

Другой пример по теме. “You have specified not a full email address” лучше переделать в “The provided login is not a full email address” или “Not a full email address was provided”.

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

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

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

Confirmation dialog

Confirmation dialog используется, когда будущее действие пользователя может нести нежелательные последствия разной степени тяжести.

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

Во-первых, повтор очевидного. Я называю это про себя “delete?-delete??-delete!”. Классика жанра:

Во-вторых, слова и фразы филлеры do you want, do you wish, are you sure и прочее, которые мы разобрали выше. Смело вычеркивайте такое и освобождайте место для текста, который действительно важен.

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

Если там кубики — скажите мне об этом и спасите мои нервы. Если там пики — тем более. Дайте мне возможность передумать и спасти ваш саппорт от лишней нагрузки.

В-четвертых, типовые название кнопок ОК и Cancel, которые могут вносить конфуз:

Хорошая UX практика — называть кнопки в confirmation dialogs так, чтобы не было места сомнениям. Например, на экране с подтверждением удаления чего-то кнопки можно назвать так: “Yes, delete” (вместо одинокого "OK") и “No, keep” (вместо просто "Cancel").

Ниже пример хорошего confirmation dialog. Повтора очевидностей нет, слов-филлеров нет, последствия есть (“will also delete all its data and controls”), кнопка удаления не просто ОК.

Еще один пример хорошего confirmation dialog:

Антракт

Всё, что было до этого, относилось непосредственно к UX writing. Всё, что будет дальше, — про английский язык во всех его проявлениях. Язык, в котором все мы неизбежно делаем ошибки, потому что не являемся его носителями.

Неправильное использование модальных глаголов

Одна из самых часто встречающихся ошибок. Модальные глаголы — это огромная тема в английском, и немаленькая в UX writing.

Если коротко. Чаще всего, вам вообще не нужен модальный глагол. Используйте глагол в повелительном наклонении.

Уверены, что вам нужен модальный глагол? Чтобы дать совет или предложить возможное решение, используйте can. Чтобы сказать, что пользователь должен что-то сделать (и выбора тут нет), используйте must.

Не используйте should, may, might и вот почему:

• May

      Глагол “дозволения”. Используется, чтобы дать или попросить разрешения, причем в официально-деловом стиле (пометка formal в словарях).

      A reader may borrow up to six books at any one time.

      "May I help myself to some more food?" "Yes, of course."

      Каждый раз, когда вы хотите написать “You may” в UX-тексте, мысленно проговорите “Вам позволено”. Если вы все еще хотите его использовать, тогда вперед.

• Should

      Глагол “дружеского совета”. You’re coughing a lot. You should see a doctor. Я не специалист. Это мой совет, но выбор за тобой.

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

• Might

      Двуликий Янус. Глагол “маловероятной возможности” или “очень вежливого совета” (еще мягче, чем should). В UX-тексте почти никогда не используется за исключением одного случая, о котором ниже.

Модальные глаголы также используют, чтобы выразить вероятность (значение express possibility в словарях). Градация вероятности выглядит следующим образом:

В хороших сообщениях об ошибках мы предлагаем решение. Однако не всегда можно быть уверенным, что оно 100% поможет. Если скорее всего поможет (вероятность больше 50%), берите can. Если не уверены — may или could. Ну а might это, наверное, когда-нибудь, может сработать, но это неточно.

Инклюзивная терминология

Речь идет о замене следующих терминов: "master/slave" и "whitelist/blacklist/greylist".

Меня всегда удивляет, какой холивар поднимается вокруг этой темы. Народ почему-то начинает обсуждать свои убеждения и ценности (“No pasaran! Защитим наш продукт от тлетворного влияния Запада! Не прогнемся под меньшинство!”), когда надо без эмоций делать cost-benefit analysis.

Ваш продукт работает исключительно на российский рынок и не планирует выход на международный? Можете продолжать использовать устоявшиеся термины master/slave" и "whitelist/blacklist/greylist". В наших широтах и культурно-историческом контексте они не должны никого обидеть.

Ваш продукт уже работает/будет работать на американском рынке? После мая 2020 думать особо нечего. Используйте новую терминологию:

• "master/slave" > "primary/secondary"
• "whitelist/blacklist/greylist" > "allowlist/denylist/restrictlist"
  Ее уже применяют ведущие игроки (Microsoft, Google, Apple, GitHub, Python, Linus Torvalds) и товарищи поменьше.

Ваш продукт уже работает/будет работать на международном рынке с каким-то процентом американских пользователей? А вот тут придется подумать.

Легко поменять терминологию, когда продукт новый. А если ваш продукт много лет на рынке (как и Plesk), и у вас написаны километры строк кода?

Тогда вам придется сменить старые термины везде, где острый глаз пользователя может за них зацепиться. Including but not limited to: тексты интерфейса, документация, скриншоты в документации, коды ошибок, CLI команды, API, названия сеттингов, статьи в корпоративном блоге…

Ужаснулись? Мы тоже. Мы провели cost-benefit analysis, и (пока) решили оставить старые термины. Единственное исключение — это Plesk extensions. Часть Plesk extensions написана сторонними вендорами, и они сами решают, какие термины им использовать. Некоторые экстеншены, например, Plesk Email Security используют инклюзивную терминологию.

Гендерно-нейтральные местоимения

Иногда я встречаю указания на половую или гендерную принадлежность пользователя в UX-тексте до редактуры. Это всегда местоимение he и его производные (хотя it тоже было пару раз). Так делать нельзя. Пользователь по ту сторону экрана может быть мужчиной/женщиной/котиком/неважно кем. Для нас user/customer/administrator существо бесполое.

Бесполое, но таки одушевленное, поэтому местоимение it тоже не используем.

Что же делать? Самый простой и безопасный вариант — поставить одушевленное существительное во множественное число и использовать they. Например: “If users face the “Bla-bla” error, they can fix it by…”

Но что если нужно обратиться к пользователю именно в третьем лице единственного числа? Как быть?

На помощь снова приходит местоимение they. Но уже singular they. Кому в деталях интересно что это, читайте тут и тут.

Если коротко, местоимение singular they и его производные (their, them) в гендерно-нейтральном английском заменяют следующее:

• местоимения he и she;
• he or she / his or her / him or her;
• he/she;
• (s)he и другие неловкие многословные конструкции.

Работает это так:

“The user, if she prefers, can change the text color." > “The user, if they prefer, can change the text color."

Это и есть singular they. Грамматически оно имеет форму множественного числа (нет окончания -s у связанного глагола), но по смыслу указывает на единственное число (“user”), чей пол для нас не известен и не важен.

Больше примеров, чтобы глаз привык:

• An employee with a grievance can file a complaint if they need to.
• The person who answered the phone said they didn't know where she was.
• "There's someone on the phone for you." "What do they want?"

Disclaimer: Singular they точно подходит для большинства UX-текстов, но бывают исключения. У нас веб-хостинговая панель. Нам пол пользователей не важен. У вас dating app, сайт бара “Голубая устрица” или приложение для женского календаря? Подумайте дважды. Хотя может и вам лучше использовать singular they. От греха подальше.

Note: Меня часто спрашивают, что за новояз такой, singular they. Нет, не новояз. Singular they впервые появилось в XIV веке. Какое-то время шли баталии, насколько корректно такое использование. В наши дни singular they снова на пике популярности в связи с необходимостью использования гендерно-нейтрального языка.

Латинские сокращения

Латинские сокращения etc., e.g., i.e, et al. соблазняют нас своей краткостью. Но благими намерениями… Положа руку на сердце, кто из нас без гугла вспомнит, как все они расшифровываются?

Все UX writing стайл гайды, что я видела, призывают убирать и заменять следующие латинские аббревиатуры:

• i.e. > that is
• e.g > for example/such as

      Note: Теоретически можно использовать и for instance, но некоторые стайл гайды не одобряют.

• etc. > and so on/and others
• et al. > and others

      Note: Насчет etc. единства нет. Google Developer Documentation Style Guide не рекомендует использовать ни etc, ни and so on. Да, ни то, ни то. Подробнее тут.

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

Параллелизм

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

Я всегда стараюсь привести UX-текст (особенно заголовки, списки и стадии progress bar-a) к одному грамматическому знаменателю. Если это возможно и не в ущерб смыслу.

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

Пунктуация

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

Тире и его разновидности

В русском языке есть тире, и есть дефис. Две штуки. Нам вроде хватает. В английском этого добра три: hyphen, en dash и em dash. Они же дефис, короткое тире и длинное тире.

Em dash чаще всего используется, чтобы показать паузу внутри предложения (похоже на функцию русского тире) и ввести обобщающее слово (функция двоеточия). Также em dash используют, когда other punctuation would be awkward, как пишет grammarly.

Не столь важно, по какой причине, вы используете em dash. Но если используете — делайте это правильно.

Во-первых, берите именно em dash, а не его собратьев. Alt+0151 на Винде и Alt + Shift + Minus на Маке.

Во-вторых, до и после em dash пробелы не ставятся. В этом его отличие от русского тире:

• You can now rename your domain or restore it from a backup—no issues with your mail for a domain will occur.
• Red, white, and blue—these are the colors of the flag.
• "I believe I shall—no, I'm going to do it."

Если em dash играет на поле авторской пунктуации, то у en dash есть два сугубо технических сценария использования:

• Разделять временные и числовые интервалы (например, 1:00–3:00 pm, 2020–2021, June–July 1968, pp. 38-55).
• Соединять контрастные понятия в одно (mother–daughter relationship, Radical–Unionist coalition).

Пробелов до и после en dash тоже нет.

Note: Для тех, кто путает en и em dash (как я раньше). Буква M — широкая, поэтому em dash — это длинное тире. Буква N уже, поэтому en dash — это короткое тире.

Основная роль hyphen — это соединять слова (dog-friendly, clear-cut, up-to-date information и многие другие compound words), что похоже на русский дефис. Hyphen можно спутать с en dash. Но даже если ошибетесь, вряд ли кто заметит.

Резюме. Используйте длинное тире правильно: именно его и без пробелов. Для временных и числовых интервалов используйте короткое тире en dash. Для всего остального — дефис. Непонятно, что брать, дефис или en dash? Уточните в словаре.

Oxford или serial comma

Та самая запятая, которая стоила 5 миллионов долларов.

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

Но если вы не используете oxford comma, следите, чтобы не получился похожий по смыслу конфуз:

Exclamation mark

Восклицательный знак — это приправа, которую нужно использовать с умом! Не переборщите!

Bulleted list

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

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

Пример 1. The API supports the following actions:

• Create
• Replace
• Update
• Delete

Create, replace, update, delete — одиночные слова. Точки в конце не нужны.

Пример 2. You can do any of the following by using the API:

• Create an item.
• Replace one item with another.
• Update an item.
• Delete an item.

Пункты списка — словосочетания с глаголом. Точки в конце нужны.

А/B тестирование (вместо заключения)

Перефразируя посыл одной хорошей статьи, UX writing — это не математический пример с одним верным ответом. Есть широко признанные практики, которые я постаралась осветить в этой статье, но есть и место для творчества. А также есть вкусовщина; разные противоречащие друг другу стайл гайды; недостаток ресурсов в команде; отсутствие UX или технического писателя; уже одобренный кривой UX, на который нужно натянуть текст; и т.д.

В продукте всегда есть более и менее важные части. Слово successfully режет глаз, но если вы его напишете, никто не умрет. А вот плохо сформулированное сообщение об ошибке уже может увеличить нагрузку на ваш саппорт.

Если вы вводите новый важный для вашего бизнеса экран или workflow, всегда полезно провести A/B тестирование.

Иногда действительно достаточно изменить только текст, как в примере ниже, где “option1-2.png is performing better, and the difference is 95.0% likely to be statistically significant. This means that you can be confident that it is actually better, and not performing better due to random chance.”

Чаще всего придется переделывать не только текст, но и сам UX. Но ведь не всегда. Возможно, вы сможете обойтись малой кровью. A/B тестирование в любом случае подарит множество чудных открытий, которые помогут сделать текст лучше. А в итоге привлечь новых пользователей, удержать уже существующих и заработать денег и на тех, и на других.

P.S. Хочу сказать “Спасибо!” моим коллегам Алексею Степанову, Владимиру Головизнину, Александру Ямшанову и ребятам из команды Solus за помощь в подготовке статьи.