Привет, Хабр! Меня зовут Саша Новицкая, я ведущий дизайнер продукта в Х5 Tech. Занимаюсь B2B продуктами и дизайн-системой. Хочу рассказать о том, как мы вместе с техническими писателями разрабатывали и дорабатывали наш ToV (Tone of voice). И даже поделимся результатом нашей работы в виде гайда. А помогать мне в этом будет мой соавтор и менеджер направления «Разработки технической документации» Х5 Tech Настя Московкина.

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

Боли в начале пути

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

У дизайнеров

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

Кстати, почему Join? С английского Join — это функция объединения данных. Была цель объединить все UI Kit продуктов в единый гайд с призывом присоединяться всех. Дизайн-система была создана для того, чтобы упростить и ускорить работу дизайнеров. Чтобы больше думали над решениями задач пользователей, а не над сборкой локальных китов.

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

Без редполитики и Tone of voice дизайнеры сталкивались с проблемой неопределенности при выборе стиля общения и тональности текстов. Это приводило к несогласованности в коммуникации бренда компании и могло запутать одних и тех же пользователей, которые пользуются разными продуктами компании. Более опытные дизайнеры сталкивались с большим количеством  спорных ситуаций: 

Эти и многие другие вопросы раз за разом возникали в чате дизайнеров.  

Сложнее всего было дизайнерам-джунам. Они еще не набили руку и большой упор делали именно на разработку макетов, а экспертизы UX/UI редактуры зачастую у них не было.  

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

У технических писателей

А направление технических писателей тогда только начинало развиваться в X5 Tech, их было  всего человека 3-4. На этом этапе мы активно развивали методологию будущего направления и готовили хорошую базу для найма новых коллег. Уже было понятно, что направление будет активно расти и было важно синхронизировать качество и консистентность текстов на этапе разработки инструкций. Для этого мы разработали первую версию нашего стайлгайда.

Как обнаружили проблему и почему решили делать вместе

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

Первый кейс

Одним из первых продуктов, где появились технические писатели в Х5, стал Портал поставщика. Там раздел Справка был как бы частью продукта и, как следствие, неотъемлемой частью интерфейса. При открытии справки одинаковые сущности, например, списки, могли находиться рядом. И если в справках строго следят за знаками препинания в списках, то в интерфейсах от них обычно отказываются. Согласитесь, было бы странно видеть на одном экране два списка, которые оформлены по-разному.

В рамках одного продукта решить проблему не так сложно – можно договориться с UX-редактором. В нашем случае все было еще проще – редакторов у нас нет, мы договорились с руководителем продукта и взяли ответственность за тексты в интерфейсе на себя. Но компания огромная, у нас около 300 продуктов и проектов в разработке, а технические писатели есть пока не везде. Плюс те же самые поставщики пользуются и другими нашими сервисами. Понятно, что проблему нужно решать не точечно.

Именно в этот момент к нам пришли с похожим запросом дизайнеры.

Второй кейс

В процессе разработки дизайн-системы стало понятно, что нужно браться за создание раздела Как общаться с пользователями, чтобы закрыть вопросы и обучить новых дизайнеров в компании. Нужны были правила, которые помогали бы поддерживать целостность восприятия бренда в рамках дизайн-системы Join:

• Палитры

• Шрифты

• Иконки

• Редполитика, стайлгайд

  

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

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

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

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

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

Сложности перехода

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

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

Как создавали

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

Сейчас у нас живут два гайда: для текстов в интерфейсе и для пользовательской документации. Из общего у них требования к качеству текста, перечни стоп-слов, требования к стилю. Отличаются они по части специфики работы. У дизайнеров описаны требования к конкретным элементам интерфейса в Figma, у технических писателей упор на структуру разных страниц и виды документации – в корпоративной Wiki.

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

Когда не получается следовать рекомендациям 

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

Наши исключения:

• случаи, когда возможно недопонимание из контекста о том, какое слово имелось ввиду. Например, «совершенный» или «совершённый»;

• в названиях брендов, например «Пятёрочка» и «Перекрёсток»;

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

А вот и наш обещанный стайлгайд: презентация в Figma Community (простите, пока что так), адаптированная для просмотра только с монитора компьютера. Переключать слайды лучше с помощью клавиш со стрелками, а читать лучше в режиме презентации, так как в режиме редактирования она неудобная. 

Вывод

После разработки и утверждения стайлгайда и ToV к нам меньше стали приходить с вопросами о том, как что-то написать, исчезли конфликты в чатах и сократилось время принятия решений о том, как правильно написать текст. Теперь каждый отдел использует гайд в удобном для себя окружении. Дизайнеры – в Figma, технические писатели – в Wiki.

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

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