Виталий Филатов

о тексте, смысле и красоте

Как ставить ссылки

Написал фрагмент редполитики ВТБ Бизнес о ссылках в тексте. Тема хорошо освещена, так что просто покажу макет со статьёй.

Cвёрстано в Фигме по дизайн-системе банка

ВТБ Бизнес открылся в 2020, а собственные редакторы появились в прошлом году. Пока нас двое. Я слежу за статьями в разделе Помощи и при случае помогаю ведущему редактору.

Нейминг и иконки пакетов курса по бэкенду

После двух потоков ребята из StringConcat изучили отзывы и решили сделать три варианта курса. Один без домашек и курсовой, второй обычный, а третий — с собственным проектом. Я собрал описание, придумал названия и картинки с метафорами для программистов.

Получилось так:

Противоядие, лечилка и комбо-поушн в разделе Стоимость

Как так вышло.

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

Простой → Средний → Сложный — обесцениваем первый вариант, нагнетаем в третьем.

Учиться → Уметь → Творить — создаём противопоставление: учиться не уметь, уметь не творить.

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

  1. [Некий упрощённый]
  2. Базовый
  3. Индивидуальный (со своим же проектом)

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

Картинки. Вот тут пришлось подумать. Смотрите, какой набор условий:

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

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

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

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

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

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

Можно сказать, что слушатель курса принимает новые знания и они его излечивают. Ассоциацию с обычным лекарством отбрасываем, как слишком прямолинейную и пафосную.

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

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

Экспресс — избавляет от яда неведения, поэтому противоядие.

Базовый — полноценно лечит, поэтому просто склянка лечения. К тому же это самый частый вид зелий в играх.

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

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

А теперь почитайте, как согласовать иконки в последовательность :3

Ляйсан в Инстаграме

Редакторический стикер

Мы с Ulv Vind выпустили собственный стикер, посвященный профессиональной работе с текстом.

Виниловая плёнка с матовой ламинацией, 50×50 мм. Устойчив к истиранию, почти не мокнет и приятно зернист на ощупь :3

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

Карандаш с ластиком, топор и рыбий скелет — древние алхимические символы редакторизма.

  • Карандаш изображен ластиком вниз, потому что редактор чаще стирает, чем пишет.
  • Топор символизирует решительное и безжалостное отсечение лишнего и вредного.
  • Рыбий скелет олицетворяет структуру, рыбу в значении временного бессмысленного контента, а также отсылает к поговорке о начале гниения с головы. Все вместе означает, что информационный продукт без структуры и осмысленного контента обречен изначально.

Замыкает круг образов редакторический девиз:

Lorem ipsum — para bellum

Девиз состоит из первых двух слов знаменитого рыбного текста Lorem ipsum и второй части латинского афоризма Si vis pacem, para bellum. Вольный перевод:

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

Форма стикера отдалённо напоминает песочные часы, что символизирует конечность жизни и времени, как самого ценного ресурса.

Стикер предназначен для оклеивания гладких поверхностей профессиональными дизайнерами и писателями зрелого возраста.

Заказать эту невыносимую красоту можно в ВК-паблике Ulv Vind.

Никодим и утекающие абстракции

Айтишная притча о квесте разработчика Никодима во чреве левиафана и кризисе корпоративного менеджмента. Позитивный сторителлинг без токсичной назидательности.

Картинка Ulv Vild

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

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

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

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

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

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

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

В конце испытательного срока Никодим получил письмо с паролем от лифта, который привёз его куда-то между 88 и 89 этажом.

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

— Тебя нет в оргструктуре, — ответил Никодим, — это ты мой руководитель?

— Верно. Я следил за твоей работой и очень доволен. Тебе пора выходить к нам.

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

В лифте Никодим обернулся.

— Почему гостевой пропуск не привязан к дате?

— Из-за безопасников. Они готовят их от недели до месяца и никогда не попадают в даты визита. Только так мы и смогли тебя протащить.

Никодим кивнул и двери лифта закрылись. Больше зодчий его не видел.

Анализ сайта DocsHouse

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

Продукт и задача

DocsHouse — платформа управления контентом (CSP). Это такая система корпоративного электронного документооборота на открытых библиотеках, микросервисах и облачных решениях.

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

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

Заказчик опередил меня с уточняющими вопросами :3

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

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

На момент анализа сайт выглядел так:

Общее впечатление

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

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

Основные проблемы

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

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

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

Сайт рассказывает о том, насколько платформа крута, а не о том, как она решает конкретные проблемы бизнеса. Чтобы оценить пользу решения, нужно ориентироваться в IT и суметь перенести прочитанное в свой контекст.

Например, какую конкретную пользу даёт парадигма CSP? Понятно, что она составляет описание продукта, но термину не хватает наглядного объяснения. Например, парадигма позволяет be agile уже на этапе внедрения.

В преимуществах много общих слов без конкретики. Они сформулированы не в мире читателя, а как некие параметры, не имеющие прямого отношения к его контексту и проблемам.

Иконки слишком абстрактны и не согласуются с текстом

Например, «Современное решение <...>, построенное на открытых технологиях» ничего толком не говорит. Чем открытые технологии лучше проприетарных? Все ли открытые технологии актуальны? Как это помогает в управлении предприятием? Техническому директору это понятно, но финансовому уже нет.

Другой пример: «100% отечественное решение, входит в Реестр ПО, разработано лидером ИТ-рынка компанией ЛАНИТ». Значит ли это, что в коде нет ни одной библиотеки, написанной иностранными разработчиками? Почему тогда используется Vue.js? Что означает 100 % отечественность?

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

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

Что такое Паутина, зачем нужна Связанность, что за Мониторы. Как это поможет мне снять десяток филиалов с иглы Битрикса? — может подумать читатель

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

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

Выглядит прямолинейным сбором базы

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

Предлагаемое решение

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

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

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

Можно составить несколько сценариев, под разные типы аудитории: финдиров, техдиров, CEO и т. д. Главная страница будет кратко рассказывать о платформе вообще, а дополнительные страницы — объяснять суть конкретным группам.

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

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

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

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

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

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

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

Проработать мелочи. Согласовать иконки с текстом, убрать со скриншотов неинформативные детали, уделить внимание типографике и вёрстке.

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

Крупные бренды часто используют эмоции для создания нужного образа продукта. Наглядный пример — Apple и производители техники для видеопродакшена Black Magic.


Анализ и составление отчёта заняли 4 часа, уточнение задачи и согласование ещё полтора.

Заказчик положительно отозвался о результате и переслал мой отчёт маркетингу. Маркетинг согласился с частью выводов, а часть забраковал, как непригодные в B2B. Наверняка из-за упоминания Apple. Сейчас я бы привёл в пример Confluence.

Если вам нужен такой анализ, напишите мне в Телеграм: @vitalyfilatov

Заглушка для сервисных работ

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

Ситуация

В Дехабе сделали страховой калькулятор для Росгосстраха. Заказчик запланировал обновление серверной части и просит подготовить заглушку.

Текст на заглушке такой:

ВНИМАНИЕ!

6 марта 2021 года с 20.00 до 23.59 по московскому времени на сайте будут проводиться технические работы.

К сожалению, оформить полис в это время будет невозможно.

Приносим извинения за временные неудобства.

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

Задача

Написать человечнее, с заботой и конкретикой.

Контекст

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

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

В нашем случае удалось выяснить следующее:

  • Заказчик вводит в эксплуатацию отказоустойчивую схему базы данных
  • Работы займут четыре часа, в это время вместо калькулятора пользователь видит заглушку
  • Заглушка привязана к дате и времени работ
  • На время работ отключится внутренний сервис расчёта полисов, поэтому страховку нельзя будет оформить по телефону или в офисе
  • Работы перенесли на вечер воскресенья, калькулятор заработает в час ночи понедельника

Текст

Дальше дело техники. Собираем всё в кучу и составляем сообщение по схеме:

Что произошло → Почему → Что делать

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

⚠ Оформление полиса временно не работает

В причине начинаем с указания времени:

Сегодня с 20:00 по Москве...

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

Чтобы работы не проводили сами себя, добавляем действующее лицо — мы (Росгосстрах). Формулируем вескую причину, как косвенно полезную для пользователя. Это может снизить досаду от неработающего калькулятора:

...мы повышаем надёжность сервиса...

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

...поэтому расчет и оформление полиса недоступны.

Вряд ли кто-то будет звонить в офис ночью, поэтому про телефон и офис не говорим. Не работает и всё, нужно ждать. Скажем, когда приходить:

В 2:00 понедельника всё вновь заработает.

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

Всё вместе:

⚠ Оформление полиса временно не работает

Сегодня с 20:00 по Москве мы повышаем надёжность сервиса, поэтому расчет и оформление полиса недоступны. В 2:00 понедельника всё вновь заработает.

Страховой калькулятор и заглушка в работе:

Досадная мелочь: в макетах я перенёс «И» на следующую строку, привязав её неразрывным пробелом к следующему слову. На вёрстке на это не обратили внимания и предлог остался висеть :(

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

Советы

  1. Сформулируйте задачу: зачем и кому писать, какую задачу существующий текст не решает. Возможно, он путанный или туманный, а может, достаточно добавить указание на московское время.
  2. Соберите контекст: всё, что относится к ситуации и пользователю. Знание контекста помогает отобрать важное и преодолеть писательский ступор.
  3. Отвечайте на вероятные вопросы пользователя. Если это сообщение об ошибке, скажите, что произошло, почему и что делать. Если о плановых работах, то какая от них польза, когда всё заработает и как решать задачу, пока сервис не доступен.
  4. Если вы менеджер, вас засыпет вопросами. Чтобы писатель меньше вас дёргал, соберите материалы по теме в постановке задачи.

Согласуем иконки тарифов

Как-то я переписывал лендинг мастерской по ремонту бытовой техники. В конце традиционно шли услуги в четыре колонки. Иконки выглядели случайными, поэтому я решил согласовать их по смыслу.

Иконка диагностики откровенно плохая, но её мы трогать не будем :-)

С первого взгляда всё в порядке: иконки выдержаны в едином стиле и масштабе, инструменты наклоняются в одну сторону и под одинаковым углом. Стиральную машину в лупе словно бездумно вклеили, а у ящика с инструментами линии чуть толще, но в остальном иконки выглядят нормально. Просто они не выстраиваются в последовательность.

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

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

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

Движение мысли такое:

Чтобы открыть корпус большинства бытовых приборов достаточно отвёртки.

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

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

Вроде логично, но почему тогда мы начинаем с отвёртки, потом берём ключ, а после сразу ящик? Хорошо было бы показать, что инструментов для среднего ремонта мы используем больше. При этом хочется сохранить признаки малого ремонта, поскольку средний его расширяет. Короче, добавим к отвёртке ключ.

Конечно, отвёртка нужна крестовая, но у плоской более узнаваемый силуэт, это важно

Картинки были в векторном формате SVG, поэтому я закинул их в Фигму, развернул ключ и прилепил его поверх отвёртки. Так отвёртка сохранила наклон, а мы подчеркнули идею добавления нового инструмента.

Получилось так:

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

Выводы.

  1. Давайте редактору макеты или доступ в Тильду. Редактор работает со всеми смыслами в продукте, а не только с текстом. Что-то сделает сам, что-то передаст дизайнеру.
  2. Векторные иконки — благо: масштабируются, мало весят, можно редактировать в Фигме. Одни плюсы.
  3. Согласованные иконки добавляют красоты и помогают передать комплексный смысл без слов.

Как ставить задачи UX-писателю (диплом 6/6)

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

Это шестая, заключительная статья из цикла о моём UX-дипломе. Ссылки на предыдущие части — в конце страницы.

О писателе и его задачах

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

Писатель работает со смыслами: решает, как писать, и помогает определиться, что писать.

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

UX-писатель может помочь:

  • с текстом интерфейса — кнопками, сообщениями, надписями;
  • логикой и проектированием пользовательских сценариев;
  • обучающими материалами — инструкциями, онбордингом и подсказками;
  • типографикой и вёрсткой текста;
  • письмами и пуш-сообщениями;
  • скриптами поддержки и репликами чат-бота.

Всё многообразие случаев можно свести к формуле:

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

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

Памятка по постановке задач

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

Представьте ситуацию. У формы оформления страховки одно сообщение об ошибке на все поля. Разработчики написали технократическую заумь, менеджер просит единую красивую формулировку. Форма собрана из компонентов, менять ничего нельзя, релиз послезавтра. Писатель выдаёт что-то невнятное, все разочарованы.

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

2. Заложите время на анализ. Набрать текст — четверть дела. Чтобы слова работали, писателю нужно разобраться в ситуации и понять, что именно следует сказать. Это может занять больше 5 минут.

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

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

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

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

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

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

Писатель похож на ведьмин котёл: кидаете в него побольше конкретики — получается магия. Кидаете общие фразы — получается вода.

5. Поставьте формальную задачу. Соберите всё в письме, Джире или Трелло. Объясните приоритет и укажите сроки. Добавьте ссылки на макеты, документы и примеры. Если этого не сделать, писатель сначала возьмёт срочные задачи, а потом пойдёт собирать материалы, уточнять контекст и ожидаемый результат.

Менеджер и писатель созвонились и обсудили онбординг. Менеджер ждёт, что писатель сделает задачу к вечеру. Но у писателя ещё пять звонков и свой ритм переключения между изучением материалов и редактированием. Когда писатель освобождает голову для задачи, ему приходится восстанавливать контекст и дело затягивается.

Если вы соберёте всё нужное в одном месте и поставите сроки, писатель сможет спланировать и восстановить контекст в комфортное время, никого не отвлекая.

Пример

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

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

Ставим задачу в письме или таск-трекере:

Тема: Онбординг для главного экрана

Привет! Главной странице личного кабинета жильца нужен онбординг. Напиши, плиз, и предложи визуальное решение, если будут идеи.

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

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

Что хотим: при первом заходе после установки приложения объяснять, что штука в самом верху — это чат с живым человеком, а уже внутри можно позвонить. Следующие по значимости: панель разделов внизу, блок новостей-оповещений и список с кнопками по центру. Но чат — главное.

Сроки: до четверга, 4 марта. Хотим выкатить со следующим релизом с багфиксами, поэтому желательно первый вариант посмотреть к четвергу, чтобы успеть согласовать и закодить.

Всё по задаче

Сторифреймы: miro.com/app/board/o8K_kxzrs1P=/?fbclid=IzAS2JyWuVp2JYDN_4qczjAeBE_WqjGEhupECAhtjbs6t6ML27tloNCEG5xJS

Исследование юзабилити. Там крутые комменты от участников, могут пригодиться: docs.google.com/document/d/1pP2af5Ec2fTyGj9b7jW8DE0E_aVIQlCb_-rHegxX8cc/edit

Макеты главной: www.figma.com/file/l3dNqhytcjCGIKjqSfJJYn/01-Main-Screen

Редполитика: confluence.drakkar.io/pages/viewpage.action?pageId=39321

Кейсы из запросов операторов ТП, про звонки и чат: confluence.drakkar.io/pages/viewpage.action?pageId=21347123

Визуальной частью занимается дизайнер Лёня @lkobiakov. Напиши ему, как приступишь, он в курсе. Его задача прилинкована к твоей.

Будут вопросы по проекту — звони/пиши:

+7 987 654-32-10 / @vfilat

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

Опоссум Ulv Vind

Ссылки

Памятка и пример — часть моей дипломной работы по курсу Нетологии «UX-писатель». Все статьи об учебном проекте:

  1. Задачи и результат
  2. Потребности пользователей
  3. Основы ToV
  4. Интерактивные макеты
  5. UX-исследование
  6. Как ставить задачи UX-писателю — вы находитесь здесь

Учебный проект: UX-исследование (часть 5/6)

Пятая часть цикла о моём UX-дипломе. Рассказываю, как показывал кусок интерфейса живым людям и какие выводы сделал из их отзывов. Будет много умных слов цветных диаграмм :3

Чтобы узнать побольше об учёбе и дипломном проекте, почитайте предыдущие части по ссылкам внизу.

Напомню, о чём диплом. Есть выдуманный холдинг «Яркий», который сам строит дома, продаёт квартиры и управляет коммунальным хозяйством. Для удобства жильцов и автоматизации процессов «Яркий» делает мобильное приложение с личным кабинетом. Диплом о разработке этого приложения: анализе потребностей пользователей, создании прототипа и проверке гипотез.

Предмет исследования

В макетах первой итерации меня смущал дизайн панели с чатом службы поддержки. Она расположена вверху экрана:

Главный экран с первой версией чата

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

Проблема состояла в том, что панель получилась запутанной и я не был уверен, что пользователи правильно поймут её назначение.

Для автора выглядит логично, а что поймёт пользователь — вопрос исследования

Я решил показать главный экран с блоком чата потенциальным пользователям и собрать обратную связь. Для этого я сформулировал вопросы, провёл анонимный опрос и проанализировал результаты.

Подробное описание исследования и выводов в домашней работе № 5.

Исследовательские вопросы

  1. Считывает ли пользователь последовательность из иконки, подписи и индикатора как возможность перейти к чату с поддержкой?
  2. Понимает ли пользователь, что зелёный индикатор рядом со словом «оператор» означает, что оператор поддержки в сети?
  3. Понимает ли пользователь число в правом углу как количество ещё непрочитанных сообщений от оператора?
  4. Ожидает ли пользователь увидеть другие возможности связи на экране чата с оператором?

Методика исследования

Понятность блока с чатом оценивалась анонимным опросом в гугл-формах.

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

Респонденты квалифицировались по возрасту и опыту общения со службами поддержки. В анализе эти данные не участвовали, я собирал их для справки.

Вопросы размещались на отдельных слайдах:

  1. Подводка и квалификационные вопросы о возрасте и опыте.
  2. Целевой вопрос и необязательный комментарий.
  3. Благодарность.
Первый экран с подводкой и квалификационными вопросами
Второй экран с целевым вопросом
Финальный экран с благодарностью за прохождение

Выборка

Я предположил, что, по данным маркетологов компании и опросам общественного мнения, квартиры в «Ярком» чаще всего покупают люди 30—50 лет. Люди постарше уже обеспечены жильём, а моложе — ещё не готовы к ипотеке. Среди покупателей преобладают технические специалисты и энтузиасты цифровых сервисов.

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

Для большей убедительности приведу фрагмент из домашней работы, где всё расписано подробнее:

Расчёт доверительного интервала

Доверительная вероятность — 95 %

Генеральная выборка — больше 100 000 человек

Размер выборки — 30—50

Ожидаемый процент ответов — 70 %

Вероятность взята выше 50 %, поскольку респондент самостоятельно решает перейти по ссылке на форму опроса.

Доверительный интервал — 16,4—12,7

Калькулятор и методика расчёта

Результаты

Опрос собрал 65 ответов. Респонденты — мои друзья и подписчики в социальных сетях, а также их друзья, знакомые и коллеги. Результаты я собрал в гугл-таблицу и перевёл ответы в значения по шкалам.

Таблица с ответами и обработанными результатами

Получилась следующая картина:

Возраст. В выборке преобладают представители ЦА «Яркого» и небольшое количество респондентов моложе 25 и старше 50 лет.

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

Связь опыта и возраста. Пользователи 25—30 лет чаще пользуются мобильными приложениями социальных сетей, сервисов такси и доставки. Пользователи в возрасте 30—50 лет чаще обладают выраженным и начальным опытом.

Общая понятность перевалила за 50 %.

Большинство опрошенных достаточно ясно поняли, что делает блок с чатом.

Совсем не поняли только 4,7 %.

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

Мне стало любопытно, как понимание распределяется по опыту и возрасту.

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

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

Выводы

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

Вот что вышло в финале:

Главный экран приложения

Благодарности

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

Благодаря вам исследование дало результаты, мне зачли домашку, а прототип приложения стал ощутимо лучше :3

Ссылки

Дипломная работа в гугл-документах

Макеты в Фигме, если хотите посмотреть на бардак в слоях

Все статьи об учебном проекте:

  1. Задачи и результат
  2. Потребности пользователей
  3. Основы ToV
  4. Интерактивные макеты
  5. UX-исследование — вы находитесь здесь
  6. Как ставить задачи UX-писателю

Абзац с отступом и иконкой в гугл-доках

Иногда в текст нужно добавить примечание с отступом и иконкой. Это проще всего сделать списком с маркером-эмодзи:

Выделяем текст примечания и делаем его маркированным списком.

Кликаем правой клавишей по маркеру списка и выбираем «Другие маркеры».

В окне «Вставка специальных символов» ищем эмодзи по категориям или в строке поиска по ключевым словам в названии. Например, bulb (лампочка). Кликаем по нужному значку, он становится маркером списка.

Если потребуется второй абзац уже без иконки, отбейте тест вправо кнопкой «Увеличить отступ». По умолчанию он равен отступу списка.

Расстояния до основного текста настраиваются в «Формат → Межстрочный интервал → Настройка интервалов». Посмотрите, какие интервалы у обычного абзаца и добавьте примечанию 2—3 пункта сверху и снизу.


Для справки ещё два способа, но не таких удобных.

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

Точные отступы абзацев и строк настраиваются в «Формат → Выравнивание и отступы», но если вы потом замените значок, всё может немного съехать.

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

Ранее Ctrl + ↓
UX