UX-писатели — это люди, которые при помощи текста делают продукты удобнее и понятнее для пользователя. В МойОфис роль таких специалистов особенно заметна. Мы выпускаем широкую линейку корпоративных решений, от редакторов документов до почтовых систем. Продукты содержат сложные интерфейсы с множеством разделов, вкладок, параметров — и разумеется, часть этих элементов невозможно представить без текста.
Вместе с тем наши UX-писатели отвечают за «голос» продуктов. Ведь интерфейсные тексты — форма коммуникации, и от нее напрямую зависит, как пользователь воспринимает приложение. В компании мы стремимся к тому, чтобы все наши решения «звучали» в едином ключе: уделяем большое внимание не только содержанию текстов, но также их стилистике и тональности.
Под катом рассказываем, как устроена работа UX-писателей в МойОфис: в какие процессы они вовлечены и какие проблемы решают в работе.
Привет, Хабр! Меня зовут Дана Спиридонова, в МойОфис я пишу интерфейсные тексты. Помимо меня в нашей команде занят еще один UX-писатель, а также тимлид, который направляет и контролирует процессы. Мы пишем тексты для всех продуктов компании — но на этом наша миссия не заканчивается. Вот ключевые задачи, которые мы регулярно решаем:
Пишем с нуля и улучшаем существующие тексты. Не просто ждем новых задач, но и сами проявляем инициативу. Например, если заметили неправильный термин в каком-либо диалоге или ошибке, то дорабатываем текст.
Улучшаем дизайн и логику. При работе над задачей мы тщательно изучаем весь флоу и функциональность. Если понимаем, что экран можно изменить и упростить путь пользователя, то говорим об этом дизайнеру — и приходим вместе к новому решению.
Координируем переводы на другие языки. Мы взаимодействуем с внештатными переводчиками, следим за ключами в системах локализации. Писатели в нашей команде готовят тексты на русском и английском. На другие языки их переводят подрядчики. Тексты на английском служат основой для перевода на европейские языки, например французский или испанский. Тексты на русском — основа для перевода на остальные языки, например башкирский и казахский. Поэтому нам важно следить, чтобы наши тексты на английском были максимально приближены к русским. Подробнее почитать о том, как локализуют продукты в МойОфис, вы можете в другой нашей хабр-статье.
Следим за единообразием терминов и названий. Наша компания выпускает разные продукты, при этом человек может пользоваться сразу несколькими — например почтой, файловым менеджером и редакторами документов. Поэтому консистентность в текстах очень важна.
Пишем внутренние гайды. Сейчас мы работаем над редстандартами, которые облегчают нам работу и помогут будущим писателям в компании.
Рассмотрим некоторые этапы и нюансы нашей работы подробнее.
Принимаем задачи
Задачи по текстам обычно приходят от UX-дизайнеров. За бэклогом следит лид, он же распределяет задачи по исполнителям.
Процесс написания текстов уже давно налажен и знаком нашим коллегам, поэтому задачи обычно прописаны очень подробно. Мы получаем информацию о том, что и как работает, макеты с интерфейсами и специальную таблицу с текстами. Сначала ее заполняет заказчик — добавляет туда скриншоты и описания элементов интерфейса, добавляет черновые варианты текста. Писатели вносят в эту таблицу тексты на русском и английском. Таблица становится ориентиром для разработчиков, которые вносят ключи в систему локализации. У такого подхода есть свои плюсы: вся информация о фиче или проекте находится в одном месте, и можно легко отследить изменения и дополнения.
В процессе работы мы собираем вопросы, с которыми можем обратиться к дизайнерам, владельцам продукта, иногда к разработчикам. Также примеряем тексты в макетах в «Фигме». Не забываем, что тексты будут переводить — если попытаться вместить слишком длинный текст в маленьком окошке, на другом языке, например на французском, он может не влезть совсем. Также важно смотреть, есть ли подробные фичи и тексты в других продуктах или платформах — опять же, чтобы поддерживать единообразие.
Дальше всё стандартно — отдаем заказчику задачу и работаем с замечаниями.
Случаи из практики
Расскажу о некоторых сложностях, с которыми мы встречаемся.
Я уже говорила, что нам важно следить за единообразием в текстах разных продуктов для разных платформ. Однажды мы заметили, что в трех смежных веб-продуктах — в почте, календаре и планировщике задач — по-разному называется кнопка, прикрепляющая файл к письму, событию или задаче.
Обычно пользователи работают со всеми этими приложениями, и разный текст кнопки может как минимум напрягать. В результате мы унифицировали текст, и теперь подобные кнопки будут называться «Прикрепить файл».
Также во всех наших продуктах есть страницы входа. Раньше на этих экранах была путаница с терминами: например, где-то писали Email, в другом месте — «Электронная почта». Теперь в редстандартах закреплен термин «Адрес электронной почты». Иногда дизайнер или владелец продукта может сказать что-то вроде: «А давайте напишем тут Email, так ведь короче?». Тогда мы можем сослаться на редстандарты и нашу политику использовать как можно меньше англицизмов в интерфейсе на русском языке.
Иногда в черновых текстах заказчиков появляются узкоспециализированные термины. Мы выясняем подробности и подбираем более понятную замену, доступную для всех пользователей. Так, «алиас» становится «дополнительной электронной почтой», а «тенант» — «организацией». Да и кнопку «Авторизоваться» мы всегда заменим на «Войти».
Следующая трудность связана с нарушением правил. Бывает, что UX-писатели сознательно используют повторы слов. Несмотря на то, что во всех гайдах редакторов учат избегать повторов, в текстах для интерфейсов без них порой не обойтись. Например, есть задача: спросить у пользователя, нужно ли сохранять изменения в документе. Мы нарушили правила и три раза повторили слово «Сохранить», потому что текст в интерфейсе должен быть абсолютно прозрачным, сущности и команды должны называться своими именами, а не синонимами.
Наши продукты сложные, и в редакторах документов есть много специфических сценариев. Нужно учитывать, что помимо продвинутых пользователей есть и те, кто может совершать какое-либо действие в первый раз. Поэтому в подобных интерфейсах необходимо давать больше подробностей, помогать пользователю текстом.
В редакторе таблиц можно задавать имена для ячеек и диапазонов — тогда в формулах будет отображаться узнаваемое слово, а не просто адрес вроде «А4:С5». Чтобы пользователь, незнакомый с этой фичей, быстрее понял ее ценность и разобрался, как задавать имена, мы добавили в интерфейс текстовые подсказки.
В работе с заданными именами есть свои ограничения. Например, пользователь может ввести имя в некорректном формате. В таком случае необходимо объяснить, что именно неправильно и как это исправить. В примерах ниже мы прямо говорим, как вводить адрес, какие символы можно использовать в имени, почему не подходит имя «сумм».
Пользователь может совершить операцию, которая повлечет за собой последствия. Тогда в текстах стоит рассказать, что именно произойдет, и дать возможность отменить действие. Например, если пользователь хочет перейти к имени на скрытом листе, работая в документе вместе с коллегами, он увидит предупреждение, что этот лист станет доступен другим людям.
Последний кейс, о котором я расскажу, связан с трудностями нейминга. Например, недавно мы добавили в файловый менеджер возможность следить за тем, кто и как изменял файл: создавал, переименовывал, открывал и закрывал доступ. Такая функция есть у других сервисов для хранения файлов, и она знакома пользователям. О чем же думать нам — о сохранении паттернов пользователей или об уникальности? Вариант «История», также знакомый пользователям одного крупного конкурента, мы отбросили, чтобы избежать путаницы. В наших редакторах у документов уже есть функция «История версий», она позволяет следить за изменениями содержимого файла. В итоге новую фичу мы назвали привычным термином «События».
Общие выводы
Хороший UX-писатель — не тот, кто пишет красивые тексты по запросам заказчика. Писатель должен уметь смотреть глазами пользователя — причем не только на текст, но и на контекст: нужно учитывать, где человек находится, в какой обстановке использует приложение, какие цели и задачи решает. При этом писателю критически важно быть внимательным и дотошным. Иногда, чтобы написать одно предложение, нужно проверить множество других экранов, поговорить с заказчиком, узнать о различных ограничениях.
Работая над частным, UX-писатель всегда помнит об общем — голосе продукта, консистентности терминов, пользовательских целях. В таком случае даже сложный продукт с богатой функциональностью будет комфортен в освоении, и станет удобным инструментом для решения задач пользователя.
Комментарии (7)
Ivnika
03.04.2023 11:32+1Интересен этот пункт обязанностей — "Улучшаем дизайн и логику", у вас же есть дизайнеры, зачем дублировать функции? Или у вас есть какие- то спец знания?
Поясню, сейчас эта функция выглядит аналогично как если бы вы смотрели код (будучи писателями) и давали советы разработчикам где / что можно улучшить
danasprdnv Автор
03.04.2023 11:32+1У писателя и дизайнера разные функции, но работаем мы вместе, и у нас есть общая цель: сделать так, чтобы пользователю было все понятно в приложении. В статье я как раз отмечаю, что задача UX-писателя не просто написать текст, который помещается на кнопку. Большая часть работы писателя — задать кучу вопросов, выяснить, как, зачем и для чего пользователь взаимодействует с конкретным интерфейсом. И поэтому в процессе работы писатели могут заметить то, что не учел коллега-дизайнер. И конечно, UX-писатель должен обладать «спецзнаниями», так как мы пишем не просто тексты, а тексты для конкретной области экрана в конкретном приложении, смотрим на текст в связке с интерфейсом, приложением, устройством, на котором это приложение открыто.
niccolo2019
03.04.2023 11:32+2Честно говоря, когда мне говорят, что люди, не являющиеся ПРОФЕССИОНАЛЬНЫМИ И ОЧЕНЬ ВЫСОКОКВАЛИФИЦИРОВАННЫМИ ПОЛЬЗОВАТЕЛЯМИ продуктов, могут реально что -то улучшить, кроме разве что мелких исправлений, мне становится смешно....
Но как же тяжело это просто признать и написать вместо
Писатель должен уметь смотреть глазами пользователя — причем не только на текст, но и на контекст: нужно учитывать, где человек находится, в какой обстановке использует приложение, какие цели и задачи решает.
Писатель ДОЛЖЕН БЫТЬ суперпользователем, на голову выше остальных.
Недостатки, противоречия и нарушения здравого смысла в ваших рассуждениях.
1. Имя бывает у того, кто может именоваться (сам себя назвать). У остального бывают названия.
2. Вместо e-mail, чтобы не разводить надписи на пол-листа, давно уже пора использовать соответствующий символ юникода или значок....
3. Отмена Удалить — Существительное и глагол. Даже несмотря на распространённость данного огреха благодаря MS - это признак плохого языка... В хорошем русском языке все названия в интерфейсе должны быть в однотипной манере - Существительные (словосчетания с существительными) или глаголы (глагольные словосочетания), но никак не смешиваться в кучу....И тут действительно часто надо очень сильно думать и тщательно смотреть.
4. Рассуждаете о вытеснении из интерфейса английского и пишете «фичей», «кейс», «нейминга» ? Вы действительно хорошо знаете русский язык и способны справиться с поставленной задачей?
5. События ваши уже давно называются «Листом/ведомостью учёта изменений». Длинно, можно подумать, как сократить, но называть изменения СОБЫТИЯМИ очень странно...ИМХО, это нарушение вашего же правила «текст в интерфейсе должен быть абсолютно прозрачным, сущности и команды должны называться своими именами»
В очередной раз чувство, что вчерашние студенты, вместо того, чтобы изучить опыт своих отцов, начинают изобретать велосипед на пустом месте....
persii
03.04.2023 11:32+1Формулировка языковой политики (причём далеко не у одного "МоегоОфиса") — вообще дело на границе смешного и стыдного: "адрес", "электронной" и "почты" — слова приемлемые, а "Email" — нет; при этом, стоит задуматься о проихождении допустимого аналога — как обнаружится, что он всего лишь старше, но не намного руссче.
danasprdnv Автор
03.04.2023 11:32Это ваше мнение, я не согласна с вашими аргументами. Я считаю, что каждый, кто занимается созданием интерфейсов, должен уметь смотреть на них глазами пользователей и учитывать их потребности и ожидания, независимо от того, является ли он профессиональным пользователем или нет.
1. «Задать имя», «Именованные диапазоны» — это привычные названия для пользователей таблиц разных разработчиков: МS, Google, Libreoffice и др. Если бы в нашем или другом редакторе использовали термин «название», пользователи бы просто не смогли найти нужную им функцию.
2. Использовать «символ юникода или значок» в лейблах, плейсхолдерах и других местах нецелесообразно, так как это нарушит ожидания пользователя, да и далеко не все пользователи расшифруют значок.
3. Работая с текстами (не только для интерфейса), конечно, нужно следить за частями речи — например, пункты списка не должны начинаться с разных частей речи. Но в приведенном вами случае с кнопками никаких нарушений нет. Попробуйте внимательнее просматривать интерфейсы популярных приложений, которые вам нравятся.
4. Я действительно хорошо знаю русский язык и использую в своей речи заимствования, которые являются частью русского языка и знакомы аудитории этого сайта. Редполитика моей компании — это ориентир для написания текстов, но не для моей повседневной речи или моих статей.
5. Вариант «События» показал себя прозрачным и понятным для пользователей. В статье я как раз объясняю, почему мы взяли такое название. Подобные названия используют и другие популярные разработчики редакторов документов и облачных хранилищ. Варианты «Лист/ведомость учета изменений» во время исследований не встретились. Возможно, вы видели их в специализированных программах, которые не стоит сравнивать с нашими продуктами, направленными на широкую аудиторию.
Очевидно, у нас с вами разные понятия о том, что такое хороший текст. Не знаю, какой у вас опыт в UX-редактуре и в какое время вы ею занимались. Я не считаю, что мы должны ограничивать себя только изучением «опыта отцов». Мир быстро меняется, и мы должны постоянно совершенствовать наши знания и навыки, чтобы создавать более эффективные и удобные интерфейсы для пользователей, которые развиваются в месте с миром. Если вам интересно узнать больше про современную UX-редактуру, то вы легко сможете найти информацию в интернете. Например, могу посоветовать телеграм-каналы «Редач», «Плавучая редакция», книги И. Бирмана «Пользовательский интерфейс» и К. Егерева «Этой кнопке нужен текст».
niccolo2019
03.04.2023 11:32+1Считать вы можете, что хотите, но конструкторам самолётов мнение лётчиков-испытателей ГОРАЗДО важнее мнения уборщиков взлётно-посадочной полосы (ВПП). А что будет, если конструкторы самолётов начнут уделять время уборщикам ВПП столько же, сколько и лётчикам-испытателям, я думаю вы и сами понимаете...
1. Если вы берёте привычные вещи и просто переносите их в ОО, тогда о чём статья... У MS уже давно все более или менее названо и стало более-менее привычным.
2. Про какие ожидания пользователей вы говорите. Нигде про такие желания не читал и даже никогда не слыхивал.... Зато постоянно слышу про то, как реальные желания пользователей засовываются в долгий ящик, потому что их реализация сложна, затратна и еще 110 других причин от продакшена (как это у вас говорится).
В стремлении «впихнуть невпихуемое» всегда приходится идти на компромиссы. И графика - один из лучших, тем более что он устраняет все проблемы, связанные с локализацией.
3. А какие нарушения могут быть с кнопками? Есть привычная дефективность стиля наименования кнопок (в вашем окне кнопка Отменить, вместо Отмена - смотрелась бы более органично). Поэтому определитесь - вы стараетесь сделать всё привычно или отлично, хотя во втором случае к вам будут претензии от сторонников привычного.
4. Кем утверждены эти заимствования, которые вам кажутся привычными. В словарях русского языка их нет. Институт русского языка такие слова вроде тоже не утверждал.
О редполитика!!! (Наконец то правда). Так может надо было начать с её анализа и проверить, насколько она отвечает заявленным вами целям (и недавно принятому закону об ограничении заимствований)?
5. Каким образом вы оцениваете прозрачность и понятность для пользователей вещей, до которых приличное количество пользователей просто не доходит? У вас есть пул из хотя бы 5-10 десятков опытных пользователей, верстающих в ОО сложные документы? По опыту знаю, что, скорее всего, НЕТ. Судя по тому, что указанный вариант вам не знаком, ГОСТы серий ЕСКД, ЕСТД, ЕСПД вам тоже знакомы плохо. По вашему это, вероятно, талмуды ветхих старикашек. Зачем их читать, если есть Бирман и Егерев...
То, что не считаете, ваше право. Я вообще смотрю, нынешняя молодёжь любит походить по граблям, поломать работающее потому, что это старый код (или по вашему легаси), в котором уже никто не разбирается, и проще написать взамен что-то ужасное с точки зрения эргономики и скорости работы (откуда другое то при отсутствии жизненного опыта и хотя бы 5-10 летнего опыта использования программы). Но это ваше право, конечно.
Мир меняется как декорации в театре. В софте это хорошо заметно, особенно на MS - перерисовываются интерфейсы, иконки, окна, а программы особо лучше не становятся, да и рост быстродействия ДАЛЕКО не такой, как заявляют производители железа...
Вот только люди, на которых в театр и ходят, остаются....
dlc
Для UX writer'ов, которые везде пишут "Адрес электронной почты" заготовлен отдельный котёл.